From xen-devel-bounces@lists.xenproject.org Sun Mar 01 05:05:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 05:05:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243670.1543291 (Exim 4.92) (envelope-from ) id 1vwYzX-0000tu-QZ; Sun, 01 Mar 2026 05:05:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243670.1543291; Sun, 01 Mar 2026 05: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 ) id 1vwYzX-0000ti-L1; Sun, 01 Mar 2026 05:05:19 +0000 Received: by outflank-mailman (input) for mailman id 1243670; Sun, 01 Mar 2026 05:05:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwYzV-0000ta-67 for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 05:05:18 +0000 Received: from out28-170.mail.aliyun.com (out28-170.mail.aliyun.com [115.124.28.170]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 355011fc-152c-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 06:05:08 +0100 (CET) Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.ghnzBIM_1772341500 cluster:ay29) by smtp.aliyun-inc.com; Sun, 01 Mar 2026 13:05:01 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 355011fc-152c-11f1-b164-2bf370ae4941 DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1772341503; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=sdX+g4xfWUksNlVfdbgGXJ5fc68UgBRbz+En866aoYQ=; b=OrxFPWtB1uoOs3ftFfEAAKSQQe0ftc1to0gMiiOzN+bvR6wC+G/uIePYFORNpXNXseYXaT/zs++N3YHFCnMC/5xMvfMDllO/sm81JPby+yH7EKxkTLkKnbZYNls6jU2AlflOWGQZaWBsfPGMtr4/oZVg5/hxB6QgrnZbMAErM7g= From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Juergen Gross , Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , xen-devel@lists.xenproject.org Subject: [PATCH 1/2] x86/PVH: Use boot params to pass RSDP address in start_info page Date: Sun, 1 Mar 2026 13:04:52 +0800 Message-Id: <76675c4d49d3a8f72252076812ef8f22276230c2.1772282441.git.houwenlong.hwl@antgroup.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit After commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available"), the RSDP address can be passed in boot params. Therefore, store the RSDP address in start_info page into boot params in the PVH entry instead of registering a different callback. This removes an absolute reference during the PVH entry and is more standardized. Signed-off-by: Hou Wenlong --- arch/x86/platform/pvh/enlighten.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/arch/x86/platform/pvh/enlighten.c b/arch/x86/platform/pvh/enlighten.c index 2263885d16ba..f2053cbe9b0c 100644 --- a/arch/x86/platform/pvh/enlighten.c +++ b/arch/x86/platform/pvh/enlighten.c @@ -25,11 +25,6 @@ struct hvm_start_info __initdata pvh_start_info; const unsigned int __initconst pvh_start_info_sz = sizeof(pvh_start_info); -static u64 __init pvh_get_root_pointer(void) -{ - return pvh_start_info.rsdp_paddr; -} - /* * Xen guests are able to obtain the memory map from the hypervisor via the * HYPERVISOR_memory_op hypercall. @@ -95,7 +90,7 @@ static void __init init_pvh_bootparams(bool xen_guest) pvh_bootparams.hdr.version = (2 << 8) | 12; pvh_bootparams.hdr.type_of_loader = ((xen_guest ? 0x9 : 0xb) << 4) | 0; - x86_init.acpi.get_root_pointer = pvh_get_root_pointer; + pvh_bootparams.acpi_rsdp_addr = pvh_start_info.rsdp_paddr; } /* -- 2.31.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 01 08:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 08:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243703.1543307 (Exim 4.92) (envelope-from ) id 1vwcJ9-0000tu-SH; Sun, 01 Mar 2026 08:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243703.1543307; Sun, 01 Mar 2026 08:37:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcJ9-0000tm-Na; Sun, 01 Mar 2026 08:37:47 +0000 Received: by outflank-mailman (input) for mailman id 1243703; Sun, 01 Mar 2026 08:36:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcHe-0000nw-9N for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 08:36:14 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b09d3183-1549-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 09:36:07 +0100 (CET) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6212HKN61732630 for ; Sun, 1 Mar 2026 08:36:06 GMT Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksf6jcqj-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 08:36:05 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-c70f19f0f37so1923129a12.0 for ; Sun, 01 Mar 2026 00:36:05 -0800 (PST) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa82dd09sm9177300a12.28.2026.03.01.00.35.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 00:36:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b09d3183-1549-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=qcppdkim1; bh=h/J87S3x56AlWUvhsWA468 cx/T1N6JOg3YVREGRvJqA=; b=Soibzn4N/ZkM5J3qoqIornB47kjVSoW4OSYFdA JxHI+jCEFG5AvcKA6uqJnh2JesMWopy+nx3HDqBpTUvNGDuFejcPfcLe9Wzv31dL lZmPlWfTua+C1ln4pDhPH3wO0uF/KAKlbaurOU0Lyvb/HT3LlRYDU5RicRjeIINR QpXTC9yyk0HMnRkljCIyNpxDx3575VsDL+yiy4jgj2xHmPPD5HbYk9UXvz0mnraL sorBjyjDTyJXLHZLUZX9b2mC5nbJ0Wy1mT6ghkzAsD2FR+BQU64qTD44WcqMK0f9 o5vQEB9V06sSulMdm2F48Z6RTI7ze1Qmdf4VUiOntKatRtgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772354165; x=1772958965; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=h/J87S3x56AlWUvhsWA468cx/T1N6JOg3YVREGRvJqA=; b=F4VZ85rA7fmi9WGqjNz1ccAfUAcZWrC9ni7s6cRAVejT1OSWmKj0Ooc/OwdCmQu2g9 9yvz12LRB7VSSu2ft/sx0UD2jJ01Grbiq59w9T0wWtMtW/kL3gYxFUt1ZXlBfHN+0nLR LFJ9GqRbAmT3MSj0O0zmK4SS/Y48rpL33rzAa5SGK6Duv2lCLPKWoJMsiYug3q6MqKh7 k874+hzsLllyOj899AkRG2VCBc6MpXbvsFvLO0b3hU4GZlvMCBFVYbOdHmoE618RgxeU FlxKh+ve0JH7+YIZSAaEfEWq1qsdXseI8EsCbwc0IMMVfLU99CnyqCvpSqW8Y1FoXNrw ok9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772354165; x=1772958965; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h/J87S3x56AlWUvhsWA468cx/T1N6JOg3YVREGRvJqA=; b=NjJ3U2xUvTJQO3svDjSIftyXuTNv2qEuhZcpiZrxQ6GJrnWbedetaiUeapY+Rvyl+w LK3TYabscE5an/ai75JdPXbghF+nCJDrZpGMTQq2/pibQh3MLDFauTu1rIf1KzQPmpCt Yrsq4RucpmplbZJBfiCu4lJ/FI/ET87uGU+c5XMtZyNikkC4jQ1oXQXAat2x9FkuFlbA dYEPLwItqxVJm8QBTY7/tyI6ezCjR+2J222EsVruWMNqPGoc20L3xRL80cXb/lYe+L3T sWpfLOeZr2Tn6RsMOTtShSnrP4mZ2mXOAStUQPgmf0xYQ3A4U+Dwo849DsvpxYBQTC2A jf1Q== X-Forwarded-Encrypted: i=1; AJvYcCUPXez4GCPPPG/Tc92DpodlOoKm/sa03R5Z+TlPDqr3D8OhQGC0h+knxZoHQjOYqlUMuVRnZFtSNb4=@lists.xenproject.org X-Gm-Message-State: AOJu0YyMrsuu2juaqP8B8qw4K0XbZKpItTahCsnoSZH/aoN7BfreWpSF RsamAK6ElijoIgWZKOXhoETyfGdo3zXgG0kkxSyFQhGvHzQqm3tQxZbFXOfh5aKrkeSmXjCrVCB 7FSFd4mz+2QJSS866Ww4yMh1vqr0eeBx7frcfxAmeJVHv6NVKNEoJGl4fx0IPS0AXeXRt5A== X-Gm-Gg: ATEYQzxDb/ikAbAqPuYdZ6EQ8xMJamHHLMBNX9gTNjtIKP+GK+x3J06IZTuR2Mqe3cX aYfGkQkDr6FBBO46O8cQBjRXIxElrIVaWl3Gs62xaiukTMFsTzb1pPadzts4L28/yk4IQpTSjDB YpdVISdM065vFpPvvUPPgwGokCFrTTIfkYhvR6BdqofgYLgm6LEIVG8GmMRbLMiFtn/cwcyqkeo mj1zG28CERnfFGG8nBqsZOSRFXSuNUNn2AJgsxn79xCflRwg2Py6nojhQF0aPa5yF3tOPznFqZW i5TvBo7bSST1I6lY7OGr6dwW6d71c7Ju6ojbw0xxzbLsEfGYVSU/RPtGxE5TojwQlHH5HSc2qqf yu2dAdsNY6yoJ6y5b7iGan1pw5SHMnS522qWCzCIrrVH1q3SlLbP0DC8F X-Received: by 2002:a05:6a00:1d14:b0:823:1444:7873 with SMTP id d2e1a72fcca58-827398630afmr9488137b3a.32.1772354164639; Sun, 01 Mar 2026 00:36:04 -0800 (PST) X-Received: by 2002:a05:6a00:1d14:b0:823:1444:7873 with SMTP id d2e1a72fcca58-827398630afmr9488110b3a.32.1772354164035; Sun, 01 Mar 2026 00:36:04 -0800 (PST) From: Vijayanand Jitta Subject: [PATCH v9 0/3] of: parsing of multi #{iommu,msi}-cells in maps Date: Sun, 01 Mar 2026 14:04:18 +0530 Message-Id: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIAAr6o2kC/x3MTQqAIBBA4avErBM0ob+rRIjZVANq4VAE0d2Tl t/ivQcYEyFDXzyQ8CKmPWZ0ZQFus3FFQXM2VLKqpZZKHDYxGtpDOI1D71kop3VTtxanyULujoQ L3f9zGN/3A61zjrxjAAAA To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, Vijayanand Jitta , linux-arm-msm@vger.kernel.org, Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772354153; l=4172; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=H6nPK0TK5n+SrUMyTi0tJArgcayT5+iAOxNLWT6jD+I=; b=0138PH3DyBpH6CTf5Gshrd2F5CdUzVc0F0MxX4wX0mhvTjGvGhC4k9OE5ekOV5Mibl6bnxqrt Gf0jdcWnaG7Anf+I2c3nVSolMIhssmbuOeaTts0urN2JZSagf5VqNQT X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-ORIG-GUID: nC_k3CF1wKFDaDdcuCNCuxK_XTihnHsl X-Authority-Analysis: v=2.4 cv=JoL8bc4C c=1 sm=1 tr=0 ts=69a3fa75 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=VwQbUJbxAAAA:8 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=NEAV23lmAAAA:8 a=hUMMoPFcHhpVZiwYRzIA:9 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA3NiBTYWx0ZWRfX4DRfWh8eFQGq qf/ONY1xYk9oZK3EdbvgJ8IplpOSpLyOsb8ka2msMNBZ3hAS7wV0f0d9QGb+XrI9A1R2zMEs0UZ EY/zz34HfzwyVA/yiu0SRVrApIAlY9J2scsUPWXNz9GSRjU7iHfa/R08E2fv5KVsdsCSiOokGtZ wzAlCeEyETCHaLtU5YSUUHA1QN7g+L3ozN7NuhfdbDlMEIFzmtmzwA5BPhCPCrAb7en3PCGY7of UyKsHlOG9IUotxYX4sC7rS94x+1vdgtrjvBGZsibDlc0273qxPFoUNejmV9laS4Iend1WY1kpvC TLvcsND3m6VPXfh4QCRLh0ow5NPxY6sxsjLlWOjL2wKum3ixP22odrQPCRwGeVlWbZT22+3SNRI +pNJmCJXJp3edb4aRnXqn50nsl5ORQgVhKPOenx7VUz8SDSQJJr3vAGNiVetbJKKplIWz5JCJnn OpjoYaPmmiooP9igLjQ== X-Proofpoint-GUID: nC_k3CF1wKFDaDdcuCNCuxK_XTihnHsl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 adultscore=0 bulkscore=0 clxscore=1011 impostorscore=0 spamscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010076 So far our parsing of {iommu,msi}-map properites has always blindly assumed that the output specifiers will always have exactly 1 cell. This typically does happen to be the case, but is not actually enforced (and the PCI msi-map binding even explicitly states support for 0 or 1 cells) - as a result we've now ended up with dodgy DTs out in the field which depend on this behaviour to map a 1-cell specifier for a 2-cell provider, despite that being bogus per the bindings themselves. Since there is some potential use[1] in being able to map at least single input IDs to multi-cell output specifiers (and properly support 0-cell outputs as well), add support for properly parsing and using the target nodes' #cells values, albeit with the unfortunate complication of still having to work around expectations of the old behaviour too. -- Robin. Unlike single #{}-cell, it is complex to establish a linear relation between input 'id' and output specifier for multi-cell properties, thus it is always expected that len never going to be > 1. These changes have been tested on QEMU for the arm64 architecture. [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/ V9: - Updated TO/CC list based on feedback to include all relevant maintainers. - No functional changes to the patches themselves. Link to V8: https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/ V8: - Removed mentions of of_map_args from commit message to match code. Link to V7: https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/ V7: - Removed of_map_id_args structure and replaced it with of_phandle_args as suggested by Dmitry. Link to V6: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/ V6: - Fixed build error reported by kernel test bot. Link to V5: https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/ V5: - Fixed Build Warnings. - Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184 Link to V4: https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/ V4: - Added Reviewed-by tag. - Resolved warnings reported by kernel test bot, minor code reorganization. Link to V3: https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/ V3: - Added Reviewed-by tag. - Updated of_map_id_args struct as a wrapper to of_phandle_args and added comment description as suggested by Rob Herring. Link to V2: https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/ V2: - Incorporated the patches from Robin that does the clean implementation. - Dropped the patches the were adding multi-map support from this series as suggested. V1: https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ RFC: https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r Signed-off-by: Vijayanand Jitta --- Charan Teja Kalla (1): of: factor arguments passed to of_map_id() into a struct Robin Murphy (2): of: Add convenience wrappers for of_map_id() of: Respect #{iommu,msi}-cells in maps drivers/cdx/cdx_msi.c | 3 +- drivers/iommu/of_iommu.c | 6 +- drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- drivers/of/base.c | 148 ++++++++++++++++++++++--------- drivers/of/irq.c | 3 +- drivers/pci/controller/dwc/pci-imx6.c | 12 ++- drivers/pci/controller/pcie-apple.c | 5 +- drivers/xen/grant-dma-ops.c | 3 +- include/linux/of.h | 33 +++++-- 9 files changed, 152 insertions(+), 63 deletions(-) --- base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31 change-id: 20260301-parse_iommu_cells-1c33768aebba Best regards, -- Vijayanand Jitta From xen-devel-bounces@lists.xenproject.org Sun Mar 01 08:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 08:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243707.1543322 (Exim 4.92) (envelope-from ) id 1vwcJA-00017u-Ih; Sun, 01 Mar 2026 08:37:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243707.1543322; Sun, 01 Mar 2026 08: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 ) id 1vwcJA-00014K-8w; Sun, 01 Mar 2026 08:37:48 +0000 Received: by outflank-mailman (input) for mailman id 1243707; Sun, 01 Mar 2026 08:36:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcHv-0000nw-9A for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 08:36:31 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bda8582b-1549-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 09:36:29 +0100 (CET) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6214Ea3A3978903 for ; Sun, 1 Mar 2026 08:36:28 GMT Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ckshktbv4-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 08:36:27 +0000 (GMT) Received: by mail-pg1-f199.google.com with SMTP id 41be03b00d2f7-b630753cc38so18467743a12.1 for ; Sun, 01 Mar 2026 00:36:27 -0800 (PST) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa82dd09sm9177300a12.28.2026.03.01.00.36.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 00:36:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bda8582b-1549-11f1-9ccf-f158ae23cfc8 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= JWC4EWZ3YtPp4HbcYOknKtzY08XiWmMw2Q79Uzh+F0E=; b=WPZzCqUyGxdnLn2y pdgl6gf2J0urmQmnaJ/KOhuTlNLijdzlWjYEXvefXkcYImP7A9IEOnDlJgmDZ5vc yrqJnITXucUqL0TJZxVarZyKZBt/E7hQEi79M1bc9IAsRHhBGB+QUKuvXaJPdqvR l4ghcOtQUy6P88fH0JbkRNM1C1Taqr82HdyX/YnPo+C+hQTxrcceQqcXp16Owyjf xPIDTgjnEwBubkLLyqwxP+sH0M1Pq+RMJ/TdLSAJP5xVJT+LCdVB40myHCln8MJh A15mlyNS7NccWEFHCTMbVb/1DJhvhjvP0JyIE2KI7LUAGFJ8Zrjlnz2JezK+PoUc QEkgOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772354187; x=1772958987; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=JWC4EWZ3YtPp4HbcYOknKtzY08XiWmMw2Q79Uzh+F0E=; b=Y0/tJur/kXgm1xVEM3i0X1hpjpIKJZTt0LtmRVKeqva5RSTi3mlZ/dtt4mVbPP/COO 5AVKOORDNV39UsObL3ZvLtDp6ms8YBsSMCZaf5w4+xhwr6TNH6dok2SqmltLgTciBqxH 3OZ1K4NbLJFeaWb15JauMzZXFEFhLSQDxR3Lfm5rfgJmA0Rkv6zshJIbvr2tzJbC4+TM IzPIZSTWbK0QUwoSt4BvcQg5p1w2lXMOiX24g94sB82E18eC/1w0YBRpqTbwc++Mcs0h 61dccNjtN8F0NydZu3fiKfUROSg85NwF3PmDMiJtGeWt/dYzVCIpVMW2CBAd1dHTmriS 8Ckw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772354187; x=1772958987; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=JWC4EWZ3YtPp4HbcYOknKtzY08XiWmMw2Q79Uzh+F0E=; b=tXP6INAOU4XIdKHea2/TAnId2IUHgLFGVNVOgREIaaoNCkzCrr7sfGXOJ6vaB7ZxEw JtIan5p1c0X9SSKZVNAFOeDILwCtjMxxtftE+yABy45i8VeU7oHdtEW+fXhmCraD01mQ xndgAs8BigNXamU/88OcDMV/vI0Nvydhdzr7xylnQviw2SvKUTYoBOcQHSrkVi/4TttR kT3A/MnVKoQhusW+YuSwA8SomEbwut3XuCwVrX40Qtmg6xuPTTd0TfdNueogKvATlChI T/Rq2sc+600lFX2EuMCdfh2iWXGMG+0TfdRGItDefsHMR65Azf2ceFHNbqxbYr2ZzMtz bDuw== X-Forwarded-Encrypted: i=1; AJvYcCVENAoF5TtPiEAMdi3eufCk+pzew+3werCGlSxT3XIC8Vm5bsMbbpSkmowu/PAz/UVAhJDqCltsflY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxslB5ZVVIbzp/3TA4JGUi+zKYmeUmGXVSOiyrrxUdibhft0XjQ novjHK+8wQv9ZmAETEvC7LXkPAk9NP3c6mtNWvJZWxla/0ma+7rInaIobk++UYohLTBAohGdndk MNjnzw3hTpVB8FUeo7wNWzFDS7IpB3avCtpmW9Lp4ZS85jjYQiVkwRe6S3/MlfeIL1xIWug== X-Gm-Gg: ATEYQzxogJBWS1cDZzH1TXRDh9KOR1t/v2tclhpfW7sU9fTreIhTMuBQr4YDd7J8E/B 4WfbGH6LR2RVudHLI7oFDtkp1dPKbVyD4eAk9QxQWW1hf3F+PlbrPt193TdB6okU96WBPxNV+fq GDsnGj7/FVCbb7oStRsuCt1T10lhGAQ3ktAqonboX5Mh8kok1ysRxbEKQMTuPBWu1z8UQW6wejD +zYAd+Remq3dxZ8j/LxTB3SG0ch1jnNvlipZ+JJEYorjnSF6NfX3oiOqiEkVsSbrfxlVdgkZmPP C5oIKe6HBLQ3P0myNDFI2mrXD+P4uC/r3tMNd9KJ8TOIHRAI7pIDrsUKWDcCF0iimf8UvGbLszq v6x3WdV42njqfqNnoHX4hydSE3rOmuKT3bQrLE9bJ0vbI9gsGDxiMnxyo X-Received: by 2002:a05:6a21:610e:b0:38e:9e81:d403 with SMTP id adf61e73a8af0-395c3a1b597mr8708792637.13.1772354186649; Sun, 01 Mar 2026 00:36:26 -0800 (PST) X-Received: by 2002:a05:6a21:610e:b0:38e:9e81:d403 with SMTP id adf61e73a8af0-395c3a1b597mr8708760637.13.1772354186052; Sun, 01 Mar 2026 00:36:26 -0800 (PST) From: Vijayanand Jitta Date: Sun, 01 Mar 2026 14:04:20 +0530 Subject: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> In-Reply-To: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, Vijayanand Jitta , linux-arm-msm@vger.kernel.org, Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772354153; l=8142; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=r2qfSqiqIjEbj4wTPrMkzeKvLvtgLnSihSwqEGZhuYg=; b=r/dhHroymMbLBDFlYf1GFDusEMnB4gD+ozyYy/V79x+uvbreXh9f3EYvZPK8M1Yk14K7fnxjU EevL6+OwaOGAPeTwTrmt9IjrFVaa9IWd9FQFUl0AWbT8tn7Gmzj0smi X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA3NiBTYWx0ZWRfX9qJspae3QzIX 83WtFJ111fV3dZM2yP4ReBnD/CsTCrStOSx2vfWL6vg7Lyb9B3IPgNsQ5MtLxZRMEVKmPd5+EVz HepboVDXr2s7xUmcmZToKfB1ruZQ929vOIFXrJ7QxwyYUqt5rhc81zyRbq2WPQsArclEAyvzgcD TMll3Ewsm+1nMdP0QPxQnh8jCztmlfN4mxVKdHgvVWkWhyjQhBkrQdcFlw48ciDwSZoxAbV/wiO Uga/DSC15kAm6IWAHAOCoFiilLBIkMZ1cO2eVsBE2ODvk1N8+ZU3+wvrfieTGlY45ZYyerIspzA KWaR154XSrBAzmMQrBjB+GIFTpTlhijI3LMEUocpLnnOH/ZlOzWRksUaQJv8nC7N6Lrhdo8KNtC GKG8PMTdG88yHjVruVIkbdfEqtuMltwlaNaRCGdst39NSMQMxkBCWR3ONV+UH9A+SPPJmpfCbJG FVWIbjARVe+vdAQXb+w== X-Proofpoint-ORIG-GUID: -2QVLZLOOf3_RztYv_oeuvJYyNrglmHR X-Authority-Analysis: v=2.4 cv=EvbfbCcA c=1 sm=1 tr=0 ts=69a3fa8b cx=c_pps a=Oh5Dbbf/trHjhBongsHeRQ==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=I3pr03k2-ahTGQre_g8A:9 a=QEXdDO2ut3YA:10 a=_Vgx9l1VpLgwpw_dHYaR:22 X-Proofpoint-GUID: -2QVLZLOOf3_RztYv_oeuvJYyNrglmHR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 adultscore=0 impostorscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010076 From: Charan Teja Kalla Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Subsequent patch will make use of the args_count field in struct of_phandle_args. Suggested-by: Rob Herring (Arm) Signed-off-by: Charan Teja Kalla Signed-off-by: Vijayanand Jitta --- drivers/iommu/of_iommu.c | 2 +- drivers/of/base.c | 37 +++++++++++++++++------------------ drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- drivers/pci/controller/pcie-apple.c | 4 +++- drivers/xen/grant-dma-ops.c | 2 +- include/linux/of.h | 21 +++++++++++++------- 6 files changed, 44 insertions(+), 30 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index a511ecf21fcd..d255d0f58e8c 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); + err = of_map_iommu_id(master_np, *id, &iommu_spec); if (err) return err; diff --git a/drivers/of/base.c b/drivers/of/base.c index 57420806c1a2..6c3628255908 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -2102,8 +2102,11 @@ int of_find_last_cache_level(unsigned int cpu) * @id: device ID to map. * @map_name: property name of the map to use. * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. + * @arg: of_phandle_args structure, + * which includes: + * np: pointer to the target device node + * args_count: number of arguments + * args[]: array to receive the translated ID(s). * * Given a device ID, look up the appropriate implementation-defined * platform ID and/or the target device which receives transactions on that @@ -2117,21 +2120,21 @@ int of_find_last_cache_level(unsigned int cpu) */ int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { u32 map_mask, masked_id; int map_len; const __be32 *map = NULL; - if (!np || !map_name || (!target && !id_out)) + if (!np || !map_name || !arg) return -EINVAL; map = of_get_property(np, map_name, &map_len); if (!map) { - if (target) + if (arg->np) return -ENODEV; /* Otherwise, no map implies no translation */ - *id_out = id; + arg->args[0] = id; return 0; } @@ -2173,18 +2176,15 @@ int of_map_id(const struct device_node *np, u32 id, if (!phandle_node) return -ENODEV; - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; + if (arg->np) + of_node_put(phandle_node); + else + arg->np = phandle_node; - if (*target != phandle_node) - continue; - } + if (arg->np != phandle_node) + continue; - if (id_out) - *id_out = masked_id - id_base + out_base; + arg->args[0] = masked_id - id_base + out_base; pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", np, map_name, map_mask, id_base, out_base, @@ -2193,11 +2193,10 @@ int of_map_id(const struct device_node *np, u32 id, } pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, - id, target && *target ? *target : NULL); + id, arg->np ? arg->np : NULL); /* Bypasses translation */ - if (id_out) - *id_out = id; + arg->args[0] = id; return 0; } EXPORT_SYMBOL_GPL(of_map_id); diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index bff8289f804a..74fc603b3f84 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -1139,12 +1139,18 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) { struct device *dev = imx_pcie->pci->dev; struct device_node *target; + struct of_phandle_args iommu_spec = { .args_count = 1 }; u32 sid_i, sid_m; int err_i, err_m; u32 sid = 0; target = NULL; - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); + if (!err_i) { + target = iommu_spec.np; + sid_i = iommu_spec.args[0]; + } + if (target) { of_node_put(target); } else { diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c index a0937b7b3c4d..e1d4b37d200d 100644 --- a/drivers/pci/controller/pcie-apple.c +++ b/drivers/pci/controller/pcie-apple.c @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d { u32 sid, rid = pci_dev_id(pdev); struct apple_pcie_port *port; + struct of_phandle_args iommu_spec = { .args_count = 1 }; int idx, err; port = apple_pcie_get_port(pdev); @@ -764,10 +765,11 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d dev_dbg(&pdev->dev, "added to bus %s, index %d\n", pci_name(pdev->bus->self), port->idx); - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); if (err) return err; + sid = iommu_spec.args[0]; mutex_lock(&port->pcie->lock); idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0); diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c index 1b7696b2d762..5f1d6540049a 100644 --- a/drivers/xen/grant-dma-ops.c +++ b/drivers/xen/grant-dma-ops.c @@ -325,7 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, struct pci_dev *pdev = to_pci_dev(dev); u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); - if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { + if (of_map_iommu_id(np, rid, &iommu_spec)) { dev_dbg(dev, "Cannot translate ID\n"); return -ESRCH; } diff --git a/include/linux/of.h b/include/linux/of.h index 824649867810..9d72d76f909d 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -463,7 +463,7 @@ bool of_console_check(const struct device_node *dn, char *name, int index); int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); + struct of_phandle_args *arg); phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); @@ -929,7 +929,7 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag static inline int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { return -EINVAL; } @@ -1458,17 +1458,24 @@ static inline int of_property_read_s32(const struct device_node *np, } static inline int of_map_iommu_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { - return of_map_id(np, id, "iommu-map", "iommu-map-mask", - target, id_out); + return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); } static inline int of_map_msi_id(const struct device_node *np, u32 id, struct device_node **target, u32 *id_out) { - return of_map_id(np, id, "msi-map", "msi-map-mask", - target, id_out); + struct of_phandle_args msi_spec = { .np = *target, .args_count = 1 }; + int ret; + + ret = of_map_id(np, id, "msi-map", "msi-map-mask", &msi_spec); + if (!ret) { + *target = msi_spec.np; + *id_out = msi_spec.args[0]; + } + + return ret; } #define of_for_each_phandle(it, err, np, ln, cn, cc) \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 01 08:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 08:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243637.1543302 (Exim 4.92) (envelope-from ) id 1vwcJ9-0000qk-Jr; Sun, 01 Mar 2026 08:37:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243637.1543302; Sun, 01 Mar 2026 08:37:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcJ9-0000qd-Fq; Sun, 01 Mar 2026 08:37:47 +0000 Received: by outflank-mailman (input) for mailman id 1243637; Sun, 01 Mar 2026 00:38:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwUpl-0005e6-4G for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 00:38:57 +0000 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [2607:f8b0:4864:20::829]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 06e01d70-1507-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 01:38:55 +0100 (CET) Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-5069ad750b7so28839321cf.2 for ; Sat, 28 Feb 2026 16:38:55 -0800 (PST) Received: from instance-20260207-1316.vcn12250046.oraclevcn.com ([150.136.248.187]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-507451cda23sm82758741cf.18.2026.02.28.16.38.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Feb 2026 16:38:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 06e01d70-1507-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772325534; x=1772930334; 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; bh=8GnZ6scY9RatwDOdF0bnkSG216StlRqp+YcA3P3cM/E=; b=cud8h2MIiL85D3gkQgS4kA0uBidWAwcpccqfgZwBMPzUW9OGUZpOMTSP5sxSY7Vn8f mL0ROhtCqWE3vrFOlzHIRgSCO0gU5fWx6WFdmPvlcZGvRe9l3Jk3hG1ymv0Mpk/xYLM6 jE1u9z/27PS8vXQB5wcztcI1GzCzIqI6T8EcGOo9Ym9f3hi9XPmpN5eJTpJI9q0UNApa 3tRN1rG6SU911YT+rCN1BsISyBYqpc0L5c807xTq/3TwrSvhk7vdWUbvpaqkXr/rah9B M+ta+lUQa3XCbqzr1vRCwOxDJXNFCqFQG3cFp+F67y4+MYnUWBipMfinEzTGea7GoZfV Wnfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772325534; x=1772930334; 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; bh=8GnZ6scY9RatwDOdF0bnkSG216StlRqp+YcA3P3cM/E=; b=QT+akXLquTiJ2wAWhmQLh7HzANemW0WMkIuv89GvCNZ5OmpmO7WM1Uist8fg9vEL8+ iZooAalETdz4G+fhV4r3oW7OkT4cPGJt3HSjeV2wzNcCa/IDCsSAw5YmisyqYkx3kIK0 ZiKFsAQcSnPWUogk3GldVchDr1YYiE4oMgn0zwWXQWQ5KbSsaKhOBhBf8vClMlCnCuPF wfcYFaShTRU9MGOlixLSgArjJVoaVkqeO812d6kdPtGEfGStLfA6nNH+DyN/n1O17+jG lglH1GV34PJHh0vPMAP+5dLH5528guB0aC+IwkOVzodZSHL5vHRHnE4qDpq1o6Ae00Tr OHaA== X-Gm-Message-State: AOJu0Yw4884BXrbp/e7lWZAM2bAHrukWARmatYgVR+XHO9bxRcrP0hWE ajVz7hlSfqKebgO47rR2/i5kMi+RjatafypwoBDMwo/cEFOtIlTGHAZ2 X-Gm-Gg: ATEYQzwxT/X+e8EaHcqK6DZ0kCSnnOckxZRrc4aS69j5QBtX/DzH0B/60UCai9TyCyj hAsmC+N3tFsFrVux5UUEW1jMVwZbcSUNxC8L1+YW3xKlX0vhIhuw27gGgzkya2SyV2QFibTACC/ FLGpjEd8j8mzYRbUC82qBcKtKESydqyk2gqT9eaA5GKpX9oVxwtUuno4+8yVYlhfuut8AskXssr MUdLvX6P2dozEB6JnnXtKCbbDsrfhm4XA5S3+ln+NWYW0qWzKsUquIeaXzMzzWpRybcDIyN+jWP PZHjJGV8Oaf9C3CcIXzqtygQJ59/OFN/dnQ3RETyToaxnn1IFaOh/7obhojw0Qa/g6tD6Nskvdf Fe7ZcKbJALdqEgeheX+bg1vCO38G20Htr0DOboC/AKOooV1YAJuu7j4bNki9C2cHzJMWZyqjf3n zj+58z+ewZYOmCyMn6BiEeBh5gcGJgCz53RdwF4sNQBndmlOQRHG203H+xQ/kWFNSsdHAQEnRhP qvvh9iJgcs/Zww= X-Received: by 2002:ac8:7d41:0:b0:4ee:5fc:43e5 with SMTP id d75a77b69052e-50752714416mr109988071cf.12.1772325534323; Sat, 28 Feb 2026 16:38:54 -0800 (PST) From: Josh Law X-Google-Original-From: Josh Law To: Stefano Stabellini , Catalin Marinas , Will Deacon Cc: xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Josh Law Subject: [PATCH 1/4] arm64: xen: add missing SPDX-License-Identifier Date: Sun, 1 Mar 2026 00:38:53 +0000 Message-ID: <20260301003853.2504449-1-objecting@objecting.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Signed-off-by: Josh Law --- arch/arm64/xen/hypercall.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/xen/hypercall.S b/arch/arm64/xen/hypercall.S index ae551b857137..19c99e6bab7a 100644 --- a/arch/arm64/xen/hypercall.S +++ b/arch/arm64/xen/hypercall.S @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ /****************************************************************************** * hypercall.S * -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Sun Mar 01 08:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 08:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243709.1543325 (Exim 4.92) (envelope-from ) id 1vwcJA-0001Dm-OP; Sun, 01 Mar 2026 08:37:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243709.1543325; Sun, 01 Mar 2026 08: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 ) id 1vwcJA-0001Bh-KS; Sun, 01 Mar 2026 08:37:48 +0000 Received: by outflank-mailman (input) for mailman id 1243709; Sun, 01 Mar 2026 08:36:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcI7-0000pY-2f for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 08:36:43 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c46778b4-1549-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 09:36:41 +0100 (CET) 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 6217jVT7511531 for ; Sun, 1 Mar 2026 08:36:39 GMT Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksg72bv8-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 08:36:39 +0000 (GMT) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-35983ee9f3bso500102a91.1 for ; Sun, 01 Mar 2026 00:36:38 -0800 (PST) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa82dd09sm9177300a12.28.2026.03.01.00.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 00:36:36 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c46778b4-1549-11f1-b164-2bf370ae4941 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= Mbns5ViOe94sVRFpbuwhgj3c35clcURMMrJnuCno/wA=; b=fTkYFz6CiVqazCX2 HTXagNtEtcQRIN6wvUVsLdCw07hKyjPEewUZRvCwa8dDai/5kVaxSvtL8RKefS+T gQWEc4/o7mm6EGM1OSBic7RRsSrE6yPDZnZOXIG21FB0RUWI4o7S460/jm0zcLqN SPTr19hsIvyM6Dd8+CT9kv8I1NHPPhC/hnmDV8rG34uIDV7vKYv+yl2pIzs3WGDr bvjjEoQ22tDCxT9GWSjMqvRnQ2oFi84m6HLbMMm82jnxb21SDTuSQclkO+aB96a4 JJADZsd994wcfFx2VQb0uneydrRhfFZr7EMD0/wnDmjhxtDew0TMThwOoOCZhRbH CaB1SA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772354198; x=1772958998; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=Mbns5ViOe94sVRFpbuwhgj3c35clcURMMrJnuCno/wA=; b=DpWrap2oC4+fmtY0gqmK4CzpSfRE4gWZqXW5yowfJHBdnm5JpWX1Y5X00guJkVpMn7 qKzXsZRz4MxqNuwu3qbiy48RYb6MjHid9W1ptx4fgNV/hL9Sdx4NBpNBMDMELhvkiGk2 7e4IU6LAhissEVlpokIne0sr+FDHVBNN3dEgDzCATgv7zUbtqNszhjn7nQLhxOMFwgG3 xjLoxPsDSZrWHIsDZ0pYIuefHHUxajnOgAyv+E8AKekH3e6/lDCXRe2F9UvlmSE6wFjC Rq2O69ZJKobUVeXL9aoFz0lHOT+DEKsJL8+2QOqoTGzVfoyhchLnTWIcz/TiTNhbUt5U BDGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772354198; x=1772958998; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Mbns5ViOe94sVRFpbuwhgj3c35clcURMMrJnuCno/wA=; b=ONsIYmGyrmY28nRPL+8jq/gi1cagpWTlusMOp5jSlJQeEOV9YWEz/45L0PHPYIctbN iXKgioSqdxADuKCEQQ7AbUXwayOGzAXodOoywh4x6d7NcZD9Odj3XPEnUaakP9/hsoNf xgv9cUfHVFqbd6WJqkrT3BQ5aPS03MoJ2aO0rJTosd3FCqdaID0q7eJgIs0tGfSgNsaL YnyN+0lADKGMuJV/m5YVE6ZDS+drgSoF36TQETc0bNul0v/848NvouzxVswuUeRSHn3E 83P6V4v8RTKbg+TufV8fBcvpukKnh+InKmQstHxVv9XnXR12St0ze+yDKgEN+4yI8M0R /+iA== X-Forwarded-Encrypted: i=1; AJvYcCUvMVFQK0efLBEwauutG/FNPybkJIFQGQi5pNvZJpK42SLW/6tVdqSmH4NXZHw6V4IXchX4F89WVeY=@lists.xenproject.org X-Gm-Message-State: AOJu0YwyL4489oTLFPSf1B6FpJp4nIKF00VlQX6dgVGRD/XznPvgMA2y Ud62mFg1IgbDCUzFy7mJ0SPFbuBaV52ybphaMgbKYlYnzeGu9wJNeCrKaz0E/WKrhLD3KMx6TRb SgfIawQNAOxMAoRWMRPmlMR/GYoQNK2HJmWlUAeT+w32mWgcAxp91q0kfdPCiS9Dgwfl5UQ== X-Gm-Gg: ATEYQzxNy2KFjKqI/w1gIHg9u+1T+1vWR5gHwekZUlAwskxBAA8yWh3OR6D+m8Zbcqc 1AC49xtDXnYVzQGaNi7gQzDsONlRqqCpSNLcu/bYpKjfVXuk6fBL+4zJZqucleVAGT8h4n9q8GO qbKS4oD1Blae3Ibt+p5qiet2PnE6Ui7I2YzGYSJ1aoSRRJlsKJ7fJjpS51VEL+O28TJ+FU8SJ/N y08uAYc8XE/hKuC7fjXqdpcAefI554EMon4SFp30WKNcMGAPyETlfUNq3EC8YNCAL8NuzPUMouZ Pb5WvIJgoxb6gUCM2WVc5t2SaPtmZS2VYeyflvxjL9oKrL+tnwGMdizbjalwcfQhrFz127EHU4d AnLPNFjtXr7OgnbnL2FskPEoD0tBh3StUMfWW9O1/beeABFMJucaR5MEg X-Received: by 2002:a17:90a:fc4d:b0:359:1cbd:5495 with SMTP id 98e67ed59e1d1-35965c27e66mr7272877a91.6.1772354197990; Sun, 01 Mar 2026 00:36:37 -0800 (PST) X-Received: by 2002:a17:90a:fc4d:b0:359:1cbd:5495 with SMTP id 98e67ed59e1d1-35965c27e66mr7272861a91.6.1772354197416; Sun, 01 Mar 2026 00:36:37 -0800 (PST) From: Vijayanand Jitta Date: Sun, 01 Mar 2026 14:04:21 +0530 Subject: [PATCH v9 3/3] of: Respect #{iommu,msi}-cells in maps MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260301-parse_iommu_cells-v9-3-4d1bceecc5e1@oss.qualcomm.com> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> In-Reply-To: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, Vijayanand Jitta , linux-arm-msm@vger.kernel.org, Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772354153; l=9839; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=rMn0oPM33QyWz+pe9qSYvRaJ0TXg29twIWDnLRGtMmg=; b=2gF3YAzuiCPKTO4QehGinqQzgmCnP6QEz+si20I/lunzZCq8Cuhj6wMkXGjkBYmw7DwgsA73Z YR8Sh/N7qN1BvB2nlbfl7LdbKSKjVZ5LyP7xBrBDdJgMrAY97DdwrpT X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-ORIG-GUID: RyVGWCipcaSHCDEjLqxTz0mRwfTr76V5 X-Proofpoint-GUID: RyVGWCipcaSHCDEjLqxTz0mRwfTr76V5 X-Authority-Analysis: v=2.4 cv=FaA6BZ+6 c=1 sm=1 tr=0 ts=69a3fa97 cx=c_pps a=vVfyC5vLCtgYJKYeQD43oA==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=7CQSdrXTAAAA:8 a=EUspDBNiAAAA:8 a=wJGdY9mNwEi-N7fqGJcA:9 a=QEXdDO2ut3YA:10 a=rl5im9kqc5Lf4LNbBjHf:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA3NiBTYWx0ZWRfX5fnSW2XiW5+U Kql5IxXfu1pZAXCHeVyR/bz7TKRSeYhdTuYzPMeO6ugI8JItG0ANdKEx+KhYwuaIwNr20VPlAe3 2Q9R7VhqmhNJyfCP4pF+YwGagz6yaUP5R3miW1b+3spH3mYWJOfhN2HDUBmAz6aHvnFhgQX0giM FGZ0j+8QFnDp37afFtu7qf0fNP/VblIMiE2BQe0dORN9hA4HQszXKWvMtp9LocTDJy0SLS4aThG Gt/HGf2yOWlVsWd51finXkWrlnNqJeWuOREQKd5qM3JH4MXdk8XYqqYJJhneYL2QqgkyeA0ET49 pITnmr6fEIloM2teqxN18Jbf0jSkN9lNX0iJ4mSwOQVz997q71jLV0cp7DURr1bL7dosesEurwb 7iBjRtUzVE9qIyXysFNeS5JBx/jQrCQtm++rq6hGw2jqZIALVPUizuKGSda21P0etUJ6nvdAOun 5850feApPdkcDREFvrg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1011 phishscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010076 From: Robin Murphy So far our parsing of {iommu,msi}-map properites has always blindly assumed that the output specifiers will always have exactly 1 cell. This typically does happen to be the case, but is not actually enforced (and the PCI msi-map binding even explicitly states support for 0 or 1 cells) - as a result we've now ended up with dodgy DTs out in the field which depend on this behaviour to map a 1-cell specifier for a 2-cell provider, despite that being bogus per the bindings themselves. Since there is some potential use in being able to map at least single input IDs to multi-cell output specifiers (and properly support 0-cell outputs as well), add support for properly parsing and using the target nodes' #cells values, albeit with the unfortunate complication of still having to work around expectations of the old behaviour too. Since there are multi-cell output specifiers, the callers of of_map_id() may need to get the exact cell output value for further processing. Added support for that part --charan Signed-off-by: Robin Murphy Signed-off-by: Charan Teja Kalla Signed-off-by: Vijayanand Jitta --- drivers/iommu/of_iommu.c | 2 +- drivers/of/base.c | 117 +++++++++++++++++++++++++++++++++++++---------- include/linux/of.h | 16 +++---- 3 files changed, 102 insertions(+), 33 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index d255d0f58e8c..a18bb60f6f3d 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -45,7 +45,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct device *dev, const u32 *id) { - struct of_phandle_args iommu_spec = { .args_count = 1 }; + struct of_phandle_args iommu_spec = {}; int err; err = of_map_iommu_id(master_np, *id, &iommu_spec); diff --git a/drivers/of/base.c b/drivers/of/base.c index 6c3628255908..596bcf993dcb 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -2096,11 +2096,38 @@ int of_find_last_cache_level(unsigned int cpu) return cache_level; } +/* + * Some DTs have an iommu-map targeting a 2-cell IOMMU node while + * specifying only 1 cell. Fortunately they all consist of value '1' + * as the 2nd cell entry with the same target, so check for that pattern. + * + * Example: + * IOMMU node: + * #iommu-cells = <2>; + * + * Device node: + * iommu-map = <0x0000 &smmu 0x0000 0x1>, + * <0x0100 &smmu 0x0100 0x1>; + */ +static bool of_check_bad_map(const __be32 *map, int len) +{ + __be32 phandle = map[1]; + + if (len % 4) + return false; + for (int i = 0; i < len; i += 4) { + if (map[i + 1] != phandle || map[i + 3] != cpu_to_be32(1)) + return false; + } + return true; +} + /** * of_map_id - Translate an ID through a downstream mapping. * @np: root complex device node. * @id: device ID to map. * @map_name: property name of the map to use. + * @cells_name: property name of target specifier cells. * @map_mask_name: optional property name of the mask to use. * @arg: of_phandle_args structure, * which includes: @@ -2118,18 +2145,19 @@ int of_find_last_cache_level(unsigned int cpu) * * Return: 0 on success or a standard error code on failure. */ -int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, - struct of_phandle_args *arg) +int of_map_id(const struct device_node *np, u32 id, const char *map_name, + const char *cells_name, const char *map_mask_name, + struct of_phandle_args *arg) { u32 map_mask, masked_id; - int map_len; + int map_bytes, map_len, offset = 0; + bool bad_map = false; const __be32 *map = NULL; if (!np || !map_name || !arg) return -EINVAL; - map = of_get_property(np, map_name, &map_len); + map = of_get_property(np, map_name, &map_bytes); if (!map) { if (arg->np) return -ENODEV; @@ -2138,11 +2166,9 @@ int of_map_id(const struct device_node *np, u32 id, return 0; } - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } + if (map_bytes % sizeof(*map)) + goto err_map_len; + map_len = map_bytes / sizeof(*map); /* The default is to select all bits. */ map_mask = 0xffffffff; @@ -2155,27 +2181,63 @@ int of_map_id(const struct device_node *np, u32 id, of_property_read_u32(np, map_mask_name, &map_mask); masked_id = map_mask & id; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + + while (offset < map_len) { struct device_node *phandle_node; - u32 id_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 id_len = be32_to_cpup(map + 3); + u32 id_base, phandle, id_len, id_off, cells = 0; + const __be32 *out_base; + + if (map_len - offset < 2) + goto err_map_len; + + id_base = be32_to_cpup(map + offset); if (id_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n", - np, map_name, map_name, - map_mask, id_base); + pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n", + np, map_name, map_mask_name, map_mask, id_base); return -EFAULT; } - if (masked_id < id_base || masked_id >= id_base + id_len) - continue; - + phandle = be32_to_cpup(map + offset + 1); phandle_node = of_find_node_by_phandle(phandle); if (!phandle_node) return -ENODEV; + if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) { + pr_err("%pOF: missing %s property\n", phandle_node, cells_name); + return -EINVAL; + } + + if (map_len - offset < 3 + cells) + goto err_map_len; + + if (offset == 0 && cells == 2) { + bad_map = of_check_bad_map(map, map_len); + if (bad_map) { + pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n", + np, map_name, cells_name); + cells = 1; + } + } + + out_base = map + offset + 2; + offset += 3 + cells; + + id_len = be32_to_cpup(map + offset - 1); + if (id_len > 1 && cells > 1) { + /* + * With 1 output cell we reasonably assume its value + * has a linear relationship to the input; with more, + * we'd need help from the provider to know what to do. + */ + pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n", + np, map_name, id_len, cells); + return -EINVAL; + } + id_off = masked_id - id_base; + if (masked_id < id_base || id_off >= id_len) + continue; + if (arg->np) of_node_put(phandle_node); else @@ -2184,11 +2246,14 @@ int of_map_id(const struct device_node *np, u32 id, if (arg->np != phandle_node) continue; - arg->args[0] = masked_id - id_base + out_base; + for (int i = 0; i < cells; i++) + arg->args[i] = (id_off + be32_to_cpu(out_base[i])); + + arg->args_count = cells; pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", - np, map_name, map_mask, id_base, out_base, - id_len, id, masked_id - id_base + out_base); + np, map_name, map_mask, id_base, be32_to_cpup(out_base), + id_len, id, id_off + be32_to_cpup(out_base)); return 0; } @@ -2198,5 +2263,9 @@ int of_map_id(const struct device_node *np, u32 id, /* Bypasses translation */ arg->args[0] = id; return 0; + +err_map_len: + pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes); + return -EINVAL; } EXPORT_SYMBOL_GPL(of_map_id); diff --git a/include/linux/of.h b/include/linux/of.h index 9d72d76f909d..5b5b5dc2d3f3 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -461,9 +461,9 @@ const char *of_prop_next_string(const struct property *prop, const char *cur); bool of_console_check(const struct device_node *dn, char *name, int index); -int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, - struct of_phandle_args *arg); +int of_map_id(const struct device_node *np, u32 id, const char *map_name, + const char *cells_name, const char *map_mask_name, + struct of_phandle_args *arg); phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); @@ -927,9 +927,9 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag { } -static inline int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, - struct of_phandle_args *arg) +static inline int of_map_id(const struct device_node *np, u32 id, const char *map_name, + const char *cells_name, const char *map_mask_name, + struct of_phandle_args *arg) { return -EINVAL; } @@ -1460,7 +1460,7 @@ static inline int of_property_read_s32(const struct device_node *np, static inline int of_map_iommu_id(const struct device_node *np, u32 id, struct of_phandle_args *arg) { - return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); + return of_map_id(np, id, "iommu-map", "#iommu-cells", "iommu-map-mask", arg); } static inline int of_map_msi_id(const struct device_node *np, u32 id, @@ -1469,7 +1469,7 @@ static inline int of_map_msi_id(const struct device_node *np, u32 id, struct of_phandle_args msi_spec = { .np = *target, .args_count = 1 }; int ret; - ret = of_map_id(np, id, "msi-map", "msi-map-mask", &msi_spec); + ret = of_map_id(np, id, "msi-map", "#msi-cells", "msi-map-mask", &msi_spec); if (!ret) { *target = msi_spec.np; *id_out = msi_spec.args[0]; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 01 08:37:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 08:37:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243705.1543312 (Exim 4.92) (envelope-from ) id 1vwcJA-0000zB-4T; Sun, 01 Mar 2026 08:37:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243705.1543312; Sun, 01 Mar 2026 08: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 ) id 1vwcJA-0000yn-0Y; Sun, 01 Mar 2026 08:37:48 +0000 Received: by outflank-mailman (input) for mailman id 1243705; Sun, 01 Mar 2026 08:36:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwcHl-0000nw-1f for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 08:36:21 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b6e7c6a2-1549-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 09:36:18 +0100 (CET) Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61SH01KC3052043 for ; Sun, 1 Mar 2026 08:36:16 GMT Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksgrtf77-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 08:36:16 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-3597baf976dso4735197a91.3 for ; Sun, 01 Mar 2026 00:36:15 -0800 (PST) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa82dd09sm9177300a12.28.2026.03.01.00.36.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 00:36:14 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b6e7c6a2-1549-11f1-9ccf-f158ae23cfc8 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= DPGZ2f1FRPz5cKw/lYBC8NifEzRRofLwMqRkmKqE50Y=; b=C7NeJH8K06j+LTBZ 7LR40EB36WJwpFFTzjB9ZDJlkwJWGu6HWZfLkqId4jdSEhuWDuFKcdICoy0ocOiJ A5O+R76J5rU7eK49upDs8N+bAXhwYPO+K+Zu4fDztMUqzEMVc/ItxhxLDrLnEs4I 1Frzbmk+s/Mfva7mpn0o8E4o3de83z4D/Steqx6aMT3tMA1brrCd/6pp+pIgtkjr 6GR90Jt4VwP0f9bkobEW3+SR2iy6xaiZI9vm52ZpeIfFgZnyZVQTB7wh1u2SMpiE /68FnB1FN+LACGaR+iqaWkRegihbEOYZpU/0iSXl1UIC+SQ2pdu1qNRhE66ZlaSu 2S3QHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772354175; x=1772958975; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=DPGZ2f1FRPz5cKw/lYBC8NifEzRRofLwMqRkmKqE50Y=; b=F8NfpKtZKYse0hYZV0b+cWP/HiCo6KtCdioDc2dGCXNDXickYJuOpFLGmDjR6gBwce adVZj2hfk2bL/XAar3HctFLNE3obQ9SrO63JYvteKz3qHEqAK6Rl1I45L3rfNcEwyKuE eFvlJi0lgOnjLQTxwjOwBYlExhWYc2n3EBTl0VXfGUKfIJsCRcjdCby9y0wgvspD7RXP BwiHYWA/M0jU5oKUqT8okxPZIkQpl4ku7ujqUpw1JGsVFK3CTLQQLouqAl+1JoJJ0vEH 8gPaLiwgqClfaJcpJklKySvxHdleFvdH7KxUO1GMKg4PLEuz20nCUamqq4dV0Zn9Lbjg d24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772354175; x=1772958975; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=DPGZ2f1FRPz5cKw/lYBC8NifEzRRofLwMqRkmKqE50Y=; b=Ao04ZDCLfVhMqj8o2T4is0e9vxmtDxcftJC0flJKzTC+FyXwdJcqydodfcRgTbN/pp lxX7fMBFw2l5Wd3IXt0hCUAiSQuWRFnBkuWwc02o1FsJ28SRGTfPYrEasEfiuiLzsawp VuqDSS8Oa+Pr40kisCvoQgcAr1XS/hD+KZPm82TnCTqv/p7WAsUwRIm2jWW6pzeA/gAZ MGpGfVmxRGPRn8fBEuBJYlF/S0mubxaHImy9JzlUfcBxxgqthyLyKbw1TvlskwgW7nqN caXNKfdTPG4MIACf4QRnmAcp4VBToh+NEhPttMg7qtPprYXI5HFEPACKF2cWUO7jG/e3 pnQA== X-Forwarded-Encrypted: i=1; AJvYcCXE/i5fTNUA9hDVGAh1vIKea+p97EZeifmWrmVX4qvo5O6hYXTfPn9eYvd8rRYEJmnQwW2/25r4GZc=@lists.xenproject.org X-Gm-Message-State: AOJu0YzoHfbpZKzJKbu6e3vvVpBRNrr3ujbVZ/krFIG9KP3Wso4NrNPK 4gwFFWOoVi7vAeIoNNXpvoiDWvyYxWrRlLM6aaYYZDjqwJqapg+kgU4jU0NyVTicoiQg2mm7KbX DOytuGc81cxunPx1lxUCM8Wcxv81WuoL5Kydh/LkfuBv/82V9lrjxuCjEgXIFrVILnay27g== X-Gm-Gg: ATEYQzwy3ym8RvdeVwqzWtl3M8ldYaBTHxthiz6b/WF5yTfAN7XXHRCCBhEomfU0OYf pyyj8If2BOGGo7wSoGpMdWqHiOr2xs2X4H9ztUm+yztVheDDdMJXTfUdWV2wRKLSnfkP6UTVlsc NijzgmAo+VMLm+6X91mlEsqje9A9/a+yTNOrLKZNn6qRcoTjuST1LoW9hjqSqD7s3hl7UE8StE4 cXTMxPgj+yZeBhPfqvQiuruE7v7HOAQxVEjymMSMzJu1MqD+sMAqfLSzi3uVUKDIto6sBL6iGXY rKmc/fyGawCXYcGaabUIHKdRDtorvwV9x07Kz8RkhCjRRgGq0/U8dujQFUsL4wPQ83n2BWAhv1A y9K2U7b7WxkXXorlcY/ex5kxxeSzvVK+XSS54Ay1vAewr3lZr4FMcRh/c X-Received: by 2002:a17:90b:3c45:b0:356:3cfd:3ed5 with SMTP id 98e67ed59e1d1-35965ccf206mr7771060a91.18.1772354175275; Sun, 01 Mar 2026 00:36:15 -0800 (PST) X-Received: by 2002:a17:90b:3c45:b0:356:3cfd:3ed5 with SMTP id 98e67ed59e1d1-35965ccf206mr7771004a91.18.1772354174764; Sun, 01 Mar 2026 00:36:14 -0800 (PST) From: Vijayanand Jitta Date: Sun, 01 Mar 2026 14:04:19 +0530 Subject: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> In-Reply-To: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, Vijayanand Jitta , linux-arm-msm@vger.kernel.org X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772354153; l=6405; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=34KJIw1PW/qCZqrDovFnZs5F7MkA8lH3ZSq6PGA9s7o=; b=iPrFA0Mla+rfvrsVCBVpRZ9RWdwdgwTS89Lg21ZBrY5kmaFRHUg823viwJAJk6c1NGz4OkqG0 bmC5iBdpD+FCSrT5S1eAy2UKywWw/UDcFmwwy35h1w6fxW83D7WiEy1 X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA3NiBTYWx0ZWRfXwJirRxuoCnK8 bC/XtLNEZ7a9y8yxuYfdeEQ8ZQjOvHAOUbPL8v4bQWkT8IR5PO/bJt6dvOIb/FyOLj5cBU7Al1p tC9r3OXdPG4Ef6ZexvuAmyjiEtZsbkftz87VOLcv37emAKEQDKs5AbhDeT8i3J5PReQfirbft1A XLxAYOj7vJ6wLJiMq06GF/5RVVw/X2RVUorICX+eckzTQnGUctIOVs3EhK/xO3LCk4lv/0CVv1Y XWoThfRm1bmmjZ0l/grsVbXPL+doGFxYpFg/qSDGHQfS0b1xTm2BLplgVlM+jJ0VMOX2Dm1zDtq vNEbJTTsbd7Kvv5oa0UyMp675QLySb1ztug85XDsIwLQoWIbK1gZL3eRdWUS9oOYibHvWe7yzyj bbMrkdrIYp6LYVnS0fccnyHAHd1q5CYbAa295pRQhoCBzKbfGCP/9qGmtk1E2jx4q9eN5vcQ8b3 NOy8f0I4NQ38sj3xYfg== X-Proofpoint-GUID: DKqK8fsKXMjivrrvPM0JTL54-8fLFN6d X-Proofpoint-ORIG-GUID: DKqK8fsKXMjivrrvPM0JTL54-8fLFN6d X-Authority-Analysis: v=2.4 cv=Zqzg6t7G c=1 sm=1 tr=0 ts=69a3fa80 cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=EUspDBNiAAAA:8 a=wrOk0Nx1w3hKWqktZycA:9 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 lowpriorityscore=0 spamscore=0 priorityscore=1501 phishscore=0 suspectscore=0 impostorscore=0 malwarescore=0 bulkscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010076 From: Robin Murphy Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Reviewed-by: Rob Herring (Arm) Reviewed-by: Frank Li Signed-off-by: Robin Murphy Signed-off-by: Vijayanand Jitta --- drivers/cdx/cdx_msi.c | 3 +-- drivers/iommu/of_iommu.c | 4 +--- drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- drivers/of/irq.c | 3 +-- drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- drivers/pci/controller/pcie-apple.c | 3 +-- drivers/xen/grant-dma-ops.c | 3 +-- include/linux/of.h | 14 ++++++++++++++ 8 files changed, 22 insertions(+), 16 deletions(-) diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c index 91b95422b263..63b3544ec997 100644 --- a/drivers/cdx/cdx_msi.c +++ b/drivers/cdx/cdx_msi.c @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, int ret; /* Retrieve device ID from requestor ID using parent device */ - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", - NULL, &dev_id); + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); if (ret) { dev_err(dev, "of_map_id failed for MSI: %d\n", ret); return ret; diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 6b989a62def2..a511ecf21fcd 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_map_id(master_np, *id, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); if (err) return err; diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c index d36b278ae66c..b63343a227a9 100644 --- a/drivers/irqchip/irq-gic-its-msi-parent.c +++ b/drivers/irqchip/irq-gic-its-msi-parent.c @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u struct device_node *msi_ctrl __free(device_node) = NULL; - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); } static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 6367c67732d2..e37c1b3f8736 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) * "msi-map" or an "msi-parent" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", - "msi-map-mask", msi_np, &id_out)) + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) break; if (!of_check_msi_parent(parent_dev->of_node, msi_np)) break; diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index a5b8d0b71677..bff8289f804a 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) u32 sid = 0; target = NULL; - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", - &target, &sid_i); + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); if (target) { of_node_put(target); } else { @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) } target = NULL; - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", - &target, &sid_m); + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); /* * err_m target diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c index 2d92fc79f6dd..a0937b7b3c4d 100644 --- a/drivers/pci/controller/pcie-apple.c +++ b/drivers/pci/controller/pcie-apple.c @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d dev_dbg(&pdev->dev, "added to bus %s, index %d\n", pci_name(pdev->bus->self), port->idx); - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", - "iommu-map-mask", NULL, &sid); + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); if (err) return err; diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c index c2603e700178..1b7696b2d762 100644 --- a/drivers/xen/grant-dma-ops.c +++ b/drivers/xen/grant-dma-ops.c @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, struct pci_dev *pdev = to_pci_dev(dev); u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, - iommu_spec.args)) { + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { dev_dbg(dev, "Cannot translate ID\n"); return -ESRCH; } diff --git a/include/linux/of.h b/include/linux/of.h index be6ec4916adf..824649867810 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, return of_property_read_u32(np, propname, (u32*) out_value); } +static inline int of_map_iommu_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return of_map_id(np, id, "iommu-map", "iommu-map-mask", + target, id_out); +} + +static inline int of_map_msi_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return of_map_id(np, id, "msi-map", "msi-map-mask", + target, id_out); +} + #define of_for_each_phandle(it, err, np, ln, cn, cc) \ for (of_phandle_iterator_init((it), (np), (ln), (cn), (cc)), \ err = of_phandle_iterator_next(it); \ -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 01 09:47:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 09:47:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243764.1543351 (Exim 4.92) (envelope-from ) id 1vwdNw-0003fY-VO; Sun, 01 Mar 2026 09:46:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243764.1543351; Sun, 01 Mar 2026 09:46:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwdNw-0003fR-SK; Sun, 01 Mar 2026 09:46:48 +0000 Received: by outflank-mailman (input) for mailman id 1243764; Sun, 01 Mar 2026 09:46:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwdNv-0003fL-9k for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 09:46:47 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8b67bb5e-1553-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 10:46:40 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 46D61402BE; Sun, 1 Mar 2026 09:46:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC8E1C116C6; Sun, 1 Mar 2026 09:46:37 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vwdNi-0000000Eusy-3vXA; Sun, 01 Mar 2026 09:46:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b67bb5e-1553-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772358398; bh=ah8m82Urr9ZVdbuAaL7dhveEEkY6qwHNCon+PPeoyBY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Z0KHJpNunNcjXEqJWgt/2aE9/sPgUgk19iKbhLZyj5sIoyncIPiC5DtoCtdNTI5rN ae0CchWvin1ZNSonWM/xcQgjOh45AZVjjLAorbihnBcMIFCKtMS24eSaPw8HZnnVNh 5m4IkmnaB7evNsc6rbzVP0cRVentf+1TS247vJ3/0N8jlZzcWLmBhtl2BAJGolpc3K SnBcnBqiqxfnfBMAkYqzWAVYsHCE+jWgxpQKRt5AkvNqeOi+fCiSa9vUa65yy7weLX yKjk6CJMJJlg4upoVm/xuuaj7cVFmtysK8UpS29DujEG5BWbnmwsyrINgwPMuAJ4Ye 0ngrTpp3uzY1g== Date: Sun, 01 Mar 2026 09:46:34 +0000 Message-ID: <86342janlx.wl-maz@kernel.org> From: Marc Zyngier To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() In-Reply-To: <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: vijayanand.jitta@oss.qualcomm.com, nipun.gupta@amd.com, nikhil.agarwal@amd.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, lpieralisi@kernel.org, tglx@kernel.org, robh@kernel.org, saravanak@kernel.org, hongxing.zhu@nxp.com, l.stach@pengutronix.de, kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com, Frank.Li@nxp.com, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, dmitry.baryshkov@oss.qualcomm.com, konrad.dybcio@oss.qualcomm.com, bjorn.andersson@oss.qualcomm.com, conor+dt@kernel.org, krzk+dt@kernel.org, prakash.gupta@oss.qualcomm.com, vikash.garodia@oss.qualcomm.com, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 01 Mar 2026 08:34:19 +0000, Vijayanand Jitta wrote: > > From: Robin Murphy > > Since we now have quite a few users parsing "iommu-map" and "msi-map" > properties, give them some wrappers to conveniently encapsulate the > appropriate sets of property names. This will also make it easier to > then change of_map_id() to correctly account for specifier cells. > > Reviewed-by: Rob Herring (Arm) > Reviewed-by: Frank Li > Signed-off-by: Robin Murphy > Signed-off-by: Vijayanand Jitta > --- > drivers/cdx/cdx_msi.c | 3 +-- > drivers/iommu/of_iommu.c | 4 +--- > drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- > drivers/of/irq.c | 3 +-- > drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- > drivers/pci/controller/pcie-apple.c | 3 +-- > drivers/xen/grant-dma-ops.c | 3 +-- > include/linux/of.h | 14 ++++++++++++++ > 8 files changed, 22 insertions(+), 16 deletions(-) > > diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c > index 91b95422b263..63b3544ec997 100644 > --- a/drivers/cdx/cdx_msi.c > +++ b/drivers/cdx/cdx_msi.c > @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > int ret; > > /* Retrieve device ID from requestor ID using parent device */ > - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", > - NULL, &dev_id); > + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); > if (ret) { > dev_err(dev, "of_map_id failed for MSI: %d\n", ret); > return ret; > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index 6b989a62def2..a511ecf21fcd 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_map_id(master_np, *id, "iommu-map", > - "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args); > + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > if (err) > return err; > > diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c > index d36b278ae66c..b63343a227a9 100644 > --- a/drivers/irqchip/irq-gic-its-msi-parent.c > +++ b/drivers/irqchip/irq-gic-its-msi-parent.c > @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u > > struct device_node *msi_ctrl __free(device_node) = NULL; > > - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); > + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); > } > > static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 6367c67732d2..e37c1b3f8736 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) > * "msi-map" or an "msi-parent" property. > */ > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { > - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", > - "msi-map-mask", msi_np, &id_out)) > + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) > break; > if (!of_check_msi_parent(parent_dev->of_node, msi_np)) > break; > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > index a5b8d0b71677..bff8289f804a 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > u32 sid = 0; > > target = NULL; > - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", > - &target, &sid_i); > + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > if (target) { > of_node_put(target); > } else { > @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > } > > target = NULL; > - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", > - &target, &sid_m); > + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); > > /* > * err_m target > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > index 2d92fc79f6dd..a0937b7b3c4d 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > pci_name(pdev->bus->self), port->idx); > > - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", > - "iommu-map-mask", NULL, &sid); > + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > if (err) > return err; > > diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > index c2603e700178..1b7696b2d762 100644 > --- a/drivers/xen/grant-dma-ops.c > +++ b/drivers/xen/grant-dma-ops.c > @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > struct pci_dev *pdev = to_pci_dev(dev); > u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > > - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args)) { > + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { > dev_dbg(dev, "Cannot translate ID\n"); > return -ESRCH; > } > diff --git a/include/linux/of.h b/include/linux/of.h > index be6ec4916adf..824649867810 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, > return of_property_read_u32(np, propname, (u32*) out_value); > } > > +static inline int of_map_iommu_id(const struct device_node *np, u32 id, > + struct device_node **target, u32 *id_out) > +{ > + return of_map_id(np, id, "iommu-map", "iommu-map-mask", > + target, id_out); > +} > + > +static inline int of_map_msi_id(const struct device_node *np, u32 id, > + struct device_node **target, u32 *id_out) > +{ > + return of_map_id(np, id, "msi-map", "msi-map-mask", > + target, id_out); > +} > + Any particular reason why this is made inline instead of out of line in of/base.c? Also, some documentation would be helpful for the aspiring hackers dipping into this. Other than that, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible. From xen-devel-bounces@lists.xenproject.org Sun Mar 01 10:02:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 10:02:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243774.1543361 (Exim 4.92) (envelope-from ) id 1vwddG-0006Zp-9h; Sun, 01 Mar 2026 10:02:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243774.1543361; Sun, 01 Mar 2026 10:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwddG-0006Zi-5U; Sun, 01 Mar 2026 10:02:38 +0000 Received: by outflank-mailman (input) for mailman id 1243774; Sun, 01 Mar 2026 10:02:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwddF-0006ZZ-5p for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 10:02:37 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c23cc130-1555-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 11:02:31 +0100 (CET) Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6216kFTu530173 for ; Sun, 1 Mar 2026 10:02:29 GMT Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksgq2j29-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 10:02:29 +0000 (GMT) Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-8cb37db8b79so2689801985a.3 for ; Sun, 01 Mar 2026 02:02:29 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-389f302285fsm22929771fa.44.2026.03.01.02.02.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 02:02:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c23cc130-1555-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=0xpqoMV9nCv7588O/2lb3+Dy gEwHNzZq2QKo2gKrDEI=; b=MFDwcsRMUoLALjslv9VY/VdAydAxc3/eD8jPp+b0 3dbJ7aTibd/9b6GV9IF2gWn6gSpe/I3btoHNAVjlHAbEwxC6eHSVdnwqOitswsKK BFmc5ona0teu2h6YmGm5UzCmJDzSNJQeil3gsT4tu2E/DuMyeeU2M4A9oTkvAzIU 6Nj7aXpW3vgAMvolk/oLAysN+VfAUn/SXHBScRSfZ3wrgr7md5skbPHMUU+5C7cg PDWi6o6khIMR296Rtf2LMqviKvYVMgehPnRNL1VGGCDd7pD1khwDOQnaVh1y70D6 5NTfRB58X2oh3kZa0pAyMmBzeNyGrUi6kb5A/jodMBBWgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772359348; x=1772964148; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0xpqoMV9nCv7588O/2lb3+DygEwHNzZq2QKo2gKrDEI=; b=OOMuRFdYKywRNM5hVzYRAOhkRg2Ana2174wer/K75BaWKaztBxjyDQuDm85wqxrVyQ WQx5wA5Z1KKIDSqK/h+5crLr4NtIKUEErpcuSKlGOBYrOwRKkjMV3Bj/JDUGABvPpLVp zF7vcdLGVcFYuXo9R2cGJ3A6+lUG9PFecs+4bknvsXtA2VbfGZzRQbnAthznEPnmtDnQ saiZz36U/YPNPh1GkCLj7FUS+s8qzhuKmzV3WdLf04jOiYzGZxBWXB/3nSeBthQGZR/o kO8BkTAUaFW6gljuZuAUF64pwO5/hr6zb6Ef1qFFplEL/TQwl5wDtnF0tpLnrIP2UfFU XOIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772359348; x=1772964148; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0xpqoMV9nCv7588O/2lb3+DygEwHNzZq2QKo2gKrDEI=; b=GZrHrvrxKA+UtjRIK96u5n1sT0Oj37qQdDj+K1foneb0Mq6LNrZuptH/soqLk6ooOp gZv0s7DftCLi+mOgjj94XiPWhrzEZOEYlb5F63fmZy25RCAxg1NJG1UTsprLZLIms0xZ gXeXpgK5stICYkSXqVdrICvRwwCnu9hzSZKnIpU2QZXNo05vzXRlLNLpgWIZEC/IdyqD sQKNaDZeQjVnTyXOcUyQqETiNLuIlQYBnEWeor80e3/jebtxrMqKIFEfSfXyXRI8dwTB AAjvFOuUvfLL1U0KeA0o/k2CICCIKmrKXJ67KaSl6PySp3VN7B9n/Jjm5d4SM1mWPdsu sYmA== X-Forwarded-Encrypted: i=1; AJvYcCVBRX3v574EoCMgxR6Z6XdfzZybrTnGdBurMt/MYtLL1j3TTECOpjccxT6cNtWcdCH7i6jJm66jZv8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxCB5iDc6TPJQbX1TOLdMpy+1s/Fv5ZMwcVo+9bWa1podVdavXV Cm+C8DaTuXZuPijQC4JfO/5T85qh3B8g47JY+GvWPxD2FG9Hk91LYXNzPZnBf9ViLdxtiCPZ6RG fkdcCxy7ShjWFGFjzNNkGdnXKGy/28d8dmJS4iahD+3WbtkwH6pMDAiQoHo6mya0B0JqAlg== X-Gm-Gg: ATEYQzznfABLmkTTiWRckAqw4xIPOAtx60+OKZhlIoyrYEYqy1NNJWfQeyfmE2LNN64 yk8h/F1YDku8pC9Eh5IBq+vh6AqL5Z3ilzzXsbU36iQXgH573NzcdBZ2dptBv/qnMhmymvatzSI e+KVoJhkP9TDPbIH7pqwZW8ubxhLZsixdsYcNBJ8Xwqk0e71uES9WT+hnNWVEAXGgqIOclqcEiQ eZ3gKpmKzIAIF2tk7adAyKhr6SqztVja839m1VcU5HXBw9FBk9wuMWO1ZTjg88yQ1Yw4zuZT76n QzHjOJAX6HkaCqG2BNZZP4idezBXT+2G11c53g798rGM9fpCgDaVjzwEgUScQPB5HmW26kk+/PT /0Vjvv7Sm4O6z83FJ0GluJWWzwI3jpO+FCWkNO8q0FgT8JwKp9Z25XpN7TcELIgpvfFgGFxclY0 fyehleNCJ7fNJXeSCHHTh3lwmFJwfdGGkfT8E= X-Received: by 2002:a05:620a:2904:b0:8b2:e17a:37 with SMTP id af79cd13be357-8cbc8df0942mr1244110785a.43.1772359348315; Sun, 01 Mar 2026 02:02:28 -0800 (PST) X-Received: by 2002:a05:620a:2904:b0:8b2:e17a:37 with SMTP id af79cd13be357-8cbc8df0942mr1244105085a.43.1772359347812; Sun, 01 Mar 2026 02:02:27 -0800 (PST) Date: Sun, 1 Mar 2026 12:02:23 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> X-Proofpoint-GUID: 6vKIxRpvDIiK-n-eqLiIHq-LFRBGMIST X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA4OSBTYWx0ZWRfXyyBsmJawSHj1 sYSf4u+EOjOK9onJiixHjYgXU9WWo/INWtnmtbSQl5DuGr2014dixxsb5O8c036OdPI3u6XNv4V +W41n+eZ2ojejtqzUUghDT6z0o+TAesU6erciSOljaFXflDnyitsX4CJijSYe3NA/e+cv0uN09D NZqqoR1BZA0Mz58GtRIxIDAQB12v2E4mrCnMnyOv5vRdSUSZ6hHggE+g98HELA85MBB7R3bcKYA 0Y74kwlML0URQgIwvYfDgZ/pUzutYXrJaMc2/0lWqmgW+b8de7HFgqqLeiqc9o6kOnC/suRW7rZ vPBqaaE1BVM/jHpjEHGF0/og8oVHyedc3Wvzqom8Dfc9Ois5foGPLPFMCI/Y/X1l5YBbtfyRPdX Oz021a8X/BRLYsdZLAtEDXA2QuUrZAr3L5l8RWwPM96GpWHFJ3vq50YesCzSFDUX/Rglgl+kcQz fhbcPfmVFbogplVdL8A== X-Authority-Analysis: v=2.4 cv=bdRmkePB c=1 sm=1 tr=0 ts=69a40eb5 cx=c_pps a=hnmNkyzTK/kJ09Xio7VxxA==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=ZF1vm7_Oee5k7ESqZ6kA:9 a=CjuIK1q_8ugA:10 a=PEH46H7Ffwr30OY-TuGO:22 X-Proofpoint-ORIG-GUID: 6vKIxRpvDIiK-n-eqLiIHq-LFRBGMIST X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 clxscore=1011 malwarescore=0 impostorscore=0 suspectscore=0 adultscore=0 spamscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010089 On Sun, Mar 01, 2026 at 02:04:20PM +0530, Vijayanand Jitta wrote: > From: Charan Teja Kalla > > Change of_map_id() to take a pointer to struct of_phandle_args > instead of passing target device node and translated IDs separately. > Update all callers accordingly. > > Subsequent patch will make use of the args_count field in > struct of_phandle_args. > > Suggested-by: Rob Herring (Arm) > Signed-off-by: Charan Teja Kalla > Signed-off-by: Vijayanand Jitta > --- > drivers/iommu/of_iommu.c | 2 +- > drivers/of/base.c | 37 +++++++++++++++++------------------ > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > drivers/pci/controller/pcie-apple.c | 4 +++- > drivers/xen/grant-dma-ops.c | 2 +- > include/linux/of.h | 21 +++++++++++++------- > 6 files changed, 44 insertions(+), 30 deletions(-) > > @@ -2193,11 +2193,10 @@ int of_map_id(const struct device_node *np, u32 id, > } > > pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, > - id, target && *target ? *target : NULL); > + id, arg->np ? arg->np : NULL); Is it just 'args->np' then? If it's NULL, it's NULL anyway. > > /* Bypasses translation */ > - if (id_out) > - *id_out = id; > + arg->args[0] = id; > return 0; > } > EXPORT_SYMBOL_GPL(of_map_id); > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > index bff8289f804a..74fc603b3f84 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -1139,12 +1139,18 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > { > struct device *dev = imx_pcie->pci->dev; > struct device_node *target; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > u32 sid_i, sid_m; > int err_i, err_m; > u32 sid = 0; > > target = NULL; > - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); > + if (!err_i) { > + target = iommu_spec.np; > + sid_i = iommu_spec.args[0]; > + } > + > if (target) { > of_node_put(target); > } else { > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > index a0937b7b3c4d..e1d4b37d200d 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > { > u32 sid, rid = pci_dev_id(pdev); > struct apple_pcie_port *port; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > int idx, err; > > port = apple_pcie_get_port(pdev); > @@ -764,10 +765,11 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > pci_name(pdev->bus->self), port->idx); > > - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); > if (err) > return err; of_node_put(iommu_spec.np); > > + sid = iommu_spec.args[0]; > mutex_lock(&port->pcie->lock); > > idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0); > diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > index 1b7696b2d762..5f1d6540049a 100644 > --- a/drivers/xen/grant-dma-ops.c > +++ b/drivers/xen/grant-dma-ops.c > @@ -325,7 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > struct pci_dev *pdev = to_pci_dev(dev); > u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > > - if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { > + if (of_map_iommu_id(np, rid, &iommu_spec)) { > dev_dbg(dev, "Cannot translate ID\n"); > return -ESRCH; > } > diff --git a/include/linux/of.h b/include/linux/of.h > index 824649867810..9d72d76f909d 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -463,7 +463,7 @@ bool of_console_check(const struct device_node *dn, char *name, int index); > > int of_map_id(const struct device_node *np, u32 id, > const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out); > + struct of_phandle_args *arg); > > phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); > > @@ -929,7 +929,7 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag > > static inline int of_map_id(const struct device_node *np, u32 id, > const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > + struct of_phandle_args *arg) > { > return -EINVAL; > } > @@ -1458,17 +1458,24 @@ static inline int of_property_read_s32(const struct device_node *np, > } > > static inline int of_map_iommu_id(const struct device_node *np, u32 id, > - struct device_node **target, u32 *id_out) > + struct of_phandle_args *arg) Document that it's the caller's responsibility to of_node_put() returned node. As it can be seen from the previous comment, it's not obvious. > { > - return of_map_id(np, id, "iommu-map", "iommu-map-mask", > - target, id_out); > + return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); > } > > static inline int of_map_msi_id(const struct device_node *np, u32 id, > struct device_node **target, u32 *id_out) Is there a reason for chaning the of_map_iommu_id() args but not of_map_msi_id() args? > { > - return of_map_id(np, id, "msi-map", "msi-map-mask", > - target, id_out); > + struct of_phandle_args msi_spec = { .np = *target, .args_count = 1 }; Which driver passes something being worth of storing in .np? > + int ret; > + > + ret = of_map_id(np, id, "msi-map", "msi-map-mask", &msi_spec); > + if (!ret) { > + *target = msi_spec.np; > + *id_out = msi_spec.args[0]; > + } > + > + return ret; > } > > #define of_for_each_phandle(it, err, np, ln, cn, cc) \ > > -- > 2.34.1 > -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Sun Mar 01 10:02:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 10:02:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243776.1543371 (Exim 4.92) (envelope-from ) id 1vwddZ-0006rm-F9; Sun, 01 Mar 2026 10:02:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243776.1543371; Sun, 01 Mar 2026 10: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 ) id 1vwddZ-0006rf-CY; Sun, 01 Mar 2026 10:02:57 +0000 Received: by outflank-mailman (input) for mailman id 1243776; Sun, 01 Mar 2026 10:02:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwddY-0006q8-Kk for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 10:02:56 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d0a82a7e-1555-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 11:02:55 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8051941B57; Sun, 1 Mar 2026 10:02:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6B71C116C6; Sun, 1 Mar 2026 10:02:52 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vwddS-0000000Ev2N-1H9X; Sun, 01 Mar 2026 10:02:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0a82a7e-1555-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772359373; bh=vtpZN1m1i7JB60bMgpFDRckohYAe2rTfHOUBY7CPkt8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IiiSrQMxEXvnAmwK9OX3matQowi1OfBQGfa4wsnqZv0VCq9h4hi+Zz6eWNcJvyp/v NKNEiJfQkOpipGT7qicIxsVx6iBqj9gkjCFVtdAyeuy4KsPdv7YgEPy/0IUfd+Ky6T FCIvl841AaG7hzOLpmL6YDHKu58OOkeozdhjL/90dmjbHUQMOOhRvblZPdRLY9Ht+m 0UTfWVjWsewWXaC4++PUlDwCrawhx8s8fCQGvLTqMuOFiahVk0+ZI2X+c5Au/hCvwb EQlrFqjagExB54Zt8V/LeB5iU4ngXho+Wv2XfBowHcX8X6MjHXzRljnh73mzuLFo8+ j55rBYk5pnByQ== Date: Sun, 01 Mar 2026 10:02:49 +0000 Message-ID: <861pi3amuu.wl-maz@kernel.org> From: Marc Zyngier To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct In-Reply-To: <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: vijayanand.jitta@oss.qualcomm.com, nipun.gupta@amd.com, nikhil.agarwal@amd.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, lpieralisi@kernel.org, tglx@kernel.org, robh@kernel.org, saravanak@kernel.org, hongxing.zhu@nxp.com, l.stach@pengutronix.de, kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com, Frank.Li@nxp.com, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, dmitry.baryshkov@oss.qualcomm.com, konrad.dybcio@oss.qualcomm.com, bjorn.andersson@oss.qualcomm.com, conor+dt@kernel.org, krzk+dt@kernel.org, prakash.gupta@oss.qualcomm.com, vikash.garodia@oss.qualcomm.com, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, charan.kalla@oss.qualcomm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 01 Mar 2026 08:34:20 +0000, Vijayanand Jitta wrote: > > From: Charan Teja Kalla > > Change of_map_id() to take a pointer to struct of_phandle_args > instead of passing target device node and translated IDs separately. > Update all callers accordingly. > > Subsequent patch will make use of the args_count field in > struct of_phandle_args. > > Suggested-by: Rob Herring (Arm) > Signed-off-by: Charan Teja Kalla > Signed-off-by: Vijayanand Jitta > --- > drivers/iommu/of_iommu.c | 2 +- > drivers/of/base.c | 37 +++++++++++++++++------------------ > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > drivers/pci/controller/pcie-apple.c | 4 +++- > drivers/xen/grant-dma-ops.c | 2 +- > include/linux/of.h | 21 +++++++++++++------- > 6 files changed, 44 insertions(+), 30 deletions(-) > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index a511ecf21fcd..d255d0f58e8c 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > + err = of_map_iommu_id(master_np, *id, &iommu_spec); > if (err) > return err; > > diff --git a/drivers/of/base.c b/drivers/of/base.c > index 57420806c1a2..6c3628255908 100644 > --- a/drivers/of/base.c > +++ b/drivers/of/base.c > @@ -2102,8 +2102,11 @@ int of_find_last_cache_level(unsigned int cpu) > * @id: device ID to map. > * @map_name: property name of the map to use. > * @map_mask_name: optional property name of the mask to use. > - * @target: optional pointer to a target device node. > - * @id_out: optional pointer to receive the translated ID. > + * @arg: of_phandle_args structure, > + * which includes: > + * np: pointer to the target device node > + * args_count: number of arguments Number of arguments *to what*? Isn't that the size of args[] instead? > + * args[]: array to receive the translated ID(s). > * > * Given a device ID, look up the appropriate implementation-defined > * platform ID and/or the target device which receives transactions on that > @@ -2117,21 +2120,21 @@ int of_find_last_cache_level(unsigned int cpu) > */ > int of_map_id(const struct device_node *np, u32 id, > const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > + struct of_phandle_args *arg) > { > u32 map_mask, masked_id; > int map_len; > const __be32 *map = NULL; > > - if (!np || !map_name || (!target && !id_out)) > + if (!np || !map_name || !arg) > return -EINVAL; > > map = of_get_property(np, map_name, &map_len); > if (!map) { > - if (target) > + if (arg->np) > return -ENODEV; > /* Otherwise, no map implies no translation */ > - *id_out = id; > + arg->args[0] = id; What if args_count is 0? Given that you place no restriction on the way this can be called, that'd be entirely legitimate, and you'd corrupt something you're not supposed to touch. > return 0; > } > > @@ -2173,18 +2176,15 @@ int of_map_id(const struct device_node *np, u32 id, > if (!phandle_node) > return -ENODEV; > > - if (target) { > - if (*target) > - of_node_put(phandle_node); > - else > - *target = phandle_node; > + if (arg->np) > + of_node_put(phandle_node); > + else > + arg->np = phandle_node; > > - if (*target != phandle_node) > - continue; > - } > + if (arg->np != phandle_node) > + continue; > > - if (id_out) > - *id_out = masked_id - id_base + out_base; > + arg->args[0] = masked_id - id_base + out_base; > > pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", > np, map_name, map_mask, id_base, out_base, > @@ -2193,11 +2193,10 @@ int of_map_id(const struct device_node *np, u32 id, > } > > pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, > - id, target && *target ? *target : NULL); > + id, arg->np ? arg->np : NULL); > > /* Bypasses translation */ > - if (id_out) > - *id_out = id; > + arg->args[0] = id; > return 0; > } > EXPORT_SYMBOL_GPL(of_map_id); > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > index bff8289f804a..74fc603b3f84 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -1139,12 +1139,18 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > { > struct device *dev = imx_pcie->pci->dev; > struct device_node *target; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > u32 sid_i, sid_m; > int err_i, err_m; > u32 sid = 0; > > target = NULL; > - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); > + if (!err_i) { > + target = iommu_spec.np; > + sid_i = iommu_spec.args[0]; > + } > + > if (target) { > of_node_put(target); > } else { > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > index a0937b7b3c4d..e1d4b37d200d 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > { > u32 sid, rid = pci_dev_id(pdev); > struct apple_pcie_port *port; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > int idx, err; > > port = apple_pcie_get_port(pdev); > @@ -764,10 +765,11 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > pci_name(pdev->bus->self), port->idx); > > - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); > if (err) > return err; > > + sid = iommu_spec.args[0]; I find this stuff absolutely unreadable. You're fishing the SID in a random position of a random structure, without any documentation of how this is supposed to work. This really needs a wrapper that hides this implementation detail. Thanks, M. -- Without deviation from the norm, progress is not possible. From xen-devel-bounces@lists.xenproject.org Sun Mar 01 10:14:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 10:14:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243794.1543382 (Exim 4.92) (envelope-from ) id 1vwdop-0000Sw-KF; Sun, 01 Mar 2026 10:14:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243794.1543382; Sun, 01 Mar 2026 10:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwdop-0000Sp-GH; Sun, 01 Mar 2026 10:14:35 +0000 Received: by outflank-mailman (input) for mailman id 1243794; Sun, 01 Mar 2026 10:14:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwdoo-0000Sj-6h for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 10:14:34 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6f05364b-1557-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 11:14:30 +0100 (CET) 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 61SH08QQ2942023 for ; Sun, 1 Mar 2026 10:14:29 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 4cksfd2fnq-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 10:14:28 +0000 (GMT) Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8cb52a9c0eeso2611176785a.2 for ; Sun, 01 Mar 2026 02:14:28 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a115bce377sm961212e87.15.2026.03.01.02.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 02:14:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f05364b-1557-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=AaYtDY7i19JC+kgo6Aub+wpd CRyygwATCwFfvf7SeLs=; b=hppjOok7n3kZEvdpFxy+oGrOFaOPC7WA6YKIHC/P RLEYZxYbkUwgyYloRukhuv54XIuvwPWWpkPINmqgr0ipcG19c+mBC/unxCISJ5r8 zv7oYZVSJSJYmp55jiMff6vOdPdxkh2HD9IUTL9/EGMSQq7cxEt5ifcUcnLdvyPQ CC0CKVFN4N93C/eKDl3lfXTKt14GvBGu6SOZqNz1kipYOf05iepCsnG0pQWfv/Tj WFKOcpyXYTiGyABliGv3BCzT079+WL77nYdK0AQqkVT1B1nEmAl3yQKyr4QgxvnL 0GB6owfy1UPawDPjWgbesksP+P/Io90JOQoe94KPSYHL8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772360068; x=1772964868; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AaYtDY7i19JC+kgo6Aub+wpdCRyygwATCwFfvf7SeLs=; b=UJDpvag+7m3v0iJCv/61JOCJp+AH5V9lobHW76VtdlLaU2HYFK0DjHV6hn/86sDaDf Bamgdo8LQYE+QQK96Rg4uOSO2IkPXsRxgJdAzZkhco1r0yYRbVbsbW4t3M6A6/z4vQ0X GIlMNjjY8+RCVNxlJzqAZ/VZyYAz3rBbYdYqWiiA1+dDKOOUXgafK6DeVSiTD56m3Opm O4TBphQcJYZayj6MxzKw6xCs+2jmdsCxqGVu0sivClhGmkwOT2RzOYqxSckgdf1R/ILZ l15skYj7JVtagYq5Mbka9L3TEHgDjX5WQl6xWL35jl9Wfaqe+YqYoKQvCK2gfKs0A07z w3zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772360068; x=1772964868; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AaYtDY7i19JC+kgo6Aub+wpdCRyygwATCwFfvf7SeLs=; b=WKacjeKdGsozyUcbM6opk/JWVMi7xuwCiGsdg73Assk4n9m2VQ281P3gwU23tO25ZH iiSKMr6nR+ksaAF+tNI0haDeqL+pnV7HLrrLbJtF1q2keMA5eCCf8fxykkRseuSY6Bf4 wkhzTrg6d1l/rYbe0/D5XEdZ1Kylx4+WyxgA+0ry9VGxBYbToUhRLQQVBVvdZKr2tmzZ c7bJt01TrjWErb1BTCJHwFRRWi2EyX3E1CRJudOimqCirtXVEfd+51fhBdcXw2tUqqe3 Igkn5d8vWZmy/nME987f8P6RQIdThJKpbm1+V4gZdRVGAVvFMQwPfPBoLIXbS3+c2IOo 82mA== X-Forwarded-Encrypted: i=1; AJvYcCUrdUvyEPCpgJvVYYfxBFhB3zbVHLS1t+SHj4wa1Q6TZB7LL62Tzc9cve6z7RotnPxaPl0vokBXxXw=@lists.xenproject.org X-Gm-Message-State: AOJu0YxGUfzR/RCY2La22aK9F3k21MvXMfkJKAHPeTci//oKEY+NMpYU pUPfCrmZAoeaZGt4rhjvq5xvgkuDjmGevWoEEHhqwmHEZYG3OJk7DwOe4P869EDOa9Ivt/mbwaJ 1bLcCm8KHDlSGe2hPxmgrf8jJhMDp2yki8y2L8dfxoQxrYgfoV32G96gtPVbRFSYvTsPOoQ== X-Gm-Gg: ATEYQzyF1B5S2R2nkC2u1f0Qq46wkEu+OEBZwUPzL6bOIXH06g8pLcGd9T/xAkjdT4U 0MzrLVSpLOusedgVS7ikinZkAx9jaOxuHZHsOhpKuGWgPVMUBoP2lkqNrXcbqcuJrXer8eca6fR zeQu0n3q9A9BpKSNbOUp/IXuQ0lQtuqK34w9S1WKKmqvGEoGkoijbxs7GgFwKNpQucJNZEj+bHI 40bMoB4k9/vuHEkUtwcpLQMZ3ZZFkGA2jLaNMCqqbM97vKvpJmthhAIdtusrZrfkzRZ9fHohad1 IqIB8ryHGy+4gvJbA0Dt+5qxGnmh0Iw+4Y3WCTpF2vZO4vvX77fExEBPNRqDAyR0PVWVh4ossUY 6Py+bixsnxiNqvnMVzzavrLmt8jcCUWZLMWw9G3cQ1y+CLNiD7KW83MWhrv64O1joltl313jXWt vhuAu3hxeUStXfmlogjTrdwAHVvp2Uo4TrFCE= X-Received: by 2002:a05:620a:c4a:b0:8b6:1877:3689 with SMTP id af79cd13be357-8cbc8d9f7f5mr1039716085a.35.1772360067923; Sun, 01 Mar 2026 02:14:27 -0800 (PST) X-Received: by 2002:a05:620a:c4a:b0:8b6:1877:3689 with SMTP id af79cd13be357-8cbc8d9f7f5mr1039712785a.35.1772360067368; Sun, 01 Mar 2026 02:14:27 -0800 (PST) Date: Sun, 1 Mar 2026 12:14:23 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 3/3] of: Respect #{iommu,msi}-cells in maps Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-3-4d1bceecc5e1@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260301-parse_iommu_cells-v9-3-4d1bceecc5e1@oss.qualcomm.com> X-Proofpoint-ORIG-GUID: bHA-iXZAqDUafR2HJbsBttLMiP8UykgI X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA5MSBTYWx0ZWRfXxX1VBNKYWRVU UpQ+V9K0LjgExjP19NlU3QtaP3RLg9caJPTZ5X0WdpR82xhuaPoBnEeExowKuw26nvHMgxaT3x4 nKywnDH8GEa0a726lcypLeLpPOhsqp20WVJqWtclaZbPTE1Xioz2U9Td/Jpdfqxh+QaNJErzOc5 14Eb7dT9miDa32YLyS/rHeqzZwKSs6WjnNb7yJwVcW5qGbF127Cngn2pyrEsBzt83A75ITK+he9 8rFKUEUGMCt5d5rwd+dbidM1wSLjK5JZ8sVZ+LgHPqTJHiv4mfxsMxPLXQ2ivEnI8sZ0BolaqIH 0phaThc0fLUKiq4tEePzz00l5EXK73r9wkdzSezKwfwl/hRQVdf+rsCpj8VXklzeDDORp6Eoz24 oPmSSKYoQPLPGFhc19hsARPWeAS/ljr8d2C4/bIy0I+XtmuTufqzz9YiphtLWtNhNdumu3XPwpj Z/DJL0pRffgqhXhSxaw== X-Authority-Analysis: v=2.4 cv=HKDO14tv c=1 sm=1 tr=0 ts=69a41184 cx=c_pps a=qKBjSQ1v91RyAK45QCPf5w==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=7CQSdrXTAAAA:8 a=EUspDBNiAAAA:8 a=7GgscoS1Nejt2LJ9sp4A:9 a=CjuIK1q_8ugA:10 a=NFOGd7dJGGMPyQGDc5-O:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-GUID: bHA-iXZAqDUafR2HJbsBttLMiP8UykgI X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 phishscore=0 impostorscore=0 adultscore=0 spamscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010091 On Sun, Mar 01, 2026 at 02:04:21PM +0530, Vijayanand Jitta wrote: > From: Robin Murphy > > So far our parsing of {iommu,msi}-map properites has always blindly > assumed that the output specifiers will always have exactly 1 cell. > This typically does happen to be the case, but is not actually enforced > (and the PCI msi-map binding even explicitly states support for 0 or 1 > cells) - as a result we've now ended up with dodgy DTs out in the field > which depend on this behaviour to map a 1-cell specifier for a 2-cell > provider, despite that being bogus per the bindings themselves. > > Since there is some potential use in being able to map at least single > input IDs to multi-cell output specifiers (and properly support 0-cell > outputs as well), add support for properly parsing and using the target > nodes' #cells values, albeit with the unfortunate complication of still > having to work around expectations of the old behaviour too. > > Since there are multi-cell output specifiers, the callers of of_map_id() > may need to get the exact cell output value for further processing. > Added support for that part --charan > > Signed-off-by: Robin Murphy > Signed-off-by: Charan Teja Kalla > Signed-off-by: Vijayanand Jitta > --- > drivers/iommu/of_iommu.c | 2 +- > drivers/of/base.c | 117 +++++++++++++++++++++++++++++++++++++---------- > include/linux/of.h | 16 +++---- > 3 files changed, 102 insertions(+), 33 deletions(-) > > /** > * of_map_id - Translate an ID through a downstream mapping. > * @np: root complex device node. > * @id: device ID to map. > * @map_name: property name of the map to use. > + * @cells_name: property name of target specifier cells. > * @map_mask_name: optional property name of the mask to use. > * @arg: of_phandle_args structure, > * which includes: > @@ -2118,18 +2145,19 @@ int of_find_last_cache_level(unsigned int cpu) > * > * Return: 0 on success or a standard error code on failure. > */ > -int of_map_id(const struct device_node *np, u32 id, > - const char *map_name, const char *map_mask_name, > - struct of_phandle_args *arg) > +int of_map_id(const struct device_node *np, u32 id, const char *map_name, > + const char *cells_name, const char *map_mask_name, > + struct of_phandle_args *arg) Some extra whitespace-related noise in here. Last line wasn't changed, so there is no need to touch it. > { > u32 map_mask, masked_id; > - int map_len; > + int map_bytes, map_len, offset = 0; > + bool bad_map = false; > const __be32 *map = NULL; > > if (!np || !map_name || !arg) > return -EINVAL; > > - map = of_get_property(np, map_name, &map_len); > + map = of_get_property(np, map_name, &map_bytes); > if (!map) { > if (arg->np) > return -ENODEV; > @@ -2138,11 +2166,9 @@ int of_map_id(const struct device_node *np, u32 id, > return 0; > } > > - if (!map_len || map_len % (4 * sizeof(*map))) { > - pr_err("%pOF: Error: Bad %s length: %d\n", np, > - map_name, map_len); > - return -EINVAL; > - } > + if (map_bytes % sizeof(*map)) > + goto err_map_len; > + map_len = map_bytes / sizeof(*map); > > /* The default is to select all bits. */ > map_mask = 0xffffffff; > @@ -2155,27 +2181,63 @@ int of_map_id(const struct device_node *np, u32 id, > of_property_read_u32(np, map_mask_name, &map_mask); > > masked_id = map_mask & id; > - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { > + > + while (offset < map_len) { > struct device_node *phandle_node; > - u32 id_base = be32_to_cpup(map + 0); > - u32 phandle = be32_to_cpup(map + 1); > - u32 out_base = be32_to_cpup(map + 2); > - u32 id_len = be32_to_cpup(map + 3); > + u32 id_base, phandle, id_len, id_off, cells = 0; > + const __be32 *out_base; > + > + if (map_len - offset < 2) > + goto err_map_len; > + > + id_base = be32_to_cpup(map + offset); > > if (id_base & ~map_mask) { > - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n", > - np, map_name, map_name, > - map_mask, id_base); > + pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n", > + np, map_name, map_mask_name, map_mask, id_base); > return -EFAULT; > } > > - if (masked_id < id_base || masked_id >= id_base + id_len) > - continue; > - > + phandle = be32_to_cpup(map + offset + 1); > phandle_node = of_find_node_by_phandle(phandle); > if (!phandle_node) > return -ENODEV; > > + if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) { > + pr_err("%pOF: missing %s property\n", phandle_node, cells_name); > + return -EINVAL; > + } This will trigger the cells_name property check even if later we discover that we have a "bad" map. Is it intended / required? > + > + if (map_len - offset < 3 + cells) of_node_put(phandle_node); > + goto err_map_len; > + > + if (offset == 0 && cells == 2) { ... if it's not required, then the bad_map check can be moved before the loop. > + bad_map = of_check_bad_map(map, map_len); > + if (bad_map) { > + pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n", > + np, map_name, cells_name); > + cells = 1; > + } > + } > + > + out_base = map + offset + 2; > + offset += 3 + cells; > + > + id_len = be32_to_cpup(map + offset - 1); > + if (id_len > 1 && cells > 1) { > + /* > + * With 1 output cell we reasonably assume its value > + * has a linear relationship to the input; with more, > + * we'd need help from the provider to know what to do. > + */ > + pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n", > + np, map_name, id_len, cells); > + return -EINVAL; > + } > + id_off = masked_id - id_base; > + if (masked_id < id_base || id_off >= id_len) > + continue; > + > if (arg->np) > of_node_put(phandle_node); > else > @@ -2184,11 +2246,14 @@ int of_map_id(const struct device_node *np, u32 id, > if (arg->np != phandle_node) > continue; > > - arg->args[0] = masked_id - id_base + out_base; > + for (int i = 0; i < cells; i++) > + arg->args[i] = (id_off + be32_to_cpu(out_base[i])); > + > + arg->args_count = cells; > > pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", > - np, map_name, map_mask, id_base, out_base, > - id_len, id, masked_id - id_base + out_base); > + np, map_name, map_mask, id_base, be32_to_cpup(out_base), > + id_len, id, id_off + be32_to_cpup(out_base)); Again, having whitespace changes doesn't simplify reviewing. > return 0; > } > > @@ -2198,5 +2263,9 @@ int of_map_id(const struct device_node *np, u32 id, > /* Bypasses translation */ > arg->args[0] = id; > return 0; > + > +err_map_len: > + pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes); > + return -EINVAL; > } > EXPORT_SYMBOL_GPL(of_map_id); -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Sun Mar 01 10:47:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 10:47:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243803.1543391 (Exim 4.92) (envelope-from ) id 1vweKL-0004Zi-W2; Sun, 01 Mar 2026 10:47:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243803.1543391; Sun, 01 Mar 2026 10:47:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vweKL-0004Zb-Rp; Sun, 01 Mar 2026 10:47:09 +0000 Received: by outflank-mailman (input) for mailman id 1243803; Sun, 01 Mar 2026 10:47:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vweKK-0004ZV-Ha for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 10:47:08 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fb96339f-155b-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 11:47:04 +0100 (CET) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6214Ea7A3978903 for ; Sun, 1 Mar 2026 10:47:02 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 4ckshktfyx-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 10:47:02 +0000 (GMT) Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8cb37db8b79so2721104285a.3 for ; Sun, 01 Mar 2026 02:47:02 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a115bce377sm971860e87.15.2026.03.01.02.46.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 02:47:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb96339f-155b-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=zMjjSX07o27ArEy58bafhXTf zgI0LtEb8dLPu9QRg6g=; b=YHzedMVvaaQRmITBFe8xlRAGp8P99EssBQY/pKU4 5F2QJ5TRhTc6aItMbvykuefuUQIazptsv9UE9PHpvwpC1M+e1jXsUT62ohJytu/e RldhLQBp18YepRjUSmK6wuw5wmhrPTkxHh0nYq0lBb+4nK4Ztl0J/nvTVcQEhFmQ jAhvb//acoWSA3UXKpi1kdahy8aWY8gtcFTmo0MoXVHVDbZtADY+PBM2PDG5mLct 9m7MkPMdZ843hZ+h40XdTx1WGnDLataaldhWe/qsX5StDb8rU25k1g+v6s9gPp5d 3cg1+H4J+zKzj/uIE/BAyVD607KfK0kE+a/7LiwBCbbnSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772362022; x=1772966822; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=zMjjSX07o27ArEy58bafhXTfzgI0LtEb8dLPu9QRg6g=; b=XC0G5Ls6bLClgeMflWtxNL0t1rdp+B3JkQc/nvk7JdtNUdV+l/YFgSoeqM4BYOmS4b K1jt9Nmkv+2qkcWOBw1LsrZlDU297qBw6QOM74zpUDAMVw3E3xtauI8eOXKst7M8h0Gt FkNsR4ehpJtN8D3q9vBkBUvJ0U25XA4aIkwHh6EmbjIrVgkqiyn2Vi3yPQbtByQiejnY jcCR/sre5aWJpGnluiipiK7MbcWhJHNZTdcbT9cfqsyx5zpKBLoTuX+fuWYKljgD6oV0 KvoNxUtPJJxF+1bKNzYNUT/3J8fkFS/Pm/JwtgKncbyILBerk0HKBpLVPvXCXWhW/a8p 3eQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772362022; x=1772966822; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zMjjSX07o27ArEy58bafhXTfzgI0LtEb8dLPu9QRg6g=; b=pxy0NIFZ7AGmXMSA+buBr4QZ33+MN7MvDP2a9rjvIpVg9U/CInAK9RTFKnGQ9XDf76 IOVImUWEG7mR9Rf0SIVNZ5ZaZS/szw2Aat5iWwuPWRqBnZbooyEf4W1t/9w4EGdp01St oAbr8MwM9EUxXwzr9D5+ZsYtlU1TAoT9gNseCaZ5TvLWu+LIDytrkEzoPloEAuLStays nLf0wBgrt5p1IUhS76DQbOFZ+cKAhEatOip6YnTmyYPQ9B/p/Y7uWRIfWVpvvdHECUdM ZAZ4WElXGwWK8SPrKbeCH2URFamu6eXMsEeQpPF785TMVUp3L7lThvMwrwcolholmomL KIVw== X-Forwarded-Encrypted: i=1; AJvYcCVPj4Qrm29M8HceLD3LIzTUu5wA9oteaEDtamFIgrNPOE7XlDMonT88sqtoLQ0SmMbBKC+B8f380Ag=@lists.xenproject.org X-Gm-Message-State: AOJu0YwKyfJCFGMrFNxA+vgi718CXP2n6owoGtc+F/VP3t4kULese58d /tqoqZO/jFFsy35l7mDGp2ytiPfhbJ8K61qTq8nGv7FELT0c9cBR38xg97R2Q/Lnw9P9iPh5RMn OF/FZvHyBk+PXg1d0h6/qjAwBMP69BesE2Xz5iczCWJ5bKWiISrFHLbxT/TEdSfnZ67LaNQ== X-Gm-Gg: ATEYQzzvD26fScucBUszrHZaUrH0Lri0KKnpUFoEyhPf1w8IohCuvJNmiV9hUT0aZL3 rcfzRv2SFzPTtkNWl8t15oJCw+QnmP2jBAIODtn3m0YjF3fTJLDklemm1pZgyoKdFP6AfvdpECy B7WfldIThWOQgQM56VuSoijZEEurorBY4KLNALfjifKk9VJ0GQFFYpH1ChC5uKQvN8kussE1Hd2 xw75QPq6HSGoS0Ybo2OhX/Pmh1rb0TdhoUpl2otKincY3hyEY3P0zUWBzNzzDjP+1oDEqHGUVE4 tKMdbxuJMjbiiG8lUeQ9nmGAjOqVfq8mw03LjQ9HUyRz03KbY3RETyXSF6VEHsGpDCgsWrrxmZf Jjr/w0wNh2g6IddeHV4uQ+bBA89kRzWhvEMS7l35DJFkvMSp6NpnB+4/AuypNZCyAFwAnxuu7we hbzcvsZzf0RKybkwl2nKVt4ze1vmWqSjGXtcs= X-Received: by 2002:a05:620a:199c:b0:8cb:50d6:18c3 with SMTP id af79cd13be357-8cbc8d6ef5bmr1217220385a.1.1772362021859; Sun, 01 Mar 2026 02:47:01 -0800 (PST) X-Received: by 2002:a05:620a:199c:b0:8cb:50d6:18c3 with SMTP id af79cd13be357-8cbc8d6ef5bmr1217215585a.1.1772362021320; Sun, 01 Mar 2026 02:47:01 -0800 (PST) Date: Sun, 1 Mar 2026 12:46:57 +0200 From: Dmitry Baryshkov To: Marc Zyngier Cc: Vijayanand Jitta , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> <861pi3amuu.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <861pi3amuu.wl-maz@kernel.org> X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA5NiBTYWx0ZWRfX79fsq6WkQFxx /4CvNQ5ZavR3XP8yY3s7qbK4hDi2JhSeowfHc9Fjw/6Arj1toQM2qX6B+DuJFLLGuZVeyffKlEs yIo6v17DnBmkTZxCEKywqlTuTg+pQdyu/yHczRMt4UbSPfx3UIkcqzJ7LDjWU+NfgXqqUqihJLr yIwttF1z4bPv9mIReaXdFzbP8Wg+hN/mpRpvhZsGCxZmsvfRTkRW9BE/oDzMjIEEFJrg8ryilIY uqnHrfKOq9e+2ZKY84iF4Yp/DcbuGA/W/GZYq90LIKDzENWy8hOqoa603q8uLc5FzAEgpP4OD37 NkOrGp/FSTg+1sPSQ+5bHHJ+P2dlmbl2W/Gr8sorxlWXivxqzhHF+wWdf1DyqNxxn21RVRt3aQT DeNDBiadEYNLxMhiTTi8sP21blSa/ZrRgIMD5pg3tz0jAInRT7XCqez9GjQn0FPJYKBAPnHVY2e fVIwIHvCr9wflRFIG8A== X-Proofpoint-ORIG-GUID: HDdCV8scuzg9j5vqD-yrLcITck0T3K2n X-Authority-Analysis: v=2.4 cv=EvbfbCcA c=1 sm=1 tr=0 ts=69a41926 cx=c_pps a=qKBjSQ1v91RyAK45QCPf5w==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=YG64nluAAAAA:20 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=Pq9JgrngHnaR5_AiyuMA:9 a=CjuIK1q_8ugA:10 a=NFOGd7dJGGMPyQGDc5-O:22 a=bA3UWDv6hWIuX7UZL3qL:22 X-Proofpoint-GUID: HDdCV8scuzg9j5vqD-yrLcITck0T3K2n X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 adultscore=0 impostorscore=0 clxscore=1015 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010096 On Sun, Mar 01, 2026 at 10:02:49AM +0000, Marc Zyngier wrote: > On Sun, 01 Mar 2026 08:34:20 +0000, > Vijayanand Jitta wrote: > > > > From: Charan Teja Kalla > > > > Change of_map_id() to take a pointer to struct of_phandle_args > > instead of passing target device node and translated IDs separately. > > Update all callers accordingly. > > > > Subsequent patch will make use of the args_count field in > > struct of_phandle_args. > > > > Suggested-by: Rob Herring (Arm) > > Signed-off-by: Charan Teja Kalla > > Signed-off-by: Vijayanand Jitta > > --- > > drivers/iommu/of_iommu.c | 2 +- > > drivers/of/base.c | 37 +++++++++++++++++------------------ > > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > > drivers/pci/controller/pcie-apple.c | 4 +++- > > drivers/xen/grant-dma-ops.c | 2 +- > > include/linux/of.h | 21 +++++++++++++------- > > 6 files changed, 44 insertions(+), 30 deletions(-) > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > > index a511ecf21fcd..d255d0f58e8c 100644 > > --- a/drivers/iommu/of_iommu.c > > +++ b/drivers/iommu/of_iommu.c > > @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int err; > > > > - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > > + err = of_map_iommu_id(master_np, *id, &iommu_spec); > > if (err) > > return err; > > > > diff --git a/drivers/of/base.c b/drivers/of/base.c > > index 57420806c1a2..6c3628255908 100644 > > --- a/drivers/of/base.c > > +++ b/drivers/of/base.c > > @@ -2102,8 +2102,11 @@ int of_find_last_cache_level(unsigned int cpu) > > * @id: device ID to map. > > * @map_name: property name of the map to use. > > * @map_mask_name: optional property name of the mask to use. > > - * @target: optional pointer to a target device node. > > - * @id_out: optional pointer to receive the translated ID. > > + * @arg: of_phandle_args structure, > > + * which includes: > > + * np: pointer to the target device node > > + * args_count: number of arguments > > Number of arguments *to what*? Isn't that the size of args[] instead? It is a number of values corresponding to the phandle in the DT property. It might be not obvious here for iommu-maps, but the struct is idiomatic in OF world. Let me quote a (trimmed) example from qcom/sm8650.dtsi (for a different property, but it explains the meaning of the values here): gem_noc: interconnect@24100000 { #interconnect-cells = <2>; }; epss_l3: interconnect@17d90000 { #interconnect-cells = <1>; }; interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>, <&epss_l3 MASTER_EPSS_L3_APPS &epss_l3 SLAVE_EPSS_L3_SHARED>; /* I skipped the second pair, it adds nothing here */ Here the parsing function for this property (of_icc_get_by_index()) will call of_parse_phandle_with_args() 4 times and it expects to return the following values in the of_phandle_args: 1. { .np = gem_noc, .args_count = 2, .args = [MASTER_APPSS_PROC, QCOM_ICC_TAG_ACTIVE_ONLY] } 2. { .np = gem_noc, .args_count = 2, .args = [SLAVE_LLCC, QCOM_ICC_TAG_ACTIVE_ONLY] } 3. { .np = epss_l3, .args_count = 1, .args = [MASTER_EPSS_L3_APPS] } 4. { .np = epss_l3, .args_count = 1, .args = [SLAVE_EPSS_L3_SHARED] } The whole of_phandle_args is then typically passed to the corresponding xlate function, specific to the paricular .np ('provider'), which will use #args_count values from the #args array to return the object from the provider. Now let's see iommu-maps (again, qcom/sm8650.dtsi): apps_smmu: iommu@15000000 { #iommu-cells = <2>; }; iommu-map = <0 &apps_smmu 0x1400 0x1>, <0x100 &apps_smmu 0x1401 0x1>; The property matches current definition at [1], however this spec doesn't match the DT practice. It forces that the property should use 1 cell for identifying the "object" in the IOMMU provider, even if the provider expects to use 2 cells (two args). The correct property should look like: iommu-map = <0 &apps_smmu 0x1400 0x0 0x1>, <0x100 &apps_smmu 0x1401 0x0 0x1>; [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-iommu.yaml > > > + * args[]: array to receive the translated ID(s). > > * > > * Given a device ID, look up the appropriate implementation-defined > > * platform ID and/or the target device which receives transactions on that > > @@ -2117,21 +2120,21 @@ int of_find_last_cache_level(unsigned int cpu) > > */ > > int of_map_id(const struct device_node *np, u32 id, > > const char *map_name, const char *map_mask_name, > > - struct device_node **target, u32 *id_out) > > + struct of_phandle_args *arg) > > { > > u32 map_mask, masked_id; > > int map_len; > > const __be32 *map = NULL; > > > > - if (!np || !map_name || (!target && !id_out)) > > + if (!np || !map_name || !arg) > > return -EINVAL; > > > > map = of_get_property(np, map_name, &map_len); > > if (!map) { > > - if (target) > > + if (arg->np) > > return -ENODEV; > > /* Otherwise, no map implies no translation */ > > - *id_out = id; > > + arg->args[0] = id; > > What if args_count is 0? Given that you place no restriction on the > way this can be called, that'd be entirely legitimate, and you'd > corrupt something you're not supposed to touch. args is an array (not a pointer) in of_phandle_args. As such we know that args[0] is legit. > > > return 0; > > } > > > > @@ -2173,18 +2176,15 @@ int of_map_id(const struct device_node *np, u32 id, > > if (!phandle_node) > > return -ENODEV; > > > > - if (target) { > > - if (*target) > > - of_node_put(phandle_node); > > - else > > - *target = phandle_node; > > + if (arg->np) > > + of_node_put(phandle_node); > > + else > > + arg->np = phandle_node; > > > > - if (*target != phandle_node) > > - continue; > > - } > > + if (arg->np != phandle_node) > > + continue; > > > > - if (id_out) > > - *id_out = masked_id - id_base + out_base; > > + arg->args[0] = masked_id - id_base + out_base; > > > > pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", > > np, map_name, map_mask, id_base, out_base, > > @@ -2193,11 +2193,10 @@ int of_map_id(const struct device_node *np, u32 id, > > } > > > > pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, > > - id, target && *target ? *target : NULL); > > + id, arg->np ? arg->np : NULL); > > > > /* Bypasses translation */ > > - if (id_out) > > - *id_out = id; > > + arg->args[0] = id; > > return 0; > > } > > EXPORT_SYMBOL_GPL(of_map_id); > > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > > index bff8289f804a..74fc603b3f84 100644 > > --- a/drivers/pci/controller/dwc/pci-imx6.c > > +++ b/drivers/pci/controller/dwc/pci-imx6.c > > @@ -1139,12 +1139,18 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > > { > > struct device *dev = imx_pcie->pci->dev; > > struct device_node *target; > > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > > u32 sid_i, sid_m; > > int err_i, err_m; > > u32 sid = 0; > > > > target = NULL; > > - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > > + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); > > + if (!err_i) { > > + target = iommu_spec.np; > > + sid_i = iommu_spec.args[0]; > > + } > > + > > if (target) { > > of_node_put(target); > > } else { > > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > > index a0937b7b3c4d..e1d4b37d200d 100644 > > --- a/drivers/pci/controller/pcie-apple.c > > +++ b/drivers/pci/controller/pcie-apple.c > > @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > > { > > u32 sid, rid = pci_dev_id(pdev); > > struct apple_pcie_port *port; > > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > > int idx, err; > > > > port = apple_pcie_get_port(pdev); > > @@ -764,10 +765,11 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > > dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > > pci_name(pdev->bus->self), port->idx); > > > > - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > > + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); > > if (err) > > return err; > > > > + sid = iommu_spec.args[0]; > > I find this stuff absolutely unreadable. You're fishing the SID in a > random position of a random structure, without any documentation of > how this is supposed to work. This really needs a wrapper that hides > this implementation detail. > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible. -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Sun Mar 01 10:59:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 10:59:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243818.1543400 (Exim 4.92) (envelope-from ) id 1vweWM-0006Mq-3o; Sun, 01 Mar 2026 10:59:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243818.1543400; Sun, 01 Mar 2026 10: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 ) id 1vweWM-0006Mj-1I; Sun, 01 Mar 2026 10:59:34 +0000 Received: by outflank-mailman (input) for mailman id 1243818; Sun, 01 Mar 2026 10:59:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vweWK-0006Md-TX for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 10:59:32 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b83a6768-155d-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 11:59:30 +0100 (CET) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6216rYmt2276909 for ; Sun, 1 Mar 2026 10:59:28 GMT Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksf6jhex-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 10:59:28 +0000 (GMT) Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8cb403842b6so3546395085a.1 for ; Sun, 01 Mar 2026 02:59:28 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a116de019esm872280e87.3.2026.03.01.02.59.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 02:59:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b83a6768-155d-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=tWvbzoSirp2+/mfj208EVtuC kSsURTVI0XL++QIzXe8=; b=ZbRtpKNVrLZlATBeln8U+o1HVMJ1NJFODQD2g1Xt 5zqmD26FEi7oT89X6dB/3Kf0XkkF6A8sXLJiy6k2cdCfTElYXz+CjMK5FIy3AQPe xpwFsAEbry2aIJz+ovYfTdhNnokCCupYZNrBBmfiE6N5iXxEnaecxqJfkBq7jA6g atxv+7P2SKJ+CThu9PnqyE+e14r5zyxB6+fChJWyb7bmsbhO1nbIl9sdXtyQ92aF 9NNtP7wU75FlG/y0oxLuqIE1sXvncry7ovuFrwD64sbYiUvq0bz1X2QeTCCuTyIj PQrXowySKFMO/mebdHFA3zvBB6060oQ2+M3ZZuPrtLkY+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772362768; x=1772967568; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tWvbzoSirp2+/mfj208EVtuCkSsURTVI0XL++QIzXe8=; b=Qg0SasUz6gZf4s5euvPZwSPcATKKIMaNscPyHYwyWkBXUO4DNtvlrBqdbtygHVc1yP zLcAnypjfrHTgWInQYPh9LlMWGAjdq5PTAt7FRTJ51G6M0DWrb7Vl1ilTs7bfBl4TdsF Us3WgFRfHh6fxTwlvlfr2Bgm19Q+SVHrXduE5khIkNr/JSOvrdWt08m00jFjTkiw9Tqz seTpcR3ZYBMObNMap8E6xDjywP6pfopQEkDHxgB+l2aI4ZiAu+HIhJfHlR3BmjmnNrAW IcFU79RXY7XKzOICTqP6H12YCRYDYwvdjHYZdjnOtwOzHl/rykbTqRyiAA1zbtcU3/kP QFKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772362768; x=1772967568; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tWvbzoSirp2+/mfj208EVtuCkSsURTVI0XL++QIzXe8=; b=FP8eV5TnvZrtFGlu8ZvS+qFFsKSzM7COXkzqNzj6Mpr3HzyTEVy30eH/idv+WCUW1a X2jDzOif8P+tkQxFQYUV+oK6GYc5gOq5fkcWzFhvG8W1nJS0ZeBLJi7SpuBsSih3euY1 4+dfxPnzI41uacGulN24RIhmL4zOmmY6ZfziIu9nr/lxcKCH3P3WjqMR0lg2U2cCxpFO AI6x2fXBOwN1O2QCT1a1muEb60ftET47trYp7A+Yaz1HiOdpt1iUZVlXH289lp6PRWTV fU8s/i113kjKJN6QXDsItWvoikwGk7taFA0MFg7oSOxgDkYZ0Za+KKdJOMPJybxscM9r 9enQ== X-Forwarded-Encrypted: i=1; AJvYcCVm/N++qBxd20APkQhMJR3vDnRbr53Yj2D8pph6aQsBB9f2xOhTZkmJ53eDGdgLHyqA5i9Uz4X3yGM=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvRWBXh/qbu//ZjtFR6U8fpx3FhAOifKnoauouDEDLljSRfa7b MbeLhAVj2zrSIWh4/odlAjkAzVHx9R0gGpDFRLTfhOT4NyNbcG9cC7fcB/8DnhPqlQ6yfHwyiKY yoOM7ml6kOkh8XMtT9xgjLhJX975IwAjsKm/BDe0PP2SkANMC9Azy5to/5B79yoPPPkZTWA== X-Gm-Gg: ATEYQzxTSUdWTcLCfZg5/J1E/332WlDUIr4Hx5r1lmA2aZv456f6b9OewVMwXgy7dCq XP5Q13umuR2MMMYr3YOQ5phGzOpWhBq7Ww3QOmFxuiwLfYLv/zhE6eq1uGbwGFFkNqVVYkSS7Ix mZPLrxUAb/8P8b79UHbinaHIt8EuQXgrXEGZFezQja/H8+PI9ZWHnuKdK4ExNW/xw3f4+j49gFF XfX6A9VfTQnVyizRw7zwlW7KVUyMLQ+EUzfjnQ22ficO4tRQxNBNBs+Uf9dk++eeZ4KRSiMxX8J FjuuVdhrUP43dgKhsfThqL2vhA6GkdqyOjlXAshrEhUBn8XvIJ8fbVh0pJSz1THUzFoqvSesNMA aDdxNUY4IXms0+75F/M1VkFiSjGFTDtthGMD9SqDxQp7N/iyYkcabDtOBKj+mCoWi8/yp84B4Su PPHKA1Qgpns1+i2MuPFy7+eSTT7tJM/tCW0hI= X-Received: by 2002:a05:620a:3949:b0:8c7:1b3f:7d0c with SMTP id af79cd13be357-8cbc8e55216mr1090398185a.16.1772362767988; Sun, 01 Mar 2026 02:59:27 -0800 (PST) X-Received: by 2002:a05:620a:3949:b0:8c7:1b3f:7d0c with SMTP id af79cd13be357-8cbc8e55216mr1090393285a.16.1772362767407; Sun, 01 Mar 2026 02:59:27 -0800 (PST) Date: Sun, 1 Mar 2026 12:59:23 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> X-Proofpoint-ORIG-GUID: AqYHgkeaIFy1I0tZBoVWJRpFOlKOp3bZ X-Authority-Analysis: v=2.4 cv=JoL8bc4C c=1 sm=1 tr=0 ts=69a41c10 cx=c_pps a=HLyN3IcIa5EE8TELMZ618Q==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=Dq95N7oyZucg39lo86YA:9 a=CjuIK1q_8ugA:10 a=bTQJ7kPSJx9SKPbeHEYW:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDA5OSBTYWx0ZWRfX1CMnxWNYOxdD 61g6NC0A7ONFCP2KoLCXBasSdyGsWn2PEmAClqHws9s6HMAWfsMIxkduQW9XJeBoR5CkEOnmdEN G5Nresuh53mjd6vOAmUOWaJ3WUk6ugqUSESgZCPVzHApp7Bnzx85A2T7HU5VUf6RI5kFL/jkXn6 Zw5bmr/Kxoen1EHiaGi3lrFGKB8uI/rDWyF5Rbwom3jx8BOsp8OuUxAf/KnoLurB+kLBUyq31x8 uvL2igXJ5M/ZMYJN/ZgjcOROiXQddg4adFPi9uHzEb+JxgR0mN2O4v9CfpPB/e6oqAr4ttx0mI1 WqDDUIJraNU3tdJBlWj3nysErGN9e1WgDrb9vEpvbxzC/I1Lw5XjvxfLhPkiB3C1I8iinT5tTyy mR7Gt1tZf0TI3VyC0q2tCLtbzeUN+yzmM+rFlUbNQXfi4zWHdusdZQmNjLxt7+wzvUqdFnp83+y Q6FkkJzV47vT8jFEMMw== X-Proofpoint-GUID: AqYHgkeaIFy1I0tZBoVWJRpFOlKOp3bZ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 adultscore=0 bulkscore=0 clxscore=1015 impostorscore=0 spamscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010099 On Sun, Mar 01, 2026 at 02:04:20PM +0530, Vijayanand Jitta wrote: > From: Charan Teja Kalla > > Change of_map_id() to take a pointer to struct of_phandle_args > instead of passing target device node and translated IDs separately. > Update all callers accordingly. > > Subsequent patch will make use of the args_count field in > struct of_phandle_args. > > Suggested-by: Rob Herring (Arm) > Signed-off-by: Charan Teja Kalla > Signed-off-by: Vijayanand Jitta > --- > drivers/iommu/of_iommu.c | 2 +- > drivers/of/base.c | 37 +++++++++++++++++------------------ > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > drivers/pci/controller/pcie-apple.c | 4 +++- > drivers/xen/grant-dma-ops.c | 2 +- > include/linux/of.h | 21 +++++++++++++------- > 6 files changed, 44 insertions(+), 30 deletions(-) > > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > index a0937b7b3c4d..e1d4b37d200d 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > { > u32 sid, rid = pci_dev_id(pdev); > struct apple_pcie_port *port; > + struct of_phandle_args iommu_spec = { .args_count = 1 }; Hmm, I didn't notice this. Parsing functions are expected to ignore of_phandle_args before the parsing. So passing .args_count = 1 is strange. > int idx, err; > > port = apple_pcie_get_port(pdev); -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Sun Mar 01 11:43:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 11:43:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243834.1543410 (Exim 4.92) (envelope-from ) id 1vwfCL-00047u-22; Sun, 01 Mar 2026 11:42:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243834.1543410; Sun, 01 Mar 2026 11:42:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwfCK-00047n-VZ; Sun, 01 Mar 2026 11:42:56 +0000 Received: by outflank-mailman (input) for mailman id 1243834; Sun, 01 Mar 2026 11:42:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwfCK-00047O-C7 for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 11:42:56 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c7cb559a-1563-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 12:42:53 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8E195409F6; Sun, 1 Mar 2026 11:42:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 113CAC116C6; Sun, 1 Mar 2026 11:42:51 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vwfCC-0000000EvkI-1rlx; Sun, 01 Mar 2026 11:42:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7cb559a-1563-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772365371; bh=pnG7tvFrtdyv3WXvEJzx29lT5AfLh/MG9mcbrHMAO58=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lyYXU+m2KtoMlQCaYHSTGYS7k3vPg+urdvgKLLe+VN1j5otDmcgzfqS+iLGDgFJzX jCm7hWoMDFKF2Tln9kI+qBdbepd8+KQENY3/NjjjFYTz+YGvjuP7e4k7wNe3Uk2Zgu Jr0bPBy+UyNWcQvmQCXzz+KPPnayGZHysd8y7IcOOuHF81+roKEctBCQTqq0NnX+4d fClOtSBtYojZA6yE8Z6jdIfXQIEaNPa5QpjG5XK3H5qVbVu43by8JChZx1rOYHJHuw r6L7w1bU0QM7Du1mb7FBQWrad28PDiwEwILS4hk/qRBD+Wu7VA1tNSGsNwyA07oYd8 XzD9ut4GML8xA== Date: Sun, 01 Mar 2026 11:42:47 +0000 Message-ID: <86zf4r93ns.wl-maz@kernel.org> From: Marc Zyngier To: Dmitry Baryshkov Cc: Vijayanand Jitta , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct In-Reply-To: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> <861pi3amuu.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dmitry.baryshkov@oss.qualcomm.com, vijayanand.jitta@oss.qualcomm.com, nipun.gupta@amd.com, nikhil.agarwal@amd.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, lpieralisi@kernel.org, tglx@kernel.org, robh@kernel.org, saravanak@kernel.org, hongxing.zhu@nxp.com, l.stach@pengutronix.de, kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com, Frank.Li@nxp.com, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, konrad.dybcio@oss.qualcomm.com, bjorn.andersson@oss.qualcomm.com, conor+dt@kernel.org, krzk+dt@kernel.org, prakash.gupta@oss.qualcomm.com, vikash.garodia@oss.qualcomm.com, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, charan.kalla@oss.qualcomm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 01 Mar 2026 10:46:57 +0000, Dmitry Baryshkov wrote: > > On Sun, Mar 01, 2026 at 10:02:49AM +0000, Marc Zyngier wrote: > > On Sun, 01 Mar 2026 08:34:20 +0000, > > Vijayanand Jitta wrote: > > > > > > From: Charan Teja Kalla > > > > > > Change of_map_id() to take a pointer to struct of_phandle_args > > > instead of passing target device node and translated IDs separately. > > > Update all callers accordingly. > > > > > > Subsequent patch will make use of the args_count field in > > > struct of_phandle_args. > > > > > > Suggested-by: Rob Herring (Arm) > > > Signed-off-by: Charan Teja Kalla > > > Signed-off-by: Vijayanand Jitta > > > --- > > > drivers/iommu/of_iommu.c | 2 +- > > > drivers/of/base.c | 37 +++++++++++++++++------------------ > > > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > > > drivers/pci/controller/pcie-apple.c | 4 +++- > > > drivers/xen/grant-dma-ops.c | 2 +- > > > include/linux/of.h | 21 +++++++++++++------- > > > 6 files changed, 44 insertions(+), 30 deletions(-) > > > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > > > index a511ecf21fcd..d255d0f58e8c 100644 > > > --- a/drivers/iommu/of_iommu.c > > > +++ b/drivers/iommu/of_iommu.c > > > @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > > int err; > > > > > > - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > > > + err = of_map_iommu_id(master_np, *id, &iommu_spec); > > > if (err) > > > return err; > > > > > > diff --git a/drivers/of/base.c b/drivers/of/base.c > > > index 57420806c1a2..6c3628255908 100644 > > > --- a/drivers/of/base.c > > > +++ b/drivers/of/base.c > > > @@ -2102,8 +2102,11 @@ int of_find_last_cache_level(unsigned int cpu) > > > * @id: device ID to map. > > > * @map_name: property name of the map to use. > > > * @map_mask_name: optional property name of the mask to use. > > > - * @target: optional pointer to a target device node. > > > - * @id_out: optional pointer to receive the translated ID. > > > + * @arg: of_phandle_args structure, > > > + * which includes: > > > + * np: pointer to the target device node > > > + * args_count: number of arguments > > > > Number of arguments *to what*? Isn't that the size of args[] instead? > > It is a number of values corresponding to the phandle in the DT > property. No. It is what the *caller* expects. Not what is is in the DT, which could be (and generally is) a pile of random crap. If the two don't match, return an error. But don't randomly overwrite data that is not yours. [...] > It might be not obvious here for iommu-maps, but the struct is > idiomatic in OF world. Let me quote a (trimmed) example from > qcom/sm8650.dtsi (for a different property, but it explains the meaning > of the values here): > > gem_noc: interconnect@24100000 { > #interconnect-cells = <2>; > }; > > epss_l3: interconnect@17d90000 { > #interconnect-cells = <1>; > }; > > interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY > &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>, > <&epss_l3 MASTER_EPSS_L3_APPS > &epss_l3 SLAVE_EPSS_L3_SHARED>; > /* I skipped the second pair, it adds nothing here */ > > Here the parsing function for this property (of_icc_get_by_index()) will > call of_parse_phandle_with_args() 4 times and it expects to return the > following values in the of_phandle_args: > > 1. { .np = gem_noc, .args_count = 2, .args = [MASTER_APPSS_PROC, > QCOM_ICC_TAG_ACTIVE_ONLY] } > 2. { .np = gem_noc, .args_count = 2, .args = [SLAVE_LLCC, > QCOM_ICC_TAG_ACTIVE_ONLY] } > 3. { .np = epss_l3, .args_count = 1, .args = [MASTER_EPSS_L3_APPS] } > 4. { .np = epss_l3, .args_count = 1, .args = [SLAVE_EPSS_L3_SHARED] } > > The whole of_phandle_args is then typically passed to the corresponding > xlate function, specific to the paricular .np ('provider'), which will > use #args_count values from the #args array to return the object from > the provider. > > Now let's see iommu-maps (again, qcom/sm8650.dtsi): > > apps_smmu: iommu@15000000 { > #iommu-cells = <2>; > }; > > iommu-map = <0 &apps_smmu 0x1400 0x1>, > <0x100 &apps_smmu 0x1401 0x1>; > > The property matches current definition at [1], however this spec > doesn't match the DT practice. It forces that the property should use 1 > cell for identifying the "object" in the IOMMU provider, even if the > provider expects to use 2 cells (two args). > > The correct property should look like: > > iommu-map = <0 &apps_smmu 0x1400 0x0 0x1>, > <0x100 &apps_smmu 0x1401 0x0 0x1>; > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-iommu.yaml > > > > > > + * args[]: array to receive the translated ID(s). > > > * > > > * Given a device ID, look up the appropriate implementation-defined > > > * platform ID and/or the target device which receives transactions on that > > > @@ -2117,21 +2120,21 @@ int of_find_last_cache_level(unsigned int cpu) > > > */ > > > int of_map_id(const struct device_node *np, u32 id, > > > const char *map_name, const char *map_mask_name, > > > - struct device_node **target, u32 *id_out) > > > + struct of_phandle_args *arg) > > > { > > > u32 map_mask, masked_id; > > > int map_len; > > > const __be32 *map = NULL; > > > > > > - if (!np || !map_name || (!target && !id_out)) > > > + if (!np || !map_name || !arg) > > > return -EINVAL; > > > > > > map = of_get_property(np, map_name, &map_len); > > > if (!map) { > > > - if (target) > > > + if (arg->np) > > > return -ENODEV; > > > /* Otherwise, no map implies no translation */ > > > - *id_out = id; > > > + arg->args[0] = id; > > > > What if args_count is 0? Given that you place no restriction on the > > way this can be called, that'd be entirely legitimate, and you'd > > corrupt something you're not supposed to touch. > > args is an array (not a pointer) in of_phandle_args. As such we know > that args[0] is legit. Again, no. The caller is telling you what it expects. This is strictly equivalent to: void func(void *blah[], int sz); func() is not supposed to look beyond sz. As it stands, this change in not acceptable. M. -- Without deviation from the norm, progress is not possible. From xen-devel-bounces@lists.xenproject.org Sun Mar 01 11:45:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 11:45:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243841.1543422 (Exim 4.92) (envelope-from ) id 1vwfEd-0004cv-EV; Sun, 01 Mar 2026 11:45:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243841.1543422; Sun, 01 Mar 2026 11: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 ) id 1vwfEd-0004cn-AG; Sun, 01 Mar 2026 11:45:19 +0000 Received: by outflank-mailman (input) for mailman id 1243841; Sun, 01 Mar 2026 11:45:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwfEc-0004ch-3h for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 11:45:18 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1d49f44d-1564-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 12:45:16 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 5687343D62; Sun, 1 Mar 2026 11:45:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B912C2BCB2; Sun, 1 Mar 2026 11:45:15 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vwfEW-0000000Evlq-39lc; Sun, 01 Mar 2026 11:45:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1d49f44d-1564-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772365515; bh=HO8YivHWw2NmKZjyR/AaPuMHAlumMfbukAjMxjZL6Ow=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pyVYHmTD0THNl+QW/OMlfXylHjgGxR6zOTKcWckHv/fbwcSv/a4MGsrLSPLyTt/9c m1omC4beoBiybHQqt2Onfs+8XhXwJAipyW8ze6mQXR8U8BreiItSVgmAr6NLj/ekkH 6fPIA4qi2F20OWSxjPIKmEBjsD8FUWhITpueJbN4ShldBizLAMPh9d4HopLuCX/Yef N5YF+fLvKzeP3QZQyUcqz/8XWY/svr2zap2p4hEns8t0BcDxROrFhSdvL/pcZ6bAYB oMjheTQk2V+OPqyY2/h9Po+cVyjg74hJYXwEfnN2A11MOkZAlxtC/n+7KwEhDK8gt8 KVA0jtHMBACAQ== Date: Sun, 01 Mar 2026 11:45:12 +0000 Message-ID: <86y0kb93jr.wl-maz@kernel.org> From: Marc Zyngier To: Dmitry Baryshkov Cc: Vijayanand Jitta , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct In-Reply-To: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: dmitry.baryshkov@oss.qualcomm.com, vijayanand.jitta@oss.qualcomm.com, nipun.gupta@amd.com, nikhil.agarwal@amd.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, lpieralisi@kernel.org, tglx@kernel.org, robh@kernel.org, saravanak@kernel.org, hongxing.zhu@nxp.com, l.stach@pengutronix.de, kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com, Frank.Li@nxp.com, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com, konrad.dybcio@oss.qualcomm.com, bjorn.andersson@oss.qualcomm.com, conor+dt@kernel.org, krzk+dt@kernel.org, prakash.gupta@oss.qualcomm.com, vikash.garodia@oss.qualcomm.com, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, charan.kalla@oss.qualcomm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sun, 01 Mar 2026 10:59:23 +0000, Dmitry Baryshkov wrote: > > On Sun, Mar 01, 2026 at 02:04:20PM +0530, Vijayanand Jitta wrote: > > From: Charan Teja Kalla > > > > Change of_map_id() to take a pointer to struct of_phandle_args > > instead of passing target device node and translated IDs separately. > > Update all callers accordingly. > > > > Subsequent patch will make use of the args_count field in > > struct of_phandle_args. > > > > Suggested-by: Rob Herring (Arm) > > Signed-off-by: Charan Teja Kalla > > Signed-off-by: Vijayanand Jitta > > --- > > drivers/iommu/of_iommu.c | 2 +- > > drivers/of/base.c | 37 +++++++++++++++++------------------ > > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > > drivers/pci/controller/pcie-apple.c | 4 +++- > > drivers/xen/grant-dma-ops.c | 2 +- > > include/linux/of.h | 21 +++++++++++++------- > > 6 files changed, 44 insertions(+), 30 deletions(-) > > > > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > > index a0937b7b3c4d..e1d4b37d200d 100644 > > --- a/drivers/pci/controller/pcie-apple.c > > +++ b/drivers/pci/controller/pcie-apple.c > > @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > > { > > u32 sid, rid = pci_dev_id(pdev); > > struct apple_pcie_port *port; > > + struct of_phandle_args iommu_spec = { .args_count = 1 }; > > Hmm, I didn't notice this. Parsing functions are expected to ignore > of_phandle_args before the parsing. So passing .args_count = 1 is > strange. It isn't strange. It is a semantic requirement. It explicitly indicates the boundary of what the driver is prepared to receive, just like passing a single u32 * is perfectly clear. Frankly, this patch makes an absolute mess of the current API. M. -- Without deviation from the norm, progress is not possible. From xen-devel-bounces@lists.xenproject.org Sun Mar 01 12:00:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 12:00:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243856.1543430 (Exim 4.92) (envelope-from ) id 1vwfTU-0007XT-Mh; Sun, 01 Mar 2026 12:00:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243856.1543430; Sun, 01 Mar 2026 12:00:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwfTU-0007XM-JT; Sun, 01 Mar 2026 12:00:40 +0000 Received: by outflank-mailman (input) for mailman id 1243856; Sun, 01 Mar 2026 12:00:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwfTT-0007XG-7j for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 12:00:39 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 422a1042-1566-11f1-b164-2bf370ae4941; Sun, 01 Mar 2026 13:00:37 +0100 (CET) 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 61SMU8QJ3616510 for ; Sun, 1 Mar 2026 12:00:36 GMT Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cksg72jh8-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 01 Mar 2026 12:00:35 +0000 (GMT) Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8c70fadd9a3so4001143285a.0 for ; Sun, 01 Mar 2026 04:00:35 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a115bd5a66sm1006367e87.34.2026.03.01.04.00.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Mar 2026 04:00:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 422a1042-1566-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=CHM6ea+T/SQTyKD6VE8gREYx tQS0AV0BBIY+fO3U/+Q=; b=WoP5ZbKpVdVKlkXv2aH+KEPi03kUWMTYBCJXM+o0 bueM9nMs/bFFYl420otJKZY2dXshgOWxzxAFKqgZHYZv9Y+wfE00JUx9gc9JCh6y V+d7SqShjxe+e3A4/hPi/TSmO2SHHa3u4E4bpGSwPJrOw7mX9mMBDw/bmCKTBp/I txGW5FF5wCHDF770OacBskjkh+vvedtPD21saeukgigmMIxit4IgxQAnS+fsvhPs F+p68LXBy/X93NlrWUCnmXUMXNp8Iordm9wjkO/Ua6JnTSz5zG0EFCHsrsYlGufg Kw00/KOKaJQnpLM74TWrU6XkLJxwFn1k/m3ivgU4SjGccA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772366435; x=1772971235; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CHM6ea+T/SQTyKD6VE8gREYxtQS0AV0BBIY+fO3U/+Q=; b=cgSJQYr+k+82bgGdMF4UCkz/hzNtYGcDGaQfve4Sm8O10z8Gjh3uwEoRJeoYv6Mc4h TK5HMYUDhj6ckhnS3JXeHdYt4UZC64ulhogI6vMTOyqJybZGfErNficnd2Nxcx3lefJX xG1JKJXrBGe0X9l0/JfE6wLdOkwXbNqMVgI4bv2ad7e3TtY04iWnpiDj3htwxJw63kc7 8ryKYYcbKd64Q4+g0p5yicLwiljE2hA8nO0+YFuP0PnQbiNbmrVTx2ayCVQp5FSu0viJ ub9bKCRdOX9LkHE9oAOFblbSXtc3OjUQ5Zm7PCsPF/bN92tSzh9S3Rrj8G2reYHqviUj 0LcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772366435; x=1772971235; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CHM6ea+T/SQTyKD6VE8gREYxtQS0AV0BBIY+fO3U/+Q=; b=c5bATWlC4xWj+0PwUTnR8QrsHO6y+24L1m4F0SRs5fKxytx8cSF/ZM46nTACxReQ9N PmbdskkDWm863T+qVOcsBAsCWNFKGPoAPjNZajdiUV/k3huxN2nA9xoqAsAtIGudbLSc j9Inmad4fB4fAw1bI/Plnb7vuIRL2Ct9VpLjkReTNxBJToER52xxUWT2RwvHOXbDNwX9 FPxcCLHOKnn/wev0ukkYrjELetCzz/Xhms3DWpWk2O+NWzOhdoxuBULWNEZdAe9apu8f 7pZPY5ACLqDyVJpmXrdkRQQe0Na3YTXXK4wGZXCjYbqedLwB7jItjG5RXpHXr76Qntmq Bt0Q== X-Forwarded-Encrypted: i=1; AJvYcCVuw786dOZhhGDYTHSouIp/Ux+c+ggqyp+h/Pmz3zMmMlUS60Dvz0XvBTisnef7lly/4Uo7kUr6yFU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDULQQxT+HdvHEiDbuAT1o2lE/LFkZ1jfNhri5Dkr3WKhAijeK wyDMHZWeS+fVAcM1HXyx9LhM1WdTmpHoni3D+gyM9zyYBXUcbn6tvqTqt3de9hgZ49dl/eBZp7R LGxhsWfpKjrm90oEph+m0HjOpiGA27x7iu+btPy76LBKzVs6/C3BdfHg+6PjOAs2vQ8d1ag== X-Gm-Gg: ATEYQzy6M7kVN0LtFJBZwQVlIwMuoPQu1dhnwqLYto2EsyTBracF0+TKF2b5GKD0l/W A/aZHOK7CbekMWRDrdLmUouDSzSnRZyyarjvde3gmMoPy4MpGp8crdODLugzmSof4jDcyF0nbbj HEO6yqKuheJjr1rxjBSRfc9o417UHfUVE51btD8FTgcvQ/AdsQ8endiVVv2Oz4lyjZu4y8gRya/ /pFJARNuzIj5eRPb+oIoQPLxA0OrtY6Q5jwFR6UH/StcxVtez/NEqRMKc2Xnt6lHVZylEWNN5qi 3zlZo5Ena21oIS6ZgIYDoKLobimvSz0n6/tlq8hcXJx2YK/cmmc5kdKWV2WxACBX6PM5U0N6jFb AFmaYiMaFhUuUK2wPcOXgTDAnMfH+F3mgfqNoQiV4bB3bkb+t4NqX0hLPcdIOhhzsxoFEFbu/K0 BAdvL2D+fkf6frUH/ngU/p7etB7v+1oTkXv2o= X-Received: by 2002:a05:620a:198a:b0:8b2:7435:f5ef with SMTP id af79cd13be357-8cbc8e4f7a8mr1056040185a.41.1772366434884; Sun, 01 Mar 2026 04:00:34 -0800 (PST) X-Received: by 2002:a05:620a:198a:b0:8b2:7435:f5ef with SMTP id af79cd13be357-8cbc8e4f7a8mr1056033185a.41.1772366434283; Sun, 01 Mar 2026 04:00:34 -0800 (PST) Date: Sun, 1 Mar 2026 14:00:28 +0200 From: Dmitry Baryshkov To: Marc Zyngier Cc: Vijayanand Jitta , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> <861pi3amuu.wl-maz@kernel.org> <86zf4r93ns.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86zf4r93ns.wl-maz@kernel.org> X-Proofpoint-ORIG-GUID: H51xz7HrqNA3PM1J_tRM-p4gZKWcB4fC X-Proofpoint-GUID: H51xz7HrqNA3PM1J_tRM-p4gZKWcB4fC X-Authority-Analysis: v=2.4 cv=FaA6BZ+6 c=1 sm=1 tr=0 ts=69a42a63 cx=c_pps a=HLyN3IcIa5EE8TELMZ618Q==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=YG64nluAAAAA:20 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=BCSTLeMbECCLQgZ0D0gA:9 a=CjuIK1q_8ugA:10 a=bTQJ7kPSJx9SKPbeHEYW:22 a=bA3UWDv6hWIuX7UZL3qL:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAxMDEwOCBTYWx0ZWRfX0pAeYKvU+Pfy tj392hXrG0VguXMbtV/3JLBIhJ1VxRWYrbUimoRtnUAWFv4ebQYhJIHZfYiA1X/2WIVlS5Gj+Gp SMgHtLaG1If3HT4FUu7K2KP9/EZWhtSQlKV4uGQg714o+FbnQxLVMAY+jkzppH8wBWLSiPurEN2 kDwWU+i2gZ923ZNoIp4aWWo2qQH9zwsyN4V7e4BTw2d39/SLhkWgPpv5XNguP+rRBVOOrfA+O3u 3Cw7kn2RRbvjpaC/tWQcoFi3GaQerQOiwz/JF9p0mMNFbBWArjXT4RuPLOMcQ8BR/LV2WZlgP/I HOR0KF0gBr/vaTbFuuzjBaOgJZ9VvO8/DZFOHjxi3l5f51GGG5bAIzTnLmnp4cdJAtWF8Zi1rfE 9m9spBa6PX8Jzx6/yDxsgUM7I5yxL0c1I2coQdTWXp9APPj1sghSQeLlW781mjs+LgA4lfzgCFA 2618DG6/DoCAH6F7/IA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-01_01,2026-02-27_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 bulkscore=0 adultscore=0 malwarescore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603010108 On Sun, Mar 01, 2026 at 11:42:47AM +0000, Marc Zyngier wrote: > On Sun, 01 Mar 2026 10:46:57 +0000, > Dmitry Baryshkov wrote: > > > > On Sun, Mar 01, 2026 at 10:02:49AM +0000, Marc Zyngier wrote: > > > On Sun, 01 Mar 2026 08:34:20 +0000, > > > Vijayanand Jitta wrote: > > > > > > > > From: Charan Teja Kalla > > > > > > > > Change of_map_id() to take a pointer to struct of_phandle_args > > > > instead of passing target device node and translated IDs separately. > > > > Update all callers accordingly. > > > > > > > > Subsequent patch will make use of the args_count field in > > > > struct of_phandle_args. > > > > > > > > Suggested-by: Rob Herring (Arm) > > > > Signed-off-by: Charan Teja Kalla > > > > Signed-off-by: Vijayanand Jitta > > > > --- > > > > drivers/iommu/of_iommu.c | 2 +- > > > > drivers/of/base.c | 37 +++++++++++++++++------------------ > > > > drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- > > > > drivers/pci/controller/pcie-apple.c | 4 +++- > > > > drivers/xen/grant-dma-ops.c | 2 +- > > > > include/linux/of.h | 21 +++++++++++++------- > > > > 6 files changed, 44 insertions(+), 30 deletions(-) > > > > > > > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > > > > index a511ecf21fcd..d255d0f58e8c 100644 > > > > --- a/drivers/iommu/of_iommu.c > > > > +++ b/drivers/iommu/of_iommu.c > > > > @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > > > > struct of_phandle_args iommu_spec = { .args_count = 1 }; > > > > int err; > > > > > > > > - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > > > > + err = of_map_iommu_id(master_np, *id, &iommu_spec); > > > > if (err) > > > > return err; > > > > > > > > diff --git a/drivers/of/base.c b/drivers/of/base.c > > > > index 57420806c1a2..6c3628255908 100644 > > > > --- a/drivers/of/base.c > > > > +++ b/drivers/of/base.c > > > > @@ -2102,8 +2102,11 @@ int of_find_last_cache_level(unsigned int cpu) > > > > * @id: device ID to map. > > > > * @map_name: property name of the map to use. > > > > * @map_mask_name: optional property name of the mask to use. > > > > - * @target: optional pointer to a target device node. > > > > - * @id_out: optional pointer to receive the translated ID. > > > > + * @arg: of_phandle_args structure, > > > > + * which includes: > > > > + * np: pointer to the target device node > > > > + * args_count: number of arguments > > > > > > Number of arguments *to what*? Isn't that the size of args[] instead? > > > > It is a number of values corresponding to the phandle in the DT > > property. > > No. It is what the *caller* expects. Not what is is in the DT, which > could be (and generally is) a pile of random crap. Nice > If the two don't > match, return an error. But don't randomly overwrite data that is not > yours. Mark, no. The caller can't know how many cell arguments the provider uses until: - the provider handle is parsed - provider node is consulted for the #foo-cells It is not a number of arguments for the _caller_. It is how many u32 values are used by the _provider_. In case of IOMMUs, enough IOMMU devices have #iommu-cells = <2>, which means that it uses two u32 values to identify the SID or set of SIDs. Following your analogy, if we force 1 cell in the iommu-map property, we are trying to force the function which expects to take two arguments to accept just one. But it's not the caller, it's the IOMMU's xlate function. > > [...] > > > It might be not obvious here for iommu-maps, but the struct is > > idiomatic in OF world. Let me quote a (trimmed) example from > > qcom/sm8650.dtsi (for a different property, but it explains the meaning > > of the values here): > > > > gem_noc: interconnect@24100000 { > > #interconnect-cells = <2>; > > }; > > > > epss_l3: interconnect@17d90000 { > > #interconnect-cells = <1>; > > }; > > > > interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY > > &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>, > > <&epss_l3 MASTER_EPSS_L3_APPS > > &epss_l3 SLAVE_EPSS_L3_SHARED>; > > /* I skipped the second pair, it adds nothing here */ > > > > Here the parsing function for this property (of_icc_get_by_index()) will > > call of_parse_phandle_with_args() 4 times and it expects to return the > > following values in the of_phandle_args: > > > > 1. { .np = gem_noc, .args_count = 2, .args = [MASTER_APPSS_PROC, > > QCOM_ICC_TAG_ACTIVE_ONLY] } > > 2. { .np = gem_noc, .args_count = 2, .args = [SLAVE_LLCC, > > QCOM_ICC_TAG_ACTIVE_ONLY] } > > 3. { .np = epss_l3, .args_count = 1, .args = [MASTER_EPSS_L3_APPS] } > > 4. { .np = epss_l3, .args_count = 1, .args = [SLAVE_EPSS_L3_SHARED] } > > > > The whole of_phandle_args is then typically passed to the corresponding > > xlate function, specific to the paricular .np ('provider'), which will > > use #args_count values from the #args array to return the object from > > the provider. > > > > Now let's see iommu-maps (again, qcom/sm8650.dtsi): > > > > apps_smmu: iommu@15000000 { > > #iommu-cells = <2>; > > }; > > > > iommu-map = <0 &apps_smmu 0x1400 0x1>, > > <0x100 &apps_smmu 0x1401 0x1>; > > > > The property matches current definition at [1], however this spec > > doesn't match the DT practice. It forces that the property should use 1 > > cell for identifying the "object" in the IOMMU provider, even if the > > provider expects to use 2 cells (two args). > > > > The correct property should look like: > > > > iommu-map = <0 &apps_smmu 0x1400 0x0 0x1>, > > <0x100 &apps_smmu 0x1401 0x0 0x1>; > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pci/pci-iommu.yaml > > > > > > > > > + * args[]: array to receive the translated ID(s). > > > > * > > > > * Given a device ID, look up the appropriate implementation-defined > > > > * platform ID and/or the target device which receives transactions on that > > > > @@ -2117,21 +2120,21 @@ int of_find_last_cache_level(unsigned int cpu) > > > > */ > > > > int of_map_id(const struct device_node *np, u32 id, > > > > const char *map_name, const char *map_mask_name, > > > > - struct device_node **target, u32 *id_out) > > > > + struct of_phandle_args *arg) > > > > { > > > > u32 map_mask, masked_id; > > > > int map_len; > > > > const __be32 *map = NULL; > > > > > > > > - if (!np || !map_name || (!target && !id_out)) > > > > + if (!np || !map_name || !arg) > > > > return -EINVAL; > > > > > > > > map = of_get_property(np, map_name, &map_len); > > > > if (!map) { > > > > - if (target) > > > > + if (arg->np) > > > > return -ENODEV; > > > > /* Otherwise, no map implies no translation */ > > > > - *id_out = id; > > > > + arg->args[0] = id; > > > > > > What if args_count is 0? Given that you place no restriction on the > > > way this can be called, that'd be entirely legitimate, and you'd > > > corrupt something you're not supposed to touch. > > > > args is an array (not a pointer) in of_phandle_args. As such we know > > that args[0] is legit. > > Again, no. The caller is telling you what it expects. This is strictly > equivalent to: > > void func(void *blah[], int sz); > > func() is not supposed to look beyond sz. As it stands, this change in > not acceptable. DT parsing functions follow a different approach, because of the "random crap". It is: int parse(void *phandle, u32 **args, int *sz); So, if the caller insists that it can handle only one argument, it should call parse(), then check that (sz == 1) and return -EINVAL otherwise (kfreeing *args and of_node_puting phandle while it does so). I will quote of_phandle_args here: struct of_phandle_args { struct device_node *np; int args_count; uint32_t args[MAX_PHANDLE_ARGS]; }; Please take a look at how of_parse_phandle_with_args() works. -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Sun Mar 01 15:04:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 01 Mar 2026 15:04:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243903.1543442 (Exim 4.92) (envelope-from ) id 1vwiLQ-0003VP-1f; Sun, 01 Mar 2026 15:04:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243903.1543442; Sun, 01 Mar 2026 15:04:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwiLP-0003VI-Tc; Sun, 01 Mar 2026 15:04:31 +0000 Received: by outflank-mailman (input) for mailman id 1243903; Sun, 01 Mar 2026 15:04:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwiLO-0003VC-1t for xen-devel@lists.xenproject.org; Sun, 01 Mar 2026 15:04:30 +0000 Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ee1dcc03-157f-11f1-9ccf-f158ae23cfc8; Sun, 01 Mar 2026 16:04:23 +0100 (CET) Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id EF5351400041; Sun, 1 Mar 2026 10:04:21 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sun, 01 Mar 2026 10:04:21 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 1 Mar 2026 10:04:20 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee1dcc03-157f-11f1-9ccf-f158ae23cfc8 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:message-id:mime-version:reply-to :subject:subject:to:to; s=fm3; t=1772377461; x=1772463861; bh=WE DyKPtzrdTYeQrs6sXaKHMHgxci7AQYZmlLMmwrR0c=; b=MOZckj4blRe6GpBJ9K mrFLHjWzhvxV6IfWrMeYsZv94I73ac4DisWR9mr4KIfWY6qe9MruhZm5BfVk8DlI qrGswbo6ttGYzCIYr8HJWwjj5a0XfLruQebDPGlt1JmAaLnDpu30jYeaoxzbASyz gpCPiho2r9CAO+QI4recP3De4mNH3V1/fg7Y3w+hORWaohNdrYQW0DfCMwENkaJN lqJXhPmfV7focWMPJ1MMtyw2BPU2CyAg16i+IrlNwHqRo4zB0VEstzZT88MnvUBt Imz8PHxQY8c8SUtSc3EfiNLlhLPeM+QJ8KlvB64JDeJSq62PpUycsdv7s0DdvuQ5 tehA== 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:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1772377461; x= 1772463861; bh=WEDyKPtzrdTYeQrs6sXaKHMHgxci7AQYZmlLMmwrR0c=; b=f kG6+E2VoodApJN/EJ8l7DI2H1dhuidCPTWV00X9B2K4adlBSduICjvJOcD1U54mO JcZ1eZ6VsLEDOJinDsZihX1KIbUYIJbKzHeKbu0j0wUv+LN/gKnKObCzcW7HvXts wKp9SXyJ2Yp8mzUJSvFY4854RXzyJL+0rDc1Mw9szORGOpieneM4KiaZmZNGhvjX WlHn8xHK/IR4Yj9catvZYjrFPRfeF9xxwoHGlhuC0HEWlk5YDBPIr9Ms0osDBdkl z1KGPsEkTd+CvSAhv90h+MG6v9usy8QeSjqXj+tpzWx+HOOzSfnYinH+avlYPz9K /ozYPZPF1qroMkGmflHBw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheehuddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcuofgr rhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvihhsih gslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephfetuefhiefg tddtlefggffggeevhedtvdefffeugfeiieeiheefteefgefggeejnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhmpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpohhuthdprhgtphhtthho peigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtph htthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtohepsghorhhishdrohhs thhrohhvshhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheprghkphhmsehlihhnuh igqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopegurghvihgusehkvghrnhgv lhdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 1 Mar 2026 16:04:17 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Juergen Gross , Boris Ostrovsky , Andrew Morton , David Hildenbrand Subject: Excluding init_on_free for pages for initial balloon down (Xen) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TuuO5D0SW37++uJS" Content-Disposition: inline --TuuO5D0SW37++uJS Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Mar 2026 16:04:17 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Cc: Juergen Gross , Boris Ostrovsky , Andrew Morton , David Hildenbrand Subject: Excluding init_on_free for pages for initial balloon down (Xen) Hi, Some time ago I made a change to disable scrubbing pages that are ballooned out during system boot. I'll paste the whole commit message as it's relevant here: 197ecb3802c0 xen/balloon: add runtime control for scrubbing ballooned o= ut pages Scrubbing pages on initial balloon down can take some time, especially in nested virtualization case (nested EPT is slow). When HVM/PVH guest = is started with memory=3D significantly lower than maxmem=3D, all the extra pages will be scrubbed before returning to Xen. But since most of them weren't used at all at that point, Xen needs to populate them first (from populate-on-demand pool). In nested virt case (Xen inside KVM) this slows down the guest boot by 15-30s with just 1.5GB needed to be returned to Xen. =20 Add runtime parameter to enable/disable it, to allow initially disabling scrubbing, then enable it back during boot (for example in initramfs). Such usage relies on assumption that a) most pages ballooned out during initial boot weren't used at all, and b) even if they were, very few secrets are in the guest at that time (before any serious userspace kicks in). Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_SCRUB_PAGES_DEFAULT (also enabled by default), controlling default value for the new runtime switch. Now, I face the same issue with init_on_free/init_on_alloc (not sure which one applies here, probably the latter one), which several distributions enable by default. The result is (see timestamps): [2026-02-24 01:12:55] [ 7.485151] xen:balloon: Waiting for initial b= allooning down having finished. [2026-02-24 01:14:14] [ 86.581510] xen:balloon: Initial ballooning do= wn finished. But here the situation is a bit more complicated: init_on_free/init_on_alloc applies to any pages, not just those for balloon driver. I see two approaches to solve the issue: 1. Similar to xen_scrub_pages=3D, add a runtime switch for init_on_free/init_on_alloc, then force them off during boot, and re-enable early in initramfs. 2. Somehow adjust balloon driver to bypass init_on_alloc when ballooning a page out. The first approach is likely easier to implement, but also has some drawbacks: it may result in some kernel structures that are allocated early to remain with garbage data in uninitialized places. While it may not matter during early boot, such structures may survive for quite some time, and maybe attacker can use them later on to exploit some other bug. This wasn't really a concern with xen_scrub_pages, as those pages were immediately ballooned out. The second approach sounds architecturally better, and maybe init_on_alloc could be always bypassed during balloon out? The balloon driver can scrub the page on its own already (which is enabled by default). That of course assumes the issue is only about init_on_alloc, not init_on_free (or both) - which I haven't really confirmed yet... If going this way, I see the balloon driver does basically alloc_page(GFP_BALLOON), where GFP_BALLOON is: /* When ballooning out (allocating memory to return to Xen) we don't re= ally want the kernel to try too hard since that can trigger the oom kille= r. */ #define GFP_BALLOON \ (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC) Would that be about adding some new flag here? Or maybe there is already one for this purpose? Any opinions? PS issue tracked at https://github.com/QubesOS/qubes-issues/issues/10723 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --TuuO5D0SW37++uJS Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmkVXEACgkQ24/THMrX 1ywhmgf/eZeGTjx6//+hTB2Qy9RqzuXOwOQ6AfyQquM85TNDY4pn/smySDi3d6PL fHo5sweOijroW7tFUMeUQPO+7IewuVJo9OlE9wq09nM3J5KwiamrKDrgedaDuqP5 1Trg1sd4LV+qLNXvlHHZ49EuSoNzbz76ZBcHZQwqnGWF5L8Y9ruqQXPKpoi1MplN 5A2uOLr9QWYIrpYkMxl+8bMzlGWS+nhASDy4V/0R2ba5z6QzPS/4RMI/p65SalHI ZfiER1PFuL+bIo+SWciATW+SJgC5XmmMXPW3NbTrKVyFW8+tcu3u31pvJKivC5qy zvseR3nvv808lqmg/ErE6FXP7nRWWg== =Uy3v -----END PGP SIGNATURE----- --TuuO5D0SW37++uJS-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 06:37:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 06:37:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243968.1543451 (Exim 4.92) (envelope-from ) id 1vwwtd-0004eE-Ss; Mon, 02 Mar 2026 06:36:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243968.1543451; Mon, 02 Mar 2026 06: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 ) id 1vwwtd-0004e6-Nn; Mon, 02 Mar 2026 06:36:49 +0000 Received: by outflank-mailman (input) for mailman id 1243968; Mon, 02 Mar 2026 06:36:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwwtc-0004e0-1O for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 06:36:48 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2b9a331f-1602-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 07:36:40 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b936505e7a0so2541266b.1 for ; Sun, 01 Mar 2026 22:36:40 -0800 (PST) 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-b935ae93357sm432523066b.48.2026.03.01.22.36.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 01 Mar 2026 22:36:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2b9a331f-1602-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772433400; x=1773038200; darn=lists.xenproject.org; h=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; bh=VFeJ+uog/nc+ErP+4beRmfPzDf5x5oIBCjw/2iilkvM=; b=gTXeXyGyTZvOJiYne9hZ078Icpmc8767kQeOwZ/E+zH7Oj3vgvpxPSISko7/qqio3L huOE6zdCd8Y0pMRUcIdZSI3bsr76TrKprG9FDvLhOObZHsMtV/CooV0vdaHEUAemrZwI g8FkfeUAqz8z4EQo8qKSt/zol2d6PMMeoufp8cflMe6cWnqvJEQRhcjYbspuJfwTe/CX 6yYcsWadUv6bzEdGThE7u67yGWuic6m0wmIhsHB9iZlLbiH6BdZ9a8ExOit9SS3PYZIF KJOeoibbdM825APx+6kku+Ddom8ZmGSib9pOnQCIJIqyL8YPMjaTp+9wHnev9V40l1s5 3V6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772433400; x=1773038200; h=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; bh=VFeJ+uog/nc+ErP+4beRmfPzDf5x5oIBCjw/2iilkvM=; b=TH6+vTk8YF+KThDDEyR5CqLho7YWznJ5GUvSWXgHK21kkXHrKynCqHi/EkIPkZjtxF 0ujnFzKlEKTvtLZykjAYIiIlFODOpyNmT8BVB4b3eU8Diju9HXplBxILPjS3DG4JxBNI o9w8/qQlGXs+9SDnZzgo1A40yUSeuJcgQ2Bcb5J4E59Dw9znGmmJv2v3y6L8IaU3qp14 IPoZRjxW/yhcEOCHRp9DnQTOF59vYAzQpA5Zwo7v1xG2yZXFltRYvwvXpgtKmA/wG4jZ H1/zRPqUfYPywA3G0jvTJKh4kJ6DaWwg0hvYSTLlAQsTKeQBDaWofW0ocOtJ5vms//EH SbJQ== X-Forwarded-Encrypted: i=1; AJvYcCVQTnOOOPjrXl0cjXSSd0d0uAuj7IvIyadT5SPRlF3kWGUDoxEbWgRIssOgV1ctOXJUbyHYYL050AE=@lists.xenproject.org X-Gm-Message-State: AOJu0YyjqJDG7AVaPU6OBDSZrUQ3i5XgkigtlJW3t6gzbdM3NKcKsZrc rZbQHu0gbWVBRpDrIZbQX1zPDdRTJmVClEu7fKyziWcVFSe8CE/YK2hBddmlnabdZlyoecnZD8+ 0gRvZ X-Gm-Gg: ATEYQzxAWCt5iebCQV5epe2Klgj3xZQF6ZXQab54FVNbQHKsi0xochjS8z2kj718BYN RADGlfzwmgcqBiS9cGz6K3eu3MMD/jjSxGEbFpcqsJvn7VprilLm52nVohhy0CCRs8GqjW1dn38 fWUkN+djTujReVyLLhnMd6BHNgqyfHPfT0CwS4w2nItR5phR4AufLrbjs9X4dCsVv/IHw2rn9rd vtm1N8nvao8FwoScFDNLo/F0FaDijdGeAeVNCAm6Od9T+Yk+Hf7fhZqUHDTYgezJqIfvuDiOu0D TBQdnvTXOK0otLl+LGnibmKkRjZDGRrWhxbofWznnBKizJsaZU9m8OrlJan8JVmGFS3VTDVlADy rrmJ9uerNuOixOJWYKgopskrH7UdxoRq/Y3B6rcNrzGeqa0w7ulUq9NCzNwUOBCZNdijrbvDdkG WwLRgkyhpIi64JqeohoR3LYO6ZOW4NSc6BmK1Xr/edH35gmnvphEdbCB2I74MBSPN7OKndjN5Y1 JiFyOG1CwrzzrxV2XBMNHQMIpIe56W4JeSqfgw1C/MJCmv0jxa/Pg== X-Received: by 2002:a17:906:abc7:b0:b93:6360:9072 with SMTP id a640c23a62f3a-b936360a883mr727897966b.6.1772433399602; Sun, 01 Mar 2026 22:36:39 -0800 (PST) Message-ID: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> Date: Mon, 2 Mar 2026 07:36:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Boris Ostrovsky , Andrew Morton , David Hildenbrand References: Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------qOpJCOcuQxIXdDyr1Z4W58Du" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------qOpJCOcuQxIXdDyr1Z4W58Du Content-Type: multipart/mixed; boundary="------------K1a5M0y8ZSsiDXJ2z5xwGIzT"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Boris Ostrovsky , Andrew Morton , David Hildenbrand Message-ID: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) References: In-Reply-To: --------------K1a5M0y8ZSsiDXJ2z5xwGIzT Content-Type: multipart/mixed; boundary="------------VJ240JE505tAHMm1IzpxKJeu" --------------VJ240JE505tAHMm1IzpxKJeu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDMuMjYgMTY6MDQsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN Cj4gSGksDQo+IA0KPiBTb21lIHRpbWUgYWdvIEkgbWFkZSBhIGNoYW5nZSB0byBkaXNhYmxl IHNjcnViYmluZyBwYWdlcyB0aGF0IGFyZQ0KPiBiYWxsb29uZWQgb3V0IGR1cmluZyBzeXN0 ZW0gYm9vdC4gSSdsbCBwYXN0ZSB0aGUgd2hvbGUgY29tbWl0IG1lc3NhZ2UgYXMNCj4gaXQn cyByZWxldmFudCBoZXJlOg0KPiANCj4gICAgICAxOTdlY2IzODAyYzAgeGVuL2JhbGxvb246 IGFkZCBydW50aW1lIGNvbnRyb2wgZm9yIHNjcnViYmluZyBiYWxsb29uZWQgb3V0IHBhZ2Vz DQo+IA0KPiAgICAgIFNjcnViYmluZyBwYWdlcyBvbiBpbml0aWFsIGJhbGxvb24gZG93biBj YW4gdGFrZSBzb21lIHRpbWUsIGVzcGVjaWFsbHkNCj4gICAgICBpbiBuZXN0ZWQgdmlydHVh bGl6YXRpb24gY2FzZSAobmVzdGVkIEVQVCBpcyBzbG93KS4gV2hlbiBIVk0vUFZIIGd1ZXN0 IGlzDQo+ICAgICAgc3RhcnRlZCB3aXRoIG1lbW9yeT0gc2lnbmlmaWNhbnRseSBsb3dlciB0 aGFuIG1heG1lbT0sIGFsbCB0aGUgZXh0cmENCj4gICAgICBwYWdlcyB3aWxsIGJlIHNjcnVi YmVkIGJlZm9yZSByZXR1cm5pbmcgdG8gWGVuLiBCdXQgc2luY2UgbW9zdCBvZiB0aGVtDQo+ ICAgICAgd2VyZW4ndCB1c2VkIGF0IGFsbCBhdCB0aGF0IHBvaW50LCBYZW4gbmVlZHMgdG8g cG9wdWxhdGUgdGhlbSBmaXJzdA0KPiAgICAgIChmcm9tIHBvcHVsYXRlLW9uLWRlbWFuZCBw b29sKS4gSW4gbmVzdGVkIHZpcnQgY2FzZSAoWGVuIGluc2lkZSBLVk0pDQo+ICAgICAgdGhp cyBzbG93cyBkb3duIHRoZSBndWVzdCBib290IGJ5IDE1LTMwcyB3aXRoIGp1c3QgMS41R0Ig bmVlZGVkIHRvIGJlDQo+ICAgICAgcmV0dXJuZWQgdG8gWGVuLg0KPiAgICAgIA0KPiAgICAg IEFkZCBydW50aW1lIHBhcmFtZXRlciB0byBlbmFibGUvZGlzYWJsZSBpdCwgdG8gYWxsb3cg aW5pdGlhbGx5IGRpc2FibGluZw0KPiAgICAgIHNjcnViYmluZywgdGhlbiBlbmFibGUgaXQg YmFjayBkdXJpbmcgYm9vdCAoZm9yIGV4YW1wbGUgaW4gaW5pdHJhbWZzKS4NCj4gICAgICBT dWNoIHVzYWdlIHJlbGllcyBvbiBhc3N1bXB0aW9uIHRoYXQgYSkgbW9zdCBwYWdlcyBiYWxs b29uZWQgb3V0IGR1cmluZw0KPiAgICAgIGluaXRpYWwgYm9vdCB3ZXJlbid0IHVzZWQgYXQg YWxsLCBhbmQgYikgZXZlbiBpZiB0aGV5IHdlcmUsIHZlcnkgZmV3DQo+ICAgICAgc2VjcmV0 cyBhcmUgaW4gdGhlIGd1ZXN0IGF0IHRoYXQgdGltZSAoYmVmb3JlIGFueSBzZXJpb3VzIHVz ZXJzcGFjZQ0KPiAgICAgIGtpY2tzIGluKS4NCj4gICAgICBDb252ZXJ0IENPTkZJR19YRU5f U0NSVUJfUEFHRVMgdG8gQ09ORklHX1hFTl9TQ1JVQl9QQUdFU19ERUZBVUxUIChhbHNvDQo+ ICAgICAgZW5hYmxlZCBieSBkZWZhdWx0KSwgY29udHJvbGxpbmcgZGVmYXVsdCB2YWx1ZSBm b3IgdGhlIG5ldyBydW50aW1lDQo+ICAgICAgc3dpdGNoLg0KPiANCj4gTm93LCBJIGZhY2Ug dGhlIHNhbWUgaXNzdWUgd2l0aCBpbml0X29uX2ZyZWUvaW5pdF9vbl9hbGxvYyAobm90IHN1 cmUNCj4gd2hpY2ggb25lIGFwcGxpZXMgaGVyZSwgcHJvYmFibHkgdGhlIGxhdHRlciBvbmUp LCB3aGljaCBzZXZlcmFsDQo+IGRpc3RyaWJ1dGlvbnMgZW5hYmxlIGJ5IGRlZmF1bHQuIFRo ZSByZXN1bHQgaXMgKHNlZSB0aW1lc3RhbXBzKToNCj4gDQo+ICAgICAgWzIwMjYtMDItMjQg MDE6MTI6NTVdIFsgICAgNy40ODUxNTFdIHhlbjpiYWxsb29uOiBXYWl0aW5nIGZvciBpbml0 aWFsIGJhbGxvb25pbmcgZG93biBoYXZpbmcgZmluaXNoZWQuDQo+ICAgICAgWzIwMjYtMDIt MjQgMDE6MTQ6MTRdIFsgICA4Ni41ODE1MTBdIHhlbjpiYWxsb29uOiBJbml0aWFsIGJhbGxv b25pbmcgZG93biBmaW5pc2hlZC4NCj4gDQo+IEJ1dCBoZXJlIHRoZSBzaXR1YXRpb24gaXMg YSBiaXQgbW9yZSBjb21wbGljYXRlZDoNCj4gaW5pdF9vbl9mcmVlL2luaXRfb25fYWxsb2Mg YXBwbGllcyB0byBhbnkgcGFnZXMsIG5vdCBqdXN0IHRob3NlIGZvcg0KPiBiYWxsb29uIGRy aXZlci4gSSBzZWUgdHdvIGFwcHJvYWNoZXMgdG8gc29sdmUgdGhlIGlzc3VlOg0KPiAxLiBT aW1pbGFyIHRvIHhlbl9zY3J1Yl9wYWdlcz0sIGFkZCBhIHJ1bnRpbWUgc3dpdGNoIGZvcg0K PiAgICAgaW5pdF9vbl9mcmVlL2luaXRfb25fYWxsb2MsIHRoZW4gZm9yY2UgdGhlbSBvZmYg ZHVyaW5nIGJvb3QsIGFuZA0KPiAgICAgcmUtZW5hYmxlIGVhcmx5IGluIGluaXRyYW1mcy4N Cj4gMi4gU29tZWhvdyBhZGp1c3QgYmFsbG9vbiBkcml2ZXIgdG8gYnlwYXNzIGluaXRfb25f YWxsb2Mgd2hlbiBiYWxsb29uaW5nDQo+ICAgICBhIHBhZ2Ugb3V0Lg0KPiANCj4gVGhlIGZp cnN0IGFwcHJvYWNoIGlzIGxpa2VseSBlYXNpZXIgdG8gaW1wbGVtZW50LCBidXQgYWxzbyBo YXMgc29tZQ0KPiBkcmF3YmFja3M6IGl0IG1heSByZXN1bHQgaW4gc29tZSBrZXJuZWwgc3Ry dWN0dXJlcyB0aGF0IGFyZSBhbGxvY2F0ZWQNCj4gZWFybHkgdG8gcmVtYWluIHdpdGggZ2Fy YmFnZSBkYXRhIGluIHVuaW5pdGlhbGl6ZWQgcGxhY2VzLiBXaGlsZSBpdCBtYXkNCj4gbm90 IG1hdHRlciBkdXJpbmcgZWFybHkgYm9vdCwgc3VjaCBzdHJ1Y3R1cmVzIG1heSBzdXJ2aXZl IGZvciBxdWl0ZSBzb21lDQo+IHRpbWUsIGFuZCBtYXliZSBhdHRhY2tlciBjYW4gdXNlIHRo ZW0gbGF0ZXIgb24gdG8gZXhwbG9pdCBzb21lIG90aGVyDQo+IGJ1Zy4gVGhpcyB3YXNuJ3Qg cmVhbGx5IGEgY29uY2VybiB3aXRoIHhlbl9zY3J1Yl9wYWdlcywgYXMgdGhvc2UgcGFnZXMN Cj4gd2VyZSBpbW1lZGlhdGVseSBiYWxsb29uZWQgb3V0Lg0KPiANCj4gVGhlIHNlY29uZCBh cHByb2FjaCBzb3VuZHMgYXJjaGl0ZWN0dXJhbGx5IGJldHRlciwgYW5kIG1heWJlDQo+IGlu aXRfb25fYWxsb2MgY291bGQgYmUgYWx3YXlzIGJ5cGFzc2VkIGR1cmluZyBiYWxsb29uIG91 dD8gVGhlIGJhbGxvb24NCj4gZHJpdmVyIGNhbiBzY3J1YiB0aGUgcGFnZSBvbiBpdHMgb3du IGFscmVhZHkgKHdoaWNoIGlzIGVuYWJsZWQgYnkNCj4gZGVmYXVsdCkuIFRoYXQgb2YgY291 cnNlIGFzc3VtZXMgdGhlIGlzc3VlIGlzIG9ubHkgYWJvdXQgaW5pdF9vbl9hbGxvYywNCj4g bm90IGluaXRfb25fZnJlZSAob3IgYm90aCkgLSB3aGljaCBJIGhhdmVuJ3QgcmVhbGx5IGNv bmZpcm1lZCB5ZXQuLi4NCj4gSWYgZ29pbmcgdGhpcyB3YXksIEkgc2VlIHRoZSBiYWxsb29u IGRyaXZlciBkb2VzIGJhc2ljYWxseQ0KPiBhbGxvY19wYWdlKEdGUF9CQUxMT09OKSwgd2hl cmUgR0ZQX0JBTExPT04gaXM6DQo+IA0KPiAgICAgIC8qIFdoZW4gYmFsbG9vbmluZyBvdXQg KGFsbG9jYXRpbmcgbWVtb3J5IHRvIHJldHVybiB0byBYZW4pIHdlIGRvbid0IHJlYWxseQ0K PiAgICAgICAgIHdhbnQgdGhlIGtlcm5lbCB0byB0cnkgdG9vIGhhcmQgc2luY2UgdGhhdCBj YW4gdHJpZ2dlciB0aGUgb29tIGtpbGxlci4gKi8NCj4gICAgICAjZGVmaW5lIEdGUF9CQUxM T09OIFwNCj4gICAgICAgICAgKEdGUF9ISUdIVVNFUiB8IF9fR0ZQX05PV0FSTiB8IF9fR0ZQ X05PUkVUUlkgfCBfX0dGUF9OT01FTUFMTE9DKQ0KPiANCj4gV291bGQgdGhhdCBiZSBhYm91 dCBhZGRpbmcgc29tZSBuZXcgZmxhZyBoZXJlPyBPciBtYXliZSB0aGVyZSBpcyBhbHJlYWR5 DQo+IG9uZSBmb3IgdGhpcyBwdXJwb3NlPw0KDQpUaGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUg YSBmbGFnIGZvciB0aGF0Lg0KDQpCdXQgSSB0aGluayBhZGRpbmcgYSBuZXcgZmxhZyBfX0dG UF9OT19JTklUIGFuZCB0ZXN0aW5nIHRoYXQgaW4NCndhbnRfaW5pdF9vbl9hbGxvYygpIF9i ZWZvcmVfIGNoZWNraW5nIENPTkZJR19JTklUX09OX0FMTE9DX0RFRkFVTFRfT04NCndvdWxk IGJlIGEgc2Vuc2libGUgYXBwcm9hY2guDQoNCj4gQW55IG9waW5pb25zPw0KDQpZb3UgYXJl IGF3YXJlIG9mIHRoZSAiaW5pdF9vbl9hbGxvYyIgYm9vdCBwYXJhbWV0ZXI/IFNvIGlmIHRo aXMgaXMgZmluZQ0KZm9yIHlvdSwgeW91IGNvdWxkIGp1c3QgdXNlIGFwcHJvYWNoIDEgYWJv dmUgd2l0aG91dCBhbnkga2VybmVsIHBhdGNoZXMNCm5lZWRlZC4NCg0KDQpKdWVyZ2VuDQo= --------------VJ240JE505tAHMm1IzpxKJeu 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----- --------------VJ240JE505tAHMm1IzpxKJeu-- --------------K1a5M0y8ZSsiDXJ2z5xwGIzT-- --------------qOpJCOcuQxIXdDyr1Z4W58Du 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/Ey8FAmmlL/YFAwAAAAAACgkQsN6d1ii/Ey81 qQf+PTMsI7Hq7JSUHhpmr/vwbm8btfqjtmwua2OO13bo7WqKkmuLDhXULaUgxZK+XYeFSKD+AcDM COd+7jWlsXc2qAIZVI5G/T2eKS0ffRDeAogYTHIa4DtCkiNophXREE/vzVq1/BP+66StkE9FBC9U JL0T/rjZtlsIgR1VmoGwp3BaRDnw/7/nNeth/LO1v42SrYZZqgusREzUpnrdS8qHM/84aAPc4cmI Qe7KY0q50wjAufDu5UyolUsnIarLDtg6OExXUpMPGyyg8fLV8bXmHueaDgyomGwpz86PE2THkXDM ldb/CetwNror1xjYQdVWQBc5zQGcKBqvcNFjqUyVyQ== =4j19 -----END PGP SIGNATURE----- --------------qOpJCOcuQxIXdDyr1Z4W58Du-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 08:34:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 08:34:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243989.1543462 (Exim 4.92) (envelope-from ) id 1vwyiw-0002PX-3r; Mon, 02 Mar 2026 08:33:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243989.1543462; Mon, 02 Mar 2026 08:33:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwyiv-0002PQ-WE; Mon, 02 Mar 2026 08:33:54 +0000 Received: by outflank-mailman (input) for mailman id 1243989; Mon, 02 Mar 2026 08:33:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwyiu-0002PF-H6 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 08:33:52 +0000 Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [2607:f8b0:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 84d7210a-1612-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 09:33:42 +0100 (CET) Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-7d598f4b6fdso937832a34.1 for ; Mon, 02 Mar 2026 00:33:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 84d7210a-1612-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1772440421; cv=none; d=google.com; s=arc-20240605; b=IGzZ8CKTkRroaLTcKSe5z7N46teAIoQhXY8Q1tC4AmVB6idYF5E26rjMRNzC8yLOW3 v6gq10iudB9746fneQqS+a9+6NabPMCLolPCRalecIEKxFhwgC7nMyWuFLXFGUKZgw6w tiiA4F4KgkF5Ztq/EtcHa6aCsb1yWKek5goFGyiUTKIZKL3safc+DDTdY3E10X9Z5EUg FQDfom2aiCMtT0DTEamZb4Hj0c/xSPRy2PV0NRFzplZD4807mie3gkqDowf6LTAfS0vy lsA80FeImQ+StySOEAFOjqZhzDmDF0wyMNTR5Rq4i44XGZvSyXWopYnleIWkhvN4upAu fF8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UONVnuEsnDlLi6dga+MRvTcYSIUJ9EuC23412FVLdvc=; fh=wNLC6Hyb5Ukz/ErppBRQBwv8vwa/OMsdh6R8bnNsiPU=; b=Am1702s3E9WxxRxR0Y78H3fvbBhXMDyXFGZf77fia6fqg6WAjF+wM1JBN4i4QnZmB2 2Pz6fRb9E5jzCYwfLI2BP0lfacm4LgaUIi4BWFKm0K2724BA+1M1Ga6k1g6bK6ju9sSM LZFfe+pOzG2/S6lwK2MCgpAmC4zJt5t44u2WjlZmIsOAR7BzOAg0bPYjeAbyo10X6+jV wZPpvn1ATXpU+SGGxPmZ9DPQ7Y9H8YYvYwiBCONmwm1pj6cvnEU8YiS87H8pKjzMQwY6 gVlNg+K87xuMoj7fIEtinSQNu8JCEKwKlusmQf1+/HXaUAyGJBK4+paX7JRtVrJnI6S7 o8OA==; 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=1772440421; x=1773045221; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UONVnuEsnDlLi6dga+MRvTcYSIUJ9EuC23412FVLdvc=; b=ATP4SJ0UPiiC0N2KCTKqbgUI+qORlPPAYwAsXTPGHfh99mWMG7/xycWTE5cu0mysUx SBdp/upDAeN+SYVoDvbrtvYF7/j3/8OgjRNG5YodcP/HGwMyIBVktg8CX9q3oi4R8YUk iZPg7udZxogg7Pu0kWrmrRvptpY4Q+nXJEAw67i7yjG27kZToQEAIyi1QL8hbdjk/uuc gSGN1YlOCx07dYYX2jsdqILM65Z95Pgb+Qqck8lV374KMglyjWwPr4KE9+gf0qRIVwO2 rlfuQ8CL7xinYAcWN0ZtT6NACwcDBJ5gtVGtGM/wBl6Ij8BiTBRzb4x1xh1X/sJtYlZu lA7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772440421; x=1773045221; h=content-transfer-encoding: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; bh=UONVnuEsnDlLi6dga+MRvTcYSIUJ9EuC23412FVLdvc=; b=DlVIfgrrdo6ThVDAay3c/QRJnkGp8SdW46peG12P4xy2K16nISK49bmscowIo5prXC YsMT6EFI3zdnwvNSHO6BMIqkaVBXv+HRM4lg/6NxfYdKa1ENpf8Pit/BJ28ynGwGVof8 civHG9VSqYaA22bzElyyXMG3bIPbT4nFbutx8jQk2/Ie4qe38zy+T21kzoOqgul8aL+L KwghlUJpQklN+wvIYjsXgnjrVpUeb7UJYWOIr3OQxiNUhiKgBUK1ySAkZtT1Wmi5rTFW bv2i4DekAF48HMhfqKBI6XDXhZW9YCnwdrOgrIQBy9EyhqFhd7q6qPQRbKsQ9+bViILo xw+g== X-Gm-Message-State: AOJu0YxkIR7BMHKpOZZO3BmtBHrxMvOh+F6hNzmclw24BA6UtCWRcdQf XsO5SKPietJtfDT+lq2Y5gG7RhPRNSrW47StZ4gRw1ym8n4ib+4Z8dnmnvtrLsGgRnGqMAsmYge RcCwzb2esn4scE7dguXXj6rhDvwKVhRngjsKGawcpfw== X-Gm-Gg: ATEYQzyihKuD15GrHHfc0GCIrtLwyebamP1ZP3fKUa0YiiTGp49WmhvUTPRMsM/epkR zpuebkyauQpa1koOPKt1WB/jKWVbF7YlVIPgUYB+2d21m1VivqP+Z9capYPQ71Ay51r5aTWswMl XIr3WrIxA/7ESEk5a2h7F0vVBSOTCKSrM3XEPK2diy3GohTKohv9PvLrk0quMjP+iM3Dgm9spNm SzL076FLfFt/2/K9dHqQ9SQA0tnyiKJPEy79VhjMYlEtjQdK8rZRXkuUsV2ROk9L4n5AIUI5Z4i /laFxk1kIFDWwhd/rdwN1l2J6ACw8cnC/uduBQ== X-Received: by 2002:a05:6830:380b:b0:7c7:55e3:9117 with SMTP id 46e09a7af769-7d591bc1e3cmr7564349a34.22.1772440421101; Mon, 02 Mar 2026 00:33:41 -0800 (PST) MIME-Version: 1.0 References: <826eae4c8346e79a227c8cf418cd5f42ee3420a1.1772013062.git.bertrand.marquis@arm.com> In-Reply-To: <826eae4c8346e79a227c8cf418cd5f42ee3420a1.1772013062.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Mon, 2 Mar 2026 09:33:27 +0100 X-Gm-Features: AaiRm52sezAPYUFnC9jbgganbpPHAChpELXuYx8Z6l0QpwXx8DuJbaT50EKHJOw Message-ID: Subject: Re: [PATCH 1/4] xen/arm: ffa: Add start_index to VM partinfo helper To: Bertrand Marquis Cc: xen-devel@lists.xenproject.org, Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Wed, Feb 25, 2026 at 11:02=E2=80=AFAM Bertrand Marquis wrote: > > Windowed GET_REGS retrieval needs to emit VM entries starting from an > arbitrary index, but ffa_get_vm_partinfo() always starts from index 0. > > Add a start_index parameter to ffa_get_vm_partinfo() and skip entries > until the local index reaches start_index. Update > ffa_handle_partition_info_get() to pass start_index=3D0 to preserve > existing behavior. > > No functional changes. > > Signed-off-by: Bertrand Marquis > --- > xen/arch/arm/tee/ffa_partinfo.c | 61 +++++++++++++++++++-------------- > 1 file changed, 35 insertions(+), 26 deletions(-) Looks good: Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index fdb03dae9a0c..6a6f3ffb822e 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -167,14 +167,15 @@ out: > return ret; > } > > -static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t *vm_co= unt, > - void **dst_buf, void *end_buf, > - uint32_t dst_size) > +static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_= index, > + uint32_t *vm_count, void **dst_buf, > + void *end_buf, uint32_t dst_size) > { > struct domain *d =3D current->domain; > struct ffa_ctx *curr_ctx =3D d->arch.tee; > struct ffa_ctx *dest_ctx; > uint32_t count =3D 0; > + uint32_t idx =3D 0; > int32_t ret =3D FFA_RET_OK; > /* > * We do not have UUID info for VMs so use the 1.0 structure so that= we set > @@ -202,17 +203,21 @@ static int32_t ffa_get_vm_partinfo(struct ffa_uuid = uuid, uint32_t *vm_count, > if ( ACCESS_ONCE(curr_ctx->guest_vers) >=3D FFA_VERSION_1_2 ) > { > /* Add caller VM information */ > - info.id =3D curr_ctx->ffa_id; > - info.execution_context =3D curr_ctx->num_vcpus; > - info.partition_properties =3D FFA_PART_VM_PROP; > - if ( is_64bit_domain(d) ) > - info.partition_properties |=3D FFA_PART_PROP_AARCH64_STATE; > - > - ret =3D ffa_copy_info(dst_buf, end_buf, &info, dst_size, sizeof(= info)); > - if ( ret ) > - return ret; > + if ( start_index =3D=3D 0) > + { > + info.id =3D curr_ctx->ffa_id; > + info.execution_context =3D curr_ctx->num_vcpus; > + info.partition_properties =3D FFA_PART_VM_PROP; > + if ( is_64bit_domain(d) ) > + info.partition_properties |=3D FFA_PART_PROP_AARCH64_STA= TE; > > - count++; > + ret =3D ffa_copy_info(dst_buf, end_buf, &info, dst_size, > + sizeof(info)); > + if ( ret ) > + return ret; > + count++; > + } > + idx++; > } > > if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > @@ -231,21 +236,25 @@ static int32_t ffa_get_vm_partinfo(struct ffa_uuid = uuid, uint32_t *vm_count, > if ( dest_ctx =3D=3D curr_ctx ) > continue; > > - info.id =3D dest_ctx->ffa_id; > - info.execution_context =3D dest_ctx->num_vcpus; > - info.partition_properties =3D FFA_PART_VM_PROP; > - if ( dest_ctx->is_64bit ) > - info.partition_properties |=3D FFA_PART_PROP_AARCH64_STA= TE; > - > - ret =3D ffa_copy_info(dst_buf, end_buf, &info, dst_size, > - sizeof(info)); > - if ( ret ) > + if ( idx >=3D start_index ) > { > - read_unlock(&ffa_ctx_list_rwlock); > - return ret; > + info.id =3D dest_ctx->ffa_id; > + info.execution_context =3D dest_ctx->num_vcpus; > + info.partition_properties =3D FFA_PART_VM_PROP; > + if ( dest_ctx->is_64bit ) > + info.partition_properties |=3D FFA_PART_PROP_AARCH64= _STATE; > + > + ret =3D ffa_copy_info(dst_buf, end_buf, &info, dst_size, > + sizeof(info)); > + if ( ret ) > + { > + read_unlock(&ffa_ctx_list_rwlock); > + return ret; > + } > + count++; > } > > - count++; > + idx++; > } > read_unlock(&ffa_ctx_list_rwlock); > } > @@ -355,7 +364,7 @@ void ffa_handle_partition_info_get(struct cpu_user_re= gs *regs) > goto out_rx_release; > } > > - ret =3D ffa_get_vm_partinfo(uuid, &ffa_vm_count, &dst_buf, end_buf, > + ret =3D ffa_get_vm_partinfo(uuid, 0, &ffa_vm_count, &dst_buf, end_bu= f, > dst_size); > > out_rx_release: > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Mon Mar 02 08:40:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 08:40:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1243999.1543471 (Exim 4.92) (envelope-from ) id 1vwypR-00042g-Ny; Mon, 02 Mar 2026 08:40:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1243999.1543471; Mon, 02 Mar 2026 08: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 ) id 1vwypR-00042Z-Ki; Mon, 02 Mar 2026 08:40:37 +0000 Received: by outflank-mailman (input) for mailman id 1243999; Mon, 02 Mar 2026 08:40:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwypQ-00042T-MI for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 08:40:36 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7ab7dbb8-1613-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 09:40:35 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id B1BAF60008; Mon, 2 Mar 2026 08:40:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0849CC19423; Mon, 2 Mar 2026 08:40:31 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7ab7dbb8-1613-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772440833; bh=/Q5zfmMQXbJWAqYkNWhUOcCTSWBqGiUqOPv9rbR/Ibc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=LuNm/tc3l7URqrTm6aEeseGI5PkQjzDhdAG0uL0yX6cNXmpBpCwdEGe7tlz2yXwHW 8fCZGkALcGj99mrBh8SRXYu2X2oRtO5clHc9cziOhiqTPhBjpPcThmjIEn532CLxDU xVWrXAAHfZDZ6IpFcq/qENqO++4VQCh+9HzOxopPi4OZ7jGO5RjYkR8+gHF6epDya9 aouQuXwyUNK0JvXgsEvptUnouQMcTPpenddZK7OxW+oyMHCz+Q3HRWqD1Np2OSTLan or4k9EAZoJtaB/mTm+9Kf/luKGsV8cVo3rCR3EhUM9cPJg8U1WC57a24krPaZJsc7r H7fUOJ4ywkOIQ== Message-ID: <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> Date: Mon, 2 Mar 2026 09:40:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel Cc: Boris Ostrovsky , Andrew Morton References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> From: "David Hildenbrand (Arm)" 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: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/2/26 07:36, Jürgen Groß wrote: > On 01.03.26 16:04, Marek Marczykowski-Górecki wrote: >> Hi, >> >> Some time ago I made a change to disable scrubbing pages that are >> ballooned out during system boot. I'll paste the whole commit message as >> it's relevant here: >> >>      197ecb3802c0 xen/balloon: add runtime control for scrubbing >> ballooned out pages >> >>      Scrubbing pages on initial balloon down can take some time, >> especially >>      in nested virtualization case (nested EPT is slow). When HVM/PVH >> guest is >>      started with memory= significantly lower than maxmem=, all the extra >>      pages will be scrubbed before returning to Xen. But since most of >> them >>      weren't used at all at that point, Xen needs to populate them first >>      (from populate-on-demand pool). In nested virt case (Xen inside KVM) >>      this slows down the guest boot by 15-30s with just 1.5GB needed >> to be >>      returned to Xen. >>           Add runtime parameter to enable/disable it, to allow >> initially disabling >>      scrubbing, then enable it back during boot (for example in >> initramfs). >>      Such usage relies on assumption that a) most pages ballooned out >> during >>      initial boot weren't used at all, and b) even if they were, very few >>      secrets are in the guest at that time (before any serious userspace >>      kicks in). >>      Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_SCRUB_PAGES_DEFAULT >> (also >>      enabled by default), controlling default value for the new runtime >>      switch. >> >> Now, I face the same issue with init_on_free/init_on_alloc (not sure >> which one applies here, probably the latter one), which several >> distributions enable by default. The result is (see timestamps): >> >>      [2026-02-24 01:12:55] [    7.485151] xen:balloon: Waiting for >> initial ballooning down having finished. >>      [2026-02-24 01:14:14] [   86.581510] xen:balloon: Initial >> ballooning down finished. >> >> But here the situation is a bit more complicated: >> init_on_free/init_on_alloc applies to any pages, not just those for >> balloon driver. I see two approaches to solve the issue: >> 1. Similar to xen_scrub_pages=, add a runtime switch for >>     init_on_free/init_on_alloc, then force them off during boot, and >>     re-enable early in initramfs. >> 2. Somehow adjust balloon driver to bypass init_on_alloc when ballooning >>     a page out. >> >> The first approach is likely easier to implement, but also has some >> drawbacks: it may result in some kernel structures that are allocated >> early to remain with garbage data in uninitialized places. While it may >> not matter during early boot, such structures may survive for quite some >> time, and maybe attacker can use them later on to exploit some other >> bug. This wasn't really a concern with xen_scrub_pages, as those pages >> were immediately ballooned out. >> >> The second approach sounds architecturally better, and maybe >> init_on_alloc could be always bypassed during balloon out? The balloon >> driver can scrub the page on its own already (which is enabled by >> default). That of course assumes the issue is only about init_on_alloc, >> not init_on_free (or both) - which I haven't really confirmed yet... >> If going this way, I see the balloon driver does basically >> alloc_page(GFP_BALLOON), where GFP_BALLOON is: >> >>      /* When ballooning out (allocating memory to return to Xen) we >> don't really >>         want the kernel to try too hard since that can trigger the oom >> killer. */ >>      #define GFP_BALLOON \ >>          (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC) >> >> Would that be about adding some new flag here? Or maybe there is already >> one for this purpose? > > There doesn't seem to be a flag for that. > > But I think adding a new flag __GFP_NO_INIT and testing that in > want_init_on_alloc() _before_ checking CONFIG_INIT_ON_ALLOC_DEFAULT_ON > would be a sensible approach. People argued against such flags in the past, because it will simply get abused by arbitrary drivers that want to be smart. Whatever leaves the buddy shall be zeroed out. If there is a double-zeroing happen, the latter could get optimized out by checking something like user_alloc_needs_zeroing(). See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we avoid double-zeroing. > >> Any opinions? > > You are aware of the "init_on_alloc" boot parameter? So if this is fine > for you, you could just use approach 1 above without any kernel patches > needed. I don't think init_on_alloc can be enabled after boot. IIUC, 1) would require a runtime switch. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Mon Mar 02 08:51:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 08:51:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244008.1543481 (Exim 4.92) (envelope-from ) id 1vwz05-0005ji-Lq; Mon, 02 Mar 2026 08:51:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244008.1543481; Mon, 02 Mar 2026 08: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 ) id 1vwz05-0005jb-IJ; Mon, 02 Mar 2026 08:51:37 +0000 Received: by outflank-mailman (input) for mailman id 1244008; Mon, 02 Mar 2026 08:51:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwz03-0005jV-UH for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 08:51:36 +0000 Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c202::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 013bfcd5-1615-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 09:51:29 +0100 (CET) Received: from DB3PR08CA0004.eurprd08.prod.outlook.com (2603:10a6:8::17) by DBBPR08MB5930.eurprd08.prod.outlook.com (2603:10a6:10:200::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 08:51:26 +0000 Received: from DB1PEPF000509F6.eurprd02.prod.outlook.com (2603:10a6:8:0:cafe::64) by DB3PR08CA0004.outlook.office365.com (2603:10a6:8::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.19 via Frontend Transport; Mon, 2 Mar 2026 08:51:27 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF000509F6.mail.protection.outlook.com (10.167.242.152) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Mon, 2 Mar 2026 08:51:26 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by DU2PR08MB9989.eurprd08.prod.outlook.com (2603:10a6:10:497::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 08:50:21 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 08:50:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 013bfcd5-1615-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=q3F/FRKFyyNJflldeGfEUw6sxxnBUF2JbnMBqtxbvBjnrk9g6IqRi1ffKOxJhq2EuXz2ZXFG7t+71os2BPeKBOFjoolTMy7UXGh/RaT4G7Wnj8RaQEGfEbV3osQG2ibLBwe6N+kllbxqX2nHfN2LaaSrZmYAAu5EFhc0cXLQSCxfA2nrciDsx5jhVi+RVaQDYbOsFalVh4eQDlFyi6ioeT5E6hmQ2qPjY4RfgsvHHialSpstK1UWr+i7zRIf7rBRaUfRldIc5oGrpVqeY4cyLb5CaB9jRPC+jhKCy2zJtvB+KPFGXBC58nxQV+edAfZY7XnDaqVGcZShzXCyMrH05A== 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=9mffT2Wougc0FFTmnAYzzng6GGh6ZOAwfWhbALZNV4s=; b=DyxjjcTCcKMJDYVGPhhLy6TcC0iq3fX5EcaTVODbGP7E6GI1xyPI7waRikqSyS9deg4MeICjg4EQi7t23SldocRvpJG02viz7MltuaL8/m1p/zDeJ1wH1/oSxVXIbckcvQX6B6HEeyrwzbZog4zjQRm9CXijVi07yBHfbfjM+U8ZRiXm/mpxMJVJlk33d8qELGiVuOAwznK/T3LQi1Qck2jllb9wyDk7xHgHJTmc7m68G4j39snAcy27JE+/bCH1N9HbVxvH9JzI1ug64LiVIBwLVbanvPJ4Ae6J6ihi8YWNFVZcUqbv55tDj9dOn9bV/+bliSrr9p24ue+ySJ2nBA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=9mffT2Wougc0FFTmnAYzzng6GGh6ZOAwfWhbALZNV4s=; b=VbHs5mMI5u4S/9dIJn0RLsqnLRTgoVOees8I3MY8EGTjfkYyKAvw/x1ajNhjMDpsMA6DCljRcJGbjozdmlbcPTsIq+dw/pKUu/uZ1tHfEeatHMto2Md6G6PqQcp0yCIVr6jk+rmpy+21ciPPBZVeU9fD0R+SCqcDnst14XJyDgE= 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=lKXX2cYboYUaqaURIg2UFnUmWWgZ2L77kjDd1XJa+hyWF1pyb5g0IQn8g7fwFmiE6MMQKc4d0osW1tGCaF0EBR5oSu0ZPPkUzpTK9SYwAWsjUZwufFloZ/X/xUJ5jAv3XyoPfOB6MUP9vNUWtverh2uRRes2qU4W7svEqG1ZPqWb9p59wFTDjxDlL2AEMgYbTCV3SVG9cPPodLB6qk/YXSM+ejy77BxB5tCjoOHmrZddFkr3oEeT/MME7a1k1XlgS9rSRnzHs21jhNszW9qf451hmIskDahS968Lh8vkbvS/0qe/T859D17alSX+17xe381h9nJ5dPl2DJVAMbTZJw== 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=9mffT2Wougc0FFTmnAYzzng6GGh6ZOAwfWhbALZNV4s=; b=fBkhBUS0dZ+9aPj6JJ2R+ElCTIMDEyPEATe1z+RDOV64EbC+76N8Nf8o26T77Pi+a7iJgXxleuadmyh1te7tsVht9+QE7bPIXaGUTHeVzc38kqXBLIQCuPkyB+PVNNc4xpupxQ0SPBcBPHvqp+hn7NLjkTi5MZHevn0GvIE+mnFOtiHlIpmKmkoYIiEsM8K9XH9DNbwiKBy9EYo4O/OrG9Kuj7iNOTAZqCExjTsQ6bGLgbVtyYJNpD4rxnDZFqDkTgRuNCQmtyJ8FKTt2WJFoRI20SS9dhwgE9S33BBvpBpv2kvMUK0r5AtBNSTCIE/PjAbGmPyhub5BElJvQmDz2g== 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=9mffT2Wougc0FFTmnAYzzng6GGh6ZOAwfWhbALZNV4s=; b=VbHs5mMI5u4S/9dIJn0RLsqnLRTgoVOees8I3MY8EGTjfkYyKAvw/x1ajNhjMDpsMA6DCljRcJGbjozdmlbcPTsIq+dw/pKUu/uZ1tHfEeatHMto2Md6G6PqQcp0yCIVr6jk+rmpy+21ciPPBZVeU9fD0R+SCqcDnst14XJyDgE= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init Thread-Topic: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init Thread-Index: AQHcpj3iktrazLk1t0mCBnzOLulDCLWWXkkAgASYY4A= Date: Mon, 2 Mar 2026 08:50:21 +0000 Message-ID: <9B608F0B-E564-42C6-9F85-E1701F707554@arm.com> References: <0a5f66eaa16f262d4ffad6a8ec4b1b02461f96c1.1772013062.git.bertrand.marquis@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|DU2PR08MB9989:EE_|DB1PEPF000509F6:EE_|DBBPR08MB5930:EE_ X-MS-Office365-Filtering-Correlation-Id: 5ca40bef-f924-44dc-3e53-08de7838e3b1 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|10070799003|1800799024|366016|38070700021; X-Microsoft-Antispam-Message-Info-Original: juGlxVbqBK5/7n+7eAC4yku+sTOa1SY421b8TU20UOHzdA2VXhtRDazT98VicX6Q6KcGoHKM/ynRSkyKmSqdY0KlyAATMDknU5kIuLe/fYb+v68UrdSnI+tzoZ9kbMjKAwy5C2u2PrNnHNBDwU+SUUjt5LG3FMfsTPz2oy81aHPDmbO1km9T0Tz4xzmHWqvx+Oozz2eLNGHgwUr1+hMpP5sEEd1muahOzSSEzyMgvVUreaCh94Ll0JVuJ8TebDwPUWDgexkqEI8xzdeczEAxll9qQ7myrMvqVh6Zc6IFxhRPidsyDqH+FquCV+iznMfBtOaMMwGfyEF9ty5gCyoLVr5eByF5WDHKv42KiZ8NRhPE2KQDE2MnpUSrSM1hygxR4FJEGzs0qb9B2r0gh0iRSsN8D7EOCpf/qWgHXOI5DA4qi5ET6438mi02dWUbIZSEc+X71b+GE0FFH+QRf0lxjYWQY665QzhwZWd6OwyzXI5pdG0ETcF31KIkoLGmaEBSHbecXHutCDzaXNmYhjWmjLHQ8ZpmECBC7gANeKEq2I0jpq3V0l6xKgS2iCpxXwyvHqNaqFMiD8LyGBwNx6GR4MPBb2n8de6cS9DR8mGlWXPpb1Ejzxa2Cmj2qX4BuKKThxLKfDnxKFChc3JOPsXFRBgDIEKpiFHmyvTfEL7mWcKBmL+pUD1b3+I+QXNBL5YIMwHsU3TNFqes6atlAOYf1z5QGF7pkoh2kOo/SeoojLDnUtQlSK6KljDvDZ50a4fGR/snHbOnzQiw7/hsXx00AplNKKt218Mc7UHvd2/Yu3k= 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)(10070799003)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB9989 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509F6.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0ac0d8be-8952-42a1-2c9f-08de7838bccb X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|376014|35042699022|14060799003|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: rtIxUWNR4dRTCYxIRWFlgzgB1BIj5nFmB9uVOXp8rzqgeoIoBOSomt+dkbXB2HKhAdhr2gNCPptfjt4jFiSKP/BCuZTLBZNDZ+lqGUnX5zMTQgxTjrqCRPNcwwNt4ayzbxtj/RMA7MXcSEBCu918aj0mTCGaCxx7Ob1LWQW/vgnnsQlDwwP5nE170eWLRHZMXqEfkZ/CLxRNrrdFPqUD/MBT6Fyn10+W0WGgbhXj8Mdp/GiUohIUZ1ShzYxvt4dXtgMWu6YImrsti3y5+kVNnq7tB0N6BtEwa+Ut98pRmJmggXrx7WoBKNmofDv7VSxqFEy+xspMWXJkjxN3PPFD/SDGqTXaar+/5qrMRYtTUSsng3dwMw8WK4AdAyxWZGOOEhBIyhOw59teDSxpjZ0R/swDWgftJPDyO9MyTSKgZRyx8ef6ZnA+iZOdN2Gjo1eQ7iv9N5wVf85lvjVmt17Hd/TP5l58dw2oCne/ir2nCye762JZ8j6EhFnDahmJHY+FoFXY1iNP0fmsOTzVAaMVBhfQmLO8bkfyi0gBNueZiZDAjUZ9qmli/J2REmNFPzyNn5v1j0pen3oCkG1RhIhbJGard59LZRhNYBoTk5bAxPSLcmj/hAw8jjpWahIRzHL8dkJkbdjxsYbeZdTibrYI640N1EGth/CznKYRpOgt3wMMM0iUAknOskR0btmoZ29Lk4n1I3ru3np7zUTwM9v/i6OfuWE1OBKJdzl0GIsbqmXKFXz1Lw1qhP0zBTOaA6K1El0CPjyXJonin+2Nc0a5Vu1649oXfLmMHtou29M4LQNrOizd8EJZK9mk4pOAV3Ys7X9eXQ+uVC5x7NbQLQE/Qg== 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)(36860700013)(82310400026)(376014)(35042699022)(14060799003)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: proBU3f02ZHiCGixd7kfXbTnAf1TtS3CjVgClPnWzF3KnE/8Dgkk9f+KTXsjFAYRmdW0PvJ518ZoF8ruoc6nSJeTPa9J7OeaDC9ifZtO54ZyFEIOsvK3pFyA9F8L5Tgm4JRXiOYA2QPDPySwR3ogDJEkEbpFv9iZk+9jtx20rr6FIqEZ6LkItEPzToWWHOMW4J8rOJ2dR+8KVbU67O7wRbDSR3+mnIPWmUMv1KmB5BM/9JFjzlHwNFhTlF5Q87XCZ5JhOk1QO/4NN8ZDat8JhssaccP68xD2tKG7MAPDTDc+k+d7+OstWMSAiZY1c/o53UYr+lD5S21DpxbbdNwnXoVWsQKmZpyaQmzsGdQL9Qh7HDnj9HJlfM0a6z7zamJkVVLxO+7xXmbo/EE6+Qbxd8rVpoCI5UwZwBaxozrR8atMy0v9Gz3bR0PhFQKskGVL X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 08:51:26.5584 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ca40bef-f924-44dc-3e53-08de7838e3b1 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: DB1PEPF000509F6.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB5930 SGkgSmVucywNCg0KPiBPbiAyNyBGZWIgMjAyNiwgYXQgMTE6MzksIEplbnMgV2lrbGFuZGVyIDxq ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiAN Cj4gT24gV2VkLCBGZWIgMjUsIDIwMjYgYXQgMTE6MDLigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+ IDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBGRkFfUEFSVElUSU9O X0lORk9fR0VUIGN1cnJlbnRseSBxdWVyaWVzIHRoZSBTUE1DIG9uIGVhY2ggY2FsbCBhbmQgd2Fs a3MgdGhlDQo+PiBSWCBidWZmZXIgZXZlcnkgdGltZS4gVGhlIFNQIGxpc3QgaXMgZXhwZWN0ZWQg dG8gYmUgc3RhdGljLCBzbyByZXBlYXRlZA0KPj4gZmlybXdhcmUgY2FsbHMgYW5kIHZhbGlkYXRp b24gYXJlIHVubmVjZXNzYXJ5Lg0KPj4gDQo+PiBDYWNoZSB0aGUgU1BNQyBwYXJ0aXRpb24taW5m byBsaXN0IGF0IGluaXQgdGltZSwga2VlcGluZyBvbmx5IHNlY3VyZQ0KPj4gZW5kcG9pbnRzLCBh bmQgcmV1c2UgdGhlIGNhY2hlZCBlbnRyaWVzIGZvciBTUCBjb3VudCBhbmQgcGFydGl0aW9uLWlu Zm8NCj4+IHJlc3BvbnNlcy4gSW5pdGlhbGl6ZSB0aGUgVk0gY3JlYXRlL2Rlc3Ryb3kgc3Vic2Ny aWJlciBsaXN0cyBmcm9tIHRoZSBjYWNoZWQNCj4+IGxpc3QgYW5kIGZyZWUgdGhlIGNhY2hlIG9u IGluaXQgZmFpbHVyZS4NCj4+IA0KPj4gU1AgcGFydGl0aW9uIGluZm8gbm93IHJlZmxlY3RzIHRo ZSBpbml0LXRpbWUgc25hcHNob3QgYW5kIHdpbGwgbm90IGNoYW5nZS4NCj4+IA0KPj4gU2lnbmVk LW9mZi1ieTogQmVydHJhbmQgTWFycXVpcyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPg0KPj4g LS0tDQo+PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jIHwgMjA1ICsrKysrKysrKysr KysrKysrKysrKy0tLS0tLS0tLS0tDQo+PiAxIGZpbGUgY2hhbmdlZCwgMTM4IGluc2VydGlvbnMo KyksIDY3IGRlbGV0aW9ucygtKQ0KPj4gDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3Rl ZS9mZmFfcGFydGluZm8uYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMNCj4+IGlu ZGV4IDZhNmYzZmZiODIyZS4uOGEzZWFjMjVmOTlmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gv YXJtL3RlZS9mZmFfcGFydGluZm8uYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFy dGluZm8uYw0KPj4gQEAgLTYsNiArNiw3IEBADQo+PiAjaW5jbHVkZSA8eGVuL2NvbnN0Lmg+DQo+ PiAjaW5jbHVkZSA8eGVuL3NpemVzLmg+DQo+PiAjaW5jbHVkZSA8eGVuL3R5cGVzLmg+DQo+PiAr I2luY2x1ZGUgPHhlbi94bWFsbG9jLmg+DQo+PiANCj4+ICNpbmNsdWRlIDxhc20vc21jY2MuaD4N Cj4+ICNpbmNsdWRlIDxhc20vcmVncy5oPg0KPj4gQEAgLTMzLDYgKzM0LDEwIEBAIHN0YXRpYyB1 aW50MTZfdCBzdWJzY3Jfdm1fY3JlYXRlZF9jb3VudCBfX3JlYWRfbW9zdGx5Ow0KPj4gc3RhdGlj IHVpbnQxNl90ICpzdWJzY3Jfdm1fZGVzdHJveWVkIF9fcmVhZF9tb3N0bHk7DQo+PiBzdGF0aWMg dWludDE2X3Qgc3Vic2NyX3ZtX2Rlc3Ryb3llZF9jb3VudCBfX3JlYWRfbW9zdGx5Ow0KPj4gDQo+ PiArLyogU1AgbGlzdCBjYWNoZSAoc2VjdXJlIGVuZHBvaW50cyBvbmx5KTsgcG9wdWxhdGVkIGF0 IGluaXQuICovDQo+PiArc3RhdGljIHZvaWQgKnNwX2xpc3QgX19yZWFkX21vc3RseTsNCj4+ICtz dGF0aWMgdWludDMyX3Qgc3BfbGlzdF9jb3VudCBfX3JlYWRfbW9zdGx5Ow0KPj4gK3N0YXRpYyB1 aW50MzJfdCBzcF9saXN0X2VudHJ5X3NpemUgX19yZWFkX21vc3RseTsNCj4+IHN0YXRpYyBpbnQz Ml90IGZmYV9wYXJ0aXRpb25faW5mb19nZXQoc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90 IGZsYWdzLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJf dCAqY291bnQsIHVpbnQzMl90ICpmcGlfc2l6ZSkNCj4+IHsNCj4+IEBAIC03OSw5MiArODQsNzgg QEAgc3RhdGljIGludDMyX3QgZmZhX2NvcHlfaW5mbyh2b2lkICoqZHN0LCB2b2lkICpkc3RfZW5k LCBjb25zdCB2b2lkICpzcmMsDQo+PiAgICAgcmV0dXJuIEZGQV9SRVRfT0s7DQo+PiB9DQo+PiAN Cj4+IC1zdGF0aWMgaW50MzJfdCBmZmFfZ2V0X3NwX2NvdW50KHN0cnVjdCBmZmFfdXVpZCB1dWlk LCB1aW50MzJfdCAqc3BfY291bnQpDQo+PiArc3RhdGljIGJvb2wgZmZhX3NwX2VudHJ5X21hdGNo ZXNfdXVpZChjb25zdCB2b2lkICplbnRyeSwgc3RydWN0IGZmYV91dWlkIHV1aWQpDQo+PiB7DQo+ PiAtICAgIHVpbnQzMl90IHNyY19zaXplOw0KPj4gKyAgICBjb25zdCBzdHJ1Y3QgZmZhX3BhcnRp dGlvbl9pbmZvXzFfMSAqZnBpID0gZW50cnk7DQo+PiArICAgIHN0cnVjdCBmZmFfdXVpZCBzcF91 dWlkOw0KPj4gKw0KPj4gKyAgICBpZiAoIGZmYV91dWlkX2lzX25pbCh1dWlkKSApDQo+PiArICAg ICAgICByZXR1cm4gdHJ1ZTsNCj4+IA0KPj4gLSAgICByZXR1cm4gZmZhX3BhcnRpdGlvbl9pbmZv X2dldCh1dWlkLCBGRkFfUEFSVElUSU9OX0lORk9fR0VUX0NPVU5UX0ZMQUcsDQo+PiAtICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwX2NvdW50LCAmc3JjX3NpemUpOw0KPj4gKyAg ICBpZiAoIHNwX2xpc3RfZW50cnlfc2l6ZSA8IHNpemVvZigqZnBpKSApDQo+PiArICAgICAgICBy ZXR1cm4gZmFsc2U7DQo+IA0KPiBUaGlzIGNhbiBuZXZlciBoYXBwZW4gc2luY2Ugd2UgZG9uJ3Qg YWNjZXB0IFNQTUMgYmVsb3cgdmVyc2lvbiAxLjEuIFdlDQo+IGV2ZW4gaGF2ZSBhIGNoZWNrIHRv IGVuc3VyZSB0aGUgU1BNQyBkb2Vzbid0IHJldHVybiBhIHRvby1zbWFsbA0KPiBzcGlfc2l6ZS4N Cg0KSSB0cmllZCB0byBtYWtlIHRoZSBjb2RlIGZvcndhcmQgY29tcGF0aWJsZS4gSXQgaXMgbm90 IHJlYWxseSBhIHBvc3NpYmxlIGNhc2UgcmlnaHQgbm93IA0KYnV0IHdlIGNvdWxkIGZhbGwgaW50 byB0aGlzIGluIHRoZSBmdXR1cmUuDQoNCj4gDQo+PiArDQo+PiArICAgIG1lbWNweSgmc3BfdXVp ZCwgZnBpLT51dWlkLCBzaXplb2Yoc3BfdXVpZCkpOw0KPj4gKyAgICByZXR1cm4gZmZhX3V1aWRf ZXF1YWwodXVpZCwgc3BfdXVpZCk7DQo+PiB9DQo+PiANCj4+IC1zdGF0aWMgaW50MzJfdCBmZmFf Z2V0X3NwX3BhcnRpbmZvKHN0cnVjdCBmZmFfdXVpZCB1dWlkLCB1aW50MzJfdCAqc3BfY291bnQs DQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICoqZHN0X2J1Ziwg dm9pZCAqZW5kX2J1ZiwNCj4+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVp bnQzMl90IGRzdF9zaXplKQ0KPj4gK3N0YXRpYyBpbnQzMl90IGZmYV9nZXRfc3BfY291bnQoc3Ry dWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90ICpzcF9jb3VudCkNCj4+IHsNCj4+IC0gICAgaW50 MzJfdCByZXQ7DQo+PiAtICAgIGludDMyX3QgcmVsZWFzZV9yZXQ7DQo+PiAtICAgIHVpbnQzMl90 IHNyY19zaXplLCByZWFsX3NwX2NvdW50Ow0KPj4gLSAgICB2b2lkICpzcmNfYnVmOw0KPj4gICAg IHVpbnQzMl90IGNvdW50ID0gMDsNCj4+IC0gICAgYm9vbCBub3RpZnlfZncgPSBmYWxzZTsNCj4+ IC0NCj4+IC0gICAgLyogV2UgbmVlZCB0byB1c2UgdGhlIFJYIGJ1ZmZlciB0byByZWNlaXZlIHRo ZSBsaXN0ICovDQo+PiAtICAgIHNyY19idWYgPSBmZmFfcnh0eF9zcG1jX3J4X2FjcXVpcmUoKTsN Cj4+IC0gICAgaWYgKCAhc3JjX2J1ZiApDQo+PiAtICAgICAgICByZXR1cm4gRkZBX1JFVF9ERU5J RUQ7DQo+PiAtDQo+PiAtICAgIHJldCA9IGZmYV9wYXJ0aXRpb25faW5mb19nZXQodXVpZCwgMCwg JnJlYWxfc3BfY291bnQsICZzcmNfc2l6ZSk7DQo+PiAtICAgIGlmICggcmV0ICkNCj4+IC0gICAg ICAgIGdvdG8gb3V0Ow0KPj4gLSAgICBub3RpZnlfZncgPSB0cnVlOw0KPj4gKyAgICB1aW50MzJf dCBuOw0KPj4gDQo+PiAtICAgIC8qIFZhbGlkYXRlIHRoZSBzcmNfc2l6ZSB3ZSBnb3QgKi8NCj4+ IC0gICAgaWYgKCBzcmNfc2l6ZSA8IHNpemVvZihzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFf MCkgfHwNCj4+IC0gICAgICAgICBzcmNfc2l6ZSA+PSBGRkFfUEFHRV9TSVpFICkNCj4+ICsgICAg Zm9yICggbiA9IDA7IG4gPCBzcF9saXN0X2NvdW50OyBuKysgKQ0KPj4gICAgIHsNCj4+IC0gICAg ICAgIHJldCA9IEZGQV9SRVRfTk9UX1NVUFBPUlRFRDsNCj4+IC0gICAgICAgIGdvdG8gb3V0Ow0K Pj4gKyAgICAgICAgdm9pZCAqZW50cnkgPSBzcF9saXN0ICsgbiAqIHNwX2xpc3RfZW50cnlfc2l6 ZTsNCj4+ICsNCj4+ICsgICAgICAgIGlmICggZmZhX3NwX2VudHJ5X21hdGNoZXNfdXVpZChlbnRy eSwgdXVpZCkgKQ0KPj4gKyAgICAgICAgICAgIGNvdW50Kys7DQo+PiAgICAgfQ0KPj4gDQo+PiAt ICAgIC8qDQo+PiAtICAgICAqIExpbWl0IHRoZSBtYXhpbXVtIHRpbWUgd2UgaG9sZCB0aGUgQ1BV IGJ5IGxpbWl0aW5nIHRoZSBudW1iZXIgb2YgU1BzLg0KPj4gLSAgICAgKiBXZSBqdXN0IGlnbm9y ZSB0aGUgZXh0cmEgb25lcyBhcyB0aGlzIGlzIHRlc3RlZCBkdXJpbmcgaW5pdCBpbg0KPj4gLSAg ICAgKiBmZmFfcGFydGluZm9faW5pdCBzbyB0aGUgb25seSBwb3NzaWJsZSByZWFzb24gaXMgU1Ag aGF2ZSBiZWVuIGFkZGVkDQo+PiAtICAgICAqIHNpbmNlIGJvb3QuDQo+PiAtICAgICAqLw0KPj4g LSAgICBpZiAoIHJlYWxfc3BfY291bnQgPiBGRkFfTUFYX05VTV9TUCApDQo+PiAtICAgICAgICBy ZWFsX3NwX2NvdW50ID0gRkZBX01BWF9OVU1fU1A7DQo+PiArICAgICpzcF9jb3VudCA9IGNvdW50 Ow0KPj4gDQo+PiAtICAgIC8qIE1ha2Ugc3VyZSB0aGUgZGF0YSBmaXRzIGluIG91ciBidWZmZXIg Ki8NCj4+IC0gICAgaWYgKCByZWFsX3NwX2NvdW50ID4gKEZGQV9SWFRYX1BBR0VfQ09VTlQgKiBG RkFfUEFHRV9TSVpFKSAvIHNyY19zaXplICkNCj4+IC0gICAgew0KPj4gLSAgICAgICAgcmV0ID0g RkZBX1JFVF9OT1RfU1VQUE9SVEVEOw0KPj4gLSAgICAgICAgZ290byBvdXQ7DQo+PiAtICAgIH0N Cj4+ICsgICAgaWYgKCAhZmZhX3V1aWRfaXNfbmlsKHV1aWQpICYmICFjb3VudCApDQo+PiArICAg ICAgICByZXR1cm4gRkZBX1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7DQo+PiANCj4+IC0gICAgZm9y ICggdWludDMyX3Qgc3BfbnVtID0gMDsgc3BfbnVtIDwgcmVhbF9zcF9jb3VudDsgc3BfbnVtKysg KQ0KPj4gLSAgICB7DQo+PiAtICAgICAgICBzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSAq ZnBpID0gc3JjX2J1ZjsNCj4+ICsgICAgcmV0dXJuIEZGQV9SRVRfT0s7DQo+PiArfQ0KPj4gDQo+ PiAtICAgICAgICAvKiBmaWx0ZXIgb3V0IFNQIG5vdCBmb2xsb3dpbmcgYml0IDE1IGNvbnZlbnRp b24gaWYgYW55ICovDQo+PiAtICAgICAgICBpZiAoIEZGQV9JRF9JU19TRUNVUkUoZnBpLT5pZCkg KQ0KPj4gLSAgICAgICAgew0KPj4gLSAgICAgICAgICAgIC8qDQo+PiAtICAgICAgICAgICAgICog SWYgVk0gaXMgMS4wIGJ1dCBmaXJtd2FyZSBpcyAxLjEgd2UgY291bGQgaGF2ZSBzZXZlcmFsIGVu dHJpZXMNCj4+IC0gICAgICAgICAgICAgKiB3aXRoIHRoZSBzYW1lIElEIGJ1dCBkaWZmZXJlbnQg VVVJRHMuIEluIHRoaXMgY2FzZSB0aGUgVk0gd2lsbA0KPj4gLSAgICAgICAgICAgICAqIGdldCBh IGxpc3Qgd2l0aCBzZXZlcmFsIHRpbWUgdGhlIHNhbWUgSUQuDQo+PiAtICAgICAgICAgICAgICog VGhpcyBpcyBhIG5vbi1jb21wbGlhbmNlIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGJ1dCAxLjAgVk1z IHNob3VsZA0KPj4gLSAgICAgICAgICAgICAqIGhhbmRsZSB0aGF0IG9uIHRoZWlyIG93biB0byBz aW1wbGlmeSBYZW4gaW1wbGVtZW50YXRpb24uDQo+PiAtICAgICAgICAgICAgICovDQo+PiArc3Rh dGljIGludDMyX3QgZmZhX2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZhX3V1aWQgdXVpZCwgdWlu dDMyX3QgKnNwX2NvdW50LA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dm9pZCAqKmRzdF9idWYsIHZvaWQgKmVuZF9idWYsDQo+PiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1aW50MzJfdCBkc3Rfc2l6ZSkNCj4+ICt7DQo+PiArICAgIGludDMyX3Qg cmV0Ow0KPj4gKyAgICB1aW50MzJfdCBjb3VudCA9IDA7DQo+PiArICAgIHVpbnQzMl90IG47DQo+ PiANCj4+IC0gICAgICAgICAgICByZXQgPSBmZmFfY29weV9pbmZvKGRzdF9idWYsIGVuZF9idWYs IHNyY19idWYsIGRzdF9zaXplLCBzcmNfc2l6ZSk7DQo+PiAtICAgICAgICAgICAgaWYgKCByZXQg KQ0KPj4gLSAgICAgICAgICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgZm9yICggbiA9IDA7IG4g PCBzcF9saXN0X2NvdW50OyBuKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB2b2lkICplbnRy eSA9IHNwX2xpc3QgKyBuICogc3BfbGlzdF9lbnRyeV9zaXplOw0KPj4gDQo+PiAtICAgICAgICAg ICAgY291bnQrKzsNCj4+IC0gICAgICAgIH0NCj4+ICsgICAgICAgIGlmICggIWZmYV9zcF9lbnRy eV9tYXRjaGVzX3V1aWQoZW50cnksIHV1aWQpICkNCj4+ICsgICAgICAgICAgICBjb250aW51ZTsN Cj4+IA0KPj4gLSAgICAgICAgc3JjX2J1ZiArPSBzcmNfc2l6ZTsNCj4+ICsgICAgICAgIC8qDQo+ PiArICAgICAgICAgKiBJZiBWTSBpcyAxLjAgYnV0IGZpcm13YXJlIGlzIDEuMSB3ZSBjb3VsZCBo YXZlIHNldmVyYWwgZW50cmllcw0KPj4gKyAgICAgICAgICogd2l0aCB0aGUgc2FtZSBJRCBidXQg ZGlmZmVyZW50IFVVSURzLiBJbiB0aGlzIGNhc2UgdGhlIFZNIHdpbGwNCj4+ICsgICAgICAgICAq IGdldCBhIGxpc3Qgd2l0aCBzZXZlcmFsIHRpbWUgdGhlIHNhbWUgSUQuDQo+PiArICAgICAgICAg KiBUaGlzIGlzIGEgbm9uLWNvbXBsaWFuY2UgdG8gdGhlIHNwZWNpZmljYXRpb24gYnV0IDEuMCBW TXMgc2hvdWxkDQo+PiArICAgICAgICAgKiBoYW5kbGUgdGhhdCBvbiB0aGVpciBvd24gdG8gc2lt cGxpZnkgWGVuIGltcGxlbWVudGF0aW9uLg0KPj4gKyAgICAgICAgICovDQo+PiArICAgICAgICBy ZXQgPSBmZmFfY29weV9pbmZvKGRzdF9idWYsIGVuZF9idWYsIGVudHJ5LCBkc3Rfc2l6ZSwNCj4+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BfbGlzdF9lbnRyeV9zaXplKTsNCj4+ICsg ICAgICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gcmV0Ow0KPj4gKw0KPj4g KyAgICAgICAgY291bnQrKzsNCj4+ICAgICB9DQo+PiANCj4+ICAgICAqc3BfY291bnQgPSBjb3Vu dDsNCj4+IA0KPj4gLW91dDoNCj4+IC0gICAgcmVsZWFzZV9yZXQgPSBmZmFfcnh0eF9zcG1jX3J4 X3JlbGVhc2Uobm90aWZ5X2Z3KTsNCj4+IC0gICAgaWYgKCByZWxlYXNlX3JldCApDQo+PiAtICAg ICAgICBncHJpbnRrKFhFTkxPR19XQVJOSU5HLA0KPj4gLSAgICAgICAgICAgICAgICAiZmZhOiBF cnJvciByZWxlYXNpbmcgU1BNQyBSWCBidWZmZXI6ICVkXG4iLCByZWxlYXNlX3JldCk7DQo+PiAt ICAgIHJldHVybiByZXQ7DQo+PiArICAgIGlmICggIWZmYV91dWlkX2lzX25pbCh1dWlkKSAmJiAh Y291bnQgKQ0KPj4gKyAgICAgICAgcmV0dXJuIEZGQV9SRVRfSU5WQUxJRF9QQVJBTUVURVJTOw0K Pj4gKw0KPj4gKyAgICByZXR1cm4gRkZBX1JFVF9PSzsNCj4+IH0NCj4+IA0KPj4gc3RhdGljIGlu dDMyX3QgZmZhX2dldF92bV9wYXJ0aW5mbyhzdHJ1Y3QgZmZhX3V1aWQgdXVpZCwgdWludDMyX3Qg c3RhcnRfaW5kZXgsDQo+PiBAQCAtNDM1LDYgKzQyNiwxNCBAQCBzdGF0aWMgaW50MzJfdCBmZmFf ZGlyZWN0X3JlcV9zZW5kX3ZtKHVpbnQxNl90IHNwX2lkLCB1aW50MTZfdCB2bV9pZCwNCj4+ICAg ICByZXR1cm4gcmVzOw0KPj4gfQ0KPj4gDQo+PiArc3RhdGljIHZvaWQgZmZhX3NwX2xpc3RfY2Fj aGVfZnJlZSh2b2lkKQ0KPj4gK3sNCj4+ICsgICAgWEZSRUUoc3BfbGlzdCk7DQo+PiArICAgIHNw X2xpc3QgPSBOVUxMOw0KPiANCj4gWEZSRUUoKSBpcyBhbHJlYWR5IHNldHRpbmcgc3BfbGlzdCB0 byBOVUxMLg0KDQpBY2sgd2lsbCBmaXggaW4gdjINCg0KPiANCj4+ICsgICAgc3BfbGlzdF9jb3Vu dCA9IDA7DQo+PiArICAgIHNwX2xpc3RfZW50cnlfc2l6ZSA9IDA7DQo+PiArfQ0KPj4gKw0KPj4g c3RhdGljIHZvaWQgdW5pbml0X3N1YnNjcmliZXJzKHZvaWQpDQo+PiB7DQo+PiAgICAgICAgIHN1 YnNjcl92bV9jcmVhdGVkX2NvdW50ID0gMDsNCj4+IEBAIC00NDMsNiArNDQyLDY4IEBAIHN0YXRp YyB2b2lkIHVuaW5pdF9zdWJzY3JpYmVycyh2b2lkKQ0KPj4gICAgICAgICBYRlJFRShzdWJzY3Jf dm1fZGVzdHJveWVkKTsNCj4+IH0NCj4+IA0KPj4gK3N0YXRpYyBib29sIGZmYV9zcF9saXN0X2Nh Y2hlX2luaXQoY29uc3Qgdm9pZCAqYnVmLCB1aW50MzJfdCBjb3VudCwNCj4+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZwaV9zaXplKQ0KPj4gK3sNCj4+ICsg ICAgY29uc3QgdWludDhfdCAqc3JjID0gYnVmOw0KPj4gKyAgICB1aW50MzJfdCBzZWN1cmVfY291 bnQgPSAwOw0KPj4gKyAgICB1aW50MzJfdCBuLCBpZHggPSAwOw0KPj4gKyAgICBib29sIHdhcm5l ZCA9IGZhbHNlOw0KPj4gKw0KPj4gKyAgICBpZiAoIGZwaV9zaXplIDwgc2l6ZW9mKHN0cnVjdCBm ZmFfcGFydGl0aW9uX2luZm9fMV8wKSB8fA0KPj4gKyAgICAgICAgIGZwaV9zaXplID49IEZGQV9Q QUdFX1NJWkUgKQ0KPj4gKyAgICAgICAgcmV0dXJuIGZhbHNlOw0KPiANCj4gV291bGQgaXQgbWFr ZSBzZW5zZSB0byBjaGVjayB0aGF0IGZwaV9zaXplIGlzIHdlbGwgYWxpZ25lZCB3aXRoIHN0cnVj dA0KPiBmZmFfcGFydGl0aW9uX2luZm9fMV8wPyBJZiBpdCdzIGFuIG9kZCBzaXplLCB3ZSdsbCBt YWtlIHVuYWxpZ25lZA0KPiBhY2Nlc3NlcyBiZWxvdyB3aXRoIG1lbWNweSgpLiBCdXQgcGVyaGFw cyB0aGF0J3MgYSBiaXQgbXVjaC4gVGhlIFNQTUMNCj4gaXNuJ3Qgc3VwcG9zZWQgdG8gcHJvdmlk ZSBnYXJiYWdlLg0KDQpNZW1jcHkgc2hvdWxkIHByZXZlbnQgaXNzdWVzIGV2ZW4gaWYgYWNjZXNz ZXMgYXJlIG5vdCBhbGlnbmVkLg0KSWYgd2UgaGFkIHRoaXMgdGVzdCwgd2UgY2Fubm90IHJldHVy biBhbiBlcnJvciB0byB0aGUgU1BNQyBzbyB3ZSB3b3VsZCBoYXZlIHRvDQpnZW5lcmF0ZSBvbmUg dG8gdGhlIGNhbGxlci4gSXQgaXMgc2ltcGxlciBpIHRoaW5rIHRvIGhhbmRsZSBub24tYWxpZ25l ZCBhcyB3ZSBkbyBub3QNCmV4cGVjdCB0aGUgU1BNQyB0byBnZW5lcmF0ZSBzdWNoIGEgY2FzZS4N ClRlbGwgbWUgaWYgeW91IGFncmVlLg0KDQo+IA0KPj4gKw0KPj4gKyAgICBpZiAoIGNvdW50ID4g KEZGQV9SWFRYX1BBR0VfQ09VTlQgKiBGRkFfUEFHRV9TSVpFKSAvIGZwaV9zaXplICkNCj4+ICsg ICAgICAgIHJldHVybiBmYWxzZTsNCj4+ICsNCj4+ICsgICAgZm9yICggbiA9IDA7IG4gPCBjb3Vu dDsgbisrICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgY29uc3Qgc3RydWN0IGZmYV9wYXJ0aXRp b25faW5mb18xXzAgKmZwaSA9DQo+PiArICAgICAgICAgICAgKGNvbnN0IHZvaWQgKikoc3JjICsg biAqIGZwaV9zaXplKTsNCj4+ICsNCj4+ICsgICAgICAgIGlmICggIUZGQV9JRF9JU19TRUNVUkUo ZnBpLT5pZCkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIGlmICggIXdhcm5lZCAp DQo+IA0KPiBJcyB0aGlzIG5lZWRlZD8gRG9lc24ndCBwcmludGtfb25jZSgpIGFscmVhZHkgZW5z dXJlIHRoaXM/IE9yIGRpZCB5b3UNCj4gaGFwcGVuIHRvIGxlYXZlIHByaW50a19vbmNlKCkgYnkg bWlzdGFrZSBhbmQgbWVhbnQgZm9yIHRoaXMgdG8gYmUNCj4gcHJpbnRlZCBvbmNlIGVhY2ggdGlt ZSBmZmFfc3BfbGlzdF9jYWNoZV9pbml0KCkgaXMgY2FsbGVkLCBzaW5jZQ0KPiAid2FybmVkIiBp c24ndCBzdGF0aWMuDQoNClZlcnkgcmlnaHQsIGkgbmVlZCB0byByZW1vdmUgdGhlIHdhcm5lZCwg cHJpbnRrX29uY2Ugc2hvdWxkIGJlIGVub3VnaCBoZXJlLg0KDQo+IA0KPj4gKyAgICAgICAgICAg IHsNCj4+ICsgICAgICAgICAgICAgICAgcHJpbnRrX29uY2UoWEVOTE9HX0VSUg0KPj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAiZmZhOiBGaXJtd2FyZSBpcyBub3QgdXNpbmcgYml0IDE1 IGNvbnZlbnRpb24gZm9yIElEcyAhIVxuIik7DQo+PiArICAgICAgICAgICAgICAgIHdhcm5lZCA9 IHRydWU7DQo+PiArICAgICAgICAgICAgfQ0KPj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0df RVJSDQo+PiArICAgICAgICAgICAgICAgICAgICJmZmE6IFNlY3VyZSBwYXJ0aXRpb24gd2l0aCBp ZCAweCUwNHggY2Fubm90IGJlIHVzZWRcbiIsDQo+PiArICAgICAgICAgICAgICAgICAgIGZwaS0+ aWQpOw0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0KPj4gKyAgICAgICAgfQ0KPj4gKw0KPj4g KyAgICAgICAgc2VjdXJlX2NvdW50Kys7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBz ZWN1cmVfY291bnQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBzcF9saXN0ID0geHphbGxvY19i eXRlcyhzZWN1cmVfY291bnQgKiBmcGlfc2l6ZSk7DQo+PiArICAgICAgICBpZiAoICFzcF9saXN0 ICkNCj4+ICsgICAgICAgICAgICByZXR1cm4gZmFsc2U7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsg ICAgc3BfbGlzdF9jb3VudCA9IHNlY3VyZV9jb3VudDsNCj4+ICsgICAgc3BfbGlzdF9lbnRyeV9z aXplID0gZnBpX3NpemU7DQo+PiArDQo+PiArICAgIGZvciAoIG4gPSAwOyBuIDwgY291bnQ7IG4r KyApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIGNvbnN0IHN0cnVjdCBmZmFfcGFydGl0aW9uX2lu Zm9fMV8wICpmcGkgPQ0KPj4gKyAgICAgICAgICAgIChjb25zdCB2b2lkICopKHNyYyArIG4gKiBm cGlfc2l6ZSk7DQo+PiArDQo+PiArICAgICAgICBpZiAoICFGRkFfSURfSVNfU0VDVVJFKGZwaS0+ aWQpICkNCj4+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4+ICsNCj4+ICsgICAgICAgIG1lbWNw eShzcF9saXN0ICsgaWR4ICogZnBpX3NpemUsIGZwaSwgZnBpX3NpemUpOw0KPj4gKyAgICAgICAg aWR4Kys7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIHRydWU7DQo+PiArfQ0KPj4g Kw0KPj4gc3RhdGljIGJvb2wgaW5pdF9zdWJzY3JpYmVycyh2b2lkICpidWYsIHVpbnQxNl90IGNv dW50LCB1aW50MzJfdCBmcGlfc2l6ZSkNCj4+IHsNCj4+ICAgICB1aW50MTZfdCBuOw0KPj4gQEAg LTU0OSwxMiArNjEwLDIyIEBAIGJvb2wgZmZhX3BhcnRpbmZvX2luaXQodm9pZCkNCj4+ICAgICAg ICAgZ290byBvdXQ7DQo+PiAgICAgfQ0KPj4gDQo+PiAtICAgIHJldCA9IGluaXRfc3Vic2NyaWJl cnMoc3BtY19yeCwgY291bnQsIGZwaV9zaXplKTsNCj4+ICsgICAgaWYgKCAhZmZhX3NwX2xpc3Rf Y2FjaGVfaW5pdChzcG1jX3J4LCBjb3VudCwgZnBpX3NpemUpICkNCj4+ICsgICAgew0KPj4gKyAg ICAgICAgcHJpbnRrKFhFTkxPR19FUlIgImZmYTogRmFpbGVkIHRvIGNhY2hlIFNQIGxpc3RcbiIp Ow0KPj4gKyAgICAgICAgZ290byBvdXQ7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0ID0g aW5pdF9zdWJzY3JpYmVycyhzcF9saXN0LCBzcF9saXN0X2NvdW50LCBzcF9saXN0X2VudHJ5X3Np emUpOw0KPj4gDQo+PiBvdXQ6DQo+PiAgICAgZSA9IGZmYV9yeHR4X3NwbWNfcnhfcmVsZWFzZShu b3RpZnlfZncpOw0KPj4gICAgIGlmICggZSApDQo+PiAgICAgICAgIHByaW50ayhYRU5MT0dfV0FS TklORyAiZmZhOiBFcnJvciByZWxlYXNpbmcgU1BNQyBSWCBidWZmZXI6ICVkXG4iLCBlKTsNCj4+ ICsgICAgaWYgKCAhcmV0ICkNCj4+ICsgICAgICAgIHVuaW5pdF9zdWJzY3JpYmVycygpOw0KPiAN Cj4gcmV0IGlzIGluaXRpYWxseSBmYWxzZSBhbmQgY2FuIG9ubHkgYmUgc2V0IHRvIHRydWUgaWYN Cj4gaW5pdF9zdWJzY3JpYmVycygpIHJldHVybnMgdHJ1ZS4gU28gdGhlcmUncyBuZXZlciBhbnkg cG9pbnQgaW4gY2FsbGluZw0KPiB1bmluaXRfc3Vic2NyaWJlcnMoKS4NCg0KVHJ1ZSwgSSB3aWxs IGZpeCB0aGF0Lg0KDQo+IA0KPj4gKyAgICBpZiAoICFyZXQgKQ0KPj4gKyAgICAgICAgZmZhX3Nw X2xpc3RfY2FjaGVfZnJlZSgpOw0KPiANCj4gcmV0IGNhbiBiZSBmYWxzZSBldmVuIGlmIGZmYV9z cF9saXN0X2NhY2hlX2luaXQoKSBoYXNuJ3QgYmVlbiBjYWxsZWQNCj4geWV0LiBDYWxsaW5nIGZm YV9zcF9saXN0X2NhY2hlX2ZyZWUoKSBhbnl3YXkgaXMgaGFybWxlc3MsIGJ1dCBub3QNCj4gZWxl Z2FudC4NCg0KeWVzLCBpIHdpbGwgcmV3b3JrIGEgYml0IHRoZSBjbGVhbnVwIGxvZ2ljIGhlcmUu DQoNClRoYW5rcyBmb3IgdGhlIHJldmlldw0KDQpDaGVlcnMNCkJlcnRyYW5kDQoNCj4gDQo+IENo ZWVycywNCj4gSmVucw0KPiANCj4+ICAgICByZXR1cm4gcmV0Ow0KPj4gfQ0KPj4gDQo+PiAtLQ0K Pj4gMi41Mi4wDQoNCg0K From xen-devel-bounces@lists.xenproject.org Mon Mar 02 08:58:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 08:58:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244019.1543491 (Exim 4.92) (envelope-from ) id 1vwz6w-0006WM-Fu; Mon, 02 Mar 2026 08:58:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244019.1543491; Mon, 02 Mar 2026 08:58:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwz6w-0006WF-Ce; Mon, 02 Mar 2026 08:58:42 +0000 Received: by outflank-mailman (input) for mailman id 1244019; Mon, 02 Mar 2026 08:58:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwz6v-0006W7-AC for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 08:58:41 +0000 Received: from OSPPR02CU001.outbound.protection.outlook.com (mail-norwayeastazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20f::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 00fdda3e-1616-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 09:58:39 +0100 (CET) Received: from AS9PR06CA0085.eurprd06.prod.outlook.com (2603:10a6:20b:464::15) by DU0PR08MB8229.eurprd08.prod.outlook.com (2603:10a6:10:3a7::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 08:58:30 +0000 Received: from AM4PEPF00027A6A.eurprd04.prod.outlook.com (2603:10a6:20b:464:cafe::49) by AS9PR06CA0085.outlook.office365.com (2603:10a6:20b:464::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.19 via Frontend Transport; Mon, 2 Mar 2026 08:58:22 +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.20.9654.16 via Frontend Transport; Mon, 2 Mar 2026 08:58:30 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by GV2PR08MB11739.eurprd08.prod.outlook.com (2603:10a6:150:327::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 08:57:25 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 08:57:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00fdda3e-1616-11f1-b164-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=CfyhpZ5j1DazCsF8HfRL/j65X89ARSuuah5BMNS4pdGlTz9+sgBF/Z9ler9iy43ZEQPJb7z0NXW4hq3+XC2qcBUcoSzJTQ2qtB7a4U/xma5/mNz78UoYYqzqHRBDoOiGa1CipyB3qGqt09hD6JnuiQbD4e3hyXMLoJU5tKVo8XyW5YHJrxY6ahh2n8cUdH3AiyEG0UTzY1r6YqnNXYSNoGBQ6JSzoFJlHmldp/xzZazrYVs46HFCWRFdJ4De3fluGmYmPRRKKqzOpMJMYMiTq0iNdOPsoE0/rv7vDGc1bfCVuqr0lFBmidaRWe29VXI3oM4AggpiLBHoysmXiNOO8w== 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=F8Z8HZbsZzhztpO46+NuZQSGKMkqTxQX0Nj3JSnA3N4=; b=T7hQ/OlkoFrtSrIdjUorp7IcTswlI1z0uo96NQgR4CQhgRnGWCmK5ndnzpIpJl8EQmh1rIFFGN5MTK1mGKLJvRp8/4T/DcA69KMQIL35eIlbtnFaRrpxQBzcGgmNvvg6JelBMetX8wVCz2DJ7+RrxdeUkBFy/dbOBv8YQv6FuNhUEpQB3XepRPvYOhlfTlFHqB3u9uQD8tE4AZ7cvzbmkjC/hys4tH2ou+v33vlEfStdjokJScrMS5ZPL/M+Z35AVVBStyvXJRc6uJ2JyXBJrg7TOv0j6DrFQLCYXpQYdjG6Xx0GtdTiEpTgNtzCbnhA87PP3IEl1IjTmU7nk7w7gQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=F8Z8HZbsZzhztpO46+NuZQSGKMkqTxQX0Nj3JSnA3N4=; b=Ez57r6NwkoxgqvUaetY7u83eY8kjFIjTFqBoMpwGJo1Mgl7edFq7jfHPDaw2UL251U1pxtW33u6B1BwYZHx/riQcouU983dNoJQUKrJzPkKX0J4cGzdVU29OycdP8/41TSjVyozv+FxIUlBHdHJqWpGltqbKrEINjk+1u9Ct1ss= 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=LaMPJcpvpdRQxI/QWU0ycl/Qt26BeEjGY6o7+F0XYCZ0BCClVKI8FFBErei4B5w1IjoBmQxG2s3Gz0s3eSeN4+jcUNOHMZK3+bxhdUJ4zXNTBOsErwYoYfTf8q0TvcMOz36ao/9qgRuYRv5wQfnjMwcQdaqQHw1b/Q4fXLTnttrX7X3Cw/EsszGvdKUix6hGj82uHP1ktEmrnxnsvQ/Pdxu6vKaQj+royCDeVyCseFJGJ7190dXfALZlpCm4UVgeRZI1hgdIqttUtiEkySOKt4AHMYmPvKO1Z4sQpye6KJUqI3lHrB9YvacSIUDnSYUcK1nmEXlSTQsYOVyuSs1wPg== 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=F8Z8HZbsZzhztpO46+NuZQSGKMkqTxQX0Nj3JSnA3N4=; b=Ba3xz5Zmsl0xtZHgu7hzUC/I3CcCKZ5ms9R6d2Fdrs6jBfowp+eTa4x3uA37Bdn1dCsNCDxSUm9PQygvdDD36Gw06/+N0wIMzPdWQiP5qI4DT7U9qBSwDg3uVoLXVTQMvkYB6hy4zI6wOoz08mFvaDBqMdQEf9v76TSGW/O9gTq+FaJ0DOTxnfVenI3lxHsiikYmPP9t+mHzV3W5vBQRuYKF2iz1/Un1gEdlXE1QwWBKpKg+h299ExwbJH9pCylM75ZoUPL2QoaXzO22g+Imx77VojMibuRJSdCq5qqnMr4MxKIFz2ZLT2YFI9ewA3ZA7P27/e6Rrj9AW+vmJk2oxg== 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=F8Z8HZbsZzhztpO46+NuZQSGKMkqTxQX0Nj3JSnA3N4=; b=Ez57r6NwkoxgqvUaetY7u83eY8kjFIjTFqBoMpwGJo1Mgl7edFq7jfHPDaw2UL251U1pxtW33u6B1BwYZHx/riQcouU983dNoJQUKrJzPkKX0J4cGzdVU29OycdP8/41TSjVyozv+FxIUlBHdHJqWpGltqbKrEINjk+1u9Ct1ss= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Topic: [PATCH 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Index: AQHcpj3kq0uMG7qoMEmDaKexZXnDI7WWpiEAgARSgwA= Date: Mon, 2 Mar 2026 08:57:24 +0000 Message-ID: References: <832ba950a53a7139b51053f6570fd9b26ba42df1.1772013062.git.bertrand.marquis@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|GV2PR08MB11739:EE_|AM4PEPF00027A6A:EE_|DU0PR08MB8229:EE_ X-MS-Office365-Filtering-Correlation-Id: dce13dc8-eec6-4ddf-1bfc-08de7839e064 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|10070799003|38070700021; X-Microsoft-Antispam-Message-Info-Original: pL6MuGIwGDMP6mLocpApm0JMxsGxBQEfoxDZrXQALbzQ4HTrU6GyznIoaDtxlpNPl2arLGVLoBlvzHAh/my4kUqNv3r8jCxJ/00tnS95SO4syMZIXWTXT3OIVmrIgKh05tVqun+3nHdKoCbcPj7koTRopDDJoGqRK0zKPZimCx0f1dYwvxfSZL59KGA0rSkN5C7AUzibpL8sNOpKpaJFGzKHfOhk1CK0AST12l6hUgg15PgW0yK5d9Vv+QGDjwhHoE8gUk8wmOcPIwtHQVrvWW0LVlhhLTiVAo7SgnzaRv3G2RQX8ybjezq9T8DqoXPglH4m+2QQgWV7EhxOcM/ELbmDks/cRiZ6pvY9E8AjEaUSp3tBS4zkvq06TsyJxcmuxoml8OgLzUtTgdf8q/cKZa4HawW/vBCTUYo/VSE1aHPrOVKDeXWWoILfY7oIYvDhSgL4VBHzEg2YsieMx4pXH0eyncotrUt/Qbk826KRg59Wh3Fzq9+7QeSlzU6qOIAmfeol+P9COjUUoilxjUo2crV6FJJd2Oka6+Ksl314hRHR6Q/d51A6hyXoPl7viZjEc5306PUIY54TWGLVT6aZG/BXnpbLUQcGya8zENQlZIZZY6o2i0g2foq9WwDGhbVhOUSzy9pymVDs8ckItvtGGubW9rsVBuJEPlcw9hy7x7bjBeZ2cM7mcWMD9lVq4aiBNoN7UPp+WHHnOJa0E1HIeJAOqfYVcMCYACBtOXaTdjSNsqxcXieeU+fM2y3rPxeViaKo66mPJxCsD0BLdfjeZKaHOiXQ2xlv8lqds5txgMk= 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)(10070799003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <822CD00BF5537D41B20498A4F818918E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR08MB11739 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A6A.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 613c4d93-8f76-4569-0289-08de7839b945 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|35042699022|376014|14060799003|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: iHffDa4jfSHsyXWu/hyKlkQfel7X7Vx38PlTaqVRPonSddrTp9LS3s9TxmEd2A+AarNC80OH7BaVE278vhZDgvuy//TOksXNH11cbMtDrgSVBbPL8OeMTNVDvNjaT1Nw7SXbOaxDuMlQnWHIBuw0/XK+kPDeRj0Vh1UukfaTA3Dx435aH4LcTFVKNv8veZuB1sO2agjysuFBhPaMGJ8dEWv9PHRABH+GmbrSokFW/Fc4LaKuJ4k8Pftra8upBoG20kFQHhGYTvFMxMA/6yeUFNOW8j8+9GMMP/xShn/aD54djIryylLNJIGFb2WEMBM+fT00xsEBceajTij2RWhnZePUN1ihgcO0vr2SG8lrufuhMxoOc1H/aSPIVA7GinYpDZfAARM4+g25SobVa1M2nAUiugS+Euia8TjwbEtZ2d7VuSpH14X4kTOGu2J9ol7GYqWu78l0ET6M6WAEGFsihY9wNhcCxvgoCJQ3Qdfd6kniHxrsWpbj8Vd4KU3XfBY0cIlAAci/YmJtBbcUdBuZTcIEDjL3uCUmYlHc9Xz//h0dj1fQsFjuE7PLlIyVdPSp95jrrxDV5j6+l8Sdt+qoBmtqxzVniae59lA1i/eJqHVIQMn45kgv9uEToaD7ADzfFWM5JnUMBvNPbZP0208TwdkoSFxpML72NAYG5qTs2Sd6Gp9a1Zv0YeZU9aUomR3enLa5lC1yvGlo1vsI6pdxRB7mb5qBwVzstcyiXAHw6DKw1ICFKH3Tg7uNwZQviK1f+pVCeX6pbK8n/g6nsCLsZe7p/BnUj+l4yYlzaHgrZnzDIuVcso2kFlwX7NTf4YqPaGY5HBYNvjzY9Sy3iZfXIA== 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)(36860700013)(82310400026)(35042699022)(376014)(14060799003)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CSfW9YWhSuiCmmpaZubl56CCiEws3dBAFgtWm+Asz7XfE+CEN6jOhhnnkI5zgKWEHda8RVZEO5SkGfYLLlpsepnvNSCPAiEr57DUNvxV0+p386mfjZdfz9wZhIgm641WBr7Ll5AG6q0bdfSsC5YGngsajtoXZBm2ZgaxyhRBLErGpe+Qt7/mFARMdKL+76KSJ185KF+DuYrJ8GIK9trEkOAGu3/NIyPDmPNUvWIJ2leFtfix4RUbzIKkBBAPgXVkomyanG6CKZ3sZyHdcBrP9rrToP6PWA994GqLCJVyAYMIl9g4FFNqlpQOH5D5ceRbnJlEYxJY5Y2tlWW0u5bF2qmJPe3mYqPKQ+c7lC2oTJrupfdWc59p5T/B2WPfT/YvbqE9DqEPN4Q76X/NOhB1UEsJvVxfiVALrtkKxM4VtpwHHih6CdtwJ25li1BOgRtz X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 08:58:30.5163 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dce13dc8-eec6-4ddf-1bfc-08de7839e064 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: DU0PR08MB8229 SGkgSmVucywNCg0KPiBPbiAyNyBGZWIgMjAyNiwgYXQgMTU6NTYsIEplbnMgV2lrbGFuZGVyIDxq ZW5zLndpa2xhbmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiAN Cj4gT24gV2VkLCBGZWIgMjUsIDIwMjYgYXQgMTE6MDLigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+ IDxiZXJ0cmFuZC5tYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBGRi1BIHYxLjIgZGVm aW5lcyBQQVJUSVRJT05fSU5GT19HRVRfUkVHUyBmb3IgcmVnaXN0ZXItYmFzZWQgcGFydGl0aW9u DQo+PiBpbmZvIHJldHJpZXZhbCwgYnV0IFhlbiBjdXJyZW50bHkgb25seSBzdXBwb3J0cyB0aGUg YnVmZmVyLWJhc2VkIEdFVA0KPj4gcGF0aCBmb3IgZ3Vlc3RzLg0KPj4gDQo+PiBJbXBsZW1lbnQg R0VUX1JFR1MgdXNpbmcgdGhlIGNhY2hlZCBTUCBsaXN0IGFuZCBWTSBlbnRyaWVzLCBpbmNsdWRp bmcNCj4+IHRoZSByZWdpc3RlciB3aW5kb3cgbGF5b3V0IGFuZCBpbnB1dCB2YWxpZGF0aW9uLiBU cmFjayBWTSBsaXN0IGNoYW5nZXMNCj4+IHZpYSB0aGUgcGFydGluZm8gdGFnIGFuZCB1c2UgaXQg dG8gdmFsaWRhdGUgR0VUX1JFR1MgdGFnIGlucHV0cy4gRW5zdXJlDQo+PiB0aGF0IHdoZW4gYSBu b24tTmlsIFVVSUQgaXMgc3BlY2lmaWVkLCB0aGUgVVVJRCBmaWVsZHMgaW4gYm90aCBHRVQgYW5k DQo+PiBHRVRfUkVHUyByZXN1bHRzIGFyZSBNQlogYXMgcmVxdWlyZWQgYnkgdGhlIHNwZWNpZmlj YXRpb24uDQo+PiANCj4+IFBBUlRJVElPTl9JTkZPX0dFVF9SRUdTIGlzIGF2YWlsYWJsZSB0byB2 MS4yIGd1ZXN0cywgcmV0dXJuaW5nIGNhY2hlZCBTUA0KPj4gZW50cmllcyBhbmQgVk0gZW50cmll cyB3aXRoIFVVSURzIHplcm9lZCBmb3Igbm9uLU5pbCBVVUlEIHF1ZXJpZXMuDQo+PiANCj4+IFNp Z25lZC1vZmYtYnk6IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4N Cj4+IC0tLQ0KPj4geGVuL2FyY2gvYXJtL3RlZS9mZmEuYyAgICAgICAgICB8ICAxNiArKysNCj4+ IHhlbi9hcmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMgfCAyMTEgKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysNCj4+IHhlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaCAgfCAgIDQg Ky0NCj4+IDMgZmlsZXMgY2hhbmdlZCwgMjMwIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkN Cj4+IA0KPj4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMgYi94ZW4vYXJjaC9h cm0vdGVlL2ZmYS5jDQo+PiBpbmRleCBhYTQzYWUyNTk1ZDcuLmQ1NmViMjBjMjIzOSAxMDA2NDQN Cj4+IC0tLSBhL3hlbi9hcmNoL2FybS90ZWUvZmZhLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS90 ZWUvZmZhLmMNCj4+IEBAIC00NCw2ICs0NCwxMSBAQA0KPj4gICogICAtIGRvZXNuJ3Qgc3VwcG9y dCBzaWduYWxsaW5nIHRoZSBzZWNvbmRhcnkgc2NoZWR1bGVyIG9mIHBlbmRpbmcNCj4+ICAqICAg ICBub3RpZmljYXRpb24gZm9yIHNlY3VyZSBwYXJ0aXRpb25zDQo+PiAgKiAgIC0gZG9lc24ndCBz dXBwb3J0IG5vdGlmaWNhdGlvbnMgZm9yIFhlbiBpdHNlbGYNCj4+ICsgKiBvIEZGQV9QQVJUSVRJ T05fSU5GT19HRVQvR0VUX1JFR1M6DQo+PiArICogICAtIHYxLjAgZ3Vlc3RzIG1heSBzZWUgZHVw bGljYXRlIFNQIElEcyB3aGVuIGZpcm13YXJlIHByb3ZpZGVzIFVVSURzDQo+PiArICogICAtIFNQ IGxpc3QgaXMgY2FjaGVkIGF0IGluaXQ7IFNQTUMgdGFnIGNoYW5nZXMgYXJlIG5vdCB0cmFja2Vk DQo+PiArICogICAgIGJldHdlZW4gY2FsbHMNCj4+ICsgKiAgIC0gU1AgbGlzdCBpcyBjYXBwZWQg YXQgRkZBX01BWF9OVU1fU1AgZW50cmllcw0KPj4gICoNCj4+ICAqIFRoZXJlIGFyZSBzb21lIGxh cmdlIGxvY2tlZCBzZWN0aW9ucyB3aXRoIGZmYV9zcG1jX3R4X2xvY2sgYW5kDQo+PiAgKiBmZmFf c3BtY19yeF9sb2NrLiBFc3BlY2lhbGx5IHRoZSBmZmFfc3BtY190eF9sb2NrIHNwaW5sb2NrIHVz ZWQNCj4+IEBAIC0xODgsNiArMTkzLDcgQEAgc3RhdGljIGJvb2wgZmZhX25lZ290aWF0ZV92ZXJz aW9uKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAgICAgICAgICAgd3JpdGVfbG9j aygmZmZhX2N0eF9saXN0X3J3bG9jayk7DQo+PiAgICAgICAgICAgICBsaXN0X2FkZF90YWlsKCZj dHgtPmN0eF9saXN0LCAmZmZhX2N0eF9oZWFkKTsNCj4+ICAgICAgICAgICAgIHdyaXRlX3VubG9j aygmZmZhX2N0eF9saXN0X3J3bG9jayk7DQo+PiArICAgICAgICAgICAgZmZhX3BhcnRpbmZvX2lu Y190YWcoKTsNCj4+ICAgICAgICAgfQ0KPj4gDQo+PiAgICAgICAgIGdvdG8gb3V0X2NvbnRpbnVl Ow0KPj4gQEAgLTM0MSw2ICszNDcsMTIgQEAgc3RhdGljIHZvaWQgaGFuZGxlX2ZlYXR1cmVzKHN0 cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAgIGNhc2UgRkZBX0ZFQVRVUkVfU0NIRURV TEVfUkVDVl9JTlRSOg0KPj4gICAgICAgICBmZmFfc2V0X3JlZ3Nfc3VjY2VzcyhyZWdzLCBHVUVT VF9GRkFfU0NIRURVTEVfUkVDVl9JTlRSX0lELCAwKTsNCj4+ICAgICAgICAgYnJlYWs7DQo+PiAr ICAgIGNhc2UgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9SRUdTOg0KPj4gKyAgICAgICAgaWYgKCBB Q0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpID49IEZGQV9WRVJTSU9OXzFfMiApDQo+PiArICAg ICAgICAgICAgZmZhX3NldF9yZWdzX3N1Y2Nlc3MocmVncywgMCwgMCk7DQo+PiArICAgICAgICBl bHNlDQo+PiArICAgICAgICAgICAgZmZhX3NldF9yZWdzX2Vycm9yKHJlZ3MsIEZGQV9SRVRfTk9U X1NVUFBPUlRFRCk7DQo+PiArICAgICAgICBicmVhazsNCj4+IA0KPj4gICAgIGNhc2UgRkZBX05P VElGSUNBVElPTl9CSU5EOg0KPj4gICAgIGNhc2UgRkZBX05PVElGSUNBVElPTl9VTkJJTkQ6DQo+ PiBAQCAtNDAyLDYgKzQxNCw5IEBAIHN0YXRpYyBib29sIGZmYV9oYW5kbGVfY2FsbChzdHJ1Y3Qg Y3B1X3VzZXJfcmVncyAqcmVncykNCj4+ICAgICBjYXNlIEZGQV9QQVJUSVRJT05fSU5GT19HRVQ6 DQo+PiAgICAgICAgIGZmYV9oYW5kbGVfcGFydGl0aW9uX2luZm9fZ2V0KHJlZ3MpOw0KPj4gICAg ICAgICByZXR1cm4gdHJ1ZTsNCj4+ICsgICAgY2FzZSBGRkFfUEFSVElUSU9OX0lORk9fR0VUX1JF R1M6DQo+PiArICAgICAgICBmZmFfaGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldF9yZWdzKHJlZ3Mp Ow0KPj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+PiAgICAgY2FzZSBGRkFfUlhfUkVMRUFTRToN Cj4+ICAgICAgICAgZSA9IGZmYV9yeF9yZWxlYXNlKGN0eCk7DQo+PiAgICAgICAgIGJyZWFrOw0K Pj4gQEAgLTYyOSw2ICs2NDQsNyBAQCBzdGF0aWMgaW50IGZmYV9kb21haW5fdGVhcmRvd24oc3Ry dWN0IGRvbWFpbiAqZCkNCj4+ICAgICAgICAgd3JpdGVfbG9jaygmZmZhX2N0eF9saXN0X3J3bG9j ayk7DQo+PiAgICAgICAgIGxpc3RfZGVsKCZjdHgtPmN0eF9saXN0KTsNCj4+ICAgICAgICAgd3Jp dGVfdW5sb2NrKCZmZmFfY3R4X2xpc3Rfcndsb2NrKTsNCj4+ICsgICAgICAgIGZmYV9wYXJ0aW5m b19pbmNfdGFnKCk7DQo+PiAgICAgfQ0KPj4gDQo+PiAgICAgZmZhX3J4dHhfZG9tYWluX2Rlc3Ry b3koZCk7DQo+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFydGluZm8uYyBi L3hlbi9hcmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMNCj4+IGluZGV4IGQ3ZjliOWY3MTUzYy4u MWM3YjM1NzlmNzk4IDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFydGlu Zm8uYw0KPj4gKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFydGluZm8uYw0KPj4gQEAgLTI4 LDEwICsyOCwzOSBAQCBzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSB7DQo+PiAgICAgdWlu dDhfdCB1dWlkWzE2XTsNCj4+IH07DQo+PiANCj4+ICsvKiBSZWdpc3RlcnMgYTMuLmExNyAoMTUg cmVncykgY2FycnkgcGFydGl0aW9uIGRlc2NyaXB0b3JzLCAzIHJlZ3MgZWFjaC4gKi8NCj4+ICsj ZGVmaW5lIEZGQV9QQVJUSU5GT19SRUdfTUFYX0VOVFJJRVMgXA0KPj4gKyAgICAoKDE1ICogc2l6 ZW9mKHVpbnQ2NF90KSkgLyBzaXplb2Yoc3RydWN0IGZmYV9wYXJ0aXRpb25faW5mb18xXzEpKQ0K Pj4gKw0KPj4gLyogU1AgbGlzdCBjYWNoZSAoc2VjdXJlIGVuZHBvaW50cyBvbmx5KTsgcG9wdWxh dGVkIGF0IGluaXQuICovDQo+PiBzdGF0aWMgdm9pZCAqc3BfbGlzdCBfX3JlYWRfbW9zdGx5Ow0K Pj4gc3RhdGljIHVpbnQzMl90IHNwX2xpc3RfY291bnQgX19yZWFkX21vc3RseTsNCj4+IHN0YXRp YyB1aW50MzJfdCBzcF9saXN0X2VudHJ5X3NpemUgX19yZWFkX21vc3RseTsNCj4+ICsNCj4+ICsv KiBTUCBsaXN0IGlzIHN0YXRpYzsgdGFnIG9ubHkgbW92ZXMgd2hlbiBWTXMgYXJlIGFkZGVkL3Jl bW92ZWQuICovDQo+PiArc3RhdGljIGF0b21pY190IGZmYV9wYXJ0aW5mb190YWcgPSBBVE9NSUNf SU5JVCgxKTsNCj4+ICsNCj4+ICt2b2lkIGZmYV9wYXJ0aW5mb19pbmNfdGFnKHZvaWQpDQo+PiAr ew0KPj4gKyAgICBhdG9taWNfaW5jKCZmZmFfcGFydGluZm9fdGFnKTsNCj4gDQo+IERvIHdlIG5l ZWQgdG8gd29ycnkgYWJvdXQgdGhpcyB2YWx1ZSB3cmFwcGluZz8gSXMgd3JhcHBpbmcgcGVybWl0 dGVkPw0KDQp3cmFwcGluZyBpcyBwZXJtaXR0ZWQsIGFzIHRoZSBlbmQgdGhpcyB2YWx1ZSBpcyB1 c2VkIHRvIGVuc3VyZSBjaGFuZ2VzIGluDQp0aGUgbWlkZGxlIG9mIGluZm9fZ2V0X3JlZ3MgYXJl IGRldGVjdGVkLiBIYXZpbmcgZW5vdWdoIGNoYW5nZXMgaW4gdGhlDQptaWRkbGUgZm9yIHRoaXMg dG8gd3JhcCBhbmQgZW5kIHVwIHVuLWRldGVjdGVkIGJ5IHRoZSBjYWxsZXIgaXMgbmVhciB0byBp bXBvc3NpYmxlLg0KSW4gYW55IGNhc2UsIHRoZSBzdGF0dXMgd2UgcmV0dXJuIGlzIGEgc25hcHNo b3Qgd2hpY2ggaGF2ZSBjaGFuZ2VkIGFzIHNvb24gYXMNCnRoZSByZXN1bHQgaXMgcmV0dXJuZWQg c28gaSB3b3VsZCBjb25zaWRlciB0aGlzIGEgYmVzdCBlZmZvcnQgKGV2ZW4gaWYgdGhlIHByb2Jh YmlsaXR5DQpmb3IgdGhpcyB0byBoYXBwZW4gaXMgdmVyeSB2ZXJ5IG5lYXIgdG8gMCkuDQoNCj4g DQo+PiArfQ0KPj4gKw0KPj4gK3N0YXRpYyBpbmxpbmUgdWludDE2X3QgZmZhX3BhcnRpbmZvX2dl dF90YWcodm9pZCkNCj4+ICt7DQo+PiArICAgIC8qDQo+PiArICAgICAqIFRhZyBtb3ZlcyB3aXRo IFZNIGxpc3QgY2hhbmdlcyBvbmx5Lg0KPj4gKyAgICAgKg0KPj4gKyAgICAgKiBMaW1pdGF0aW9u OiB3ZSBjYW5ub3QgZGV0ZWN0IGFuIFNQTUMgdGFnIGNoYW5nZSBiZXR3ZWVuIGNhbGxzIGJlY2F1 c2Ugd2UNCj4+ICsgICAgICogZG8gbm90IHJldGFpbiB0aGUgcHJldmlvdXMgU1BNQyB0YWc7IHdl IG9ubHkgcmVmcmVzaCBpdCB2aWEgdGhlIG1hbmRhdG9yeQ0KPj4gKyAgICAgKiBzdGFydF9pbmRl eD0wIGNhbGwgYW5kIGFzc3VtZSBpdCBzdGF5cyBzdGFibGUgd2hpbGUgY29tYmluZWRfdGFnIChv dXINCj4+ICsgICAgICogVk0vU1AtY291bnQgdGFnKSBpcyB1c2VkIGZvciBndWVzdCB2YWxpZGF0 aW9uLiBUaGlzIG1lYW5zIFNQTUMgdGFnDQo+PiArICAgICAqIGNoYW5nZXMgYWxvbmUgd2lsbCBu b3QgdHJpZ2dlciBSRVRSWS4NCj4+ICsgICAgICovDQo+PiArICAgIGlmICggSVNfRU5BQkxFRChD T05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+PiArICAgICAgICByZXR1cm4gYXRvbWljX3JlYWQoJmZm YV9wYXJ0aW5mb190YWcpICYgR0VOTUFTSygxNSwgMCk7DQo+PiArICAgIGVsc2UNCj4+ICsgICAg ICAgIHJldHVybiAxOw0KPj4gK30NCj4+IHN0YXRpYyBpbnQzMl90IGZmYV9wYXJ0aXRpb25faW5m b19nZXQoc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90IGZsYWdzLA0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCAqY291bnQsIHVpbnQzMl90ICpm cGlfc2l6ZSkNCj4+IHsNCj4+IEBAIC0xMjUsNiArMTU0LDcgQEAgc3RhdGljIGludDMyX3QgZmZh X2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZhX3V1aWQgdXVpZCwgdWludDMyX3QgKnNwX2NvdW50 LA0KPj4gICAgIGZvciAoIG4gPSAwOyBuIDwgc3BfbGlzdF9jb3VudDsgbisrICkNCj4+ICAgICB7 DQo+PiAgICAgICAgIHZvaWQgKmVudHJ5ID0gc3BfbGlzdCArIG4gKiBzcF9saXN0X2VudHJ5X3Np emU7DQo+PiArICAgICAgICB2b2lkICpkc3RfcG9zOw0KPj4gDQo+PiAgICAgICAgIGlmICggIWZm YV9zcF9lbnRyeV9tYXRjaGVzX3V1aWQoZW50cnksIHV1aWQpICkNCj4+ICAgICAgICAgICAgIGNv bnRpbnVlOw0KPj4gQEAgLTEzNiwxMSArMTY2LDIwIEBAIHN0YXRpYyBpbnQzMl90IGZmYV9nZXRf c3BfcGFydGluZm8oc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90ICpzcF9jb3VudCwNCj4+ ICAgICAgICAgICogVGhpcyBpcyBhIG5vbi1jb21wbGlhbmNlIHRvIHRoZSBzcGVjaWZpY2F0aW9u IGJ1dCAxLjAgVk1zIHNob3VsZA0KPj4gICAgICAgICAgKiBoYW5kbGUgdGhhdCBvbiB0aGVpciBv d24gdG8gc2ltcGxpZnkgWGVuIGltcGxlbWVudGF0aW9uLg0KPj4gICAgICAgICAgKi8NCj4+ICsg ICAgICAgIGRzdF9wb3MgPSAqZHN0X2J1ZjsNCj4+ICAgICAgICAgcmV0ID0gZmZhX2NvcHlfaW5m byhkc3RfYnVmLCBlbmRfYnVmLCBlbnRyeSwgZHN0X3NpemUsDQo+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc3BfbGlzdF9lbnRyeV9zaXplKTsNCj4+ICAgICAgICAgaWYgKCByZXQgKQ0K Pj4gICAgICAgICAgICAgcmV0dXJuIHJldDsNCj4+IA0KPj4gKyAgICAgICAgaWYgKCAhZmZhX3V1 aWRfaXNfbmlsKHV1aWQpICYmDQo+PiArICAgICAgICAgICAgIGRzdF9zaXplID49IHNpemVvZihz dHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSkgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAg ICAgICAgIHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xICpmcGkgPSBkc3RfcG9zOw0KPj4g Kw0KPj4gKyAgICAgICAgICAgIG1lbXNldChmcGktPnV1aWQsIDAsIHNpemVvZihmcGktPnV1aWQp KTsNCj4+ICsgICAgICAgIH0NCj4+ICsNCj4+ICAgICAgICAgY291bnQrKzsNCj4+ICAgICB9DQo+ PiANCj4+IEBAIC0xNTIsNiArMTkxLDM4IEBAIHN0YXRpYyBpbnQzMl90IGZmYV9nZXRfc3BfcGFy dGluZm8oc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90ICpzcF9jb3VudCwNCj4+ICAgICBy ZXR1cm4gRkZBX1JFVF9PSzsNCj4+IH0NCj4+IA0KPj4gK3N0YXRpYyB1aW50MTZfdCBmZmFfZ2V0 X3NwX3BhcnRpbmZvX3JlZ3Moc3RydWN0IGZmYV91dWlkIHV1aWQsDQo+PiArICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBzdGFydF9pbmRleCwNCj4+ICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ2NF90ICpvdXRfcmVn cywNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90 IG1heF9lbnRyaWVzKQ0KPj4gK3sNCj4+ICsgICAgdWludDMyX3QgaWR4ID0gMDsNCj4+ICsgICAg dWludDE2X3QgZmlsbGVkID0gMDsNCj4+ICsgICAgdWludDMyX3QgbjsNCj4+ICsNCj4+ICsgICAg Zm9yICggbiA9IDA7IG4gPCBzcF9saXN0X2NvdW50ICYmIGZpbGxlZCA8IG1heF9lbnRyaWVzOyBu KysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICB2b2lkICplbnRyeSA9IHNwX2xpc3QgKyBuICog c3BfbGlzdF9lbnRyeV9zaXplOw0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCAhZmZhX3NwX2VudHJ5 X21hdGNoZXNfdXVpZChlbnRyeSwgdXVpZCkgKQ0KPj4gKyAgICAgICAgICAgIGNvbnRpbnVlOw0K Pj4gKw0KPj4gKyAgICAgICAgaWYgKCBpZHgrKyA8IHN0YXJ0X2luZGV4ICkNCj4+ICsgICAgICAg ICAgICBjb250aW51ZTsNCj4+ICsNCj4+ICsgICAgICAgIG1lbWNweSgmb3V0X3JlZ3NbZmlsbGVk ICogM10sIGVudHJ5LA0KPj4gKyAgICAgICAgICAgICAgIHNpemVvZihzdHJ1Y3QgZmZhX3BhcnRp dGlvbl9pbmZvXzFfMSkpOw0KPj4gKyAgICAgICAgaWYgKCAhZmZhX3V1aWRfaXNfbmlsKHV1aWQp ICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBvdXRfcmVnc1tmaWxsZWQgKiAzICsg MV0gPSAwOw0KPj4gKyAgICAgICAgICAgIG91dF9yZWdzW2ZpbGxlZCAqIDMgKyAyXSA9IDA7DQo+ PiArICAgICAgICB9DQo+PiArICAgICAgICBmaWxsZWQrKzsNCj4+ICsgICAgfQ0KPj4gKw0KPj4g KyAgICByZXR1cm4gZmlsbGVkOw0KPj4gK30NCj4+ICsNCj4+IHN0YXRpYyBpbnQzMl90IGZmYV9n ZXRfdm1fcGFydGluZm8oc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90IHN0YXJ0X2luZGV4 LA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCAqdm1fY291 bnQsIHZvaWQgKipkc3RfYnVmLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB2b2lkICplbmRfYnVmLCB1aW50MzJfdCBkc3Rfc2l6ZSkNCj4+IEBAIC0zNjgsNiArNDM5LDE0 NiBAQCBvdXQ6DQo+PiAgICAgfQ0KPj4gfQ0KPj4gDQo+PiArdm9pZCBmZmFfaGFuZGxlX3BhcnRp dGlvbl9pbmZvX2dldF9yZWdzKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gK3sNCj4+ ICsgICAgc3RydWN0IGRvbWFpbiAqZCA9IGN1cnJlbnQtPmRvbWFpbjsNCj4+ICsgICAgc3RydWN0 IGZmYV9jdHggKmN0eCA9IGQtPmFyY2gudGVlOw0KPj4gKyAgICBzdHJ1Y3QgZmZhX3V1aWQgdXVp ZDsNCj4+ICsgICAgdWludDMyX3Qgc3BfY291bnQgPSAwLCB2bV9jb3VudCA9IDAsIHRvdGFsX2Nv dW50Ow0KPj4gKyAgICB1aW50MTZfdCBzdGFydF9pbmRleCwgdGFnOw0KPj4gKyAgICB1aW50MTZf dCBudW1fZW50cmllcyA9IDA7DQo+PiArICAgIHVpbnQ2NF90IHgzID0gZ2V0X3VzZXJfcmVnKHJl Z3MsIDMpOw0KPj4gKyAgICBpbnQzMl90IHJldCA9IEZGQV9SRVRfT0s7DQo+PiArICAgIHVpbnQ2 NF90IG91dF9yZWdzWzE4XSA9IHsgMCB9Ow0KPj4gKyAgICB1bnNpZ25lZCBpbnQgbjsNCj4+ICsg ICAgdWludDE2X3QgdGFnX291dDsNCj4+ICsNCj4+ICsgICAgaWYgKCBBQ0NFU1NfT05DRShjdHgt Pmd1ZXN0X3ZlcnMpIDwgRkZBX1ZFUlNJT05fMV8yICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAg cmV0ID0gRkZBX1JFVF9OT1RfU1VQUE9SVEVEOw0KPj4gKyAgICAgICAgZ290byBvdXQ7DQo+PiAr ICAgIH0NCj4+ICsNCj4+ICsgICAgLyoNCj4+ICsgICAgICogUmVnaXN0ZXJzIGEzLi5hMTcgKDE1 IHJlZ3MpIGNhcnJ5IHBhcnRpdGlvbiBkZXNjcmlwdG9ycywgMyByZWdzIGVhY2guDQo+PiArICAg ICAqIEZvciBGRi1BIDEuMiwgdGhhdCB5aWVsZHMgYSBtYXhpbXVtIG9mIDUgZW50cmllcyBwZXIg R0VUX1JFR1MgY2FsbC4NCj4+ICsgICAgICogRW5mb3JjZSB0aGUgYXNzdW1lZCBsYXlvdXQgc28g d2luZG93IHNpemluZyBzdGF5cyBjb3JyZWN0Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAgQlVJTERf QlVHX09OKEZGQV9QQVJUSU5GT19SRUdfTUFYX0VOVFJJRVMgIT0gNSk7DQo+PiArDQo+PiArICAg IGZvciAoIG4gPSA0OyBuIDw9IDE3OyBuKysgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBpZiAo IGdldF91c2VyX3JlZyhyZWdzLCBuKSApDQo+PiArICAgICAgICB7DQo+IA0KPiB4NC14MTcgYXJl IFNCWiwgc28gSSB0aGluayB3ZSBzaG91bGQgb25seSBpZ25vcmUgdGhlbS4NCg0KQWNrLCB0aGlz IHdhcyBhZGRlZCB0byBzYXRpc2Z5IHRoZSBjb21wbGlhbmNlIHN1aXRlIGJ1dCB0aGlzDQpoYXMg YmVlbiBzb2x2ZWQgc2luY2UuIEkgd2lsbCByZW1vdmUuDQoNCj4gDQo+PiArICAgICAgICAgICAg cmV0ID0gRkZBX1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7DQo+PiArICAgICAgICAgICAgZ290byBv dXQ7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCB4MyA+PiAz MiApDQo+IA0KPiBTYW1lIGhlcmU6IEJpdHNbNjM6MzJdIGFyZSBTQlouDQoNClNhbWUgaGVyZS4N Cg0KPiANCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9JTlZBTElEX1BBUkFN RVRFUlM7DQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBz dGFydF9pbmRleCA9IHgzICYgR0VOTUFTSygxNSwgMCk7DQo+PiArICAgIHRhZyA9ICh4MyA+PiAx NikgJiBHRU5NQVNLKDE1LCAwKTsNCj4+ICsNCj4+ICsgICAgLyogU3RhcnQgaW5kZXggbXVzdCBh bGxvdyByb29tIGZvciB1cCB0byA1IGVudHJpZXMgd2l0aG91dCAxNi1iaXQgb3ZlcmZsb3cuICov DQo+PiArICAgIGlmICggc3RhcnRfaW5kZXggPiAoR0VOTUFTSygxNSwgMCkgLSAoRkZBX1BBUlRJ TkZPX1JFR19NQVhfRU5UUklFUyAtIDEpKSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9 IEZGQV9SRVRfSU5WQUxJRF9QQVJBTUVURVJTOw0KPj4gKyAgICAgICAgZ290byBvdXQ7DQo+PiAr ICAgIH0NCj4+ICsNCj4+ICsgICAgdXVpZC52YWxbMF0gPSBnZXRfdXNlcl9yZWcocmVncywgMSk7 DQo+PiArICAgIHV1aWQudmFsWzFdID0gZ2V0X3VzZXJfcmVnKHJlZ3MsIDIpOw0KPj4gKw0KPj4g KyAgICBpZiAoIHNwX2xpc3RfY291bnQgJiYNCj4+ICsgICAgICAgICBzcF9saXN0X2VudHJ5X3Np emUgIT0gc2l6ZW9mKHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xKSApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRfTk9UX1NVUFBPUlRFRDsNCj4gDQo+IFRoaXMgY2Fu J3QgaGFwcGVuLiBCdXQgSSBndWVzcyBhIHNwX2xpc3RfZW50cnlfc2l6ZSA+IHNpemVvZihzdHJ1 Y3QNCj4gZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSkgbWlnaHQgYmUgc3VwcG9ydGVkIHRvIGJlIGZ1 dHVyZSBwcm9vZi4NCg0KUmlnaHQgbm93IHdlIGhhdmUgRkZBX1BBUlRJTkZPX1JFR19NQVhfRU5U UklFUyBlbmZvcmNpbmcgdGhlDQpzdHJ1Y3R1cmUgdG8gYmUgMS4xIHNpemUuIElmIHRoaXMgaXMg bm90IHRydWUgaW4gdGhlIGZ1dHVyZSB3ZSB3aWxsIGhhdmUgdG8gbW9kaWZ5DQp0aGlzLg0KDQpU aGlzIGlzIG5vdCByZWFsbHkgZnV0dXJlIHByb29mIGFuZCBpIHdpbGwgY2hlY2sgaWYgaSBjYW4g cmV3b3JrIHRoaXMuDQoNCj4gDQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4g Kw0KPj4gKyAgICB0YWdfb3V0ID0gZmZhX3BhcnRpbmZvX2dldF90YWcoKTsNCj4+ICsNCj4+ICsg ICAgaWYgKCBzdGFydF9pbmRleCA9PSAwICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCB0 YWcgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAgIHJldCA9IEZGQV9SRVRfSU5WQUxJ RF9QQVJBTUVURVJTOw0KPj4gKyAgICAgICAgICAgIGdvdG8gb3V0Ow0KPj4gKyAgICAgICAgfQ0K Pj4gKyAgICB9DQo+PiArICAgIGVsc2UgaWYgKCB0YWcgIT0gdGFnX291dCApDQo+PiArICAgIHsN Cj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRfUkVUUlk7DQo+PiArICAgICAgICBnb3RvIG91dDsN Cj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICBpZiAoIGZmYV91dWlkX2lzX25pbCh1dWlkKSApDQo+ PiArICAgIHsNCj4+ICsgICAgICAgIGlmICggSVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZN KSApDQo+PiArICAgICAgICAgICAgdm1fY291bnQgPSBnZXRfZmZhX3ZtX2NvdW50KCk7DQo+PiAr ICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgdm1fY291bnQgPSAxOyAvKiBDYWxsZXIgVk0g b25seSAqLw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIHJldCA9IGZmYV9nZXRfc3BfY291bnQo dXVpZCwgJnNwX2NvdW50KTsNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZ290byBv dXQ7DQo+PiArDQo+PiArICAgIHRvdGFsX2NvdW50ID0gc3BfY291bnQgKyB2bV9jb3VudDsNCj4+ ICsNCj4+ICsgICAgaWYgKCB0b3RhbF9jb3VudCA9PSAwIHx8IHN0YXJ0X2luZGV4ID49IHRvdGFs X2NvdW50ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9JTlZBTElEX1BB UkFNRVRFUlM7DQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAg ICBpZiAoIHN0YXJ0X2luZGV4IDwgc3BfY291bnQgKQ0KPj4gKyAgICAgICAgbnVtX2VudHJpZXMg PSBmZmFfZ2V0X3NwX3BhcnRpbmZvX3JlZ3ModXVpZCwgc3RhcnRfaW5kZXgsICZvdXRfcmVnc1sz XSwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZG QV9QQVJUSU5GT19SRUdfTUFYX0VOVFJJRVMpOw0KPj4gKw0KPj4gKyAgICBpZiAoIG51bV9lbnRy aWVzIDwgRkZBX1BBUlRJTkZPX1JFR19NQVhfRU5UUklFUyApDQo+PiArICAgIHsNCj4+ICsgICAg ICAgIHVpbnQzMl90IHZtX3N0YXJ0ID0gc3RhcnRfaW5kZXggPiBzcF9jb3VudCA/DQo+PiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN0YXJ0X2luZGV4IC0gc3BfY291bnQgOiAwOw0KPj4g KyAgICAgICAgdWludDMyX3QgZmlsbGVkID0gMDsNCj4+ICsgICAgICAgIHZvaWQgKnZtX2RzdCA9 ICZvdXRfcmVnc1szICsgbnVtX2VudHJpZXMgKiAzXTsNCj4+ICsgICAgICAgIHZvaWQgKnZtX2Vu ZCA9ICZvdXRfcmVnc1sxOF07DQo+PiArDQo+PiArICAgICAgICByZXQgPSBmZmFfZ2V0X3ZtX3Bh cnRpbmZvKHV1aWQsIHZtX3N0YXJ0LCAmZmlsbGVkLCAmdm1fZHN0LCB2bV9lbmQsDQo+PiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpemVvZihzdHJ1Y3QgZmZhX3BhcnRpdGlv bl9pbmZvXzFfMSkpOw0KPj4gKyAgICAgICAgaWYgKCByZXQgIT0gRkZBX1JFVF9PSyAmJiByZXQg IT0gRkZBX1JFVF9OT19NRU1PUlkgKQ0KPj4gKyAgICAgICAgICAgIGdvdG8gb3V0Ow0KPj4gKw0K Pj4gKyAgICAgICAgbnVtX2VudHJpZXMgKz0gZmlsbGVkOw0KPj4gKyAgICB9DQo+PiArDQo+PiAr ICAgIGlmICggbnVtX2VudHJpZXMgPT0gMCApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9 IEZGQV9SRVRfSU5WQUxJRF9QQVJBTUVURVJTOw0KPj4gKyAgICAgICAgZ290byBvdXQ7DQo+PiAr ICAgIH0NCj4+ICsNCj4gDQo+IFdoYXQgaWYgdGhlIHRhZyByZWFkIHdpdGggZmZhX3BhcnRpbmZv X2dldF90YWcoKSBoYXMgY2hhbmdlZD8NCg0KQXMgc2FpZCB0aGlzIGlzIGEgYmVzdCBlZmZvcnQs IHdlIHByb3ZpZGUgYSBzbmFwc2hvdC4NCk5vdyBpIGNvdWxkIGNoZWNrIGFuZCBjb21wYXJlIHRo ZSB0YWcgYXQgdGhlIGVuZCB0byBoYW5kbGUgdGhpcyBjYXNlLg0KDQpJIHdpbGwgY2hlY2sgaWYg aSBjYW4gbWFrZSB0aGlzIGEgYml0IHN0cm9uZ2VyIGJ5IGNvbXBhcmluZyB0aGUgdGFnIGF0IHRo ZQ0KYmVnaW5uaW5nIGFuZCB0aGUgZW5kIG9yIHRyeSB0byBoYW5kbGUgaXQgZGlmZmVyZW50bHkg KGdldCBpdHMgdmFsdWUgd2hpbGUgd2UNCmhhdmUgdGhlIHJ3bG9jayBvbiB0aGUgbGlzdCBvZiBW TXMgbWF5YmUpLg0KDQpDaGVlcnMNCkJlcnRyYW5kDQoNCj4gDQo+IENoZWVycywNCj4gSmVucw0K PiANCj4+ICsgICAgb3V0X3JlZ3NbMF0gPSBGRkFfU1VDQ0VTU182NDsNCj4+ICsgICAgb3V0X3Jl Z3NbMl0gPSAoKHVpbnQ2NF90KXNpemVvZihzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSkg PDwgNDgpIHwNCj4+ICsgICAgICAgICAgICAgICAgICAoKHVpbnQ2NF90KXRhZ19vdXQgPDwgMzIp IHwNCj4+ICsgICAgICAgICAgICAgICAgICAoKHVpbnQ2NF90KShzdGFydF9pbmRleCArIG51bV9l bnRyaWVzIC0gMSkgPDwgMTYpIHwNCj4+ICsgICAgICAgICAgICAgICAgICAoKHVpbnQ2NF90KSh0 b3RhbF9jb3VudCAtIDEpICYgR0VOTUFTSygxNSwgMCkpOw0KPj4gKw0KPj4gKyAgICBmb3IgKCBu ID0gMDsgbiA8IEFSUkFZX1NJWkUob3V0X3JlZ3MpOyBuKysgKQ0KPj4gKyAgICAgICAgc2V0X3Vz ZXJfcmVnKHJlZ3MsIG4sIG91dF9yZWdzW25dKTsNCj4+ICsNCj4+ICsgICAgcmV0dXJuOw0KPj4g Kw0KPj4gK291dDoNCj4+ICsgICAgaWYgKCByZXQgKQ0KPj4gKyAgICAgICAgZmZhX3NldF9yZWdz X2Vycm9yKHJlZ3MsIHJldCk7DQo+PiArfQ0KPj4gKw0KPj4gc3RhdGljIGludDMyX3QgZmZhX2Rp cmVjdF9yZXFfc2VuZF92bSh1aW50MTZfdCBzcF9pZCwgdWludDE2X3Qgdm1faWQsDQo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4X3QgbXNnKQ0KPj4gew0KPj4g ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaCBiL3hlbi9hcmNoL2Fy bS90ZWUvZmZhX3ByaXZhdGUuaA0KPj4gaW5kZXggMWE2MzI5ODNjODYwLi5jMjkxZjMyYjU2ZmYg MTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wcml2YXRlLmgNCj4+ICsrKyBi L3hlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaA0KPj4gQEAgLTI4OSw3ICsyODksNyBAQA0K Pj4gI2RlZmluZSBGRkFfTVNHX1NFTkQyICAgICAgICAgICAgICAgICAgIDB4ODQwMDAwODZVDQo+ PiAjZGVmaW5lIEZGQV9DT05TT0xFX0xPR18zMiAgICAgICAgICAgICAgMHg4NDAwMDA4QVUNCj4+ ICNkZWZpbmUgRkZBX0NPTlNPTEVfTE9HXzY0ICAgICAgICAgICAgICAweEM0MDAwMDhBVQ0KPj4g LSNkZWZpbmUgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9SRUdTICAgICAweDg0MDAwMDhCVQ0KPj4g KyNkZWZpbmUgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9SRUdTICAgICAweEM0MDAwMDhCVQ0KPj4g I2RlZmluZSBGRkFfTVNHX1NFTkRfRElSRUNUX1JFUTIgICAgICAgIDB4QzQwMDAwOERVDQo+PiAj ZGVmaW5lIEZGQV9NU0dfU0VORF9ESVJFQ1RfUkVTUDIgICAgICAgMHhDNDAwMDA4RVUNCj4+IA0K Pj4gQEAgLTQ1Miw2ICs0NTIsOCBAQCBib29sIGZmYV9wYXJ0aW5mb19pbml0KHZvaWQpOw0KPj4g aW50MzJfdCBmZmFfcGFydGluZm9fZG9tYWluX2luaXQoc3RydWN0IGRvbWFpbiAqZCk7DQo+PiBi b29sIGZmYV9wYXJ0aW5mb19kb21haW5fZGVzdHJveShzdHJ1Y3QgZG9tYWluICpkKTsNCj4+IHZv aWQgZmZhX2hhbmRsZV9wYXJ0aXRpb25faW5mb19nZXQoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJl Z3MpOw0KPj4gK3ZvaWQgZmZhX2hhbmRsZV9wYXJ0aXRpb25faW5mb19nZXRfcmVncyhzdHJ1Y3Qg Y3B1X3VzZXJfcmVncyAqcmVncyk7DQo+PiArdm9pZCBmZmFfcGFydGluZm9faW5jX3RhZyh2b2lk KTsNCj4+IA0KPj4gaW50MzJfdCBmZmFfZW5kcG9pbnRfZG9tYWluX2xvb2t1cCh1aW50MTZfdCBl bmRwb2ludF9pZCwgc3RydWN0IGRvbWFpbiAqKmRfb3V0LA0KPj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzdHJ1Y3QgZmZhX2N0eCAqKmN0eF9vdXQpOw0KPj4gLS0NCj4+IDIu NTIuMA0KDQoNCg== From xen-devel-bounces@lists.xenproject.org Mon Mar 02 09:33:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 09:33:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244035.1543501 (Exim 4.92) (envelope-from ) id 1vwzeB-0003Yd-51; Mon, 02 Mar 2026 09:33:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244035.1543501; Mon, 02 Mar 2026 09:33:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwzeB-0003YW-1B; Mon, 02 Mar 2026 09:33:03 +0000 Received: by outflank-mailman (input) for mailman id 1244035; Mon, 02 Mar 2026 09:33:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwze9-0003YP-B8 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 09:33:01 +0000 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [2607:f8b0:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cc21db40-161a-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 10:32:58 +0100 (CET) Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-7d598f4b6fdso963767a34.1 for ; Mon, 02 Mar 2026 01:32:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc21db40-161a-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1772443977; cv=none; d=google.com; s=arc-20240605; b=k6IoubsQ5ytNlr1nkujopGSKne86IxTyQMSnWl625koCi1Mc5tF2VqVv35LYVtWGUG bQCP98NZGaoNOs/C+Otliv8Px7b6GIlHLlukaUttp6H3tIJU9vDCTDBNpJjvkGWnpshi opUEE5v4yQvs6l5AMCazrUufbgzkAagY0XccZ92Ji1BXQJq7FF2jP7gPgCmqyXN3cvhf AB2OWOKhBiUESJiB7ldIlMfQ8M16XGdJWkNCGEKYDtbGaCF5MUvC8ZDgksa0MQyUgjbV qT+Zx7y9pa7qAIRx0aVDGynJtU1WUtAZ8AuKlfN17XtqFMHtRkQaRB1Wsoq6nPbFs4Au TrgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Oz/jjwH9wMeY0dltDZkbDWUYQnrhBJEIc9co1u63XqY=; fh=wB0f5JGUSpWYejuxtnrl8SDqvqyWrEsEaWvC32LbdiU=; b=MNpl0bmLicJbvbRJ/aTDO3e70jaDX6O0I2gycwVk0XdaibR8oDKJOwqke3YciLanCO Bnx6hAhID/FoCXloYYM570kbGs0Vp7RNT58//QNi/KjHt1VotgTqiOOAOkT/jAxZoGAK +//xp2kaBj0UuBanvbIYJ7LjHNX+c8nHrIfiyB2pLAO1xjpnWzDL2Ma67lBAcYFzQc7u vfgXO6WBZEavSwQOI61pnYH6Zii56iF2iITNqri8bcjRM/VS8n50d2gTQW7uQPPKdflZ WUWpesveKIFmkZ2Ufv9+rKdvEwcIuh4f2yW3cOYYeX74rrKQaStVN7ZUD4qRinHw3NGx vW6Q==; 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=1772443977; x=1773048777; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Oz/jjwH9wMeY0dltDZkbDWUYQnrhBJEIc9co1u63XqY=; b=FY2ooT3/fk2sDjSFNTqMgYzzUy9QGk6+YrJYc/qy6yzr18pQr7emuWWR3HXljtKvKA v7CDMLfvVoShcAextL61pr3yv4SZpnL7SFU4tH2aecAtqHCfkiIbY/tIyFBjZgCmYocQ eHdrsySMMYQz6WFxj57qv8jCLRlRXbDIo/KMZ9FBSwHNAdKbMa88x1A+fzKwxNAe8NN5 MC9EvhT2e1aER1WnGZnrrRK9297QVfJkWJ7sFPkYwk3ydbMKFWPdF732uP/U+RX+xFLM Ev77QqqmNzhdZW/RtsKrkYlf5uDwMOGQrwDlfAvY9980pFaQhArKi8yTo29K7+qQeZyv Izhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772443977; x=1773048777; h=content-transfer-encoding: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; bh=Oz/jjwH9wMeY0dltDZkbDWUYQnrhBJEIc9co1u63XqY=; b=qqMZVT9++5gMG5DIWR0NJL9gBCUu5AU3YjemfMD6xyp+FCMjiokhTCpHTodHtz2r0o EsEyXiPdAEtG4Sqyn/UcQ2VEfTsNpe3ot6rkoHv3f6Sb/G/OFc9YGcsZBqdCO4DqL9ox 3ipCrqVPYJXub/uCF8agRuzX1a0+mDd+3jWeCUpjHUpnZ1TGrwZ5Ib1UoKXItL+1Kkbl HrtCSdhsf4E3C6i3/AP4pFswvtf38EtngTOoYoLpqE/L1xvNDaz7nRTs8aPIhLu9iBdG EOPW+5yIXBubV5iaufLmSCoAQnAYlTgIF5qby7eHkoVWGlqN+g9KmAOMwt64m7E6zEyx +PIA== X-Gm-Message-State: AOJu0Yy+9onrI+N3JHQEJRQlV1Qak71pqiplwnADNTE6y2CqX+hasA3J fchK+ztNlGze7MyiI6kJo+sL31g5yhcl0wYsYQ7+qo4/xgzpYr1r7EHjsk38nSQ6HNZ6s0MEEkf kshPISv6lybIEdy0zB6EjtPEp9S1kgvVpeWZkttLI3g== X-Gm-Gg: ATEYQzwCQsy3avJvCATKI3TYFdTIfbtR9HuxVrUXbz8ytH8yVB6k96jgToI0lK81ji8 GBkuZzXWGPPKWepFERgH+cKDAlD0acRcnUQDq1tm9SPpumN+bb7IvENPGYlYj8vo/VQTDiL9w04 RTvT0W1/w/et0yAdKENbXpn5NnG/unx3Vj0OpmRZurhFG8mCNb6YQ3aAOwWTefMbsjgcp9Tordb ICjfn9dki7XgKO4wzn5pHdJFRUE4DpKGRLXcxXafI0nWkRGDca4mTOYc32LJpbcIECHrydZqP6R G1TlltGJVe6anzqSfuYKhLu2zVwSgNf4+sVPTw== X-Received: by 2002:a05:6870:1cf:b0:409:40bb:6b5d with SMTP id 586e51a60fabf-41627037555mr7000189fac.32.1772443976705; Mon, 02 Mar 2026 01:32:56 -0800 (PST) MIME-Version: 1.0 References: <0a5f66eaa16f262d4ffad6a8ec4b1b02461f96c1.1772013062.git.bertrand.marquis@arm.com> <9B608F0B-E564-42C6-9F85-E1701F707554@arm.com> In-Reply-To: <9B608F0B-E564-42C6-9F85-E1701F707554@arm.com> From: Jens Wiklander Date: Mon, 2 Mar 2026 10:32:45 +0100 X-Gm-Features: AaiRm53AaLLoqVe-OrkO3fZ6xPo3jnbDhrINV8JkLnXp54HlRI9BlXX3wdssV5k Message-ID: Subject: Re: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init To: Bertrand Marquis Cc: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 9:51=E2=80=AFAM Bertrand Marquis wrote: > > Hi Jens, > > > On 27 Feb 2026, at 11:39, Jens Wiklander wr= ote: > > > > Hi Bertrand, > > > > On Wed, Feb 25, 2026 at 11:02=E2=80=AFAM Bertrand Marquis > > wrote: > >> > >> FFA_PARTITION_INFO_GET currently queries the SPMC on each call and wal= ks the > >> RX buffer every time. The SP list is expected to be static, so repeate= d > >> firmware calls and validation are unnecessary. > >> > >> Cache the SPMC partition-info list at init time, keeping only secure > >> endpoints, and reuse the cached entries for SP count and partition-inf= o > >> responses. Initialize the VM create/destroy subscriber lists from the = cached > >> list and free the cache on init failure. > >> > >> SP partition info now reflects the init-time snapshot and will not cha= nge. > >> > >> Signed-off-by: Bertrand Marquis > >> --- > >> xen/arch/arm/tee/ffa_partinfo.c | 205 +++++++++++++++++++++----------- > >> 1 file changed, 138 insertions(+), 67 deletions(-) > >> > >> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_pa= rtinfo.c > >> index 6a6f3ffb822e..8a3eac25f99f 100644 > >> --- a/xen/arch/arm/tee/ffa_partinfo.c > >> +++ b/xen/arch/arm/tee/ffa_partinfo.c > >> @@ -6,6 +6,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include > >> #include > >> @@ -33,6 +34,10 @@ static uint16_t subscr_vm_created_count __read_most= ly; > >> static uint16_t *subscr_vm_destroyed __read_mostly; > >> static uint16_t subscr_vm_destroyed_count __read_mostly; > >> > >> +/* SP list cache (secure endpoints only); populated at init. */ > >> +static void *sp_list __read_mostly; > >> +static uint32_t sp_list_count __read_mostly; > >> +static uint32_t sp_list_entry_size __read_mostly; > >> static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t f= lags, > >> uint32_t *count, uint32_t *fpi_s= ize) > >> { > >> @@ -79,92 +84,78 @@ static int32_t ffa_copy_info(void **dst, void *dst= _end, const void *src, > >> return FFA_RET_OK; > >> } > >> > >> -static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_co= unt) > >> +static bool ffa_sp_entry_matches_uuid(const void *entry, struct ffa_u= uid uuid) > >> { > >> - uint32_t src_size; > >> + const struct ffa_partition_info_1_1 *fpi =3D entry; > >> + struct ffa_uuid sp_uuid; > >> + > >> + if ( ffa_uuid_is_nil(uuid) ) > >> + return true; > >> > >> - return ffa_partition_info_get(uuid, FFA_PARTITION_INFO_GET_COUNT_= FLAG, > >> - sp_count, &src_size); > >> + if ( sp_list_entry_size < sizeof(*fpi) ) > >> + return false; > > > > This can never happen since we don't accept SPMC below version 1.1. We > > even have a check to ensure the SPMC doesn't return a too-small > > spi_size. > > I tried to make the code forward compatible. It is not really a possible = case right now > but we could fall into this in the future. At the moment, it's only ffa_sp_list_cache_init(), which initializes and puts things in the SP. So as long as ffa_sp_list_cache_init() and this function are in sync, there should be no problem. It simplifies things if we can trust the SP cache to be usable. > > > > >> + > >> + memcpy(&sp_uuid, fpi->uuid, sizeof(sp_uuid)); > >> + return ffa_uuid_equal(uuid, sp_uuid); > >> } > >> > >> -static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp= _count, > >> - void **dst_buf, void *end_buf, > >> - uint32_t dst_size) > >> +static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_co= unt) > >> { > >> - int32_t ret; > >> - int32_t release_ret; > >> - uint32_t src_size, real_sp_count; > >> - void *src_buf; > >> uint32_t count =3D 0; > >> - bool notify_fw =3D false; > >> - > >> - /* We need to use the RX buffer to receive the list */ > >> - src_buf =3D ffa_rxtx_spmc_rx_acquire(); > >> - if ( !src_buf ) > >> - return FFA_RET_DENIED; > >> - > >> - ret =3D ffa_partition_info_get(uuid, 0, &real_sp_count, &src_size= ); > >> - if ( ret ) > >> - goto out; > >> - notify_fw =3D true; > >> + uint32_t n; > >> > >> - /* Validate the src_size we got */ > >> - if ( src_size < sizeof(struct ffa_partition_info_1_0) || > >> - src_size >=3D FFA_PAGE_SIZE ) > >> + for ( n =3D 0; n < sp_list_count; n++ ) > >> { > >> - ret =3D FFA_RET_NOT_SUPPORTED; > >> - goto out; > >> + void *entry =3D sp_list + n * sp_list_entry_size; > >> + > >> + if ( ffa_sp_entry_matches_uuid(entry, uuid) ) > >> + count++; > >> } > >> > >> - /* > >> - * Limit the maximum time we hold the CPU by limiting the number = of SPs. > >> - * We just ignore the extra ones as this is tested during init in > >> - * ffa_partinfo_init so the only possible reason is SP have been = added > >> - * since boot. > >> - */ > >> - if ( real_sp_count > FFA_MAX_NUM_SP ) > >> - real_sp_count =3D FFA_MAX_NUM_SP; > >> + *sp_count =3D count; > >> > >> - /* Make sure the data fits in our buffer */ > >> - if ( real_sp_count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / src_= size ) > >> - { > >> - ret =3D FFA_RET_NOT_SUPPORTED; > >> - goto out; > >> - } > >> + if ( !ffa_uuid_is_nil(uuid) && !count ) > >> + return FFA_RET_INVALID_PARAMETERS; > >> > >> - for ( uint32_t sp_num =3D 0; sp_num < real_sp_count; sp_num++ ) > >> - { > >> - struct ffa_partition_info_1_1 *fpi =3D src_buf; > >> + return FFA_RET_OK; > >> +} > >> > >> - /* filter out SP not following bit 15 convention if any */ > >> - if ( FFA_ID_IS_SECURE(fpi->id) ) > >> - { > >> - /* > >> - * If VM is 1.0 but firmware is 1.1 we could have several= entries > >> - * with the same ID but different UUIDs. In this case the= VM will > >> - * get a list with several time the same ID. > >> - * This is a non-compliance to the specification but 1.0 = VMs should > >> - * handle that on their own to simplify Xen implementatio= n. > >> - */ > >> +static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp= _count, > >> + void **dst_buf, void *end_buf, > >> + uint32_t dst_size) > >> +{ > >> + int32_t ret; > >> + uint32_t count =3D 0; > >> + uint32_t n; > >> > >> - ret =3D ffa_copy_info(dst_buf, end_buf, src_buf, dst_size= , src_size); > >> - if ( ret ) > >> - goto out; > >> + for ( n =3D 0; n < sp_list_count; n++ ) > >> + { > >> + void *entry =3D sp_list + n * sp_list_entry_size; > >> > >> - count++; > >> - } > >> + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > >> + continue; > >> > >> - src_buf +=3D src_size; > >> + /* > >> + * If VM is 1.0 but firmware is 1.1 we could have several ent= ries > >> + * with the same ID but different UUIDs. In this case the VM = will > >> + * get a list with several time the same ID. > >> + * This is a non-compliance to the specification but 1.0 VMs = should > >> + * handle that on their own to simplify Xen implementation. > >> + */ > >> + ret =3D ffa_copy_info(dst_buf, end_buf, entry, dst_size, > >> + sp_list_entry_size); > >> + if ( ret ) > >> + return ret; > >> + > >> + count++; > >> } > >> > >> *sp_count =3D count; > >> > >> -out: > >> - release_ret =3D ffa_rxtx_spmc_rx_release(notify_fw); > >> - if ( release_ret ) > >> - gprintk(XENLOG_WARNING, > >> - "ffa: Error releasing SPMC RX buffer: %d\n", release_= ret); > >> - return ret; > >> + if ( !ffa_uuid_is_nil(uuid) && !count ) > >> + return FFA_RET_INVALID_PARAMETERS; > >> + > >> + return FFA_RET_OK; > >> } > >> > >> static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t star= t_index, > >> @@ -435,6 +426,14 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp= _id, uint16_t vm_id, > >> return res; > >> } > >> > >> +static void ffa_sp_list_cache_free(void) > >> +{ > >> + XFREE(sp_list); > >> + sp_list =3D NULL; > > > > XFREE() is already setting sp_list to NULL. > > Ack will fix in v2 > > > > >> + sp_list_count =3D 0; > >> + sp_list_entry_size =3D 0; > >> +} > >> + > >> static void uninit_subscribers(void) > >> { > >> subscr_vm_created_count =3D 0; > >> @@ -443,6 +442,68 @@ static void uninit_subscribers(void) > >> XFREE(subscr_vm_destroyed); > >> } > >> > >> +static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, > >> + uint32_t fpi_size) > >> +{ > >> + const uint8_t *src =3D buf; > >> + uint32_t secure_count =3D 0; > >> + uint32_t n, idx =3D 0; > >> + bool warned =3D false; > >> + > >> + if ( fpi_size < sizeof(struct ffa_partition_info_1_0) || > >> + fpi_size >=3D FFA_PAGE_SIZE ) > >> + return false; > > > > Would it make sense to check that fpi_size is well aligned with struct > > ffa_partition_info_1_0? If it's an odd size, we'll make unaligned > > accesses below with memcpy(). But perhaps that's a bit much. The SPMC > > isn't supposed to provide garbage. > > Memcpy should prevent issues even if accesses are not aligned. > If we had this test, we cannot return an error to the SPMC so we would ha= ve to > generate one to the caller. It is simpler i think to handle non-aligned a= s we do not > expect the SPMC to generate such a case. > Tell me if you agree. We dereference fpi below, and depending on compiler flags and pointer types, memcpy() might not be safe with unaligned pointers. >From 6.3.2.3 Pointers, paragraph 7, in the C standard: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is unde=EF=AC=81ned." I've seen past examples where the compiler optimized memcpy() in a way that breaks with unaligned pointers. We don't expect the test above to fail, but if it does we will not use the secure firmware. I think refusing unexpected sizes is even simpler. It should make finding eventual errors much easier. So my question above is whether it's worth checking that fpi_size is well-aligned, or if it's so unlikely that we don't need to consider it. Cheers, Jens > > > > >> + > >> + if ( count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / fpi_size ) > >> + return false; > >> + > >> + for ( n =3D 0; n < count; n++ ) > >> + { > >> + const struct ffa_partition_info_1_0 *fpi =3D > >> + (const void *)(src + n * fpi_size); > >> + > >> + if ( !FFA_ID_IS_SECURE(fpi->id) ) > >> + { > >> + if ( !warned ) > > > > Is this needed? Doesn't printk_once() already ensure this? Or did you > > happen to leave printk_once() by mistake and meant for this to be > > printed once each time ffa_sp_list_cache_init() is called, since > > "warned" isn't static. > > Very right, i need to remove the warned, printk_once should be enough her= e. > > > > >> + { > >> + printk_once(XENLOG_ERR > >> + "ffa: Firmware is not using bit 15 conven= tion for IDs !!\n"); > >> + warned =3D true; > >> + } > >> + printk(XENLOG_ERR > >> + "ffa: Secure partition with id 0x%04x cannot be us= ed\n", > >> + fpi->id); > >> + continue; > >> + } > >> + > >> + secure_count++; > >> + } > >> + > >> + if ( secure_count ) > >> + { > >> + sp_list =3D xzalloc_bytes(secure_count * fpi_size); > >> + if ( !sp_list ) > >> + return false; > >> + } > >> + > >> + sp_list_count =3D secure_count; > >> + sp_list_entry_size =3D fpi_size; > >> + > >> + for ( n =3D 0; n < count; n++ ) > >> + { > >> + const struct ffa_partition_info_1_0 *fpi =3D > >> + (const void *)(src + n * fpi_size); > >> + > >> + if ( !FFA_ID_IS_SECURE(fpi->id) ) > >> + continue; > >> + > >> + memcpy(sp_list + idx * fpi_size, fpi, fpi_size); > >> + idx++; > >> + } > >> + > >> + return true; > >> +} > >> + > >> static bool init_subscribers(void *buf, uint16_t count, uint32_t fpi_s= ize) > >> { > >> uint16_t n; > >> @@ -549,12 +610,22 @@ bool ffa_partinfo_init(void) > >> goto out; > >> } > >> > >> - ret =3D init_subscribers(spmc_rx, count, fpi_size); > >> + if ( !ffa_sp_list_cache_init(spmc_rx, count, fpi_size) ) > >> + { > >> + printk(XENLOG_ERR "ffa: Failed to cache SP list\n"); > >> + goto out; > >> + } > >> + > >> + ret =3D init_subscribers(sp_list, sp_list_count, sp_list_entry_si= ze); > >> > >> out: > >> e =3D ffa_rxtx_spmc_rx_release(notify_fw); > >> if ( e ) > >> printk(XENLOG_WARNING "ffa: Error releasing SPMC RX buffer: %d= \n", e); > >> + if ( !ret ) > >> + uninit_subscribers(); > > > > ret is initially false and can only be set to true if > > init_subscribers() returns true. So there's never any point in calling > > uninit_subscribers(). > > True, I will fix that. > > > > >> + if ( !ret ) > >> + ffa_sp_list_cache_free(); > > > > ret can be false even if ffa_sp_list_cache_init() hasn't been called > > yet. Calling ffa_sp_list_cache_free() anyway is harmless, but not > > elegant. > > yes, i will rework a bit the cleanup logic here. > > Thanks for the review > > Cheers > Bertrand > > > > > Cheers, > > Jens > > > >> return ret; > >> } > >> > >> -- > >> 2.52.0 > > From xen-devel-bounces@lists.xenproject.org Mon Mar 02 09:46:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 09:46:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244045.1543510 (Exim 4.92) (envelope-from ) id 1vwzrD-0005JF-78; Mon, 02 Mar 2026 09:46:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244045.1543510; Mon, 02 Mar 2026 09:46:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwzrD-0005J8-4b; Mon, 02 Mar 2026 09:46:31 +0000 Received: by outflank-mailman (input) for mailman id 1244045; Mon, 02 Mar 2026 09:46:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vwzrB-0005J1-Jj for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 09:46:29 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id af1c8e77-161c-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 10:46:27 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-439a89b6fd0so1516515f8f.2 for ; Mon, 02 Mar 2026 01:46:27 -0800 (PST) Received: from [10.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-439ae0e7abasm12693544f8f.23.2026.03.02.01.46.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 01:46:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: af1c8e77-161c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772444787; x=1773049587; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=A4uQD7zUtyHXk1WG+956ZToLtgs8GZrFVfxV6u16ylE=; b=JMmOVTiJEcNeUPnr0Uvrnxh0ZrZpIBHVpCI+9Q5/jAlcYuCi5QGwT/Tb29+gvMAi0F HjnoAV32SedDpQPeHIt1zgDzsJVSJ/qqis+swGj6woYqo45Wl8fHruzix0DQZ29irRIq vY0Czf4vhZgrrbLy4Fe0wNJ2bImwa4DYu5pqNwJeC2XoqIDQiwLi9sHboFjOtdYbpAkw +q5TdAthiKoMpVuo78lBi9N/4QsTdJhq+uAFWo8T0ZHjMsfMAeV5bxKlbrAbxxzkYtzk 5nvyqB8Q8AvHfq4myUTk5ehnPx/hmKlCUJgFw7uYEK303LGYgy+5gi4QkHp4Wb0/8HTG r3XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772444787; x=1773049587; h=content-transfer-encoding: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; bh=A4uQD7zUtyHXk1WG+956ZToLtgs8GZrFVfxV6u16ylE=; b=e+f/NXuNZcak5Pxj12FhK3FFIS462XlnGNCfKPjQdJaBWW6gsqbXJM1LQ4fQ6mL1mr 3oqsv9klaUBtQ5t4VmCcdhgGJteUCWcSoBs44MSinO08IDDNipHkkuuOzM39Mk6J5+j+ 43RsrpBcbc332VHFy56/fvIp9JC52YLhWdVp2csyufRK2OdcZdSpvi9VGNJBt1TOdDbQ We4WCLPeJiq7tsBQX/EL+jp3ueyd4QZkcxGPJGpgWr5GA0CB11y88ZnfZUpiAeuj+oPe 60fVPy1rwXdHoIkzCr+LSuwIOYRjt4DV57LKSBp9K5ZXqmQXsfXIROdFSxm7FYq3PPtc ZbZg== X-Gm-Message-State: AOJu0YwC+dJt16xeBOSYK1UG3YmdzbVOiJQwC2RBBJxyhnw+CpuidbmV 6R3Im6QTT4hi76pgo2tZLoXsOf9zxnNgaCCtXEin/iw6DAkAnI9o4WCwn1m81nbtGw== X-Gm-Gg: ATEYQzwCXwOPMy/+oWjAypgbZi5KrlIz9GHJymYDtJ1HMkXu36PegqsHbzVYTB7L4n7 hOPX0bb+yZz+gDBRr3/j7JOAelRNDI3SunXItcnh1DpocyXAfCk6+qPKVX4oJQk3MXT2xbwScP6 58Ohpuok2c6N96V0XkEGkcJnSDYPkWRhJi80KoLgTm52VzpiG1/7eoYbDG4aEek8MR9pS25Yokv s9oGwg/ec3SJcaMwWOeweXn1GL2R4JmatMNwynxc0C05bdRdVhhDW85W0uKch764T41QUt/XP+y isILAWaJxvG+w/bxTyt0QhvxwtlRaLpJscf9tj/uX6qIUy1JCLyTQh6/3Ou7MWihAgIEuxYph+a 4f8QmxKV2ZlsIeBHnL9wsQ3LOYQA/2QNwuQ44uV9usCF/D7mu7Q31+WtmbnYzAPc0aHdcoaRaRc D40iMpHnyxn/drRLeUVViLn3uzAqJptDI00kvwQIdhfYcV0f9eQ1nTy1Gg3ttuBJZEgsyE+1+tN 0zW9FC2Mgfc/Uk= X-Received: by 2002:a5d:584f:0:b0:439:5c75:dc08 with SMTP id ffacd0b85a97d-4399de0b8c0mr21267342f8f.10.1772444787163; Mon, 02 Mar 2026 01:46:27 -0800 (PST) Message-ID: <8a8d0a11-2b19-4fb8-bc0f-9397c0db8ed9@suse.com> Date: Mon, 2 Mar 2026 10:46:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] xen/cpufreq: fix adjusting of sampling window on early exit To: Roger Pau Monne References: <20260227073259.1200-1-roger.pau@citrix.com> <20260227073259.1200-2-roger.pau@citrix.com> Content-Language: en-US Cc: xen-devel@lists.xenproject.org From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227073259.1200-2-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 08:32, Roger Pau Monne wrote: > The logic in dbs_check_cpu() resets the sampling window even when the > sampling period is considered too small. This leads to further calls > finding an imbalance between the total window time and the idle time, as > the total window time is possibly shorter than the idle time. > > Fix by resetting the sampling window start time in the same block where the > current idle time is stored. While there also prevent a duplicated call to > NOW() and instead re-use the previously fetched value. > > Fixes: d6f001cb91ac ("x86: Implement cpufreq ondemand policy") > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 02 09:57:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 09:57:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244055.1543521 (Exim 4.92) (envelope-from ) id 1vx024-00077b-6G; Mon, 02 Mar 2026 09:57:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244055.1543521; Mon, 02 Mar 2026 09:57:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx024-00077U-2e; Mon, 02 Mar 2026 09:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1244055; Mon, 02 Mar 2026 09:57:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx01t-00071G-TK for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 09:57:41 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3510c92a-161e-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 10:57:22 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4807068eacbso34804125e9.2 for ; Mon, 02 Mar 2026 01:57:22 -0800 (PST) Received: from [10.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-483bfcb4f8bsm309877465e9.4.2026.03.02.01.57.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 01:57:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3510c92a-161e-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772445441; x=1773050241; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=rlfLkU5zFNa46IcsgJeGs4KnjPnmVvVatz5QByV8OIc=; b=DdL/M6RSrkeQRB5UDcFFprbWzaojCzKUlcDNVPz2MUv18rAS5P3w9PFHjHMxSEQcHo MbNP9ERyVCUcKpM3aHB1E+HWnjmgq/fFKMpng6rukG3W8xQYwWJc7lzRkaxlSfaf2zHB 29S6bAvPi/bm+d5D00frTsiG5gGjZJ70wxO5UmdpEjGl3vQRs6eBDK4Dz7c4M2e9FJYs RmZq7xEli9R4cTxh0ykWu3uyqvxdCqYJDpUGG+fgE9szl+9F+UfwgdMmk+INik04O3a/ MTPt9YgJczvkuaJTVane/lfgS4JQ4L1PkVjOJ+6Ip1MOZe68aHDbZgw4c93ipBpVBoPV 2bzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772445441; x=1773050241; h=content-transfer-encoding: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; bh=rlfLkU5zFNa46IcsgJeGs4KnjPnmVvVatz5QByV8OIc=; b=jpI5ecgr7yoXP7VIavVI9xzIuqxeJOG09xVlt/WjAnK4fRBD3wCmiBg60fdG5V42dN /JMrcWOg9rM6SXG0Eon5YEBguIhUQAhhQcjK9/sYvtpE0hcVKXLB36s8LyhI4MowcD3I +Tmp/tR/g1gdid/o5MjAW+nIONsQK/3Srz0x6tKCNLLer+pbGzeliAgDfzipJJqtEZRz 0JEkbChir24uhDFDCJEKKiCIUuRJfyUkpWDWNdQAsONRLfE4+hdw5mReb405bNdqtz4x TPICkjZVj8qHUD88UT6kxz8JbqlLIIslIkdZkYulpK7qQD8/fdBAJvJRGr46txQlYF5I DGoA== X-Gm-Message-State: AOJu0Yz3PtZSdxBsiYu+X7+g91cvke/gvpNe2I9z03gju+zNJ7Ddho3d nXATPFDYTv5vnM7r8yXTn23upxbbhFbKBUFw5BnRlO8zc9++P1cAmd9Js6zaQb765A== X-Gm-Gg: ATEYQzxLqdtt0SwuETbJRzMSsW9RlC/0dvzTT1zJM41QLJPGXx+SlVfkots6mSry6yF ZV2U6WySX2ZI0iGXiyWlkqphyuzQlw+ObIffdzRyHZYxOSEass7kh1O7iWytGJqDxd/qXwIIeBu 8R0OhQBNI8aIXChJ7EzLQLlK4QCk5FBsmZrF8M2r96ihsc/kK86E2N/j0oXfr0wjV15sYCm+Alg VgVjgmCxds2XoDDzFuOqflqeRryx3l/syVYGzZSD7HADWsMWmmV00OUZIqasRYeckqVAZ4o0ext HI/DxywzPIXMULDZ5aWYEfR2R5qwQVLxC4+GSwKdiMHN907N6yjYpnvtyjF46uuz28lYtjMI7iV Q3CoGvAW7YEqNMO3hJzfaSJ1COU4f+Gbboun4yZ5LokVoki4PgBAt2RwuV/9WnQ9WToCTwoyWzp v2dOnkwN1BtUJZydoysykj5oAxNCMgZTkGGVVQTSxmLszNPX+oDNzxFSQFN8IptQPFxBBJTNnXo Y2+574WjhbXqz0= X-Received: by 2002:a05:600c:5394:b0:483:8e43:6def with SMTP id 5b1f17b1804b1-483c9bf46b7mr199465045e9.28.1772445441451; Mon, 02 Mar 2026 01:57:21 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 10:57:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] xen/cpufreq: fix usages of align_timer() in the on-demand governor To: Roger Pau Monne References: <20260227073259.1200-1-roger.pau@citrix.com> <20260227073259.1200-3-roger.pau@citrix.com> Content-Language: en-US Cc: xen-devel@lists.xenproject.org From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227073259.1200-3-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 08:32, Roger Pau Monne wrote: > The first parameter passed to align_timer() is the timer expiration, not > the current time. Adjust the calls to align_timer() in the on-demand > governor to pass the expected timer expiration as the first parameter. > > Fixes: af74e3a15a83 ("cpufreq: align dbs timer for better package C state residency") > Fixes: 382b95f627a9 ("Fix cpufreq HW-ALL coordination handle") > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 02 10:01:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 10:01:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244066.1543531 (Exim 4.92) (envelope-from ) id 1vx05s-0000Mj-PP; Mon, 02 Mar 2026 10:01:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244066.1543531; Mon, 02 Mar 2026 10:01:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx05s-0000Mc-MR; Mon, 02 Mar 2026 10:01:40 +0000 Received: by outflank-mailman (input) for mailman id 1244066; Mon, 02 Mar 2026 10:01:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx03Z-0007hB-Kz for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 10:01:39 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6f0a2727-161e-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 10:58:59 +0100 (CET) Received: from AS9PR07CA0031.eurprd07.prod.outlook.com (2603:10a6:20b:46b::33) by AM8PR08MB5745.eurprd08.prod.outlook.com (2603:10a6:20b:1c5::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 09:58:49 +0000 Received: from AM3PEPF0000A793.eurprd04.prod.outlook.com (2603:10a6:20b:46b:cafe::c0) by AS9PR07CA0031.outlook.office365.com (2603:10a6:20b:46b::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.18 via Frontend Transport; Mon, 2 Mar 2026 09:58:46 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM3PEPF0000A793.mail.protection.outlook.com (10.167.16.122) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Mon, 2 Mar 2026 09:58:49 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by VI0PR08MB11170.eurprd08.prod.outlook.com (2603:10a6:800:251::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.21; Mon, 2 Mar 2026 09:57:46 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 09:57:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6f0a2727-161e-11f1-b164-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=aUiwWNEbeEr0+eof9Wmp9/+UWCyaVA+ryXioSJYHy2OOq+UHjmEh778XP15eOFF7DTHxB2WF/Epfw4Qv+IxWVeXC8XDwVuIDFjXZCIC7Sw3XZ/FG01eCllEPesNM+r3ngmj0R9jqKsoNxLNdAFgAI5VzpOKWII7dMm0Wd5niZC4rPEMyGAWJCG3LlBLPbuDVgS8QqM+J1GzhsHSzGcyRY95DkitzYONIvO4is/B416dA4YNQTL3SGZ5F3wvityL9Gp9JZLXnavaZ+2PbwYkt4l1ZUlGNoxdPbKoTPjS0CW2BTnTZsRuwF6Y5L9sr9Qe1fZUsUIZIg8/Qa8+2wiTYKQ== 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=D+9imK5XawmDQe7P0Xr+MoPnLE1iv7IUk7n8ZiKvx7E=; b=hACBAFkC/Oklxg3+xyMhHSGpC1d2s8QkZgV97uOlilku7Ndymve1WhwNsSaghyrX7a7AxdoxDrL9K5KVQCGYSMuM/AuK6/pX6zrbcTZWfvk+KqGzplRsEx+g6kwnRvp1R+VC9h/kVLu8A7NiQsxNJBSZ4vddNFdsSPY7TGhEmfdb2OaZSHz24mW6m8CD9QokScUicNa7CenI9te9oANqO1o4VQGIBOUJ6cMny4Ou1LO/rmkgbq+tU5Ud+j/ivNbLcbYGDuhUL1XORzRsLhh/Kz3FPCe8BfBjUns1nt3UIt5ODOVPrvspw7gzk8IEyzzR6OVj2z1lpXydIadt+U/Ksg== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=D+9imK5XawmDQe7P0Xr+MoPnLE1iv7IUk7n8ZiKvx7E=; b=A5vO+nDVMryJcY0G1ei4lJZ4xGl2VMjgVJ2dgrZOS4QXVm2FeL9OQI4SJUffK1DCVMb2zhJOd8kkVV4v5cLHXKiozL4KRev3uQZxOOcOBx6plIpA6UPuFwm620mPerqxHFDb2Rt2M0jQwKlPsfaDY+2EyfabJBdn9+DuQBz1iBA= 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=kUdTZkh9r0OLqFvfuq980byy77bKKS7HHS/Chad2+kVWXkYq+Xa8yBEEGjlgonV8B1HdTVmXH3KSalE5pvYchTGOdj6qgHp00nYwHJHuQKhWDzc1LIHGkJxZFLS8m8H8IyhDuccmDJfWVMzwwE+/I+uZPkymVGxYKYoOx5rV+yUcBhSiU51dpOxZUXQzCzwbuIE9/Qw5kLcp5P0grUGKVaq8PMfqPNGUacgdvmgCiktPGLoh24SxZLK7OEQCEG7TmMlgCUSWh8tTl0gAoKgY6YKjD5+iYTPS9TeNamXCTtMbgDw+7gTkIlhv9Dvbk3Z1qru5jWNNb8vOWdHlKWFBwA== 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=D+9imK5XawmDQe7P0Xr+MoPnLE1iv7IUk7n8ZiKvx7E=; b=Frk3cOjmCZuihE138yHY7rvpAoa26e5tIDpwZ0hhHdOFpTifEvmQVqDiN7duNzEVrvNbOKfXQ06OyG6ZX7PUSPNO3HhCT6g3NKWMsWsAIUNgaJbmELDtByqgLGNCmSAG7Vy6qYoT95rdtiBLjFXLSjzAtwdEuL3+tvprBzyo8cfOdygMSM0+TaZdKFDC3LbeMxsl2BqhsEohut/FYnxg5zDw/I/d3Cq47UUifY+uEf+mcK+TPjQnY+P0RofDfz9gwvlpklmUFQg3QtzCVtGJ92Ewf7g8VQoCuUX71dgceKznkDoTBSezsu/os87IsCF0+wE+9g76UvmQrlPRSzFuBg== 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=D+9imK5XawmDQe7P0Xr+MoPnLE1iv7IUk7n8ZiKvx7E=; b=A5vO+nDVMryJcY0G1ei4lJZ4xGl2VMjgVJ2dgrZOS4QXVm2FeL9OQI4SJUffK1DCVMb2zhJOd8kkVV4v5cLHXKiozL4KRev3uQZxOOcOBx6plIpA6UPuFwm620mPerqxHFDb2Rt2M0jQwKlPsfaDY+2EyfabJBdn9+DuQBz1iBA= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init Thread-Topic: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init Thread-Index: AQHcpj3iktrazLk1t0mCBnzOLulDCLWWXkkAgASYY4CAAAvlgIAABvEA Date: Mon, 2 Mar 2026 09:57:46 +0000 Message-ID: <6A629240-E2E4-48E4-A79A-031D7258D676@arm.com> References: <0a5f66eaa16f262d4ffad6a8ec4b1b02461f96c1.1772013062.git.bertrand.marquis@arm.com> <9B608F0B-E564-42C6-9F85-E1701F707554@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|VI0PR08MB11170:EE_|AM3PEPF0000A793:EE_|AM8PR08MB5745:EE_ X-MS-Office365-Filtering-Correlation-Id: 82d979ab-744a-4dd6-a455-08de78424d72 x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|10070799003|1800799024|376014|366016|18132099003|38070700021; X-Microsoft-Antispam-Message-Info-Original: /e6Urx3Feo1bUwzfUDDaL0JnrG58PqP0pXxmoRY+IbFKHM8MmuEjbozUmYVZ6xBdtUxBNRJ5m6PjFBl5y1VmonmApqhCF9ZC1TYtGq4dwN1WgEAwthjdgE2acwytP6/jXpPRmTNLd0H2nu2BE25SV3sdbY6+RimqgalehW6PuINlDjBZWImMgLvmTuGKmTjnoths0BI0BiNNiT7CKM404Mf/QF4K/51yuKENEw5rwRa58gXClLakNr+6zqcStPB0gH5VI+lV6n0ETrJenH9j9MAtGzVBGNfPc2QyAElH2JxuWKlYriXK+dVig2YujGosCyenBjqlz2tGJ+Ux/kV4jXxOfjgwD8e3uqCYtLJ0bhQ6uJ2eKmk1czugymyeDB3RFOj9cZYAjDq8lQqpb/Ab+wAxVfl1tkas847W5EiFj7ydZDurdMs+a6bYuIVR6uZaecPtCQJPFMOT/EuRTeDAz+AdBqCpEteK16y/uyPJdLjxZYyYIahhyho5TRNjHc0+bWak+K6GibQZHF6itofRSA651uBoO6/CbxBI45eYLaxRZAqKn8LJ0aDSzbl5sjfp5Oasr/Y6IA2DyYesjKr1gwhnqM5JIAKYf7EemddRvnsYaQ3693IFQdw8xbf153IwM/a02o1pjxSu/E21VUhJD7cdIQulRlm/hk5ed3TsHE7Sd6twOjmTECMK4CEtxyA5baPa7TeI441HGg+6LVxrWDW8KjaHpRhwMvp+q/SZUeQpvzQ9YVq5toOXdEJXUddcZzgot8QzQVqyGbo5LDCoyNIVHWk5VWZWELbWV8xZW0o= 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)(10070799003)(1800799024)(376014)(366016)(18132099003)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <93165EC342A39C4F8519B3F7AA46840E@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: bHmNC6MPdXnMsxUInEL6fDQW89MbwLD8PmR1wdTR/sKGrMKGm6vZNohAToiKiuZgW5X0H39p0STZAfMBZFf9Us+98WUzmeKpdMxJFupd+qXR+XOaablQ/lG/iVIfCmJH47uid3oLXDakwePfWY3k12xT1e1PEJRPWSNjrCHrz3wjf6A6KMc7kdlcjcfdOxkHgzaYoyQazcQfzGNecIX21DCjTbgq2vwXYFkpOt2bUgksQbKjjBnC+Fj7s0jCLzWtPWneL+1sl8V+4PrwJGeCiRb0CSSWxvYHtPchRILN4X8zqRBMiSyDfc4XGb4hjTKXVnVdbUZYNh5kC12lTfeNZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB11170 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM3PEPF0000A793.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 85b4d72d-b0ee-4bb0-0b3d-08de784227d8 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|35042699022|36860700013|376014|14060799003|18132099003|7053199007; X-Microsoft-Antispam-Message-Info: w4XST4S2sBHQ2oFMjvQgX/+FqKPvFqG6OAks9wr7CbKcvu+RROUzfitmddoAWCERS8dKt1nVvmlnu7NRImv63HAaSV8dmACGxXp6Ujy+vzwm74+KZRyZ0H4h3Bgb/fSzKlY9h4+vxDxKBM2yKpZkvZ1OYU5ijpJfJtwCllfJCUm5xWrU1F4zbxC2mqUhUEN5/3SsXZCcBR1RYd8+AgPhiGWsIWSYWDrQBkMOdsEtGh9AphdW1MsZdalh25+fqjbmRSHewvHgE+zphs747YTKYi9SZi8FCtZrGqHXs1Xfef1nNY/dpI3eF3iHOQuv+uHId91YPpFxHId0fIUVX4BT+zzP0+KIaL/eb5sLbOF9ycuTwqvKo9Dv0xnBzdcTY+dA3OUIi0gf9TK1q8PBlBfP5NvO/ff+lg+Kecv+TqvaeTd2ZemyVoOtua7sJagXg3g5TQIFNDPUXaw/N28/LDXl6UDHtwtycL4YXM7UOZtj/ZnIuWCcR7heLaKDrIUg7i2AqWqWY2efbJmrkcYA89cZ/qBWSKMwo08nkOkjp28TsdlpIMr7vZAX3PfIEDc2ehfsdXN5J87tg0fgSBRIXmZ1WWKkGg9VK5CtioV+MxKjgsKC6doBfa9URAvOhjCR/x87C4SLu17s8VC08T9VwrYolmz964ryr8CqMAgEzh/k0JFWUhWP5avQqc9tbF47oiPhMiMKb1AZW80hVdc98bXVmNc/OWimXK7fgrS4yUvLQGJMkd8CtvJRNmBzXFUKjMescbSbo3pmEIkmBKF0K1GueLy62oiiV0miH+aB+e44QQIASxCoP76odvLbexiI3sUpolaAhMbNGPuPKdaHNMpEOg== 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)(1800799024)(82310400026)(35042699022)(36860700013)(376014)(14060799003)(18132099003)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: j+xB3eKcX697FNvIhqXr5PzBvMlSmubRZo35nyw3h7KMeZCmWheRoeNRC/tElX1SYRGWqqJNP44zY+Hyf4AM7yGGaGr9gRx1rnii2S7JfnTZByxw/VmGEtxCFrWQFlRtPJnxKGi829T83E7jwOfNgyZDiQT6R2Jl0uiTW6ErkkmWc1C9+6iV5Ysa98e4an7lyGns1WSM0xZ5GAhDWP/kdBCregC7sDi4X3kzCfGJ6xPBvMxuL2EEH0sektFjz51VQU3gzvhYgrTrqliFksLPcQWZS4USRqB1TttpwkIOoMrV/b/UqFahznfmEVB5R91UzuBwq3axjYJRJ3+Wb+VWkcwXzgkTOTXbyo90RzWbu41USr+/pGz+FG7hCOs/RZUZ9ILisbBwWP9GlbDV+2l+KKUYa2ldt246oE+K9A2FhEhAh5RAQBZehAZNktJoMXiE X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 09:58:49.4674 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 82d979ab-744a-4dd6-a455-08de78424d72 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: AM3PEPF0000A793.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5745 SGkgSmVucywNCg0KPiBPbiAyIE1hciAyMDI2LCBhdCAxMDozMiwgSmVucyBXaWtsYW5kZXIgPGpl bnMud2lrbGFuZGVyQGxpbmFyby5vcmc+IHdyb3RlOg0KPiANCj4gSGkgQmVydHJhbmQsDQo+IA0K PiBPbiBNb24sIE1hciAyLCAyMDI2IGF0IDk6NTHigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxC ZXJ0cmFuZC5NYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBKZW5zLA0KPj4gDQo+ Pj4gT24gMjcgRmViIDIwMjYsIGF0IDExOjM5LCBKZW5zIFdpa2xhbmRlciA8amVucy53aWtsYW5k ZXJAbGluYXJvLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQmVydHJhbmQsDQo+Pj4gDQo+Pj4g T24gV2VkLCBGZWIgMjUsIDIwMjYgYXQgMTE6MDLigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+Pj4g PGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBGRkFfUEFSVElU SU9OX0lORk9fR0VUIGN1cnJlbnRseSBxdWVyaWVzIHRoZSBTUE1DIG9uIGVhY2ggY2FsbCBhbmQg d2Fsa3MgdGhlDQo+Pj4+IFJYIGJ1ZmZlciBldmVyeSB0aW1lLiBUaGUgU1AgbGlzdCBpcyBleHBl Y3RlZCB0byBiZSBzdGF0aWMsIHNvIHJlcGVhdGVkDQo+Pj4+IGZpcm13YXJlIGNhbGxzIGFuZCB2 YWxpZGF0aW9uIGFyZSB1bm5lY2Vzc2FyeS4NCj4+Pj4gDQo+Pj4+IENhY2hlIHRoZSBTUE1DIHBh cnRpdGlvbi1pbmZvIGxpc3QgYXQgaW5pdCB0aW1lLCBrZWVwaW5nIG9ubHkgc2VjdXJlDQo+Pj4+ IGVuZHBvaW50cywgYW5kIHJldXNlIHRoZSBjYWNoZWQgZW50cmllcyBmb3IgU1AgY291bnQgYW5k IHBhcnRpdGlvbi1pbmZvDQo+Pj4+IHJlc3BvbnNlcy4gSW5pdGlhbGl6ZSB0aGUgVk0gY3JlYXRl L2Rlc3Ryb3kgc3Vic2NyaWJlciBsaXN0cyBmcm9tIHRoZSBjYWNoZWQNCj4+Pj4gbGlzdCBhbmQg ZnJlZSB0aGUgY2FjaGUgb24gaW5pdCBmYWlsdXJlLg0KPj4+PiANCj4+Pj4gU1AgcGFydGl0aW9u IGluZm8gbm93IHJlZmxlY3RzIHRoZSBpbml0LXRpbWUgc25hcHNob3QgYW5kIHdpbGwgbm90IGNo YW5nZS4NCj4+Pj4gDQo+Pj4+IFNpZ25lZC1vZmYtYnk6IEJlcnRyYW5kIE1hcnF1aXMgPGJlcnRy YW5kLm1hcnF1aXNAYXJtLmNvbT4NCj4+Pj4gLS0tDQo+Pj4+IHhlbi9hcmNoL2FybS90ZWUvZmZh X3BhcnRpbmZvLmMgfCAyMDUgKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0NCj4+Pj4g MSBmaWxlIGNoYW5nZWQsIDEzOCBpbnNlcnRpb25zKCspLCA2NyBkZWxldGlvbnMoLSkNCj4+Pj4g DQo+Pj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jIGIveGVu L2FyY2gvYXJtL3RlZS9mZmFfcGFydGluZm8uYw0KPj4+PiBpbmRleCA2YTZmM2ZmYjgyMmUuLjhh M2VhYzI1Zjk5ZiAxMDA2NDQNCj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFydGlu Zm8uYw0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jDQo+Pj4+IEBA IC02LDYgKzYsNyBAQA0KPj4+PiAjaW5jbHVkZSA8eGVuL2NvbnN0Lmg+DQo+Pj4+ICNpbmNsdWRl IDx4ZW4vc2l6ZXMuaD4NCj4+Pj4gI2luY2x1ZGUgPHhlbi90eXBlcy5oPg0KPj4+PiArI2luY2x1 ZGUgPHhlbi94bWFsbG9jLmg+DQo+Pj4+IA0KPj4+PiAjaW5jbHVkZSA8YXNtL3NtY2NjLmg+DQo+ Pj4+ICNpbmNsdWRlIDxhc20vcmVncy5oPg0KPj4+PiBAQCAtMzMsNiArMzQsMTAgQEAgc3RhdGlj IHVpbnQxNl90IHN1YnNjcl92bV9jcmVhdGVkX2NvdW50IF9fcmVhZF9tb3N0bHk7DQo+Pj4+IHN0 YXRpYyB1aW50MTZfdCAqc3Vic2NyX3ZtX2Rlc3Ryb3llZCBfX3JlYWRfbW9zdGx5Ow0KPj4+PiBz dGF0aWMgdWludDE2X3Qgc3Vic2NyX3ZtX2Rlc3Ryb3llZF9jb3VudCBfX3JlYWRfbW9zdGx5Ow0K Pj4+PiANCj4+Pj4gKy8qIFNQIGxpc3QgY2FjaGUgKHNlY3VyZSBlbmRwb2ludHMgb25seSk7IHBv cHVsYXRlZCBhdCBpbml0LiAqLw0KPj4+PiArc3RhdGljIHZvaWQgKnNwX2xpc3QgX19yZWFkX21v c3RseTsNCj4+Pj4gK3N0YXRpYyB1aW50MzJfdCBzcF9saXN0X2NvdW50IF9fcmVhZF9tb3N0bHk7 DQo+Pj4+ICtzdGF0aWMgdWludDMyX3Qgc3BfbGlzdF9lbnRyeV9zaXplIF9fcmVhZF9tb3N0bHk7 DQo+Pj4+IHN0YXRpYyBpbnQzMl90IGZmYV9wYXJ0aXRpb25faW5mb19nZXQoc3RydWN0IGZmYV91 dWlkIHV1aWQsIHVpbnQzMl90IGZsYWdzLA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdWludDMyX3QgKmNvdW50LCB1aW50MzJfdCAqZnBpX3NpemUpDQo+Pj4+IHsN Cj4+Pj4gQEAgLTc5LDkyICs4NCw3OCBAQCBzdGF0aWMgaW50MzJfdCBmZmFfY29weV9pbmZvKHZv aWQgKipkc3QsIHZvaWQgKmRzdF9lbmQsIGNvbnN0IHZvaWQgKnNyYywNCj4+Pj4gICAgcmV0dXJu IEZGQV9SRVRfT0s7DQo+Pj4+IH0NCj4+Pj4gDQo+Pj4+IC1zdGF0aWMgaW50MzJfdCBmZmFfZ2V0 X3NwX2NvdW50KHN0cnVjdCBmZmFfdXVpZCB1dWlkLCB1aW50MzJfdCAqc3BfY291bnQpDQo+Pj4+ ICtzdGF0aWMgYm9vbCBmZmFfc3BfZW50cnlfbWF0Y2hlc191dWlkKGNvbnN0IHZvaWQgKmVudHJ5 LCBzdHJ1Y3QgZmZhX3V1aWQgdXVpZCkNCj4+Pj4gew0KPj4+PiAtICAgIHVpbnQzMl90IHNyY19z aXplOw0KPj4+PiArICAgIGNvbnN0IHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xICpmcGkg PSBlbnRyeTsNCj4+Pj4gKyAgICBzdHJ1Y3QgZmZhX3V1aWQgc3BfdXVpZDsNCj4+Pj4gKw0KPj4+ PiArICAgIGlmICggZmZhX3V1aWRfaXNfbmlsKHV1aWQpICkNCj4+Pj4gKyAgICAgICAgcmV0dXJu IHRydWU7DQo+Pj4+IA0KPj4+PiAtICAgIHJldHVybiBmZmFfcGFydGl0aW9uX2luZm9fZ2V0KHV1 aWQsIEZGQV9QQVJUSVRJT05fSU5GT19HRVRfQ09VTlRfRkxBRywNCj4+Pj4gLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcF9jb3VudCwgJnNyY19zaXplKTsNCj4+Pj4gKyAgICBp ZiAoIHNwX2xpc3RfZW50cnlfc2l6ZSA8IHNpemVvZigqZnBpKSApDQo+Pj4+ICsgICAgICAgIHJl dHVybiBmYWxzZTsNCj4+PiANCj4+PiBUaGlzIGNhbiBuZXZlciBoYXBwZW4gc2luY2Ugd2UgZG9u J3QgYWNjZXB0IFNQTUMgYmVsb3cgdmVyc2lvbiAxLjEuIFdlDQo+Pj4gZXZlbiBoYXZlIGEgY2hl Y2sgdG8gZW5zdXJlIHRoZSBTUE1DIGRvZXNuJ3QgcmV0dXJuIGEgdG9vLXNtYWxsDQo+Pj4gc3Bp X3NpemUuDQo+PiANCj4+IEkgdHJpZWQgdG8gbWFrZSB0aGUgY29kZSBmb3J3YXJkIGNvbXBhdGli bGUuIEl0IGlzIG5vdCByZWFsbHkgYSBwb3NzaWJsZSBjYXNlIHJpZ2h0IG5vdw0KPj4gYnV0IHdl IGNvdWxkIGZhbGwgaW50byB0aGlzIGluIHRoZSBmdXR1cmUuDQo+IA0KPiBBdCB0aGUgbW9tZW50 LCBpdCdzIG9ubHkgZmZhX3NwX2xpc3RfY2FjaGVfaW5pdCgpLCB3aGljaCBpbml0aWFsaXplcw0K PiBhbmQgcHV0cyB0aGluZ3MgaW4gdGhlIFNQLiBTbyBhcyBsb25nIGFzIGZmYV9zcF9saXN0X2Nh Y2hlX2luaXQoKSBhbmQNCj4gdGhpcyBmdW5jdGlvbiBhcmUgaW4gc3luYywgdGhlcmUgc2hvdWxk IGJlIG5vIHByb2JsZW0uIEl0IHNpbXBsaWZpZXMNCj4gdGhpbmdzIGlmIHdlIGNhbiB0cnVzdCB0 aGUgU1AgY2FjaGUgdG8gYmUgdXNhYmxlLg0KDQpBZ3JlZSwgd2Ugc2hvdWxkIG5vdCBjb21lIGlu dG8gYSBzaXR1YXRpb24gd2hlcmUgdGhlIFNQIGNhY2hlIGNvbnRlbnQgY2Fubm90IGJlIHVzZWQu DQpBbnl0aGluZyB0byBiZSBjaGVjayBtdXN0IGhhdmUgYmVlbiBjaGVja2VkIG9yIGNvbnZlcnRl ZCB3aGVuIGNyZWF0aW5nIHRoZSBjYWNoZSBub3QNCndoZW4gdXNpbmcgaXQuDQoNCj4gDQo+PiAN Cj4+PiANCj4+Pj4gKw0KPj4+PiArICAgIG1lbWNweSgmc3BfdXVpZCwgZnBpLT51dWlkLCBzaXpl b2Yoc3BfdXVpZCkpOw0KPj4+PiArICAgIHJldHVybiBmZmFfdXVpZF9lcXVhbCh1dWlkLCBzcF91 dWlkKTsNCj4+Pj4gfQ0KPj4+PiANCj4+Pj4gLXN0YXRpYyBpbnQzMl90IGZmYV9nZXRfc3BfcGFy dGluZm8oc3RydWN0IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90ICpzcF9jb3VudCwNCj4+Pj4gLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqKmRzdF9idWYsIHZvaWQgKmVu ZF9idWYsDQo+Pj4+IC0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90 IGRzdF9zaXplKQ0KPj4+PiArc3RhdGljIGludDMyX3QgZmZhX2dldF9zcF9jb3VudChzdHJ1Y3Qg ZmZhX3V1aWQgdXVpZCwgdWludDMyX3QgKnNwX2NvdW50KQ0KPj4+PiB7DQo+Pj4+IC0gICAgaW50 MzJfdCByZXQ7DQo+Pj4+IC0gICAgaW50MzJfdCByZWxlYXNlX3JldDsNCj4+Pj4gLSAgICB1aW50 MzJfdCBzcmNfc2l6ZSwgcmVhbF9zcF9jb3VudDsNCj4+Pj4gLSAgICB2b2lkICpzcmNfYnVmOw0K Pj4+PiAgICB1aW50MzJfdCBjb3VudCA9IDA7DQo+Pj4+IC0gICAgYm9vbCBub3RpZnlfZncgPSBm YWxzZTsNCj4+Pj4gLQ0KPj4+PiAtICAgIC8qIFdlIG5lZWQgdG8gdXNlIHRoZSBSWCBidWZmZXIg dG8gcmVjZWl2ZSB0aGUgbGlzdCAqLw0KPj4+PiAtICAgIHNyY19idWYgPSBmZmFfcnh0eF9zcG1j X3J4X2FjcXVpcmUoKTsNCj4+Pj4gLSAgICBpZiAoICFzcmNfYnVmICkNCj4+Pj4gLSAgICAgICAg cmV0dXJuIEZGQV9SRVRfREVOSUVEOw0KPj4+PiAtDQo+Pj4+IC0gICAgcmV0ID0gZmZhX3BhcnRp dGlvbl9pbmZvX2dldCh1dWlkLCAwLCAmcmVhbF9zcF9jb3VudCwgJnNyY19zaXplKTsNCj4+Pj4g LSAgICBpZiAoIHJldCApDQo+Pj4+IC0gICAgICAgIGdvdG8gb3V0Ow0KPj4+PiAtICAgIG5vdGlm eV9mdyA9IHRydWU7DQo+Pj4+ICsgICAgdWludDMyX3QgbjsNCj4+Pj4gDQo+Pj4+IC0gICAgLyog VmFsaWRhdGUgdGhlIHNyY19zaXplIHdlIGdvdCAqLw0KPj4+PiAtICAgIGlmICggc3JjX3NpemUg PCBzaXplb2Yoc3RydWN0IGZmYV9wYXJ0aXRpb25faW5mb18xXzApIHx8DQo+Pj4+IC0gICAgICAg ICBzcmNfc2l6ZSA+PSBGRkFfUEFHRV9TSVpFICkNCj4+Pj4gKyAgICBmb3IgKCBuID0gMDsgbiA8 IHNwX2xpc3RfY291bnQ7IG4rKyApDQo+Pj4+ICAgIHsNCj4+Pj4gLSAgICAgICAgcmV0ID0gRkZB X1JFVF9OT1RfU1VQUE9SVEVEOw0KPj4+PiAtICAgICAgICBnb3RvIG91dDsNCj4+Pj4gKyAgICAg ICAgdm9pZCAqZW50cnkgPSBzcF9saXN0ICsgbiAqIHNwX2xpc3RfZW50cnlfc2l6ZTsNCj4+Pj4g Kw0KPj4+PiArICAgICAgICBpZiAoIGZmYV9zcF9lbnRyeV9tYXRjaGVzX3V1aWQoZW50cnksIHV1 aWQpICkNCj4+Pj4gKyAgICAgICAgICAgIGNvdW50Kys7DQo+Pj4+ICAgIH0NCj4+Pj4gDQo+Pj4+ IC0gICAgLyoNCj4+Pj4gLSAgICAgKiBMaW1pdCB0aGUgbWF4aW11bSB0aW1lIHdlIGhvbGQgdGhl IENQVSBieSBsaW1pdGluZyB0aGUgbnVtYmVyIG9mIFNQcy4NCj4+Pj4gLSAgICAgKiBXZSBqdXN0 IGlnbm9yZSB0aGUgZXh0cmEgb25lcyBhcyB0aGlzIGlzIHRlc3RlZCBkdXJpbmcgaW5pdCBpbg0K Pj4+PiAtICAgICAqIGZmYV9wYXJ0aW5mb19pbml0IHNvIHRoZSBvbmx5IHBvc3NpYmxlIHJlYXNv biBpcyBTUCBoYXZlIGJlZW4gYWRkZWQNCj4+Pj4gLSAgICAgKiBzaW5jZSBib290Lg0KPj4+PiAt ICAgICAqLw0KPj4+PiAtICAgIGlmICggcmVhbF9zcF9jb3VudCA+IEZGQV9NQVhfTlVNX1NQICkN Cj4+Pj4gLSAgICAgICAgcmVhbF9zcF9jb3VudCA9IEZGQV9NQVhfTlVNX1NQOw0KPj4+PiArICAg ICpzcF9jb3VudCA9IGNvdW50Ow0KPj4+PiANCj4+Pj4gLSAgICAvKiBNYWtlIHN1cmUgdGhlIGRh dGEgZml0cyBpbiBvdXIgYnVmZmVyICovDQo+Pj4+IC0gICAgaWYgKCByZWFsX3NwX2NvdW50ID4g KEZGQV9SWFRYX1BBR0VfQ09VTlQgKiBGRkFfUEFHRV9TSVpFKSAvIHNyY19zaXplICkNCj4+Pj4g LSAgICB7DQo+Pj4+IC0gICAgICAgIHJldCA9IEZGQV9SRVRfTk9UX1NVUFBPUlRFRDsNCj4+Pj4g LSAgICAgICAgZ290byBvdXQ7DQo+Pj4+IC0gICAgfQ0KPj4+PiArICAgIGlmICggIWZmYV91dWlk X2lzX25pbCh1dWlkKSAmJiAhY291bnQgKQ0KPj4+PiArICAgICAgICByZXR1cm4gRkZBX1JFVF9J TlZBTElEX1BBUkFNRVRFUlM7DQo+Pj4+IA0KPj4+PiAtICAgIGZvciAoIHVpbnQzMl90IHNwX251 bSA9IDA7IHNwX251bSA8IHJlYWxfc3BfY291bnQ7IHNwX251bSsrICkNCj4+Pj4gLSAgICB7DQo+ Pj4+IC0gICAgICAgIHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xICpmcGkgPSBzcmNfYnVm Ow0KPj4+PiArICAgIHJldHVybiBGRkFfUkVUX09LOw0KPj4+PiArfQ0KPj4+PiANCj4+Pj4gLSAg ICAgICAgLyogZmlsdGVyIG91dCBTUCBub3QgZm9sbG93aW5nIGJpdCAxNSBjb252ZW50aW9uIGlm IGFueSAqLw0KPj4+PiAtICAgICAgICBpZiAoIEZGQV9JRF9JU19TRUNVUkUoZnBpLT5pZCkgKQ0K Pj4+PiAtICAgICAgICB7DQo+Pj4+IC0gICAgICAgICAgICAvKg0KPj4+PiAtICAgICAgICAgICAg ICogSWYgVk0gaXMgMS4wIGJ1dCBmaXJtd2FyZSBpcyAxLjEgd2UgY291bGQgaGF2ZSBzZXZlcmFs IGVudHJpZXMNCj4+Pj4gLSAgICAgICAgICAgICAqIHdpdGggdGhlIHNhbWUgSUQgYnV0IGRpZmZl cmVudCBVVUlEcy4gSW4gdGhpcyBjYXNlIHRoZSBWTSB3aWxsDQo+Pj4+IC0gICAgICAgICAgICAg KiBnZXQgYSBsaXN0IHdpdGggc2V2ZXJhbCB0aW1lIHRoZSBzYW1lIElELg0KPj4+PiAtICAgICAg ICAgICAgICogVGhpcyBpcyBhIG5vbi1jb21wbGlhbmNlIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGJ1 dCAxLjAgVk1zIHNob3VsZA0KPj4+PiAtICAgICAgICAgICAgICogaGFuZGxlIHRoYXQgb24gdGhl aXIgb3duIHRvIHNpbXBsaWZ5IFhlbiBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4gLSAgICAgICAgICAg ICAqLw0KPj4+PiArc3RhdGljIGludDMyX3QgZmZhX2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZh X3V1aWQgdXVpZCwgdWludDMyX3QgKnNwX2NvdW50LA0KPj4+PiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB2b2lkICoqZHN0X2J1Ziwgdm9pZCAqZW5kX2J1ZiwNCj4+Pj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZHN0X3NpemUpDQo+Pj4+ ICt7DQo+Pj4+ICsgICAgaW50MzJfdCByZXQ7DQo+Pj4+ICsgICAgdWludDMyX3QgY291bnQgPSAw Ow0KPj4+PiArICAgIHVpbnQzMl90IG47DQo+Pj4+IA0KPj4+PiAtICAgICAgICAgICAgcmV0ID0g ZmZhX2NvcHlfaW5mbyhkc3RfYnVmLCBlbmRfYnVmLCBzcmNfYnVmLCBkc3Rfc2l6ZSwgc3JjX3Np emUpOw0KPj4+PiAtICAgICAgICAgICAgaWYgKCByZXQgKQ0KPj4+PiAtICAgICAgICAgICAgICAg IGdvdG8gb3V0Ow0KPj4+PiArICAgIGZvciAoIG4gPSAwOyBuIDwgc3BfbGlzdF9jb3VudDsgbisr ICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHZvaWQgKmVudHJ5ID0gc3BfbGlzdCArIG4g KiBzcF9saXN0X2VudHJ5X3NpemU7DQo+Pj4+IA0KPj4+PiAtICAgICAgICAgICAgY291bnQrKzsN Cj4+Pj4gLSAgICAgICAgfQ0KPj4+PiArICAgICAgICBpZiAoICFmZmFfc3BfZW50cnlfbWF0Y2hl c191dWlkKGVudHJ5LCB1dWlkKSApDQo+Pj4+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4+Pj4g DQo+Pj4+IC0gICAgICAgIHNyY19idWYgKz0gc3JjX3NpemU7DQo+Pj4+ICsgICAgICAgIC8qDQo+ Pj4+ICsgICAgICAgICAqIElmIFZNIGlzIDEuMCBidXQgZmlybXdhcmUgaXMgMS4xIHdlIGNvdWxk IGhhdmUgc2V2ZXJhbCBlbnRyaWVzDQo+Pj4+ICsgICAgICAgICAqIHdpdGggdGhlIHNhbWUgSUQg YnV0IGRpZmZlcmVudCBVVUlEcy4gSW4gdGhpcyBjYXNlIHRoZSBWTSB3aWxsDQo+Pj4+ICsgICAg ICAgICAqIGdldCBhIGxpc3Qgd2l0aCBzZXZlcmFsIHRpbWUgdGhlIHNhbWUgSUQuDQo+Pj4+ICsg ICAgICAgICAqIFRoaXMgaXMgYSBub24tY29tcGxpYW5jZSB0byB0aGUgc3BlY2lmaWNhdGlvbiBi dXQgMS4wIFZNcyBzaG91bGQNCj4+Pj4gKyAgICAgICAgICogaGFuZGxlIHRoYXQgb24gdGhlaXIg b3duIHRvIHNpbXBsaWZ5IFhlbiBpbXBsZW1lbnRhdGlvbi4NCj4+Pj4gKyAgICAgICAgICovDQo+ Pj4+ICsgICAgICAgIHJldCA9IGZmYV9jb3B5X2luZm8oZHN0X2J1ZiwgZW5kX2J1ZiwgZW50cnks IGRzdF9zaXplLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwX2xpc3RfZW50 cnlfc2l6ZSk7DQo+Pj4+ICsgICAgICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAgICAgICAgIHJl dHVybiByZXQ7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgY291bnQrKzsNCj4+Pj4gICAgfQ0KPj4+ PiANCj4+Pj4gICAgKnNwX2NvdW50ID0gY291bnQ7DQo+Pj4+IA0KPj4+PiAtb3V0Og0KPj4+PiAt ICAgIHJlbGVhc2VfcmV0ID0gZmZhX3J4dHhfc3BtY19yeF9yZWxlYXNlKG5vdGlmeV9mdyk7DQo+ Pj4+IC0gICAgaWYgKCByZWxlYXNlX3JldCApDQo+Pj4+IC0gICAgICAgIGdwcmludGsoWEVOTE9H X1dBUk5JTkcsDQo+Pj4+IC0gICAgICAgICAgICAgICAgImZmYTogRXJyb3IgcmVsZWFzaW5nIFNQ TUMgUlggYnVmZmVyOiAlZFxuIiwgcmVsZWFzZV9yZXQpOw0KPj4+PiAtICAgIHJldHVybiByZXQ7 DQo+Pj4+ICsgICAgaWYgKCAhZmZhX3V1aWRfaXNfbmlsKHV1aWQpICYmICFjb3VudCApDQo+Pj4+ ICsgICAgICAgIHJldHVybiBGRkFfUkVUX0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+Pj4gKw0KPj4+ PiArICAgIHJldHVybiBGRkFfUkVUX09LOw0KPj4+PiB9DQo+Pj4+IA0KPj4+PiBzdGF0aWMgaW50 MzJfdCBmZmFfZ2V0X3ZtX3BhcnRpbmZvKHN0cnVjdCBmZmFfdXVpZCB1dWlkLCB1aW50MzJfdCBz dGFydF9pbmRleCwNCj4+Pj4gQEAgLTQzNSw2ICs0MjYsMTQgQEAgc3RhdGljIGludDMyX3QgZmZh X2RpcmVjdF9yZXFfc2VuZF92bSh1aW50MTZfdCBzcF9pZCwgdWludDE2X3Qgdm1faWQsDQo+Pj4+ ICAgIHJldHVybiByZXM7DQo+Pj4+IH0NCj4+Pj4gDQo+Pj4+ICtzdGF0aWMgdm9pZCBmZmFfc3Bf bGlzdF9jYWNoZV9mcmVlKHZvaWQpDQo+Pj4+ICt7DQo+Pj4+ICsgICAgWEZSRUUoc3BfbGlzdCk7 DQo+Pj4+ICsgICAgc3BfbGlzdCA9IE5VTEw7DQo+Pj4gDQo+Pj4gWEZSRUUoKSBpcyBhbHJlYWR5 IHNldHRpbmcgc3BfbGlzdCB0byBOVUxMLg0KPj4gDQo+PiBBY2sgd2lsbCBmaXggaW4gdjINCj4+ IA0KPj4+IA0KPj4+PiArICAgIHNwX2xpc3RfY291bnQgPSAwOw0KPj4+PiArICAgIHNwX2xpc3Rf ZW50cnlfc2l6ZSA9IDA7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gc3RhdGljIHZvaWQgdW5pbml0 X3N1YnNjcmliZXJzKHZvaWQpDQo+Pj4+IHsNCj4+Pj4gICAgICAgIHN1YnNjcl92bV9jcmVhdGVk X2NvdW50ID0gMDsNCj4+Pj4gQEAgLTQ0Myw2ICs0NDIsNjggQEAgc3RhdGljIHZvaWQgdW5pbml0 X3N1YnNjcmliZXJzKHZvaWQpDQo+Pj4+ICAgICAgICBYRlJFRShzdWJzY3Jfdm1fZGVzdHJveWVk KTsNCj4+Pj4gfQ0KPj4+PiANCj4+Pj4gK3N0YXRpYyBib29sIGZmYV9zcF9saXN0X2NhY2hlX2lu aXQoY29uc3Qgdm9pZCAqYnVmLCB1aW50MzJfdCBjb3VudCwNCj4+Pj4gKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZnBpX3NpemUpDQo+Pj4+ICt7DQo+Pj4+ICsg ICAgY29uc3QgdWludDhfdCAqc3JjID0gYnVmOw0KPj4+PiArICAgIHVpbnQzMl90IHNlY3VyZV9j b3VudCA9IDA7DQo+Pj4+ICsgICAgdWludDMyX3QgbiwgaWR4ID0gMDsNCj4+Pj4gKyAgICBib29s IHdhcm5lZCA9IGZhbHNlOw0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCBmcGlfc2l6ZSA8IHNpemVv ZihzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMCkgfHwNCj4+Pj4gKyAgICAgICAgIGZwaV9z aXplID49IEZGQV9QQUdFX1NJWkUgKQ0KPj4+PiArICAgICAgICByZXR1cm4gZmFsc2U7DQo+Pj4g DQo+Pj4gV291bGQgaXQgbWFrZSBzZW5zZSB0byBjaGVjayB0aGF0IGZwaV9zaXplIGlzIHdlbGwg YWxpZ25lZCB3aXRoIHN0cnVjdA0KPj4+IGZmYV9wYXJ0aXRpb25faW5mb18xXzA/IElmIGl0J3Mg YW4gb2RkIHNpemUsIHdlJ2xsIG1ha2UgdW5hbGlnbmVkDQo+Pj4gYWNjZXNzZXMgYmVsb3cgd2l0 aCBtZW1jcHkoKS4gQnV0IHBlcmhhcHMgdGhhdCdzIGEgYml0IG11Y2guIFRoZSBTUE1DDQo+Pj4g aXNuJ3Qgc3VwcG9zZWQgdG8gcHJvdmlkZSBnYXJiYWdlLg0KPj4gDQo+PiBNZW1jcHkgc2hvdWxk IHByZXZlbnQgaXNzdWVzIGV2ZW4gaWYgYWNjZXNzZXMgYXJlIG5vdCBhbGlnbmVkLg0KPj4gSWYg d2UgaGFkIHRoaXMgdGVzdCwgd2UgY2Fubm90IHJldHVybiBhbiBlcnJvciB0byB0aGUgU1BNQyBz byB3ZSB3b3VsZCBoYXZlIHRvDQo+PiBnZW5lcmF0ZSBvbmUgdG8gdGhlIGNhbGxlci4gSXQgaXMg c2ltcGxlciBpIHRoaW5rIHRvIGhhbmRsZSBub24tYWxpZ25lZCBhcyB3ZSBkbyBub3QNCj4+IGV4 cGVjdCB0aGUgU1BNQyB0byBnZW5lcmF0ZSBzdWNoIGEgY2FzZS4NCj4+IFRlbGwgbWUgaWYgeW91 IGFncmVlLg0KPiANCj4gV2UgZGVyZWZlcmVuY2UgZnBpIGJlbG93LCBhbmQgZGVwZW5kaW5nIG9u IGNvbXBpbGVyIGZsYWdzIGFuZCBwb2ludGVyDQo+IHR5cGVzLCBtZW1jcHkoKSBtaWdodCBub3Qg YmUgc2FmZSB3aXRoIHVuYWxpZ25lZCBwb2ludGVycy4NCj4gRnJvbSA2LjMuMi4zIFBvaW50ZXJz LCBwYXJhZ3JhcGggNywgaW4gdGhlIEMgc3RhbmRhcmQ6DQo+ICJBIHBvaW50ZXIgdG8gYW4gb2Jq ZWN0IHR5cGUgbWF5IGJlIGNvbnZlcnRlZCB0byBhIHBvaW50ZXIgdG8gYQ0KPiBkaWZmZXJlbnQg b2JqZWN0IHR5cGUuIElmIHRoZQ0KPiByZXN1bHRpbmcgcG9pbnRlciBpcyBub3QgY29ycmVjdGx5 IGFsaWduZWQgZm9yIHRoZSByZWZlcmVuY2VkIHR5cGUsDQo+IHRoZSBiZWhhdmlvciBpcw0KPiB1 bmRl76yBbmVkLiINCj4gDQo+IEkndmUgc2VlbiBwYXN0IGV4YW1wbGVzIHdoZXJlIHRoZSBjb21w aWxlciBvcHRpbWl6ZWQgbWVtY3B5KCkgaW4gYSB3YXkNCj4gdGhhdCBicmVha3Mgd2l0aCB1bmFs aWduZWQgcG9pbnRlcnMuDQo+IA0KPiBXZSBkb24ndCBleHBlY3QgdGhlIHRlc3QgYWJvdmUgdG8g ZmFpbCwgYnV0IGlmIGl0IGRvZXMgd2Ugd2lsbCBub3QgdXNlDQo+IHRoZSBzZWN1cmUgZmlybXdh cmUuIEkgdGhpbmsgcmVmdXNpbmcgdW5leHBlY3RlZCBzaXplcyBpcyBldmVuDQo+IHNpbXBsZXIu IEl0IHNob3VsZCBtYWtlIGZpbmRpbmcgZXZlbnR1YWwgZXJyb3JzIG11Y2ggZWFzaWVyLg0KDQpJ biB0aGUgZmZhIHNwZWMsIHRoZSBzaXplIGNhbiBncm93IGFuZCB0aGlzIGlzIHdoeSB0aGVyZSBp cyBhIHNpemUgZmllbGQuDQpGRi1BIGV4cGVjdCB0aGF0IHdlIGVpdGhlciBpZ25vcmUgb3IgY29w eSB3aXRob3V0IGxvb2tpbmcgdGhlIGV4dHJhDQpjb250ZW50Lg0KSSB0aGluayB3ZSBzaG91bGQg bm90IGJlIGRlcGVuZGVudCBvbiBhbnkgYWxpZ25tZW50IHNvIHdlIG5lZWQgdG8NCm1ha2Ugc3Vy ZSB3ZSBkbyB0aGUgY29weSBpbiBhIHdheSB0aGF0IGlzIHJvYnVzdCB0byBub24gYWxpZ25tZW50 cy4NCg0KPiANCj4gU28gbXkgcXVlc3Rpb24gYWJvdmUgaXMgd2hldGhlciBpdCdzIHdvcnRoIGNo ZWNraW5nIHRoYXQgZnBpX3NpemUgaXMNCj4gd2VsbC1hbGlnbmVkLCBvciBpZiBpdCdzIHNvIHVu bGlrZWx5IHRoYXQgd2UgZG9uJ3QgbmVlZCB0byBjb25zaWRlcg0KPiBpdC4NCg0KSSB0aGluayB3 ZSBuZWVkIHRvIGZpbmQgYSBzb2x1dGlvbiB3aGVyZSB3ZSBoYW5kbGUgcHJvcGVybHkgdGhpbmdz IGV2ZW4NCmlmIHRoZSBzaXplIGlzIG5vdCBhbGlnbmVkLiBJIHRob3VnaCB1c2luZyBtZW1jcHkg d291bGQgcHJvdGVjdCBhZ2FpbnN0DQp0aGF0IGJ1dCBtYXliZSB3ZSBuZWVkIHRvIHVzZSBhIHN0 cm9uZ2VyIHNvbHV0aW9uIHRvIGVuc3VyZSB0aGF0IHdvcmtzDQpldmVuIGlmIGRhdGEgaXMgdW5h bGlnbmVkLg0KDQpDaGVlcnMNCkJlcnRyYW5kDQoNCj4gDQo+IENoZWVycywNCj4gSmVucw0KPiAN Cj4+IA0KPj4+IA0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCBjb3VudCA+IChGRkFfUlhUWF9QQUdF X0NPVU5UICogRkZBX1BBR0VfU0laRSkgLyBmcGlfc2l6ZSApDQo+Pj4+ICsgICAgICAgIHJldHVy biBmYWxzZTsNCj4+Pj4gKw0KPj4+PiArICAgIGZvciAoIG4gPSAwOyBuIDwgY291bnQ7IG4rKyAp DQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBjb25zdCBzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9p bmZvXzFfMCAqZnBpID0NCj4+Pj4gKyAgICAgICAgICAgIChjb25zdCB2b2lkICopKHNyYyArIG4g KiBmcGlfc2l6ZSk7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgaWYgKCAhRkZBX0lEX0lTX1NFQ1VS RShmcGktPmlkKSApDQo+Pj4+ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAgICAgIGlmICggIXdh cm5lZCApDQo+Pj4gDQo+Pj4gSXMgdGhpcyBuZWVkZWQ/IERvZXNuJ3QgcHJpbnRrX29uY2UoKSBh bHJlYWR5IGVuc3VyZSB0aGlzPyBPciBkaWQgeW91DQo+Pj4gaGFwcGVuIHRvIGxlYXZlIHByaW50 a19vbmNlKCkgYnkgbWlzdGFrZSBhbmQgbWVhbnQgZm9yIHRoaXMgdG8gYmUNCj4+PiBwcmludGVk IG9uY2UgZWFjaCB0aW1lIGZmYV9zcF9saXN0X2NhY2hlX2luaXQoKSBpcyBjYWxsZWQsIHNpbmNl DQo+Pj4gIndhcm5lZCIgaXNuJ3Qgc3RhdGljLg0KPj4gDQo+PiBWZXJ5IHJpZ2h0LCBpIG5lZWQg dG8gcmVtb3ZlIHRoZSB3YXJuZWQsIHByaW50a19vbmNlIHNob3VsZCBiZSBlbm91Z2ggaGVyZS4N Cj4+IA0KPj4+IA0KPj4+PiArICAgICAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgICAgIHBy aW50a19vbmNlKFhFTkxPR19FUlINCj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAi ZmZhOiBGaXJtd2FyZSBpcyBub3QgdXNpbmcgYml0IDE1IGNvbnZlbnRpb24gZm9yIElEcyAhIVxu Iik7DQo+Pj4+ICsgICAgICAgICAgICAgICAgd2FybmVkID0gdHJ1ZTsNCj4+Pj4gKyAgICAgICAg ICAgIH0NCj4+Pj4gKyAgICAgICAgICAgIHByaW50ayhYRU5MT0dfRVJSDQo+Pj4+ICsgICAgICAg ICAgICAgICAgICAgImZmYTogU2VjdXJlIHBhcnRpdGlvbiB3aXRoIGlkIDB4JTA0eCBjYW5ub3Qg YmUgdXNlZFxuIiwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICBmcGktPmlkKTsNCj4+Pj4gKyAg ICAgICAgICAgIGNvbnRpbnVlOw0KPj4+PiArICAgICAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICAg ICAgc2VjdXJlX2NvdW50Kys7DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgaWYgKCBz ZWN1cmVfY291bnQgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgc3BfbGlzdCA9IHh6YWxs b2NfYnl0ZXMoc2VjdXJlX2NvdW50ICogZnBpX3NpemUpOw0KPj4+PiArICAgICAgICBpZiAoICFz cF9saXN0ICkNCj4+Pj4gKyAgICAgICAgICAgIHJldHVybiBmYWxzZTsNCj4+Pj4gKyAgICB9DQo+ Pj4+ICsNCj4+Pj4gKyAgICBzcF9saXN0X2NvdW50ID0gc2VjdXJlX2NvdW50Ow0KPj4+PiArICAg IHNwX2xpc3RfZW50cnlfc2l6ZSA9IGZwaV9zaXplOw0KPj4+PiArDQo+Pj4+ICsgICAgZm9yICgg biA9IDA7IG4gPCBjb3VudDsgbisrICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIGNvbnN0 IHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8wICpmcGkgPQ0KPj4+PiArICAgICAgICAgICAg KGNvbnN0IHZvaWQgKikoc3JjICsgbiAqIGZwaV9zaXplKTsNCj4+Pj4gKw0KPj4+PiArICAgICAg ICBpZiAoICFGRkFfSURfSVNfU0VDVVJFKGZwaS0+aWQpICkNCj4+Pj4gKyAgICAgICAgICAgIGNv bnRpbnVlOw0KPj4+PiArDQo+Pj4+ICsgICAgICAgIG1lbWNweShzcF9saXN0ICsgaWR4ICogZnBp X3NpemUsIGZwaSwgZnBpX3NpemUpOw0KPj4+PiArICAgICAgICBpZHgrKzsNCj4+Pj4gKyAgICB9 DQo+Pj4+ICsNCj4+Pj4gKyAgICByZXR1cm4gdHJ1ZTsNCj4+Pj4gK30NCj4+Pj4gKw0KPj4+PiBz dGF0aWMgYm9vbCBpbml0X3N1YnNjcmliZXJzKHZvaWQgKmJ1ZiwgdWludDE2X3QgY291bnQsIHVp bnQzMl90IGZwaV9zaXplKQ0KPj4+PiB7DQo+Pj4+ICAgIHVpbnQxNl90IG47DQo+Pj4+IEBAIC01 NDksMTIgKzYxMCwyMiBAQCBib29sIGZmYV9wYXJ0aW5mb19pbml0KHZvaWQpDQo+Pj4+ICAgICAg ICBnb3RvIG91dDsNCj4+Pj4gICAgfQ0KPj4+PiANCj4+Pj4gLSAgICByZXQgPSBpbml0X3N1YnNj cmliZXJzKHNwbWNfcngsIGNvdW50LCBmcGlfc2l6ZSk7DQo+Pj4+ICsgICAgaWYgKCAhZmZhX3Nw X2xpc3RfY2FjaGVfaW5pdChzcG1jX3J4LCBjb3VudCwgZnBpX3NpemUpICkNCj4+Pj4gKyAgICB7 DQo+Pj4+ICsgICAgICAgIHByaW50ayhYRU5MT0dfRVJSICJmZmE6IEZhaWxlZCB0byBjYWNoZSBT UCBsaXN0XG4iKTsNCj4+Pj4gKyAgICAgICAgZ290byBvdXQ7DQo+Pj4+ICsgICAgfQ0KPj4+PiAr DQo+Pj4+ICsgICAgcmV0ID0gaW5pdF9zdWJzY3JpYmVycyhzcF9saXN0LCBzcF9saXN0X2NvdW50 LCBzcF9saXN0X2VudHJ5X3NpemUpOw0KPj4+PiANCj4+Pj4gb3V0Og0KPj4+PiAgICBlID0gZmZh X3J4dHhfc3BtY19yeF9yZWxlYXNlKG5vdGlmeV9mdyk7DQo+Pj4+ICAgIGlmICggZSApDQo+Pj4+ ICAgICAgICBwcmludGsoWEVOTE9HX1dBUk5JTkcgImZmYTogRXJyb3IgcmVsZWFzaW5nIFNQTUMg UlggYnVmZmVyOiAlZFxuIiwgZSk7DQo+Pj4+ICsgICAgaWYgKCAhcmV0ICkNCj4+Pj4gKyAgICAg ICAgdW5pbml0X3N1YnNjcmliZXJzKCk7DQo+Pj4gDQo+Pj4gcmV0IGlzIGluaXRpYWxseSBmYWxz ZSBhbmQgY2FuIG9ubHkgYmUgc2V0IHRvIHRydWUgaWYNCj4+PiBpbml0X3N1YnNjcmliZXJzKCkg cmV0dXJucyB0cnVlLiBTbyB0aGVyZSdzIG5ldmVyIGFueSBwb2ludCBpbiBjYWxsaW5nDQo+Pj4g dW5pbml0X3N1YnNjcmliZXJzKCkuDQo+PiANCj4+IFRydWUsIEkgd2lsbCBmaXggdGhhdC4NCj4+ IA0KPj4+IA0KPj4+PiArICAgIGlmICggIXJldCApDQo+Pj4+ICsgICAgICAgIGZmYV9zcF9saXN0 X2NhY2hlX2ZyZWUoKTsNCj4+PiANCj4+PiByZXQgY2FuIGJlIGZhbHNlIGV2ZW4gaWYgZmZhX3Nw X2xpc3RfY2FjaGVfaW5pdCgpIGhhc24ndCBiZWVuIGNhbGxlZA0KPj4+IHlldC4gQ2FsbGluZyBm ZmFfc3BfbGlzdF9jYWNoZV9mcmVlKCkgYW55d2F5IGlzIGhhcm1sZXNzLCBidXQgbm90DQo+Pj4g ZWxlZ2FudC4NCj4+IA0KPj4geWVzLCBpIHdpbGwgcmV3b3JrIGEgYml0IHRoZSBjbGVhbnVwIGxv Z2ljIGhlcmUuDQo+PiANCj4+IFRoYW5rcyBmb3IgdGhlIHJldmlldw0KPj4gDQo+PiBDaGVlcnMN Cj4+IEJlcnRyYW5kDQo+PiANCj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4gSmVucw0KPj4+IA0KPj4+ PiAgICByZXR1cm4gcmV0Ow0KPj4+PiB9DQo+Pj4+IA0KPj4+PiAtLQ0KPj4+PiAyLjUyLjANCg0K DQo= From xen-devel-bounces@lists.xenproject.org Mon Mar 02 10:07:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 10:07:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244078.1543541 (Exim 4.92) (envelope-from ) id 1vx0B4-00010q-FL; Mon, 02 Mar 2026 10:07:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244078.1543541; Mon, 02 Mar 2026 10: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 ) id 1vx0B4-00010j-CE; Mon, 02 Mar 2026 10:07:02 +0000 Received: by outflank-mailman (input) for mailman id 1244078; Mon, 02 Mar 2026 10:07:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx0B3-00010d-AL for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 10:07:01 +0000 Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [2607:f8b0:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8a59ea01-161f-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 11:06:55 +0100 (CET) Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-7d1872504cbso1855805a34.0 for ; Mon, 02 Mar 2026 02:06:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8a59ea01-161f-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1772446014; cv=none; d=google.com; s=arc-20240605; b=TpCwPOVjn3owzxUMtGbylauYIrmTtbo9AeBeJwfT0uXdupYL/E06gqI4pfGamhPJ+F RNhehsvRgg9AFdbRerb9BYDvg6yGygQfkM6i0qcqmKjSXUResmrH6dL7pkpD6BniibQf 1wbsnF2mjXL2ZEyalataTfYa1PB27dYB/6mfYV+KpF+Aba5aj04/JgP1c28VQJ0vLyA9 c6m5/AA798+JozkIdELGRiQR1ZRXuaU+lE6psX3A79KyZekUthhCEMfwkJ0ryKcQt9eB hX417r8URpSTfBAyp7U0hUjmaS3qblLIibq6suKAunqWgvaE7aixvk/v+HImBbyk334I u7Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ne+Ffqddt+jp/TSNBA9XZK1oaixSm2EvzlC0rKoP8EA=; fh=wB0f5JGUSpWYejuxtnrl8SDqvqyWrEsEaWvC32LbdiU=; b=kbIF8In98CP/aTAOJ5M59WujFW3ZL7gn5pb0h737FLWo4EBr30PsfK4s5XYIT9I05N FxgiOnxBcfHhM88/PGd87t9XRVXtnbIbhKmZO5rw3gKiwRX68tzLJzCegBf8p4iMpODe xn3ByHqkXz0RhC09T83lcuZXb4VggsWD/XZVtjMjXhhSezS5W2Z88rt/phYLZNSw8O82 oN5gdHDA+zaNTdSHHQx6pfC2UMEYa5bLdI7L+usPp12zc0sMjda2b+cQkNhEiY71ZzYX hnMJfq9vr8GnPnE/iur+zN7RFTMXPBFE730c72OvH8rlCplBY+UHvpI5oTF6uzELRvMN heRA==; 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=1772446014; x=1773050814; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ne+Ffqddt+jp/TSNBA9XZK1oaixSm2EvzlC0rKoP8EA=; b=pOWmrQQu9AeKdr+truA3zbs9zdioliKT/kOFsrJ+/UScRKI/YcpeCT6y8U68m9pxQT sVUb8txa1B90VV8weIDVxF3tp9rj7EXP41BQw93GqN9cUSGqZ+/ZVkXIM5OV/0364Anu tefuPUVTRhRTlaqyOBARokTsiggBLEoBB2TWPFtb1qhSuY3yuKvdfMePzUDhBhcvebtn UuLjJuRbkN78+/1ezTDSygx/5GGW/VYq+yCxxmTdN5zX1Y4VVGoIIOt+0ERatUOtiT7Z PXzka8aeV+RVLSJDGTCsEeYKKrqHiITYuAbXQ7E327qt5YLEqYGHJ82BtmGLKsn+C9gf e72g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772446014; x=1773050814; h=content-transfer-encoding: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; bh=ne+Ffqddt+jp/TSNBA9XZK1oaixSm2EvzlC0rKoP8EA=; b=I0nNbrcvdcB8VJ1f95X6uAyjrUXl7UbPZPJh0PLZcEm/gi0CIYSe+RemB8wIfAnbNN 6rxuDWcbANRh9gjchs1G9nQzEv2TALQLrhDiVws6tzQ2lVGMWCaL/deme6ffubwX2k0s RK1hzLN6ulXswDKB9TWxGpILurqMeLPArMCdu04keVGulfOM/GPTPHdgQan+5RAb9oaG u8hQWIEX2zx2Qb7AjWKUUfqrqFFmReGtVRfQEIckLLdq0YrAqE8E+JDtnxGvb2G7AIli EfS+2LVB44ZFxhPjthcZnaVTEHm8e3VJvSv904+1qjtJkC8WvZUMlntksiYOWCbQla2/ o8WQ== X-Gm-Message-State: AOJu0YyD6mRJGRwSqmsrOzVBM3k9401JrExlJLPa17FduYngGS8D04np 8wRwSbNnBla9H5C/fYsh4QtdBBP3y9B5HgsqUIJFE+njJqztn1Hh+5tKUdQRKyZkXgmwwKybvh4 Qs79qtFWlbX5rl7nwwStCDpqnWHJMoQI4b14ZrJ1cbA== X-Gm-Gg: ATEYQzwrRvcyAev/Uk7+1iDc1smXuDAS9DaiJI4861EwH9ZH5Yw0u9nDSOWHJGmk539 k8NUUn0Pu3WEdBoODMGFBRjsmt8A49Iwbgu+0T8gEaSwsFPT7kim3ELSdxVPRNRxpnpDLkUky+x sH350vykt8Q8n5IwEbbN6r7qNhQsAjKx2l3kqcBLleVXwJc1RqUnrcictXBPpTbmLMKigPXpZxi DiWx20uIzOXrrlHHcm+nt/pAiLnklNTJfswiV8MdosBBLPG+Zh6xoOMepClmTYblpFlNtTNwki2 tvlnf9O0+5De8hcCCvDDivm0nYW6qUXjL9uNmw== X-Received: by 2002:a05:6830:44a1:b0:7d1:9574:db9a with SMTP id 46e09a7af769-7d591eb98aamr7466286a34.12.1772446013904; Mon, 02 Mar 2026 02:06:53 -0800 (PST) MIME-Version: 1.0 References: <832ba950a53a7139b51053f6570fd9b26ba42df1.1772013062.git.bertrand.marquis@arm.com> In-Reply-To: From: Jens Wiklander Date: Mon, 2 Mar 2026 11:06:41 +0100 X-Gm-Features: AaiRm52wVBFJ97Qaqhh96KG9ybloh1x00cBNCQR_oUSruRLIKe7BQMlZOyXHPUA Message-ID: Subject: Re: [PATCH 4/4] xen/arm: ffa: Add cached GET_REGS support To: Bertrand Marquis Cc: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 9:58=E2=80=AFAM Bertrand Marquis wrote: > > Hi Jens, > > > On 27 Feb 2026, at 15:56, Jens Wiklander wr= ote: > > > > Hi Bertrand, > > > > On Wed, Feb 25, 2026 at 11:02=E2=80=AFAM Bertrand Marquis > > wrote: > >> > >> FF-A v1.2 defines PARTITION_INFO_GET_REGS for register-based partition > >> info retrieval, but Xen currently only supports the buffer-based GET > >> path for guests. > >> > >> Implement GET_REGS using the cached SP list and VM entries, including > >> the register window layout and input validation. Track VM list changes > >> via the partinfo tag and use it to validate GET_REGS tag inputs. Ensur= e > >> that when a non-Nil UUID is specified, the UUID fields in both GET and > >> GET_REGS results are MBZ as required by the specification. > >> > >> PARTITION_INFO_GET_REGS is available to v1.2 guests, returning cached = SP > >> entries and VM entries with UUIDs zeroed for non-Nil UUID queries. > >> > >> Signed-off-by: Bertrand Marquis > >> --- > >> xen/arch/arm/tee/ffa.c | 16 +++ > >> xen/arch/arm/tee/ffa_partinfo.c | 211 ++++++++++++++++++++++++++++++++ > >> xen/arch/arm/tee/ffa_private.h | 4 +- > >> 3 files changed, 230 insertions(+), 1 deletion(-) > >> > >> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > >> index aa43ae2595d7..d56eb20c2239 100644 > >> --- a/xen/arch/arm/tee/ffa.c > >> +++ b/xen/arch/arm/tee/ffa.c > >> @@ -44,6 +44,11 @@ > >> * - doesn't support signalling the secondary scheduler of pending > >> * notification for secure partitions > >> * - doesn't support notifications for Xen itself > >> + * o FFA_PARTITION_INFO_GET/GET_REGS: > >> + * - v1.0 guests may see duplicate SP IDs when firmware provides UU= IDs > >> + * - SP list is cached at init; SPMC tag changes are not tracked > >> + * between calls > >> + * - SP list is capped at FFA_MAX_NUM_SP entries > >> * > >> * There are some large locked sections with ffa_spmc_tx_lock and > >> * ffa_spmc_rx_lock. Especially the ffa_spmc_tx_lock spinlock used > >> @@ -188,6 +193,7 @@ static bool ffa_negotiate_version(struct cpu_user_= regs *regs) > >> write_lock(&ffa_ctx_list_rwlock); > >> list_add_tail(&ctx->ctx_list, &ffa_ctx_head); > >> write_unlock(&ffa_ctx_list_rwlock); > >> + ffa_partinfo_inc_tag(); > >> } > >> > >> goto out_continue; > >> @@ -341,6 +347,12 @@ static void handle_features(struct cpu_user_regs = *regs) > >> case FFA_FEATURE_SCHEDULE_RECV_INTR: > >> ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0)= ; > >> break; > >> + case FFA_PARTITION_INFO_GET_REGS: > >> + if ( ACCESS_ONCE(ctx->guest_vers) >=3D FFA_VERSION_1_2 ) > >> + ffa_set_regs_success(regs, 0, 0); > >> + else > >> + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > >> + break; > >> > >> case FFA_NOTIFICATION_BIND: > >> case FFA_NOTIFICATION_UNBIND: > >> @@ -402,6 +414,9 @@ static bool ffa_handle_call(struct cpu_user_regs *= regs) > >> case FFA_PARTITION_INFO_GET: > >> ffa_handle_partition_info_get(regs); > >> return true; > >> + case FFA_PARTITION_INFO_GET_REGS: > >> + ffa_handle_partition_info_get_regs(regs); > >> + return true; > >> case FFA_RX_RELEASE: > >> e =3D ffa_rx_release(ctx); > >> break; > >> @@ -629,6 +644,7 @@ static int ffa_domain_teardown(struct domain *d) > >> write_lock(&ffa_ctx_list_rwlock); > >> list_del(&ctx->ctx_list); > >> write_unlock(&ffa_ctx_list_rwlock); > >> + ffa_partinfo_inc_tag(); > >> } > >> > >> ffa_rxtx_domain_destroy(d); > >> diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_pa= rtinfo.c > >> index d7f9b9f7153c..1c7b3579f798 100644 > >> --- a/xen/arch/arm/tee/ffa_partinfo.c > >> +++ b/xen/arch/arm/tee/ffa_partinfo.c > >> @@ -28,10 +28,39 @@ struct ffa_partition_info_1_1 { > >> uint8_t uuid[16]; > >> }; > >> > >> +/* Registers a3..a17 (15 regs) carry partition descriptors, 3 regs ea= ch. */ > >> +#define FFA_PARTINFO_REG_MAX_ENTRIES \ > >> + ((15 * sizeof(uint64_t)) / sizeof(struct ffa_partition_info_1_1)) > >> + > >> /* SP list cache (secure endpoints only); populated at init. */ > >> static void *sp_list __read_mostly; > >> static uint32_t sp_list_count __read_mostly; > >> static uint32_t sp_list_entry_size __read_mostly; > >> + > >> +/* SP list is static; tag only moves when VMs are added/removed. */ > >> +static atomic_t ffa_partinfo_tag =3D ATOMIC_INIT(1); > >> + > >> +void ffa_partinfo_inc_tag(void) > >> +{ > >> + atomic_inc(&ffa_partinfo_tag); > > > > Do we need to worry about this value wrapping? Is wrapping permitted? > > wrapping is permitted, as the end this value is used to ensure changes in > the middle of info_get_regs are detected. Having enough changes in the > middle for this to wrap and end up un-detected by the caller is near to i= mpossible. > In any case, the status we return is a snapshot which have changed as soo= n as > the result is returned so i would consider this a best effort (even if th= e probability > for this to happen is very very near to 0). I'm sorry for being unclear. atomic_t is implemented as struct { int counter; }, wrapping the counter element is undefined behaviour. But it will take quite some time before we get there and perhaps the assembly implementation of atomic_inc() is expected to mitigate the undefined behaviour part. > > > > >> +} > >> + > >> +static inline uint16_t ffa_partinfo_get_tag(void) > >> +{ > >> + /* > >> + * Tag moves with VM list changes only. > >> + * > >> + * Limitation: we cannot detect an SPMC tag change between calls = because we > >> + * do not retain the previous SPMC tag; we only refresh it via th= e mandatory > >> + * start_index=3D0 call and assume it stays stable while combined= _tag (our > >> + * VM/SP-count tag) is used for guest validation. This means SPMC= tag > >> + * changes alone will not trigger RETRY. > >> + */ > >> + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > >> + return atomic_read(&ffa_partinfo_tag) & GENMASK(15, 0); > >> + else > >> + return 1; > >> +} > >> static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t f= lags, > >> uint32_t *count, uint32_t *fpi_s= ize) > >> { > >> @@ -125,6 +154,7 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid= uuid, uint32_t *sp_count, > >> for ( n =3D 0; n < sp_list_count; n++ ) > >> { > >> void *entry =3D sp_list + n * sp_list_entry_size; > >> + void *dst_pos; > >> > >> if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > >> continue; > >> @@ -136,11 +166,20 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uu= id uuid, uint32_t *sp_count, > >> * This is a non-compliance to the specification but 1.0 VMs s= hould > >> * handle that on their own to simplify Xen implementation. > >> */ > >> + dst_pos =3D *dst_buf; > >> ret =3D ffa_copy_info(dst_buf, end_buf, entry, dst_size, > >> sp_list_entry_size); > >> if ( ret ) > >> return ret; > >> > >> + if ( !ffa_uuid_is_nil(uuid) && > >> + dst_size >=3D sizeof(struct ffa_partition_info_1_1) ) > >> + { > >> + struct ffa_partition_info_1_1 *fpi =3D dst_pos; > >> + > >> + memset(fpi->uuid, 0, sizeof(fpi->uuid)); > >> + } > >> + > >> count++; > >> } > >> > >> @@ -152,6 +191,38 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uui= d uuid, uint32_t *sp_count, > >> return FFA_RET_OK; > >> } > >> > >> +static uint16_t ffa_get_sp_partinfo_regs(struct ffa_uuid uuid, > >> + uint16_t start_index, > >> + uint64_t *out_regs, > >> + uint16_t max_entries) > >> +{ > >> + uint32_t idx =3D 0; > >> + uint16_t filled =3D 0; > >> + uint32_t n; > >> + > >> + for ( n =3D 0; n < sp_list_count && filled < max_entries; n++ ) > >> + { > >> + void *entry =3D sp_list + n * sp_list_entry_size; > >> + > >> + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > >> + continue; > >> + > >> + if ( idx++ < start_index ) > >> + continue; > >> + > >> + memcpy(&out_regs[filled * 3], entry, > >> + sizeof(struct ffa_partition_info_1_1)); > >> + if ( !ffa_uuid_is_nil(uuid) ) > >> + { > >> + out_regs[filled * 3 + 1] =3D 0; > >> + out_regs[filled * 3 + 2] =3D 0; > >> + } > >> + filled++; > >> + } > >> + > >> + return filled; > >> +} > >> + > >> static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t star= t_index, > >> uint32_t *vm_count, void **dst_buf, > >> void *end_buf, uint32_t dst_size) > >> @@ -368,6 +439,146 @@ out: > >> } > >> } > >> > >> +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs) > >> +{ > >> + struct domain *d =3D current->domain; > >> + struct ffa_ctx *ctx =3D d->arch.tee; > >> + struct ffa_uuid uuid; > >> + uint32_t sp_count =3D 0, vm_count =3D 0, total_count; > >> + uint16_t start_index, tag; > >> + uint16_t num_entries =3D 0; > >> + uint64_t x3 =3D get_user_reg(regs, 3); > >> + int32_t ret =3D FFA_RET_OK; > >> + uint64_t out_regs[18] =3D { 0 }; > >> + unsigned int n; > >> + uint16_t tag_out; > >> + > >> + if ( ACCESS_ONCE(ctx->guest_vers) < FFA_VERSION_1_2 ) > >> + { > >> + ret =3D FFA_RET_NOT_SUPPORTED; > >> + goto out; > >> + } > >> + > >> + /* > >> + * Registers a3..a17 (15 regs) carry partition descriptors, 3 reg= s each. > >> + * For FF-A 1.2, that yields a maximum of 5 entries per GET_REGS = call. > >> + * Enforce the assumed layout so window sizing stays correct. > >> + */ > >> + BUILD_BUG_ON(FFA_PARTINFO_REG_MAX_ENTRIES !=3D 5); > >> + > >> + for ( n =3D 4; n <=3D 17; n++ ) > >> + { > >> + if ( get_user_reg(regs, n) ) > >> + { > > > > x4-x17 are SBZ, so I think we should only ignore them. > > Ack, this was added to satisfy the compliance suite but this > has been solved since. I will remove. > > > > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + } > >> + > >> + if ( x3 >> 32 ) > > > > Same here: Bits[63:32] are SBZ. > > Same here. > > > > >> + { > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + > >> + start_index =3D x3 & GENMASK(15, 0); > >> + tag =3D (x3 >> 16) & GENMASK(15, 0); > >> + > >> + /* Start index must allow room for up to 5 entries without 16-bit= overflow. */ > >> + if ( start_index > (GENMASK(15, 0) - (FFA_PARTINFO_REG_MAX_ENTRIE= S - 1)) ) > >> + { > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + > >> + uuid.val[0] =3D get_user_reg(regs, 1); > >> + uuid.val[1] =3D get_user_reg(regs, 2); > >> + > >> + if ( sp_list_count && > >> + sp_list_entry_size !=3D sizeof(struct ffa_partition_info_1_1= ) ) > >> + { > >> + ret =3D FFA_RET_NOT_SUPPORTED; > > > > This can't happen. But I guess a sp_list_entry_size > sizeof(struct > > ffa_partition_info_1_1) might be supported to be future proof. > > Right now we have FFA_PARTINFO_REG_MAX_ENTRIES enforcing the > structure to be 1.1 size. If this is not true in the future we will have = to modify > this. > > This is not really future proof and i will check if i can rework this. > > > > >> + goto out; > >> + } > >> + > >> + tag_out =3D ffa_partinfo_get_tag(); > >> + > >> + if ( start_index =3D=3D 0 ) > >> + { > >> + if ( tag ) > >> + { > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + } > >> + else if ( tag !=3D tag_out ) > >> + { > >> + ret =3D FFA_RET_RETRY; > >> + goto out; > >> + } > >> + > >> + if ( ffa_uuid_is_nil(uuid) ) > >> + { > >> + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > >> + vm_count =3D get_ffa_vm_count(); > >> + else > >> + vm_count =3D 1; /* Caller VM only */ > >> + } > >> + > >> + ret =3D ffa_get_sp_count(uuid, &sp_count); > >> + if ( ret ) > >> + goto out; > >> + > >> + total_count =3D sp_count + vm_count; > >> + > >> + if ( total_count =3D=3D 0 || start_index >=3D total_count ) > >> + { > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + > >> + if ( start_index < sp_count ) > >> + num_entries =3D ffa_get_sp_partinfo_regs(uuid, start_index, &= out_regs[3], > >> + FFA_PARTINFO_REG_MAX_E= NTRIES); > >> + > >> + if ( num_entries < FFA_PARTINFO_REG_MAX_ENTRIES ) > >> + { > >> + uint32_t vm_start =3D start_index > sp_count ? > >> + start_index - sp_count : 0; > >> + uint32_t filled =3D 0; > >> + void *vm_dst =3D &out_regs[3 + num_entries * 3]; > >> + void *vm_end =3D &out_regs[18]; > >> + > >> + ret =3D ffa_get_vm_partinfo(uuid, vm_start, &filled, &vm_dst,= vm_end, > >> + sizeof(struct ffa_partition_info_1_= 1)); > >> + if ( ret !=3D FFA_RET_OK && ret !=3D FFA_RET_NO_MEMORY ) > >> + goto out; > >> + > >> + num_entries +=3D filled; > >> + } > >> + > >> + if ( num_entries =3D=3D 0 ) > >> + { > >> + ret =3D FFA_RET_INVALID_PARAMETERS; > >> + goto out; > >> + } > >> + > > > > What if the tag read with ffa_partinfo_get_tag() has changed? > > As said this is a best effort, we provide a snapshot. > Now i could check and compare the tag at the end to handle this case. > > I will check if i can make this a bit stronger by comparing the tag at th= e > beginning and the end or try to handle it differently (get its value whil= e we > have the rwlock on the list of VMs maybe). Checking the tag at the end to let the caller retry might be enough. Cheers, Jens > > Cheers > Bertrand > > > > > Cheers, > > Jens > > > >> + out_regs[0] =3D FFA_SUCCESS_64; > >> + out_regs[2] =3D ((uint64_t)sizeof(struct ffa_partition_info_1_1) = << 48) | > >> + ((uint64_t)tag_out << 32) | > >> + ((uint64_t)(start_index + num_entries - 1) << 16) | > >> + ((uint64_t)(total_count - 1) & GENMASK(15, 0)); > >> + > >> + for ( n =3D 0; n < ARRAY_SIZE(out_regs); n++ ) > >> + set_user_reg(regs, n, out_regs[n]); > >> + > >> + return; > >> + > >> +out: > >> + if ( ret ) > >> + ffa_set_regs_error(regs, ret); > >> +} > >> + > >> static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id, > >> uint8_t msg) > >> { > >> diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_pri= vate.h > >> index 1a632983c860..c291f32b56ff 100644 > >> --- a/xen/arch/arm/tee/ffa_private.h > >> +++ b/xen/arch/arm/tee/ffa_private.h > >> @@ -289,7 +289,7 @@ > >> #define FFA_MSG_SEND2 0x84000086U > >> #define FFA_CONSOLE_LOG_32 0x8400008AU > >> #define FFA_CONSOLE_LOG_64 0xC400008AU > >> -#define FFA_PARTITION_INFO_GET_REGS 0x8400008BU > >> +#define FFA_PARTITION_INFO_GET_REGS 0xC400008BU > >> #define FFA_MSG_SEND_DIRECT_REQ2 0xC400008DU > >> #define FFA_MSG_SEND_DIRECT_RESP2 0xC400008EU > >> > >> @@ -452,6 +452,8 @@ bool ffa_partinfo_init(void); > >> int32_t ffa_partinfo_domain_init(struct domain *d); > >> bool ffa_partinfo_domain_destroy(struct domain *d); > >> void ffa_handle_partition_info_get(struct cpu_user_regs *regs); > >> +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs); > >> +void ffa_partinfo_inc_tag(void); > >> > >> int32_t ffa_endpoint_domain_lookup(uint16_t endpoint_id, struct domain= **d_out, > >> struct ffa_ctx **ctx_out); > >> -- > >> 2.52.0 > > From xen-devel-bounces@lists.xenproject.org Mon Mar 02 10:17:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 10:17:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244088.1543551 (Exim 4.92) (envelope-from ) id 1vx0LU-0002ws-D7; Mon, 02 Mar 2026 10:17:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244088.1543551; Mon, 02 Mar 2026 10:17:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx0LU-0002wl-A0; Mon, 02 Mar 2026 10:17:48 +0000 Received: by outflank-mailman (input) for mailman id 1244088; Mon, 02 Mar 2026 10:17:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx0LS-0002wd-B2 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 10:17:46 +0000 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [2607:f8b0:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0d9397df-1621-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 11:17:45 +0100 (CET) Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-7d4cb7e10efso5239468a34.0 for ; Mon, 02 Mar 2026 02:17:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0d9397df-1621-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1772446663; cv=none; d=google.com; s=arc-20240605; b=W8lZJoN7fumb+K6RhBFj3W1fsrAHBwAJYzbFj/SHjPfn9BOE7Jo3wY+wpd/Hv6G6iS gzKbvMqKT7PxEPQWFP08FbejfWJFUL7czHBjTyGBfbrybE6xZOus/irFTcFC7tGxnwHI GykVDQ7Xmnv+YN5YX6ju+SEeI9WTXIs72IAhjt7QrMULMOgP7pEy5aDZkeR+XfNqCLhg WJblEazbG3RVk2oAkzbcb3zWdCUN/6Cc9V3Kes51yRZSvbUXAdiUqX6Q+9dRtYKV2TyM GMl7wshLUn62bjEk84VoxYdyy/FN/uKvEHGu+AwdH6SF5pD+dZ8aAHmjilHCvcFk+Uqm poBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/3ZO1uASJ+Co5Rgal8hutKQ00YGgsluww0BnDoaGtWs=; fh=wB0f5JGUSpWYejuxtnrl8SDqvqyWrEsEaWvC32LbdiU=; b=CL6/LXg0QBeM4zrz9hYsJ6BZlJhQOpC5PWDceVfATUAZ6G6BAhXd/rTha1fcdzMyJT 1OcuCiIOOPgCyXpJBFYCdcAttiJQuIKUJeBO1knJTpTfjf7/kM3Pb5wI17QJn10k8LOq x48JBHcDvP9fLOm8z4/81rEc4Oo+aR90jFefYEjmxhQUIQbmdy+SjTLiAGKX3XPf7W/H IdrufOGs+dZ1ucSFMHGiFmN0rtKkgHt24O4K4Bk3dWSzP4FBaNSXVJIQCTpivBXpvnJT aT6F4V4iBuuf6I4wHWsTIjxJ/eP/2DEmglBWGtXHlk5rFlS7ShQqxyeu0bBh1EXRpaK8 Va6Q==; 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=1772446663; x=1773051463; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/3ZO1uASJ+Co5Rgal8hutKQ00YGgsluww0BnDoaGtWs=; b=SYhaTRd5yYfJ5Ffgh8aUxolekQMRwizWk9Q2ig/GkCEer46yxt4cVRHnJWFAIV8XiY 3+nz6/QBbL5ceAFzakfaJ7PoYB9skMHWrzJZhmXCTjuLW2JJg8I0ApZ6Y+fFKsPDj8U7 Ln1ZJM1GFruW5gNp2dksoVael+2LcSmSwrhsh2u2i9FqjP4Hvi/ghK+VC+kysguFfJ/S V+toeFxGnNoxBozAX2qUYXY51a9ww9CPWmDzptA2nL7rF+sTtRSq6d+ePIyvYdCB3eF6 4Fzhq+87eZbcT+p675O+uRbq6DlygjEDvo6surCN+/JD90UJChs+VvoiEmSEcd3btBqo uJmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772446663; x=1773051463; h=content-transfer-encoding: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; bh=/3ZO1uASJ+Co5Rgal8hutKQ00YGgsluww0BnDoaGtWs=; b=rXH/qo7gtgoqR7YXqU/qTS2dqKlErgK7scrmBovA6dVl8IA7PHMfu9QZYt/PEaqpC7 Ua+2xRdcfxXyxYHNjMrqPPH/xyjNLy8KkHKfTf+ZM2usCXlORjUrmLEHwuvT4ae0DKeN LVY38AcFvq083L4MxO26ojVtAqTma9PTy43tLrz4vCNCPUC7Kks/Qw2Ob25J9iIHEKna yoTnvdZ2prwfqQfLxhwFP/gwegw9DvNM0aK/PrMO7zOny2mKJ++Ut3EwSRKxanj3uPkS 9kRoFCDCuN4SoME7Sen6joW5YpL+a6LU046njlg9L5i13JXoj2//GIrAa3DtDZPx6ZKA ipTQ== X-Gm-Message-State: AOJu0YzTEVE+ywDbTBMI1SrQzOgAmCkdLAIchFjgTiqFChLfai4sZjB/ M6rd9hC1m+zDzu0lVwHLyjofnWlY0wwG1jMgW1Vepbuwy86HOpglQBYT12WXpUh+saVxFrMtBCI 6jcgBPfKbNdiiFdUjPhupmAWc8+7NeZRzufVZVmfeGg== X-Gm-Gg: ATEYQzxs+G/Iph/smhv96b6jzQM85FnXnLbgRkAN0tzFPJlDA7MjoY8S2uZZuHdDqZi OczxMDjxGhloHF734uOOkVDdOaQkiN6as1oDMnoZQcbRdOtXTsEjBjQhKVYChKCwfUdH1Mr35C+ uCgwXvGr7xyh4ajKfq/PHVraMR202jvhUTdimVicrXyuPNunhTCU5eY4AH86DLI8aQs3LQsJHUo cjy564yv32nNF3vk4zQXVdnoAyeqA6ETlTPwlt34Ebu4RGGyd4tIGY56/qw070yMSjrnD27KBWz Vsf/1m6lE4WuijIB0xNGeRW/FwYzT5A50HIrpA== X-Received: by 2002:a05:6830:3885:b0:7cf:d0f4:125c with SMTP id 46e09a7af769-7d591b39d2emr7633324a34.8.1772446663588; Mon, 02 Mar 2026 02:17:43 -0800 (PST) MIME-Version: 1.0 References: <0a5f66eaa16f262d4ffad6a8ec4b1b02461f96c1.1772013062.git.bertrand.marquis@arm.com> <9B608F0B-E564-42C6-9F85-E1701F707554@arm.com> <6A629240-E2E4-48E4-A79A-031D7258D676@arm.com> In-Reply-To: <6A629240-E2E4-48E4-A79A-031D7258D676@arm.com> From: Jens Wiklander Date: Mon, 2 Mar 2026 11:17:31 +0100 X-Gm-Features: AaiRm50zOMA5LIWMWegHhrVX_S7JC_m-Q-BKdfJNBhLq6IREC8sVwrB1NYlxYgw Message-ID: Subject: Re: [PATCH 2/4] xen/arm: ffa: Cache SP partition info at init To: Bertrand Marquis Cc: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 10:58=E2=80=AFAM Bertrand Marquis wrote: > > Hi Jens, > > > On 2 Mar 2026, at 10:32, Jens Wiklander wro= te: > > > > Hi Bertrand, > > > > On Mon, Mar 2, 2026 at 9:51=E2=80=AFAM Bertrand Marquis > > wrote: > >> > >> Hi Jens, > >> > >>> On 27 Feb 2026, at 11:39, Jens Wiklander = wrote: > >>> > >>> Hi Bertrand, > >>> > >>> On Wed, Feb 25, 2026 at 11:02=E2=80=AFAM Bertrand Marquis > >>> wrote: > >>>> > >>>> FFA_PARTITION_INFO_GET currently queries the SPMC on each call and w= alks the > >>>> RX buffer every time. The SP list is expected to be static, so repea= ted > >>>> firmware calls and validation are unnecessary. > >>>> > >>>> Cache the SPMC partition-info list at init time, keeping only secure > >>>> endpoints, and reuse the cached entries for SP count and partition-i= nfo > >>>> responses. Initialize the VM create/destroy subscriber lists from th= e cached > >>>> list and free the cache on init failure. > >>>> > >>>> SP partition info now reflects the init-time snapshot and will not c= hange. > >>>> > >>>> Signed-off-by: Bertrand Marquis > >>>> --- > >>>> xen/arch/arm/tee/ffa_partinfo.c | 205 +++++++++++++++++++++---------= -- > >>>> 1 file changed, 138 insertions(+), 67 deletions(-) > >>>> [snip] > >>>> +static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, > >>>> + uint32_t fpi_size) > >>>> +{ > >>>> + const uint8_t *src =3D buf; > >>>> + uint32_t secure_count =3D 0; > >>>> + uint32_t n, idx =3D 0; > >>>> + bool warned =3D false; > >>>> + > >>>> + if ( fpi_size < sizeof(struct ffa_partition_info_1_0) || > >>>> + fpi_size >=3D FFA_PAGE_SIZE ) > >>>> + return false; > >>> > >>> Would it make sense to check that fpi_size is well aligned with struc= t > >>> ffa_partition_info_1_0? If it's an odd size, we'll make unaligned > >>> accesses below with memcpy(). But perhaps that's a bit much. The SPMC > >>> isn't supposed to provide garbage. > >> > >> Memcpy should prevent issues even if accesses are not aligned. > >> If we had this test, we cannot return an error to the SPMC so we would= have to > >> generate one to the caller. It is simpler i think to handle non-aligne= d as we do not > >> expect the SPMC to generate such a case. > >> Tell me if you agree. > > > > We dereference fpi below, and depending on compiler flags and pointer > > types, memcpy() might not be safe with unaligned pointers. > > From 6.3.2.3 Pointers, paragraph 7, in the C standard: > > "A pointer to an object type may be converted to a pointer to a > > different object type. If the > > resulting pointer is not correctly aligned for the referenced type, > > the behavior is > > unde=EF=AC=81ned." > > > > I've seen past examples where the compiler optimized memcpy() in a way > > that breaks with unaligned pointers. > > > > We don't expect the test above to fail, but if it does we will not use > > the secure firmware. I think refusing unexpected sizes is even > > simpler. It should make finding eventual errors much easier. > > In the ffa spec, the size can grow and this is why there is a size field. > FF-A expect that we either ignore or copy without looking the extra > content. > I think we should not be dependent on any alignment so we need to > make sure we do the copy in a way that is robust to non alignments. > > > > > So my question above is whether it's worth checking that fpi_size is > > well-aligned, or if it's so unlikely that we don't need to consider > > it. > > I think we need to find a solution where we handle properly things even > if the size is not aligned. I agree, that's the most robust. > I though using memcpy would protect against > that but maybe we need to use a stronger solution to ensure that works > even if data is unaligned. memcpy() can be used, but the pointer values must not pass through a struct ffa_partition_info_1_0 pointer or such. Cheers, Jens From xen-devel-bounces@lists.xenproject.org Mon Mar 02 10:19:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 10:19:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244098.1543561 (Exim 4.92) (envelope-from ) id 1vx0NF-0003Xi-Pn; Mon, 02 Mar 2026 10:19:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244098.1543561; Mon, 02 Mar 2026 10: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 ) id 1vx0NF-0003Xb-N2; Mon, 02 Mar 2026 10:19:37 +0000 Received: by outflank-mailman (input) for mailman id 1244098; Mon, 02 Mar 2026 10:19:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx0NF-0003XV-8T for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 10:19:37 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4da1324d-1621-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 11:19:31 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48370174e18so23711335e9.2 for ; Mon, 02 Mar 2026 02:19:31 -0800 (PST) Received: from [10.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-483bd75df9fsm466930745e9.13.2026.03.02.02.19.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 02:19:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4da1324d-1621-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772446771; x=1773051571; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=BakMZ5RFd9MhIZpYeFUPwVKqIOkHWDTdjwc32yW0zaw=; b=WIct12XFJjlVdXtAAAH6S9+H6E7thOIoc9auz+DrRwAIeiXKig+zBoChTC3zwVYVnO EQ0V0Gkq6iaS3+vgL9xDOFoihrVqcggualP/p5NxAA/HkAaOm8UPqJMVuI/JYplvZnxU Lk79cI+SIdwCAbqsgVCrjJLrt4jFtzteWKcxgQffNQHC3R/CvTAoIFuBtMVPsE1hM/Vu REWVsLnP5XzCq+z+/YTwrzKRcFbUQl8AsLIfGJT4sSx20mszLDsrMFQaReVvyShaaNQ/ dYxPP8AlIpvLZ/v8cSW97DKThbZGhhrA05Gj9+rdPVaN9W0J3wfAjXbl8mdts6ZLQ5pM fa4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772446771; x=1773051571; h=content-transfer-encoding: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; bh=BakMZ5RFd9MhIZpYeFUPwVKqIOkHWDTdjwc32yW0zaw=; b=CIe4SP41lLKiv+8Enl6CsqNGhpXOh3DBKHZLI9YM5m/FHgstSf52MFMG8hyToqQjrA OYQGrW1z+iCQpvBBzpbWRlohraoAyBxp9OcTelIlhCm7podWwwPseFVM5oy/16tzZ6hD 7y4VNsQHlp11HbeEhik9HVwjhT91nGKDNxBhQMBqSVIha9AiRms437hFlM/+pn3Lnd0D 2ntrKfOMhHo6W5iKz67FrxLOw7ojfuLrT1XEJfOL1ZspA2KUa1HdwEaKozRMeNK6WZlH VoiM2VHNbhG0eZY2vUN5yLuux5mXR1vY4Mg0dRWUHPtFJaddreSuC0hWqYEpAh8T9560 N5Lg== X-Gm-Message-State: AOJu0Ywqn8FzqPVLmtF7HCOhDCWBp3QUsw0140y3tprqxZT285gYFYwL 5EZ+N8G4wOGaCfJOglQbp89YGh1xEEUFjWxaii+S6ab9Z358KxLFh0nVe3WI3+0hCw== X-Gm-Gg: ATEYQzyxXE3XE5UglvPZ7dCeo5PN48Kmny4WjDzvUPkFEcSgzL977Rqn0FwcextAU/B 0qxUMA9GJ/oEFp77lfgq593gonm0ZdBDo5HOgyJQJgcZYjwSpdpQ3EbUAqsvo5tg2X+FfsH/9hD lymwh4fu6Mlu5lfWAvPrzkB4Isk7QgKMR9Ana/1I/bTvNCmgKsTMJ5llTeFoMSKCzxXld533lXQ mg18SIfLdx1ue7hyPwswezhulDfy6Ydrvdyuppah9ukuNyxhYbppCZh5vuHvduNkQcLydqAXet7 8Cawj3wRazdDjRtiZYJ+WTKF4gmvLbBj8r+PmgM2L8MTO7zknlABazJTsMWDeSVWAYU88VaID1E Tvjy2rwEX4APxjH9j2Ae+XgbOUi2ZPwzpKLVD0MfZF6uyA/NB249Vqhr1Av4fI2DMQvoYaUgGzI l2eHf3sdUG9ec1Fic/+OdEJg5Pa+R1+N1uHW8O+gaoTvj96CZxb+G/7DhSl7ogpDWzhQ5CswJqe /b0oAbHkbmAeXw= X-Received: by 2002:a05:600c:6217:b0:476:d494:41d2 with SMTP id 5b1f17b1804b1-483c9bc5c06mr198013635e9.29.1772446771154; Mon, 02 Mar 2026 02:19:31 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 11:19:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: (auto-)ballooning issue To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Anthony PERARD , Juergen Gross , Stefano Stabellini References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.01.2026 12:14, Roger Pau Monné wrote: > On Tue, Aug 26, 2025 at 05:28:29PM +0200, Jan Beulich wrote: >> Hello, >> >> the other day I observed a strange issue with XTF's selftest failing to >> have its VMs created, when running all flavors in a group. (Other tests >> look to be similarly affected, it's just the selftest that I run most >> frequently.) Originally I suspected a PVH-specific issue, but the >> problem surfacing only there is because with PVH Dom0 I have less free >> memory left after boot than with PV Dom0. Beyond that, both >> configurations use the same hypervisor, with built-in DOM0_MEM="-255M". >> >> The issue looks to be further affected (but not caused) by domain >> cleanup being quite a bit slower under PVH Dom0, compared to PV. I.e. >> by the time the 2nd test is started, memory from the 1st one still >> wasn't completely freed. The result is that randomly one of the latter >> (batched) tests fails at domain creation ("failed to free memory for >> the domain"). >> >> xl's freemem() calls libxl_set_memory_target() followed by >> libxl_wait_for_memory_target(). The latter function expects the domain >> to balloon down enough for its ->tot_pages (in the hypervisor) to be >> at or below the previously set target. However, already immediately >> after boot "xl list -l" and "xs ls /" show target values which are 1 >> page below the hypervisor's record. With libxl_set_memory_target() >> requesting relative adjustment, the Dom0 kernel will balloon out the >> requested number of pages, but ->tot_pages going down by as many pages >> isn't enough to please libxl_wait_for_memory_target(). >> >> I'm not even close to having an opinion as to where the problem is: It >> could be that the kernel's balloon driver is off by a page. I'm more >> inclined though to think that it is entirely unrealistic to expect the >> kernel's balloon driver and Xen to have an exactly matching view of >> the memory owned by the domain. Yet then it is simply invalid to >> compare values taken from Xenstore against values taken from Xen. While >> problematic for absolute requests, for relative ones it should be >> possible apply the decrement to the source later used to compare >> against while waiting. > > Little late, sorry. I think: > > xen/balloon: improve accuracy of initial balloon target for dom0 > https://lore.kernel.org/xen-devel/20260128110510.46425-3-roger.pau@citrix.com/ > > Might improve the situation here, as it should make the dom0 initial > balloon target match what the toolstack expects, and then > (auto-)ballooning targets should also be accurate w.r.t. the memory > freed by dom0. Just to confirm (finally got around to it) - both patches together indeed eliminate the observed anomaly. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:01:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:01:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244114.1543574 (Exim 4.92) (envelope-from ) id 1vx11s-0001U4-Lu; Mon, 02 Mar 2026 11:01:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244114.1543574; Mon, 02 Mar 2026 11: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 ) id 1vx11s-0001Tx-I2; Mon, 02 Mar 2026 11:01:36 +0000 Received: by outflank-mailman (input) for mailman id 1244114; Mon, 02 Mar 2026 11:01:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx11q-0001Tr-IU for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:01:34 +0000 Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b77b212-1627-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:01:32 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id C30871400023; Mon, 2 Mar 2026 06:01:30 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Mon, 02 Mar 2026 06:01:30 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Mar 2026 06:01:29 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2b77b212-1627-11f1-b164-2bf370ae4941 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=1772449290; x=1772535690; bh=gAnUHTIVsOphxH3jyKd6jjpZxGBmcBzWVjjSXF5mb/8=; b= D12sCPCo9Jyzk/9pz+hZCOZyyy91Re0fRXsuhdPa2ghP0/IqgoW34U4z574+llbX Yj5hzl0WGL9A6aejGHFlbthF5obxHFB55HFjtCGPWpWP1onKrlDtJrC5ffg9vypP jUI5NFa1TgCgHtCAWGzzNIi5pqe8LIV9gHbLkNApnBVFkVrZ8+5SiXck7+ct1Wrm pScNRqIEy3MdwiTFLKfb6nouCroKL7e9svJPHv4XIE1xR3ZK5OoFeU1uBAlWfWIA my1tlkQT4LvhNRrqfnsYxksfd+NOY41eDiEG7O+YnztYQjpxTrbm072BGESAmV2h hs3C9LvPx/N1gmrmzd+FFg== 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=fm1; t= 1772449290; x=1772535690; bh=gAnUHTIVsOphxH3jyKd6jjpZxGBmcBzWVjj SXF5mb/8=; b=ILiMlA6p/wrbsSR+73ZIT/kTIAp8djEWaHUKYgWD0+6B2jt0vw1 70ejSC6W8UHG4Gw7bmIXYXNxeT782DcdezTRQOvasCYiWboERj4kL1A0xqBV8ODG 3mVv9BV00EMRn5LiTMoIEOpiZTmN5ltXQexW0+qevbsqZj48ulSTF+tz+JWFGijU 8KIEnQK0p29RR6S+xM8xi2F1ssz9Yhk9/oXH5DTab4K02JYUGx0pE8ep73zH1kqX lQCTjM/xQOnXyGvmrdttukzJYWPFvahTEvoSQepVU5UgD71JP6rjf9btodiAjNwA NemKJbTWN2xqVNE6QWohm7wl9F+Qd4QVB8w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheejhedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohephedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrvhhiugeskhgvrhhnvghlrdhorhhg pdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqd guvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegs ohhrihhsrdhoshhtrhhovhhskhihsehorhgrtghlvgdrtghomhdprhgtphhtthhopegrkh hpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Mar 2026 12:01:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: "David Hildenbrand (Arm)" Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) Message-ID: References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3fNdNAge+ez4rrPi" Content-Disposition: inline In-Reply-To: <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> --3fNdNAge+ez4rrPi Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2026 12:01:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: "David Hildenbrand (Arm)" Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) On Mon, Mar 02, 2026 at 09:40:29AM +0100, David Hildenbrand (Arm) wrote: > On 3/2/26 07:36, J=C3=BCrgen Gro=C3=9F wrote: > > On 01.03.26 16:04, Marek Marczykowski-G=C3=B3recki wrote: > >> Hi, > >> > >> Some time ago I made a change to disable scrubbing pages that are > >> ballooned out during system boot. I'll paste the whole commit message = as > >> it's relevant here: > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0 197ecb3802c0 xen/balloon: add runtime control= for scrubbing > >> ballooned out pages > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0 Scrubbing pages on initial balloon down can t= ake some time, > >> especially > >> =C2=A0=C2=A0=C2=A0=C2=A0 in nested virtualization case (nested EPT is = slow). When HVM/PVH > >> guest is > >> =C2=A0=C2=A0=C2=A0=C2=A0 started with memory=3D significantly lower th= an maxmem=3D, all the extra > >> =C2=A0=C2=A0=C2=A0=C2=A0 pages will be scrubbed before returning to Xe= n. But since most of > >> them > >> =C2=A0=C2=A0=C2=A0=C2=A0 weren't used at all at that point, Xen needs = to populate them first > >> =C2=A0=C2=A0=C2=A0=C2=A0 (from populate-on-demand pool). In nested vir= t case (Xen inside KVM) > >> =C2=A0=C2=A0=C2=A0=C2=A0 this slows down the guest boot by 15-30s with= just 1.5GB needed > >> to be > >> =C2=A0=C2=A0=C2=A0=C2=A0 returned to Xen. > >> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 Add runtime paramete= r to enable/disable it, to allow > >> initially disabling > >> =C2=A0=C2=A0=C2=A0=C2=A0 scrubbing, then enable it back during boot (f= or example in > >> initramfs). > >> =C2=A0=C2=A0=C2=A0=C2=A0 Such usage relies on assumption that a) most = pages ballooned out > >> during > >> =C2=A0=C2=A0=C2=A0=C2=A0 initial boot weren't used at all, and b) even= if they were, very few > >> =C2=A0=C2=A0=C2=A0=C2=A0 secrets are in the guest at that time (before= any serious userspace > >> =C2=A0=C2=A0=C2=A0=C2=A0 kicks in). > >> =C2=A0=C2=A0=C2=A0=C2=A0 Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_= SCRUB_PAGES_DEFAULT > >> (also > >> =C2=A0=C2=A0=C2=A0=C2=A0 enabled by default), controlling default valu= e for the new runtime > >> =C2=A0=C2=A0=C2=A0=C2=A0 switch. > >> > >> Now, I face the same issue with init_on_free/init_on_alloc (not sure > >> which one applies here, probably the latter one), which several > >> distributions enable by default. The result is (see timestamps): > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0 [2026-02-24 01:12:55] [=C2=A0=C2=A0=C2=A0 7.4= 85151] xen:balloon: Waiting for > >> initial ballooning down having finished. > >> =C2=A0=C2=A0=C2=A0=C2=A0 [2026-02-24 01:14:14] [=C2=A0=C2=A0 86.581510= ] xen:balloon: Initial > >> ballooning down finished. > >> > >> But here the situation is a bit more complicated: > >> init_on_free/init_on_alloc applies to any pages, not just those for > >> balloon driver. I see two approaches to solve the issue: > >> 1. Similar to xen_scrub_pages=3D, add a runtime switch for > >> =C2=A0=C2=A0=C2=A0 init_on_free/init_on_alloc, then force them off dur= ing boot, and > >> =C2=A0=C2=A0=C2=A0 re-enable early in initramfs. > >> 2. Somehow adjust balloon driver to bypass init_on_alloc when ballooni= ng > >> =C2=A0=C2=A0=C2=A0 a page out. > >> > >> The first approach is likely easier to implement, but also has some > >> drawbacks: it may result in some kernel structures that are allocated > >> early to remain with garbage data in uninitialized places. While it may > >> not matter during early boot, such structures may survive for quite so= me > >> time, and maybe attacker can use them later on to exploit some other > >> bug. This wasn't really a concern with xen_scrub_pages, as those pages > >> were immediately ballooned out. > >> > >> The second approach sounds architecturally better, and maybe > >> init_on_alloc could be always bypassed during balloon out? The balloon > >> driver can scrub the page on its own already (which is enabled by > >> default). That of course assumes the issue is only about init_on_alloc, > >> not init_on_free (or both) - which I haven't really confirmed yet... > >> If going this way, I see the balloon driver does basically > >> alloc_page(GFP_BALLOON), where GFP_BALLOON is: > >> > >> =C2=A0=C2=A0=C2=A0=C2=A0 /* When ballooning out (allocating memory to = return to Xen) we > >> don't really > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 want the kernel to try too = hard since that can trigger the oom > >> killer. */ > >> =C2=A0=C2=A0=C2=A0=C2=A0 #define GFP_BALLOON \ > >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (GFP_HIGHUSER | __GFP= _NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC) > >> > >> Would that be about adding some new flag here? Or maybe there is alrea= dy > >> one for this purpose? > >=20 > > There doesn't seem to be a flag for that. > >=20 > > But I think adding a new flag __GFP_NO_INIT and testing that in > > want_init_on_alloc() _before_ checking CONFIG_INIT_ON_ALLOC_DEFAULT_ON > > would be a sensible approach. >=20 > People argued against such flags in the past, because it will simply get > abused by arbitrary drivers that want to be smart. Could it be named differently to discourage such usage? Maybe __GFP_BALLOON_OUT ? > Whatever leaves the buddy shall be zeroed out. If there is a > double-zeroing happen, the latter could get optimized out by checking > something like user_alloc_needs_zeroing(). >=20 > See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we > avoid double-zeroing. It isn't just reducing double-zeroing to single zeroing. It's about avoiding zeroing such pages at all. If a domU is started with populate-on-demand, many (sometimes most) of its pages are populated in EPT. The idea of PoD is to start guest with high static memory size, but low actual allocation and fake it until balloon driver kicks in and make the domU really not use more pages than it has. When balloon driver try to return those pages to the hypervisor, normally it would just take unallocated page one by one and made Linux not use them. But if _any_ zeroing is happening, each page first needs to be mapped to the guest by the hypervisor (one trip through EPT), just to be removed from them a moment later... > >> Any opinions? > >=20 > > You are aware of the "init_on_alloc" boot parameter? So if this is fine > > for you, you could just use approach 1 above without any kernel patches > > needed. >=20 > I don't think init_on_alloc can be enabled after boot. IIUC, 1) would > require a runtime switch. Indeed. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --3fNdNAge+ez4rrPi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmlbgcACgkQ24/THMrX 1yxLgwf+K1N8BeW0SQO59+jFd9tMVnt8D5VFKACsD0lsn6Bzv/iR2EcZ78lOtwoa LZupAST9CXhgWxCCBRtZUN9RHmg8ZcAT/sa61SBWhk/zCSabDFvYswhooU4kjJcR yWoOpX6VNRMwnVRQCmssKYNV+JDfPCUT/YXZWsSqIkBg+VsQRBnUKJnQn44+dtTV 1vgNH8FdeMdX9l1/94Fpgj97l5mYEV/qxf+3+T4GbF+oY0KU7rSin+wvlFmLyzWa t2AtjsGJRrCdRrvC1IzKds8vYeR0MJxNCBWDvJcKREoNcLsv6gGpuH5QZKEwR1rc p+PPymMOfFFucm6OP1ArTYLpNM+hTw== =PItR -----END PGP SIGNATURE----- --3fNdNAge+ez4rrPi-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:04:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:04:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244123.1543584 (Exim 4.92) (envelope-from ) id 1vx14C-0001zg-0n; Mon, 02 Mar 2026 11:04:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244123.1543584; Mon, 02 Mar 2026 11: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 ) id 1vx14B-0001zZ-U2; Mon, 02 Mar 2026 11:03:59 +0000 Received: by outflank-mailman (input) for mailman id 1244123; Mon, 02 Mar 2026 11:03:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx14A-0001yX-J9 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:03:58 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 81dd1ba5-1627-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 12:03:56 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4834826e5a0so49519735e9.2 for ; Mon, 02 Mar 2026 03:03:56 -0800 (PST) Received: from [10.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-483bfbb465bsm291529605e9.3.2026.03.02.03.03.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:03:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 81dd1ba5-1627-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772449436; x=1773054236; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=AsZqZNlgR1am8i9fi1SsyDpNwO6zvCv9IgvoGIR0Bf8=; b=bYkTKKyMOLXMuLVz1HJT8FplfjFAz/KjcSvD8knpS/1s9hAe4RDEvkCkkEHN/ltt0R Dz2WK2PLUpvXV8t/794itLrc0XyX2/cE3oZyQ/XFYD0qwqKgIHPHpiZ6Lp9trthSUFgX +NQp7NUSL+6Y2S+XPl7rA/P2kjrmBEMfchvfRXA9Z0EahGErwNTZiE2y8cTl8cILEezG F/9JA1C1TUWQDmfpoygzHuxHCnj9v7cG50kIKl6ErZHwlzhu20h5Er4r08mlemAQP/1r 8QcVf8Szg0nacW8kgnPmFNlnuIT+oeh7um2Hz3Ey16VJnoMXZPwjvRyt+VhFzaCeqOxp sCyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772449436; x=1773054236; h=content-transfer-encoding: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; bh=AsZqZNlgR1am8i9fi1SsyDpNwO6zvCv9IgvoGIR0Bf8=; b=KThG4pKC4U5fgzVzBcabK3pYA8t8Lao24vvyWODovCca+Krl35EfJThjVaUKEY+xr1 N140U5NtZFP2r5kT/gftDEaogoOw+vctZ7GR320Rb8Sw4/OfO5InMil+1jS4+OAKtQh9 jwIO9KSb9MyoGBFEgr+hAmWwEh3FyKx2Yw9LVYf7sNQF7qqjWMsDZtwj4XbcL0UhiBD0 huCH3DEU1CPK9yTWXH+3Wrelpy8wcPH4cGel4HHUbJmWiMcrb5M5AHqoxGL2Id1cMPDa qjf4ubXJc9S5nU6vrkPgvvDUE+6Euu1W/Vps74slKYhAJsQWfch9uR8GV83YZ/dHiVKZ /qgQ== X-Forwarded-Encrypted: i=1; AJvYcCX41d8/9RO6rcWaSCIu2RII11n8bi9X6fWaqWkL+2W4vS9wOlK69g2UMppRZ8uFkXDMzqKQt/fu084=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywd10h4Jp4uy35xL5cuw6ok4o21FoHxtWNLdcbcyuI1cLjdqlH1 IzUSR9g8/g3PnbRchpzr6ZSGUguSp9ph0FvUZcxSlDN/nOtGR+jzSdeVtdSc1HjRHw== X-Gm-Gg: ATEYQzwfW6z5Q3ds+KkW1F11Ys1pXcw/HzDaPZYbme4S2OWGWbrGVS76j6Z/Xm0Xoc7 QCBhrU9z7UxXgw4HBtqqHl1rJIB0TPMr0/qBrsvqA9AIPRNjHk3Ah+359FkrSFMnsVCSfZeOl0L +ME80C9SSLkL24nDW9fq1Rw5D1TAZLUC9N2pKXMivCOzuPryBdE45d4Q11Q2dSgp+MqfF/T2ZJ8 G5myCIwIayHhsEOKqH2PiG86GoDX943bgV21bvp97YuiRq0Ki4b6+fSGJr4MgBbV5+e2oXus3b+ UEMHdx+33y5FUNAfZM+L9YZ9KI9qJBxx4XvdCJjp2EzXlABEBCxxDQJtasXXyrv8efG5jaHlXmf ME6p0VPNoMrdJCKWr7KyWC2ZZxyActFiCRDkV1oILokeKILqkHO6LXyOs01zow9wzMW9eC53WxC dgoY7aacwcUhSKkRpUSHl/Tnk1XpDv1QIIalhaIlyy5SdpGJg0b4dnDSnlO1rfBH5spnxWVLMpA c2mOF2v5WShe9BTOP5Qz/NUVQ== X-Received: by 2002:a05:600c:548a:b0:483:6e32:50d4 with SMTP id 5b1f17b1804b1-483c9bed9bbmr210520015e9.18.1772449435801; Mon, 02 Mar 2026 03:03:55 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 12:03:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/14] x86/pv: Don't assume that INT $imm8 instructions are two bytes long To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-2-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-2-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > For INT $N instructions (besides $0x80 for which there is a dedicated fast > path), handling is mostly fault-based because of DPL0 gates in the IDT. This > means that when the guest kernel allows the instruction too, Xen must > increment %rip to the end of the instruction before passing a trap to the > guest kernel. > > When an INT $N instruction has a prefix, it's longer than two bytes, and Xen > will deliver the "trap" with %rip pointing into the middle of the instruction. > > Introduce a new pv_emulate_sw_interrupt() which uses x86_insn_length() to > determine the instruction length, rather than assuming two. > > This is a change in behaviour for PV guests, but the prior behaviour cannot > reasonably be said to be intentional. > > This change does not affect the INT $0x80 fastpath. Prefixed INT $N > instructions occur almost exclusively in test code or exploits, and INT $0x80 > appears to be the only user-usable interrupt gate in contemporary PV guests. Whereas for the slow path, while the subtracting of 2 from %rip there isn't quite right either, the insn size determination here would then simply yield 2 as well, so all is good for that case as well. > @@ -1401,6 +1402,53 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs) > return 0; > } > > +/* > + * Hardware already decoded the INT $N instruction and determinted that there > + * was a DPL issue, hence the #GP. Xen has already determined that the guest > + * kernel has permitted this software interrupt. > + * > + * All that is needed is the instruction length, to turn the fault into a > + * trap. All errors are turned back into the original #GP, as that's the > + * action that really happened. > + */ > +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) > +{ > + struct vcpu *curr = current; > + struct domain *currd = curr->domain; > + struct priv_op_ctxt ctxt = { > + .ctxt.regs = regs, > + .ctxt.lma = !is_pv_32bit_domain(currd), The difference may not be overly significant here, but 64-bit guests can run 32-bit code, so setting .lma seems wrong in that case. As it ought to be largely benign, perhaps to code could even be left as is, just with a comment to clarify things? > + }; > + struct x86_emulate_state *state; > + uint8_t vector = regs->error_code >> 3; > + unsigned int len, ar; > + > + if ( !pv_emul_read_descriptor(regs->cs, curr, &ctxt.cs.base, > + &ctxt.cs.limit, &ar, 1) || > + !(ar & _SEGMENT_S) || > + !(ar & _SEGMENT_P) || > + !(ar & _SEGMENT_CODE) ) > + goto error; > + > + state = x86_decode_insn(&ctxt.ctxt, insn_fetch); > + if ( IS_ERR_OR_NULL(state) ) > + goto error; > + > + len = x86_insn_length(state, &ctxt.ctxt); > + x86_emulate_free_state(state); > + > + /* Note: Checked slightly late to simplify 'state' handling. */ > + if ( ctxt.ctxt.opcode != 0xcd /* INT $imm8 */ ) > + goto error; > + > + regs->rip += len; > + pv_inject_sw_interrupt(vector); > + return; > + > + error: > + pv_inject_hw_exception(X86_EXC_GP, regs->entry_vector); DYM regs->error_code here? Might it alternatively make sense to return a boolean here, for ... > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > @@ -1379,8 +1379,7 @@ void do_general_protection(struct cpu_user_regs *regs) > > if ( permit_softint(TI_GET_DPL(ti), v, regs) ) > { > - regs->rip += 2; > - pv_inject_sw_interrupt(vector); > + pv_emulate_sw_interrupt(regs); > return; ... the return here to become conditional, leveraging the #GP injection at the bottom of this function? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:05:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:05:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244134.1543594 (Exim 4.92) (envelope-from ) id 1vx166-0002c0-De; Mon, 02 Mar 2026 11:05:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244134.1543594; Mon, 02 Mar 2026 11:05:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx166-0002bt-Au; Mon, 02 Mar 2026 11:05:58 +0000 Received: by outflank-mailman (input) for mailman id 1244134; Mon, 02 Mar 2026 11:05:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx165-0002bn-G2 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:05:57 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c90b2bd6-1627-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:05:56 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-4398d9a12c6so3296550f8f.2 for ; Mon, 02 Mar 2026 03:05:56 -0800 (PST) Received: from [10.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-483bfb776dfsm233971295e9.1.2026.03.02.03.05.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:05:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c90b2bd6-1627-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772449555; x=1773054355; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=synUOoO4di3izuTF0VsHWZ83ix9ypOvwSIO3snD+w7c=; b=YK9Fr3UTvK3Eq+KrSo09OJA2FbW7QpIvqZZnzksIOkbpSww/t4QZa28V+xDN7z5eDx 4yIG7gyGMq1vjgZi4RzyhMaERNKHQxfgJfdSlF+CQ/Sn11yJtAMdFdd920s5w6ZNXAMy uX3vVQX4brzgwGda2PGy5p5YEKue3mGZEOdBnG15vM8TARX5roo8bQ+blhK8I5TrEv0m YoORjJ6fz1ymuO75/NkkWSP+4oAr0KuMIGKn0FQ7kkgH3GfzFxrD8cr1WSWDgMeQ03W1 HBU+6QP8yD34Da2C/W5ZDvCaEHpyiSSCyd32BCOq7CLWSixKXpU8FPu5qjK8CdvDz5EM st8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772449555; x=1773054355; h=content-transfer-encoding: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; bh=synUOoO4di3izuTF0VsHWZ83ix9ypOvwSIO3snD+w7c=; b=UPh2A0a2re3lyU6uHNa7tdnSCOZ1+9191LNOruElQo4rgIzAX6459OdcTyf/8Tbyqk ga6ycVqd8HjlPk2Zf2ZjKiPA+DenriVapd/wsRXmqICNKAYnv31a1PRva/han/Gs4Le5 RZ0NmDJT0Uu+cBJFUGo9lSCqYnyAuk+hyYmf5j78OjGT6Jx40k5f9OEE6Q4lLApA7Jdo D9ACd5evY3yYYwjxkzQRl8VcehkgOa3xFQvGiGsEVHY2fbjD2qEdwBg425cbztj3gUpG npHhTGx/z4nehUWYEutp/ifgVn9hck1XhOpr8NkNekTPPbqL6LiYN8+D1FKr2o0pD79K dH0g== X-Forwarded-Encrypted: i=1; AJvYcCVR7G5w7JGcBu/8Cza6gGiMFuT0ltIdPSa9aCQfzd1481W/DiP+15JzSKIf10SLf20aaYBwK/dPQx0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy2CCdkMcm4hsaIepgutNLPro/kibWd1nYMmsvLESEX7AiFr4v5 JEZAqepkc/LqZU40Q8d1VyEjbZpKeJX8uWANbL6jAs6rJ0M1wTxurPzOY6Pq9SQZFw== X-Gm-Gg: ATEYQzxY3IPuW0Gn8cDH8vBFwCQNgD89q0B8sQIqeFatcYStngJpgSUFMLnknMzY+fR ojSncAeHC26TOOwexT/rUy2bflWCdDK61km1HRASa4v5GDqmG5/xKDVvXiUNV+TBiT1rm6OtTip jTY/nVVKUBNYjnxLZJgWvMXcxBPnnQh89QlWc9Ri1EegrweAkEI5sY4gSz4pmtKr3akSV6RNKvG pI/64P4Fpy1QXDnO9xsWN7zZr7v+vcbbkcXCn2Er9KCAf/+TyjDxkrToRWYiB31QNvL5BGEwlyY VPVSkZ69hi9c15bHkfv7CmhEazQnc48fcSkttSW3nL2B4ozWlBzAqAnVD5cebJvO1YBJvhHMymw rkx9T2HIBHHbWJaHkrFT/TQjWJZngP/nKdyrGO4rnjjtHGwQtR/PbNh2tWRGOSVAo1mIvWQwrx/ /MhNMIWVfaC3ec5U/9BQYvc0uhQ+yMyh2XG527NHNw33uAf6CrLsGN/FQdiunD06Glc6I6NV8rX TmscqQEu/7EALI= X-Received: by 2002:a05:600c:8718:b0:480:1b1a:5526 with SMTP id 5b1f17b1804b1-483c9bde838mr208233985e9.16.1772449555158; Mon, 02 Mar 2026 03:05:55 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 12:05:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , "David Hildenbrand (Arm)" References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.03.2026 12:01, Marek Marczykowski-Górecki wrote: > On Mon, Mar 02, 2026 at 09:40:29AM +0100, David Hildenbrand (Arm) wrote: >> On 3/2/26 07:36, Jürgen Groß wrote: >>> On 01.03.26 16:04, Marek Marczykowski-Górecki wrote: >>>> Hi, >>>> >>>> Some time ago I made a change to disable scrubbing pages that are >>>> ballooned out during system boot. I'll paste the whole commit message as >>>> it's relevant here: >>>> >>>>      197ecb3802c0 xen/balloon: add runtime control for scrubbing >>>> ballooned out pages >>>> >>>>      Scrubbing pages on initial balloon down can take some time, >>>> especially >>>>      in nested virtualization case (nested EPT is slow). When HVM/PVH >>>> guest is >>>>      started with memory= significantly lower than maxmem=, all the extra >>>>      pages will be scrubbed before returning to Xen. But since most of >>>> them >>>>      weren't used at all at that point, Xen needs to populate them first >>>>      (from populate-on-demand pool). In nested virt case (Xen inside KVM) >>>>      this slows down the guest boot by 15-30s with just 1.5GB needed >>>> to be >>>>      returned to Xen. >>>>           Add runtime parameter to enable/disable it, to allow >>>> initially disabling >>>>      scrubbing, then enable it back during boot (for example in >>>> initramfs). >>>>      Such usage relies on assumption that a) most pages ballooned out >>>> during >>>>      initial boot weren't used at all, and b) even if they were, very few >>>>      secrets are in the guest at that time (before any serious userspace >>>>      kicks in). >>>>      Convert CONFIG_XEN_SCRUB_PAGES to CONFIG_XEN_SCRUB_PAGES_DEFAULT >>>> (also >>>>      enabled by default), controlling default value for the new runtime >>>>      switch. >>>> >>>> Now, I face the same issue with init_on_free/init_on_alloc (not sure >>>> which one applies here, probably the latter one), which several >>>> distributions enable by default. The result is (see timestamps): >>>> >>>>      [2026-02-24 01:12:55] [    7.485151] xen:balloon: Waiting for >>>> initial ballooning down having finished. >>>>      [2026-02-24 01:14:14] [   86.581510] xen:balloon: Initial >>>> ballooning down finished. >>>> >>>> But here the situation is a bit more complicated: >>>> init_on_free/init_on_alloc applies to any pages, not just those for >>>> balloon driver. I see two approaches to solve the issue: >>>> 1. Similar to xen_scrub_pages=, add a runtime switch for >>>>     init_on_free/init_on_alloc, then force them off during boot, and >>>>     re-enable early in initramfs. >>>> 2. Somehow adjust balloon driver to bypass init_on_alloc when ballooning >>>>     a page out. >>>> >>>> The first approach is likely easier to implement, but also has some >>>> drawbacks: it may result in some kernel structures that are allocated >>>> early to remain with garbage data in uninitialized places. While it may >>>> not matter during early boot, such structures may survive for quite some >>>> time, and maybe attacker can use them later on to exploit some other >>>> bug. This wasn't really a concern with xen_scrub_pages, as those pages >>>> were immediately ballooned out. >>>> >>>> The second approach sounds architecturally better, and maybe >>>> init_on_alloc could be always bypassed during balloon out? The balloon >>>> driver can scrub the page on its own already (which is enabled by >>>> default). That of course assumes the issue is only about init_on_alloc, >>>> not init_on_free (or both) - which I haven't really confirmed yet... >>>> If going this way, I see the balloon driver does basically >>>> alloc_page(GFP_BALLOON), where GFP_BALLOON is: >>>> >>>>      /* When ballooning out (allocating memory to return to Xen) we >>>> don't really >>>>         want the kernel to try too hard since that can trigger the oom >>>> killer. */ >>>>      #define GFP_BALLOON \ >>>>          (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC) >>>> >>>> Would that be about adding some new flag here? Or maybe there is already >>>> one for this purpose? >>> >>> There doesn't seem to be a flag for that. >>> >>> But I think adding a new flag __GFP_NO_INIT and testing that in >>> want_init_on_alloc() _before_ checking CONFIG_INIT_ON_ALLOC_DEFAULT_ON >>> would be a sensible approach. >> >> People argued against such flags in the past, because it will simply get >> abused by arbitrary drivers that want to be smart. > > Could it be named differently to discourage such usage? Maybe > __GFP_BALLOON_OUT ? > >> Whatever leaves the buddy shall be zeroed out. If there is a >> double-zeroing happen, the latter could get optimized out by checking >> something like user_alloc_needs_zeroing(). >> >> See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we >> avoid double-zeroing. > > It isn't just reducing double-zeroing to single zeroing. It's about > avoiding zeroing such pages at all. If a domU is started with > populate-on-demand, many (sometimes most) of its pages are populated in > EPT. ITYM "unpopulated in EPT"? Jan > The idea of PoD is to start guest with high static memory size, but > low actual allocation and fake it until balloon driver kicks in and make > the domU really not use more pages than it has. When balloon driver try > to return those pages to the hypervisor, normally it would just take > unallocated page one by one and made Linux not use them. But if _any_ > zeroing is happening, each page first needs to be mapped to the guest by > the hypervisor (one trip through EPT), just to be removed from them a > moment later... > >>>> Any opinions? >>> >>> You are aware of the "init_on_alloc" boot parameter? So if this is fine >>> for you, you could just use approach 1 above without any kernel patches >>> needed. >> >> I don't think init_on_alloc can be enabled after boot. IIUC, 1) would >> require a runtime switch. > > Indeed. > From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:11:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:11:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244144.1543604 (Exim 4.92) (envelope-from ) id 1vx1BT-0004K1-W4; Mon, 02 Mar 2026 11:11:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244144.1543604; Mon, 02 Mar 2026 11:11:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1BT-0004Ju-T9; Mon, 02 Mar 2026 11:11:31 +0000 Received: by outflank-mailman (input) for mailman id 1244144; Mon, 02 Mar 2026 11:11:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1BS-0004Jl-Nh for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:11:30 +0000 Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8f42d6dc-1628-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:11:29 +0100 (CET) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id E9B89EC0075; Mon, 2 Mar 2026 06:11:27 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Mon, 02 Mar 2026 06:11:27 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Mar 2026 06:11:26 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8f42d6dc-1628-11f1-b164-2bf370ae4941 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=1772449887; x=1772536287; bh=hAz78vtNmEKyYQy005oWsW/ppkghVlAM7QfBZhwbysc=; b= Z3j2U+05gRModrwbwn5SUEm7sD77bVZ2im1lmeUlbD0BMOChBdq4rRkW0jfFD3+v tqCBgZbwEJIi0w+D4ygk6/m4bPXk9E6QJKaWVEd4AZKaME0b4rRl2wLq8i4D0klM 6l71c4RWlFUCTUtXKZDFhxMwzXJ2dE2LJNLd6qufSOsdoMC+N/ncW5gMyVHbsv/V 4nTxIcTsgfRJTnMxd5rM8PBWE0BixHchema/LUdcYmnSSwsuluQ27gu/KasdvLtX j2iHCWwHNkV0iThrnLCLaVUEUm84HmohNdAtK+w2LzgLPyP6c1DZ7k/6JYojxJwl VQMcMiHdlj3tQdjwOveRFg== 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=fm1; t= 1772449887; x=1772536287; bh=hAz78vtNmEKyYQy005oWsW/ppkghVlAM7Qf BZhwbysc=; b=6KJj+AvK1TgeuAaY9kw+fJ9IVjsVn2+1biod24oci+PJMZlOhnT ucAc6iOzdwts74HmIRQGTKpBbhFNwv0+kqH3stsnOp+Rf1LiJ1qZE4u2DPloFh73 tuaIaK0YoidrkAeNdQJ1eTsRyMO4LZ9VA20dk+OHJJe+sG+ZyeGSd1FddCPOmWie HKl2037gxyIrGMzgPmWRassBQuUoUYmhHcCwqbdfDngTRjZ9fZ2VxxJq0gWm78fT 7J23HC45rYs0IjEHcl+vn06fIGPXM0PDs8SptjqAIsUPl6XqKSNpHLQxXi/8xJ5w TZGSHpGe8N0tLXoJ5iJkDzjp+O0c51kjaJA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheejhedvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepiedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho mhdprhgtphhtthhopehjghhrohhsshesshhushgvrdgtohhmpdhrtghpthhtohepgigvnh dquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohep sghorhhishdrohhsthhrohhvshhkhiesohhrrggtlhgvrdgtohhmpdhrtghpthhtoheprg hkphhmsehlihhnuhigqdhfohhunhgurghtihhonhdrohhrghdprhgtphhtthhopegurghv ihgusehkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Mar 2026 12:11:23 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , "David Hildenbrand (Arm)" Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) Message-ID: References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HjLfbADq9Cg4aQs8" Content-Disposition: inline In-Reply-To: --HjLfbADq9Cg4aQs8 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2026 12:11:23 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , "David Hildenbrand (Arm)" Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) On Mon, Mar 02, 2026 at 12:05:57PM +0100, Jan Beulich wrote: > On 02.03.2026 12:01, Marek Marczykowski-G=C3=B3recki wrote: > > It isn't just reducing double-zeroing to single zeroing. It's about > > avoiding zeroing such pages at all. If a domU is started with > > populate-on-demand, many (sometimes most) of its pages are populated in > > EPT. >=20 > ITYM "unpopulated in EPT"? Yes... --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --HjLfbADq9Cg4aQs8 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmlcFwACgkQ24/THMrX 1yzqNQf/TDwbpTaA2dHntBbwtaFb8BD+V+ciJ4Bn9CsM4jA/bjqWVqOEYDdFvW+8 ZxOxWonelMsJWD6jOAVNzjV63CXrxuKC0aQ80VBC717XO2JwvVjHcGSoEY839BxM bWOY48dSNAwG3xZT8S9H8OUgG5oc9e/UXg0nwiSugHDZaWL0mnzZyfwmQbYfxsp4 4st6ObeKWMvx8UvRI/KnN7oM1DxF1A1pUnLKrVVJEPzL/doCo7FvBFGIki0zv0vY yLepZGyLqDaA+nwDa5OnQDPJI8t4DasiIbxznhU8g0o+HKnRjzs+q9WMSzAOh6In l5rIM+BA7s/E8evluHaYs/oVgK+bsQ== =lnOg -----END PGP SIGNATURE----- --HjLfbADq9Cg4aQs8-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:18:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:18:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244154.1543614 (Exim 4.92) (envelope-from ) id 1vx1Hs-00056m-KI; Mon, 02 Mar 2026 11:18:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244154.1543614; Mon, 02 Mar 2026 11:18:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1Hs-00056f-H8; Mon, 02 Mar 2026 11:18:08 +0000 Received: by outflank-mailman (input) for mailman id 1244154; Mon, 02 Mar 2026 11:18:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1Hq-00056V-G3 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:18:06 +0000 Received: from AM0PR83CU005.outbound.protection.outlook.com (mail-westeuropeazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c201::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7b3d9aba-1629-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:18:04 +0100 (CET) Received: from AS4P190CA0039.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:5d1::12) by DBBPR08MB6171.eurprd08.prod.outlook.com (2603:10a6:10:20f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 11:18:00 +0000 Received: from AM4PEPF00027A66.eurprd04.prod.outlook.com (2603:10a6:20b:5d1:cafe::eb) by AS4P190CA0039.outlook.office365.com (2603:10a6:20b:5d1::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.21 via Frontend Transport; Mon, 2 Mar 2026 11:17:55 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by AM4PEPF00027A66.mail.protection.outlook.com (10.167.16.91) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Mon, 2 Mar 2026 11:17:59 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by AS2PR08MB9272.eurprd08.prod.outlook.com (2603:10a6:20b:59b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 11:16:47 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 11:16:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7b3d9aba-1629-11f1-b164-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=HcXeBakT3JnuY/iljMA0FC+7pjuc1UvU04zf/RVGCjOEQPpHrNYKvr8SG4PQjlq1v7tvi6AKXcI7hBCecwKEEXMuTbav9MgM32N5gRm/tSEJ/ZxN8X2KBo26WSWNoRUFJZxLHg+NhEnFxSXtUxsVCUItF/uSu3DE2+U74W3pv1e0BiudT/2Qe/cDMD7+cEa39srY7bn0bBKFlnJOzrI0odZx2fORdYEaCELAhnRjBPHsvlxHzWy5AeP+eIC6PZ5BGYxx4NT6aGB5bkkHlGUtIyU8/MGIoUgzv9ZGVMIebAhva+p3tGPmINwbOqAmj/A8PyIzPeY4vqJMnWkRKvx0Mw== 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=jbRy5X+4oLy43mMeGVkNcSr4TSLmMrjqmePb0iJ3KEo=; b=kQHS1P9ZnO9h+Bo+DblatYLDussQnf0+e/xtJ3EPVj8C9TBdbz0RagxJ6DPOevhzZK9AEXEseAvL04KLaNyu8TMP/9CAG8rj7AmeZlrLd7Q7LBJWhfw9yhpKwDSkyvEvuEzaqzQX3hf43FnEEkJoxjKiG9X4LAs2Ag611CPwfpNRavEgmlZ1XJUl0MLBJyveYIb/zPvt44FmdqcFjasMFYThIRoGcr/ZYhTwAGImOk3CNYtoMhcao8IoDZfCjkoHCvKOwxPxL9pD9eLmo18x6tEuTQB+f+g+81wZG+ziM+zRlb/O0BellYFzDhX7l48N7KTsEnoNGSoqpaehbeUmJw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=jbRy5X+4oLy43mMeGVkNcSr4TSLmMrjqmePb0iJ3KEo=; b=JayCXiuVhQpRrVhWQXT21KbLXXgLh8rVfZXAMAFYrERybatN+ey5z0UJXJgDmzyHo+TWcaFFdiTqEgAn6umiXdoCljt792Xk8kkpRTN5XdwFcEb4u6rp52yyoVN9czkU3S/MMCO02KuGTXtKo7g4VjRyZHJ6YHkQRYEaves+8eg= 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=BYeNg1CVEsbM++D2ElxafFfb5Hwb/eS5uNTqi9PnPEcjhrJanGN6w2mtjiiGa0kjVx0KkVQa9HQJWX75dG3UZ7nWjFg5FOGgVt7Ad6nLeSEHyf2f5TGFPvOI2FptK+vd6HZiU/Z8oVsMgxaPpDIZlXOubYLwZpfai/RY9PhkSlbG8zET1uuUcmff6UAb1pcJN20lZ2E2FDzFspowXabb4j59a0/ESMs5eo9ARZA4LsbZC9LwXySfWgo+wyorCBS/P9sPq/+6HCVsc20xBYlf7e28AoBvUmzSQJlcK/uI0Qj2uxkat4MMNzzyqXSoQX00jvjQ+xIFyfveDnJUDmJ5ow== 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=jbRy5X+4oLy43mMeGVkNcSr4TSLmMrjqmePb0iJ3KEo=; b=g5ApEarKm4udOMN7AUPLDGv6JF+8VK8moyRGZxzA6hW+i5LM07zqdBetu9X2u79D/2SjyMpnEh1WHUe0GL63nqULcN3vgfzeDDtT3tXhFR//BFlSI2cLLV43wTBxGfNRtzUwWOFsYi1m9tFl3gsbIoJ8ox0hig4B9cY6HoG5TlE7sSL8AP3GTrW33jJmVh7KrmnDPwMHK/Q/E+NxN/RsDWSG/XJU1TTkrURR89PhL0LA3ETxW6dCApOSmUdHc97Dd83rxbCh1iI/UR0nj+yQLzjkL4U0URPySCacyM5O/C6ZeJXWkEBxw7mKIwaucpe+48/4MkEr/TKRtzw/P6804w== 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=jbRy5X+4oLy43mMeGVkNcSr4TSLmMrjqmePb0iJ3KEo=; b=JayCXiuVhQpRrVhWQXT21KbLXXgLh8rVfZXAMAFYrERybatN+ey5z0UJXJgDmzyHo+TWcaFFdiTqEgAn6umiXdoCljt792Xk8kkpRTN5XdwFcEb4u6rp52yyoVN9czkU3S/MMCO02KuGTXtKo7g4VjRyZHJ6YHkQRYEaves+8eg= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Topic: [PATCH 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Index: AQHcpj3kq0uMG7qoMEmDaKexZXnDI7WWpiEAgARSgwCAABNogIAAE4kA Date: Mon, 2 Mar 2026 11:16:46 +0000 Message-ID: <4FDDC57C-79AA-44F5-98CF-6DD085F3D7C7@arm.com> References: <832ba950a53a7139b51053f6570fd9b26ba42df1.1772013062.git.bertrand.marquis@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|AS2PR08MB9272:EE_|AM4PEPF00027A66:EE_|DBBPR08MB6171:EE_ X-MS-Office365-Filtering-Correlation-Id: 57419717-1c9f-40e3-570f-08de784d5cec 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|38070700021; X-Microsoft-Antispam-Message-Info-Original: kQ/wYGpXK/ZxkstWuhBnUL3R/AQWp9J9u9wNiMQ8vM7QWA/vekTtAQOZ87CUThZByIGTjOVnxoYlvGb9bU7X5PVTpWrU6bwA9atPKbZlf4H3G5uiopoYryRpmu22JwKTwuVTYQ5Ade45zl+d4mpawxYRoLpDrMCwy7fq+Kyz26sSjXf1am3VcNsKjMCx3zWU2lbg0PlfEbvKZfRX5BFNNtSSM2BJ4EkvFPUmjVakwFStle4qZNhUbLqVcGSld/7z01+saR2x5jEx4CKC/Ors36/3IIVwvT2nGoA4KFwF2dscchmBjxWxWDTXspUQKiaOwslN3yHSk7qtfVZX1e4nl4ujKXwfelmyA0kfq01Cxz43SoAhc0UltHMschdy67/ZX/qCm5vBsMET9xHjcpUTs0b6HPYq0EsIbTyx5AL8MrG6DXz2rKDMZj+TAIk6sgtgThx1cJf+Tb1rKoEn1dMAorpLNbi9EyO+EoHXe8l4Yxg4nxb6LfLK6k0gxOXwrOWUOBmkenashfbk1Xe7z749zMXLifixWD1qoZ6xpV9dREQZvNc81KrD+ZSqA8i6ZbylbD5WiQxoQeRTb1mwzms5iYdtOkA/WyGc2XVYVBNtCukeGtDadlXor216dU3PBhTMzl+JyNKIgQIfvxHOqH2VBTnGEMVYpGTdVwXE/WFmdtA9PyAwwSTtSeTSWZ1OWHk0Hmon/Jg/aLzd7NLbZ6cYMvOdKJgg7Th3Fxskw2hRVfcYuyd/B3o0PZYPKQsf6swVELaf/s+5YL5HTvCl7MYWiIlbUEXqU6LUSrUkPu6ikjw= 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)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: <395F3A11FA324E4D88D99FF9C0C831C0@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9272 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 3e434d8c-3d0f-4b38-2a32-08de784d3149 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|35042699022|36860700013|376014|14060799003|7053199007; X-Microsoft-Antispam-Message-Info: J9g1aSnvFqLMQ21avAj0v01V8uPH79Txm/oU9G8WxMfs3pDMriQP15uqnWJpoVf1VhcG5LfelbWqVxVkRWKvJV2CCimymx3338Vk2wwxop26PZ0FMp8wi49v51sLJbziY7dX5w3vpxACpdc+lIr6VHL9WjTbIbujQ9z2zvOBqrc8J5UreRPXC6ELf2SuYfn1m8JPKhpD/2yN5Y67jSvpxPWFsOyOgvCXgpXKVh7Wv62mOXKq41/3wn0Sd2YaJCBMCzt6x5mBV0x5SeSBKa5UiH10z7UA9+Cg+/AHIKxmXukOagYr56j6zGG4z5geCfT0M2Dvwad/3S6Yr4+bCRZ+U1ElEZONlyR/SNEKu33YsZuCOqMZBFZXG5CikEKadad28LD2+h8cgI6pBMX6xqpBvfzrnkioDtdhKKKCSTsva5crspp3ibZu2YF1LjmYMYR6lfB80Ker47v6ML0X73pDleZePIiRUwKmWQBxgrKPfxLEPa/ibC3R6CpBnEzmpRAXT2llMf74l5FN3yGXPohH0S6xBJfXtfyJIn7cNcwJrYGdbytezhLiJgoeiWp17UfXxZQE/1oUPeJ/Qz3YqPAwxtSfH6ZOyO+rnF+slEAZOaBSzuQfcZNRrVEYKyIup3V6bNI9Yb17yT4XF20OgfKTK7T9AWlEKDRQo53tCvfaIKMPOH8bDLiBqfpvjCOXoRaFIv9N8L+4QTflQyhO2V0aWDa3fN8g4Ots6c3kNZ3hqCSDQRALe90RlKzBvk4LWbby2KdOcMhEmlU392oSfV4+hCvfmertGtg2DycGwG/QHJndr99PBU6ow6IANvCyXAiMhCau3I+ku9S7s944ZUQn5Q== 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)(82310400026)(1800799024)(35042699022)(36860700013)(376014)(14060799003)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: yz1f+12odURr9PCc6do9da+6LoSLAAWfdA449d4uLMSFuTWW/z+n/ECxvchXTec6c+ofsJ0nETiJe5KAL8nQyPlMn1MXBsJtGaOWEEte8MSOVuFhnJ4Rw59wPmEufYgioLoG/USMuCMXyyu2wH6DxlOcGU5dtwmq/lyc6G/ZUA0+hWK/IjUzPu1UZmeXviZdp3bncKmjWNS0RllMxuzP9gN5OPR4GdtaHm0OxKTmF59+g93NRv7c5BkYnO44LCFtd5o74mMj/lkbSJUTObFKrpEo1lS5XQ18A0Zezlb9yJwakv0ZjNodtKigIGdVQF/kGto3qRGepKpJYl1YC4DEkuiJTgphFzU7NbbFSlkRXqbTDVDQUranMoZ66qBCwBeSi8W7fmyCAO356MxEP/P4khSXu+4DM7TxaMchA7MejmCOWcNrfxyz5FscJBSE79rA X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 11:17:59.8912 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 57419717-1c9f-40e3-570f-08de784d5cec 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: AM4PEPF00027A66.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6171 SGkgSmVucywNCg0KPiBPbiAyIE1hciAyMDI2LCBhdCAxMTowNiwgSmVucyBXaWtsYW5kZXIgPGpl bnMud2lrbGFuZGVyQGxpbmFyby5vcmc+IHdyb3RlOg0KPiANCj4gSGkgQmVydHJhbmQsDQo+IA0K PiBPbiBNb24sIE1hciAyLCAyMDI2IGF0IDk6NTjigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+IDxC ZXJ0cmFuZC5NYXJxdWlzQGFybS5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSBKZW5zLA0KPj4gDQo+ Pj4gT24gMjcgRmViIDIwMjYsIGF0IDE1OjU2LCBKZW5zIFdpa2xhbmRlciA8amVucy53aWtsYW5k ZXJAbGluYXJvLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgQmVydHJhbmQsDQo+Pj4gDQo+Pj4g T24gV2VkLCBGZWIgMjUsIDIwMjYgYXQgMTE6MDLigK9BTSBCZXJ0cmFuZCBNYXJxdWlzDQo+Pj4g PGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBGRi1BIHYxLjIg ZGVmaW5lcyBQQVJUSVRJT05fSU5GT19HRVRfUkVHUyBmb3IgcmVnaXN0ZXItYmFzZWQgcGFydGl0 aW9uDQo+Pj4+IGluZm8gcmV0cmlldmFsLCBidXQgWGVuIGN1cnJlbnRseSBvbmx5IHN1cHBvcnRz IHRoZSBidWZmZXItYmFzZWQgR0VUDQo+Pj4+IHBhdGggZm9yIGd1ZXN0cy4NCj4+Pj4gDQo+Pj4+ IEltcGxlbWVudCBHRVRfUkVHUyB1c2luZyB0aGUgY2FjaGVkIFNQIGxpc3QgYW5kIFZNIGVudHJp ZXMsIGluY2x1ZGluZw0KPj4+PiB0aGUgcmVnaXN0ZXIgd2luZG93IGxheW91dCBhbmQgaW5wdXQg dmFsaWRhdGlvbi4gVHJhY2sgVk0gbGlzdCBjaGFuZ2VzDQo+Pj4+IHZpYSB0aGUgcGFydGluZm8g dGFnIGFuZCB1c2UgaXQgdG8gdmFsaWRhdGUgR0VUX1JFR1MgdGFnIGlucHV0cy4gRW5zdXJlDQo+ Pj4+IHRoYXQgd2hlbiBhIG5vbi1OaWwgVVVJRCBpcyBzcGVjaWZpZWQsIHRoZSBVVUlEIGZpZWxk cyBpbiBib3RoIEdFVCBhbmQNCj4+Pj4gR0VUX1JFR1MgcmVzdWx0cyBhcmUgTUJaIGFzIHJlcXVp cmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uLg0KPj4+PiANCj4+Pj4gUEFSVElUSU9OX0lORk9fR0VU X1JFR1MgaXMgYXZhaWxhYmxlIHRvIHYxLjIgZ3Vlc3RzLCByZXR1cm5pbmcgY2FjaGVkIFNQDQo+ Pj4+IGVudHJpZXMgYW5kIFZNIGVudHJpZXMgd2l0aCBVVUlEcyB6ZXJvZWQgZm9yIG5vbi1OaWwg VVVJRCBxdWVyaWVzLg0KPj4+PiANCj4+Pj4gU2lnbmVkLW9mZi1ieTogQmVydHJhbmQgTWFycXVp cyA8YmVydHJhbmQubWFycXVpc0Bhcm0uY29tPg0KPj4+PiAtLS0NCj4+Pj4geGVuL2FyY2gvYXJt L3RlZS9mZmEuYyAgICAgICAgICB8ICAxNiArKysNCj4+Pj4geGVuL2FyY2gvYXJtL3RlZS9mZmFf cGFydGluZm8uYyB8IDIxMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPj4+PiB4 ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wcml2YXRlLmggIHwgICA0ICstDQo+Pj4+IDMgZmlsZXMgY2hh bmdlZCwgMjMwIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4+Pj4gDQo+Pj4+IGRpZmYg LS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jIGIveGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0K Pj4+PiBpbmRleCBhYTQzYWUyNTk1ZDcuLmQ1NmViMjBjMjIzOSAxMDA2NDQNCj4+Pj4gLS0tIGEv eGVuL2FyY2gvYXJtL3RlZS9mZmEuYw0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5j DQo+Pj4+IEBAIC00NCw2ICs0NCwxMSBAQA0KPj4+PiAqICAgLSBkb2Vzbid0IHN1cHBvcnQgc2ln bmFsbGluZyB0aGUgc2Vjb25kYXJ5IHNjaGVkdWxlciBvZiBwZW5kaW5nDQo+Pj4+ICogICAgIG5v dGlmaWNhdGlvbiBmb3Igc2VjdXJlIHBhcnRpdGlvbnMNCj4+Pj4gKiAgIC0gZG9lc24ndCBzdXBw b3J0IG5vdGlmaWNhdGlvbnMgZm9yIFhlbiBpdHNlbGYNCj4+Pj4gKyAqIG8gRkZBX1BBUlRJVElP Tl9JTkZPX0dFVC9HRVRfUkVHUzoNCj4+Pj4gKyAqICAgLSB2MS4wIGd1ZXN0cyBtYXkgc2VlIGR1 cGxpY2F0ZSBTUCBJRHMgd2hlbiBmaXJtd2FyZSBwcm92aWRlcyBVVUlEcw0KPj4+PiArICogICAt IFNQIGxpc3QgaXMgY2FjaGVkIGF0IGluaXQ7IFNQTUMgdGFnIGNoYW5nZXMgYXJlIG5vdCB0cmFj a2VkDQo+Pj4+ICsgKiAgICAgYmV0d2VlbiBjYWxscw0KPj4+PiArICogICAtIFNQIGxpc3QgaXMg Y2FwcGVkIGF0IEZGQV9NQVhfTlVNX1NQIGVudHJpZXMNCj4+Pj4gKg0KPj4+PiAqIFRoZXJlIGFy ZSBzb21lIGxhcmdlIGxvY2tlZCBzZWN0aW9ucyB3aXRoIGZmYV9zcG1jX3R4X2xvY2sgYW5kDQo+ Pj4+ICogZmZhX3NwbWNfcnhfbG9jay4gRXNwZWNpYWxseSB0aGUgZmZhX3NwbWNfdHhfbG9jayBz cGlubG9jayB1c2VkDQo+Pj4+IEBAIC0xODgsNiArMTkzLDcgQEAgc3RhdGljIGJvb2wgZmZhX25l Z290aWF0ZV92ZXJzaW9uKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4+PiAgICAgICAg ICAgIHdyaXRlX2xvY2soJmZmYV9jdHhfbGlzdF9yd2xvY2spOw0KPj4+PiAgICAgICAgICAgIGxp c3RfYWRkX3RhaWwoJmN0eC0+Y3R4X2xpc3QsICZmZmFfY3R4X2hlYWQpOw0KPj4+PiAgICAgICAg ICAgIHdyaXRlX3VubG9jaygmZmZhX2N0eF9saXN0X3J3bG9jayk7DQo+Pj4+ICsgICAgICAgICAg ICBmZmFfcGFydGluZm9faW5jX3RhZygpOw0KPj4+PiAgICAgICAgfQ0KPj4+PiANCj4+Pj4gICAg ICAgIGdvdG8gb3V0X2NvbnRpbnVlOw0KPj4+PiBAQCAtMzQxLDYgKzM0NywxMiBAQCBzdGF0aWMg dm9pZCBoYW5kbGVfZmVhdHVyZXMoc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQo+Pj4+ICAg IGNhc2UgRkZBX0ZFQVRVUkVfU0NIRURVTEVfUkVDVl9JTlRSOg0KPj4+PiAgICAgICAgZmZhX3Nl dF9yZWdzX3N1Y2Nlc3MocmVncywgR1VFU1RfRkZBX1NDSEVEVUxFX1JFQ1ZfSU5UUl9JRCwgMCk7 DQo+Pj4+ICAgICAgICBicmVhazsNCj4+Pj4gKyAgICBjYXNlIEZGQV9QQVJUSVRJT05fSU5GT19H RVRfUkVHUzoNCj4+Pj4gKyAgICAgICAgaWYgKCBBQ0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMp ID49IEZGQV9WRVJTSU9OXzFfMiApDQo+Pj4+ICsgICAgICAgICAgICBmZmFfc2V0X3JlZ3Nfc3Vj Y2VzcyhyZWdzLCAwLCAwKTsNCj4+Pj4gKyAgICAgICAgZWxzZQ0KPj4+PiArICAgICAgICAgICAg ZmZhX3NldF9yZWdzX2Vycm9yKHJlZ3MsIEZGQV9SRVRfTk9UX1NVUFBPUlRFRCk7DQo+Pj4+ICsg ICAgICAgIGJyZWFrOw0KPj4+PiANCj4+Pj4gICAgY2FzZSBGRkFfTk9USUZJQ0FUSU9OX0JJTkQ6 DQo+Pj4+ICAgIGNhc2UgRkZBX05PVElGSUNBVElPTl9VTkJJTkQ6DQo+Pj4+IEBAIC00MDIsNiAr NDE0LDkgQEAgc3RhdGljIGJvb2wgZmZhX2hhbmRsZV9jYWxsKHN0cnVjdCBjcHVfdXNlcl9yZWdz ICpyZWdzKQ0KPj4+PiAgICBjYXNlIEZGQV9QQVJUSVRJT05fSU5GT19HRVQ6DQo+Pj4+ICAgICAg ICBmZmFfaGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldChyZWdzKTsNCj4+Pj4gICAgICAgIHJldHVy biB0cnVlOw0KPj4+PiArICAgIGNhc2UgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9SRUdTOg0KPj4+ PiArICAgICAgICBmZmFfaGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldF9yZWdzKHJlZ3MpOw0KPj4+ PiArICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+Pj4gICAgY2FzZSBGRkFfUlhfUkVMRUFTRToNCj4+ Pj4gICAgICAgIGUgPSBmZmFfcnhfcmVsZWFzZShjdHgpOw0KPj4+PiAgICAgICAgYnJlYWs7DQo+ Pj4+IEBAIC02MjksNiArNjQ0LDcgQEAgc3RhdGljIGludCBmZmFfZG9tYWluX3RlYXJkb3duKHN0 cnVjdCBkb21haW4gKmQpDQo+Pj4+ICAgICAgICB3cml0ZV9sb2NrKCZmZmFfY3R4X2xpc3Rfcnds b2NrKTsNCj4+Pj4gICAgICAgIGxpc3RfZGVsKCZjdHgtPmN0eF9saXN0KTsNCj4+Pj4gICAgICAg IHdyaXRlX3VubG9jaygmZmZhX2N0eF9saXN0X3J3bG9jayk7DQo+Pj4+ICsgICAgICAgIGZmYV9w YXJ0aW5mb19pbmNfdGFnKCk7DQo+Pj4+ICAgIH0NCj4+Pj4gDQo+Pj4+ICAgIGZmYV9yeHR4X2Rv bWFpbl9kZXN0cm95KGQpOw0KPj4+PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmFf cGFydGluZm8uYyBiL3hlbi9hcmNoL2FybS90ZWUvZmZhX3BhcnRpbmZvLmMNCj4+Pj4gaW5kZXgg ZDdmOWI5ZjcxNTNjLi4xYzdiMzU3OWY3OTggMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9hcmNoL2Fy bS90ZWUvZmZhX3BhcnRpbmZvLmMNCj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFy dGluZm8uYw0KPj4+PiBAQCAtMjgsMTAgKzI4LDM5IEBAIHN0cnVjdCBmZmFfcGFydGl0aW9uX2lu Zm9fMV8xIHsNCj4+Pj4gICAgdWludDhfdCB1dWlkWzE2XTsNCj4+Pj4gfTsNCj4+Pj4gDQo+Pj4+ ICsvKiBSZWdpc3RlcnMgYTMuLmExNyAoMTUgcmVncykgY2FycnkgcGFydGl0aW9uIGRlc2NyaXB0 b3JzLCAzIHJlZ3MgZWFjaC4gKi8NCj4+Pj4gKyNkZWZpbmUgRkZBX1BBUlRJTkZPX1JFR19NQVhf RU5UUklFUyBcDQo+Pj4+ICsgICAgKCgxNSAqIHNpemVvZih1aW50NjRfdCkpIC8gc2l6ZW9mKHN0 cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xKSkNCj4+Pj4gKw0KPj4+PiAvKiBTUCBsaXN0IGNh Y2hlIChzZWN1cmUgZW5kcG9pbnRzIG9ubHkpOyBwb3B1bGF0ZWQgYXQgaW5pdC4gKi8NCj4+Pj4g c3RhdGljIHZvaWQgKnNwX2xpc3QgX19yZWFkX21vc3RseTsNCj4+Pj4gc3RhdGljIHVpbnQzMl90 IHNwX2xpc3RfY291bnQgX19yZWFkX21vc3RseTsNCj4+Pj4gc3RhdGljIHVpbnQzMl90IHNwX2xp c3RfZW50cnlfc2l6ZSBfX3JlYWRfbW9zdGx5Ow0KPj4+PiArDQo+Pj4+ICsvKiBTUCBsaXN0IGlz IHN0YXRpYzsgdGFnIG9ubHkgbW92ZXMgd2hlbiBWTXMgYXJlIGFkZGVkL3JlbW92ZWQuICovDQo+ Pj4+ICtzdGF0aWMgYXRvbWljX3QgZmZhX3BhcnRpbmZvX3RhZyA9IEFUT01JQ19JTklUKDEpOw0K Pj4+PiArDQo+Pj4+ICt2b2lkIGZmYV9wYXJ0aW5mb19pbmNfdGFnKHZvaWQpDQo+Pj4+ICt7DQo+ Pj4+ICsgICAgYXRvbWljX2luYygmZmZhX3BhcnRpbmZvX3RhZyk7DQo+Pj4gDQo+Pj4gRG8gd2Ug bmVlZCB0byB3b3JyeSBhYm91dCB0aGlzIHZhbHVlIHdyYXBwaW5nPyBJcyB3cmFwcGluZyBwZXJt aXR0ZWQ/DQo+PiANCj4+IHdyYXBwaW5nIGlzIHBlcm1pdHRlZCwgYXMgdGhlIGVuZCB0aGlzIHZh bHVlIGlzIHVzZWQgdG8gZW5zdXJlIGNoYW5nZXMgaW4NCj4+IHRoZSBtaWRkbGUgb2YgaW5mb19n ZXRfcmVncyBhcmUgZGV0ZWN0ZWQuIEhhdmluZyBlbm91Z2ggY2hhbmdlcyBpbiB0aGUNCj4+IG1p ZGRsZSBmb3IgdGhpcyB0byB3cmFwIGFuZCBlbmQgdXAgdW4tZGV0ZWN0ZWQgYnkgdGhlIGNhbGxl ciBpcyBuZWFyIHRvIGltcG9zc2libGUuDQo+PiBJbiBhbnkgY2FzZSwgdGhlIHN0YXR1cyB3ZSBy ZXR1cm4gaXMgYSBzbmFwc2hvdCB3aGljaCBoYXZlIGNoYW5nZWQgYXMgc29vbiBhcw0KPj4gdGhl IHJlc3VsdCBpcyByZXR1cm5lZCBzbyBpIHdvdWxkIGNvbnNpZGVyIHRoaXMgYSBiZXN0IGVmZm9y dCAoZXZlbiBpZiB0aGUgcHJvYmFiaWxpdHkNCj4+IGZvciB0aGlzIHRvIGhhcHBlbiBpcyB2ZXJ5 IHZlcnkgbmVhciB0byAwKS4NCj4gDQo+IEknbSBzb3JyeSBmb3IgYmVpbmcgdW5jbGVhci4gYXRv bWljX3QgaXMgaW1wbGVtZW50ZWQgYXMgc3RydWN0IHsgaW50DQo+IGNvdW50ZXI7IH0sIHdyYXBw aW5nIHRoZSBjb3VudGVyIGVsZW1lbnQgaXMgdW5kZWZpbmVkIGJlaGF2aW91ci4gQnV0DQo+IGl0 IHdpbGwgdGFrZSBxdWl0ZSBzb21lIHRpbWUgYmVmb3JlIHdlIGdldCB0aGVyZSBhbmQgcGVyaGFw cyB0aGUNCj4gYXNzZW1ibHkgaW1wbGVtZW50YXRpb24gb2YgYXRvbWljX2luYygpIGlzIGV4cGVj dGVkIHRvIG1pdGlnYXRlIHRoZQ0KPiB1bmRlZmluZWQgYmVoYXZpb3VyIHBhcnQuDQoNCk9uIGFy bSB0aGUgYXRvbWljIG9wZXJhdGlvbnMgYXJlIGltcGxlbWVudGVkIHVzaW5nIGFuZCBhc3NlbWJs ZXIgYWRkIHdoaWNoDQppcyBub3QgdHlwZWQuDQpBdCB0aGUgZW5kIHdlIG1hc2sgdGhlIHZhbHVl IHRvIHVzZSBvbmx5IDE1IGJpdHMgc28gd2Ugd2lsbCB3cmFwIGFyb3VuZCBtb3JlIG9mdGVuDQp0 aGFuIHRoZSBjb3VudGVyIGl0c2VsZi4NClNvIGkgZG8gbm90IHRoaW5rIHdlIGhhdmUgYW4gdW5k ZWZpbmVkIGJlaGF2aW9yIGhlcmUuDQoNCj4gDQo+PiANCj4+PiANCj4+Pj4gK30NCj4+Pj4gKw0K Pj4+PiArc3RhdGljIGlubGluZSB1aW50MTZfdCBmZmFfcGFydGluZm9fZ2V0X3RhZyh2b2lkKQ0K Pj4+PiArew0KPj4+PiArICAgIC8qDQo+Pj4+ICsgICAgICogVGFnIG1vdmVzIHdpdGggVk0gbGlz dCBjaGFuZ2VzIG9ubHkuDQo+Pj4+ICsgICAgICoNCj4+Pj4gKyAgICAgKiBMaW1pdGF0aW9uOiB3 ZSBjYW5ub3QgZGV0ZWN0IGFuIFNQTUMgdGFnIGNoYW5nZSBiZXR3ZWVuIGNhbGxzIGJlY2F1c2Ug d2UNCj4+Pj4gKyAgICAgKiBkbyBub3QgcmV0YWluIHRoZSBwcmV2aW91cyBTUE1DIHRhZzsgd2Ug b25seSByZWZyZXNoIGl0IHZpYSB0aGUgbWFuZGF0b3J5DQo+Pj4+ICsgICAgICogc3RhcnRfaW5k ZXg9MCBjYWxsIGFuZCBhc3N1bWUgaXQgc3RheXMgc3RhYmxlIHdoaWxlIGNvbWJpbmVkX3RhZyAo b3VyDQo+Pj4+ICsgICAgICogVk0vU1AtY291bnQgdGFnKSBpcyB1c2VkIGZvciBndWVzdCB2YWxp ZGF0aW9uLiBUaGlzIG1lYW5zIFNQTUMgdGFnDQo+Pj4+ICsgICAgICogY2hhbmdlcyBhbG9uZSB3 aWxsIG5vdCB0cmlnZ2VyIFJFVFJZLg0KPj4+PiArICAgICAqLw0KPj4+PiArICAgIGlmICggSVNf RU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+Pj4+ICsgICAgICAgIHJldHVybiBhdG9t aWNfcmVhZCgmZmZhX3BhcnRpbmZvX3RhZykgJiBHRU5NQVNLKDE1LCAwKTsNCj4+Pj4gKyAgICBl bHNlDQo+Pj4+ICsgICAgICAgIHJldHVybiAxOw0KPj4+PiArfQ0KPj4+PiBzdGF0aWMgaW50MzJf dCBmZmFfcGFydGl0aW9uX2luZm9fZ2V0KHN0cnVjdCBmZmFfdXVpZCB1dWlkLCB1aW50MzJfdCBm bGFncywNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90 ICpjb3VudCwgdWludDMyX3QgKmZwaV9zaXplKQ0KPj4+PiB7DQo+Pj4+IEBAIC0xMjUsNiArMTU0 LDcgQEAgc3RhdGljIGludDMyX3QgZmZhX2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZhX3V1aWQg dXVpZCwgdWludDMyX3QgKnNwX2NvdW50LA0KPj4+PiAgICBmb3IgKCBuID0gMDsgbiA8IHNwX2xp c3RfY291bnQ7IG4rKyApDQo+Pj4+ICAgIHsNCj4+Pj4gICAgICAgIHZvaWQgKmVudHJ5ID0gc3Bf bGlzdCArIG4gKiBzcF9saXN0X2VudHJ5X3NpemU7DQo+Pj4+ICsgICAgICAgIHZvaWQgKmRzdF9w b3M7DQo+Pj4+IA0KPj4+PiAgICAgICAgaWYgKCAhZmZhX3NwX2VudHJ5X21hdGNoZXNfdXVpZChl bnRyeSwgdXVpZCkgKQ0KPj4+PiAgICAgICAgICAgIGNvbnRpbnVlOw0KPj4+PiBAQCAtMTM2LDEx ICsxNjYsMjAgQEAgc3RhdGljIGludDMyX3QgZmZhX2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZh X3V1aWQgdXVpZCwgdWludDMyX3QgKnNwX2NvdW50LA0KPj4+PiAgICAgICAgICogVGhpcyBpcyBh IG5vbi1jb21wbGlhbmNlIHRvIHRoZSBzcGVjaWZpY2F0aW9uIGJ1dCAxLjAgVk1zIHNob3VsZA0K Pj4+PiAgICAgICAgICogaGFuZGxlIHRoYXQgb24gdGhlaXIgb3duIHRvIHNpbXBsaWZ5IFhlbiBp bXBsZW1lbnRhdGlvbi4NCj4+Pj4gICAgICAgICAqLw0KPj4+PiArICAgICAgICBkc3RfcG9zID0g KmRzdF9idWY7DQo+Pj4+ICAgICAgICByZXQgPSBmZmFfY29weV9pbmZvKGRzdF9idWYsIGVuZF9i dWYsIGVudHJ5LCBkc3Rfc2l6ZSwNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgc3Bf bGlzdF9lbnRyeV9zaXplKTsNCj4+Pj4gICAgICAgIGlmICggcmV0ICkNCj4+Pj4gICAgICAgICAg ICByZXR1cm4gcmV0Ow0KPj4+PiANCj4+Pj4gKyAgICAgICAgaWYgKCAhZmZhX3V1aWRfaXNfbmls KHV1aWQpICYmDQo+Pj4+ICsgICAgICAgICAgICAgZHN0X3NpemUgPj0gc2l6ZW9mKHN0cnVjdCBm ZmFfcGFydGl0aW9uX2luZm9fMV8xKSApDQo+Pj4+ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAg ICAgIHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xICpmcGkgPSBkc3RfcG9zOw0KPj4+PiAr DQo+Pj4+ICsgICAgICAgICAgICBtZW1zZXQoZnBpLT51dWlkLCAwLCBzaXplb2YoZnBpLT51dWlk KSk7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gKw0KPj4+PiAgICAgICAgY291bnQrKzsNCj4+Pj4g ICAgfQ0KPj4+PiANCj4+Pj4gQEAgLTE1Miw2ICsxOTEsMzggQEAgc3RhdGljIGludDMyX3QgZmZh X2dldF9zcF9wYXJ0aW5mbyhzdHJ1Y3QgZmZhX3V1aWQgdXVpZCwgdWludDMyX3QgKnNwX2NvdW50 LA0KPj4+PiAgICByZXR1cm4gRkZBX1JFVF9PSzsNCj4+Pj4gfQ0KPj4+PiANCj4+Pj4gK3N0YXRp YyB1aW50MTZfdCBmZmFfZ2V0X3NwX3BhcnRpbmZvX3JlZ3Moc3RydWN0IGZmYV91dWlkIHV1aWQs DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNl90 IHN0YXJ0X2luZGV4LA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50NjRfdCAqb3V0X3JlZ3MsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHVpbnQxNl90IG1heF9lbnRyaWVzKQ0KPj4+PiArew0KPj4+PiArICAg IHVpbnQzMl90IGlkeCA9IDA7DQo+Pj4+ICsgICAgdWludDE2X3QgZmlsbGVkID0gMDsNCj4+Pj4g KyAgICB1aW50MzJfdCBuOw0KPj4+PiArDQo+Pj4+ICsgICAgZm9yICggbiA9IDA7IG4gPCBzcF9s aXN0X2NvdW50ICYmIGZpbGxlZCA8IG1heF9lbnRyaWVzOyBuKysgKQ0KPj4+PiArICAgIHsNCj4+ Pj4gKyAgICAgICAgdm9pZCAqZW50cnkgPSBzcF9saXN0ICsgbiAqIHNwX2xpc3RfZW50cnlfc2l6 ZTsNCj4+Pj4gKw0KPj4+PiArICAgICAgICBpZiAoICFmZmFfc3BfZW50cnlfbWF0Y2hlc191dWlk KGVudHJ5LCB1dWlkKSApDQo+Pj4+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4+Pj4gKw0KPj4+ PiArICAgICAgICBpZiAoIGlkeCsrIDwgc3RhcnRfaW5kZXggKQ0KPj4+PiArICAgICAgICAgICAg Y29udGludWU7DQo+Pj4+ICsNCj4+Pj4gKyAgICAgICAgbWVtY3B5KCZvdXRfcmVnc1tmaWxsZWQg KiAzXSwgZW50cnksDQo+Pj4+ICsgICAgICAgICAgICAgICBzaXplb2Yoc3RydWN0IGZmYV9wYXJ0 aXRpb25faW5mb18xXzEpKTsNCj4+Pj4gKyAgICAgICAgaWYgKCAhZmZhX3V1aWRfaXNfbmlsKHV1 aWQpICkNCj4+Pj4gKyAgICAgICAgew0KPj4+PiArICAgICAgICAgICAgb3V0X3JlZ3NbZmlsbGVk ICogMyArIDFdID0gMDsNCj4+Pj4gKyAgICAgICAgICAgIG91dF9yZWdzW2ZpbGxlZCAqIDMgKyAy XSA9IDA7DQo+Pj4+ICsgICAgICAgIH0NCj4+Pj4gKyAgICAgICAgZmlsbGVkKys7DQo+Pj4+ICsg ICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAgcmV0dXJuIGZpbGxlZDsNCj4+Pj4gK30NCj4+Pj4gKw0K Pj4+PiBzdGF0aWMgaW50MzJfdCBmZmFfZ2V0X3ZtX3BhcnRpbmZvKHN0cnVjdCBmZmFfdXVpZCB1 dWlkLCB1aW50MzJfdCBzdGFydF9pbmRleCwNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHVpbnQzMl90ICp2bV9jb3VudCwgdm9pZCAqKmRzdF9idWYsDQo+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2b2lkICplbmRfYnVmLCB1aW50MzJfdCBkc3Rf c2l6ZSkNCj4+Pj4gQEAgLTM2OCw2ICs0MzksMTQ2IEBAIG91dDoNCj4+Pj4gICAgfQ0KPj4+PiB9 DQo+Pj4+IA0KPj4+PiArdm9pZCBmZmFfaGFuZGxlX3BhcnRpdGlvbl9pbmZvX2dldF9yZWdzKHN0 cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4+PiArew0KPj4+PiArICAgIHN0cnVjdCBkb21h aW4gKmQgPSBjdXJyZW50LT5kb21haW47DQo+Pj4+ICsgICAgc3RydWN0IGZmYV9jdHggKmN0eCA9 IGQtPmFyY2gudGVlOw0KPj4+PiArICAgIHN0cnVjdCBmZmFfdXVpZCB1dWlkOw0KPj4+PiArICAg IHVpbnQzMl90IHNwX2NvdW50ID0gMCwgdm1fY291bnQgPSAwLCB0b3RhbF9jb3VudDsNCj4+Pj4g KyAgICB1aW50MTZfdCBzdGFydF9pbmRleCwgdGFnOw0KPj4+PiArICAgIHVpbnQxNl90IG51bV9l bnRyaWVzID0gMDsNCj4+Pj4gKyAgICB1aW50NjRfdCB4MyA9IGdldF91c2VyX3JlZyhyZWdzLCAz KTsNCj4+Pj4gKyAgICBpbnQzMl90IHJldCA9IEZGQV9SRVRfT0s7DQo+Pj4+ICsgICAgdWludDY0 X3Qgb3V0X3JlZ3NbMThdID0geyAwIH07DQo+Pj4+ICsgICAgdW5zaWduZWQgaW50IG47DQo+Pj4+ ICsgICAgdWludDE2X3QgdGFnX291dDsNCj4+Pj4gKw0KPj4+PiArICAgIGlmICggQUNDRVNTX09O Q0UoY3R4LT5ndWVzdF92ZXJzKSA8IEZGQV9WRVJTSU9OXzFfMiApDQo+Pj4+ICsgICAgew0KPj4+ PiArICAgICAgICByZXQgPSBGRkFfUkVUX05PVF9TVVBQT1JURUQ7DQo+Pj4+ICsgICAgICAgIGdv dG8gb3V0Ow0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIC8qDQo+Pj4+ICsgICAgICog UmVnaXN0ZXJzIGEzLi5hMTcgKDE1IHJlZ3MpIGNhcnJ5IHBhcnRpdGlvbiBkZXNjcmlwdG9ycywg MyByZWdzIGVhY2guDQo+Pj4+ICsgICAgICogRm9yIEZGLUEgMS4yLCB0aGF0IHlpZWxkcyBhIG1h eGltdW0gb2YgNSBlbnRyaWVzIHBlciBHRVRfUkVHUyBjYWxsLg0KPj4+PiArICAgICAqIEVuZm9y Y2UgdGhlIGFzc3VtZWQgbGF5b3V0IHNvIHdpbmRvdyBzaXppbmcgc3RheXMgY29ycmVjdC4NCj4+ Pj4gKyAgICAgKi8NCj4+Pj4gKyAgICBCVUlMRF9CVUdfT04oRkZBX1BBUlRJTkZPX1JFR19NQVhf RU5UUklFUyAhPSA1KTsNCj4+Pj4gKw0KPj4+PiArICAgIGZvciAoIG4gPSA0OyBuIDw9IDE3OyBu KysgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgaWYgKCBnZXRfdXNlcl9yZWcocmVncywg bikgKQ0KPj4+PiArICAgICAgICB7DQo+Pj4gDQo+Pj4geDQteDE3IGFyZSBTQlosIHNvIEkgdGhp bmsgd2Ugc2hvdWxkIG9ubHkgaWdub3JlIHRoZW0uDQo+PiANCj4+IEFjaywgdGhpcyB3YXMgYWRk ZWQgdG8gc2F0aXNmeSB0aGUgY29tcGxpYW5jZSBzdWl0ZSBidXQgdGhpcw0KPj4gaGFzIGJlZW4g c29sdmVkIHNpbmNlLiBJIHdpbGwgcmVtb3ZlLg0KPj4gDQo+Pj4gDQo+Pj4+ICsgICAgICAgICAg ICByZXQgPSBGRkFfUkVUX0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+Pj4gKyAgICAgICAgICAgIGdv dG8gb3V0Ow0KPj4+PiArICAgICAgICB9DQo+Pj4+ICsgICAgfQ0KPj4+PiArDQo+Pj4+ICsgICAg aWYgKCB4MyA+PiAzMiApDQo+Pj4gDQo+Pj4gU2FtZSBoZXJlOiBCaXRzWzYzOjMyXSBhcmUgU0Ja Lg0KPj4gDQo+PiBTYW1lIGhlcmUuDQo+PiANCj4+PiANCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAg ICAgIHJldCA9IEZGQV9SRVRfSU5WQUxJRF9QQVJBTUVURVJTOw0KPj4+PiArICAgICAgICBnb3Rv IG91dDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBzdGFydF9pbmRleCA9IHgzICYg R0VOTUFTSygxNSwgMCk7DQo+Pj4+ICsgICAgdGFnID0gKHgzID4+IDE2KSAmIEdFTk1BU0soMTUs IDApOw0KPj4+PiArDQo+Pj4+ICsgICAgLyogU3RhcnQgaW5kZXggbXVzdCBhbGxvdyByb29tIGZv ciB1cCB0byA1IGVudHJpZXMgd2l0aG91dCAxNi1iaXQgb3ZlcmZsb3cuICovDQo+Pj4+ICsgICAg aWYgKCBzdGFydF9pbmRleCA+IChHRU5NQVNLKDE1LCAwKSAtIChGRkFfUEFSVElORk9fUkVHX01B WF9FTlRSSUVTIC0gMSkpICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHJldCA9IEZGQV9S RVRfSU5WQUxJRF9QQVJBTUVURVJTOw0KPj4+PiArICAgICAgICBnb3RvIG91dDsNCj4+Pj4gKyAg ICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICB1dWlkLnZhbFswXSA9IGdldF91c2VyX3JlZyhyZWdzLCAx KTsNCj4+Pj4gKyAgICB1dWlkLnZhbFsxXSA9IGdldF91c2VyX3JlZyhyZWdzLCAyKTsNCj4+Pj4g Kw0KPj4+PiArICAgIGlmICggc3BfbGlzdF9jb3VudCAmJg0KPj4+PiArICAgICAgICAgc3BfbGlz dF9lbnRyeV9zaXplICE9IHNpemVvZihzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSkgKQ0K Pj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9OT1RfU1VQUE9SVEVEOw0K Pj4+IA0KPj4+IFRoaXMgY2FuJ3QgaGFwcGVuLiBCdXQgSSBndWVzcyBhIHNwX2xpc3RfZW50cnlf c2l6ZSA+IHNpemVvZihzdHJ1Y3QNCj4+PiBmZmFfcGFydGl0aW9uX2luZm9fMV8xKSBtaWdodCBi ZSBzdXBwb3J0ZWQgdG8gYmUgZnV0dXJlIHByb29mLg0KPj4gDQo+PiBSaWdodCBub3cgd2UgaGF2 ZSBGRkFfUEFSVElORk9fUkVHX01BWF9FTlRSSUVTIGVuZm9yY2luZyB0aGUNCj4+IHN0cnVjdHVy ZSB0byBiZSAxLjEgc2l6ZS4gSWYgdGhpcyBpcyBub3QgdHJ1ZSBpbiB0aGUgZnV0dXJlIHdlIHdp bGwgaGF2ZSB0byBtb2RpZnkNCj4+IHRoaXMuDQo+PiANCj4+IFRoaXMgaXMgbm90IHJlYWxseSBm dXR1cmUgcHJvb2YgYW5kIGkgd2lsbCBjaGVjayBpZiBpIGNhbiByZXdvcmsgdGhpcy4NCj4+IA0K Pj4+IA0KPj4+PiArICAgICAgICBnb3RvIG91dDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4g KyAgICB0YWdfb3V0ID0gZmZhX3BhcnRpbmZvX2dldF90YWcoKTsNCj4+Pj4gKw0KPj4+PiArICAg IGlmICggc3RhcnRfaW5kZXggPT0gMCApDQo+Pj4+ICsgICAgew0KPj4+PiArICAgICAgICBpZiAo IHRhZyApDQo+Pj4+ICsgICAgICAgIHsNCj4+Pj4gKyAgICAgICAgICAgIHJldCA9IEZGQV9SRVRf SU5WQUxJRF9QQVJBTUVURVJTOw0KPj4+PiArICAgICAgICAgICAgZ290byBvdXQ7DQo+Pj4+ICsg ICAgICAgIH0NCj4+Pj4gKyAgICB9DQo+Pj4+ICsgICAgZWxzZSBpZiAoIHRhZyAhPSB0YWdfb3V0 ICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRfUkVUUlk7DQo+Pj4+ ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiArICAgIH0NCj4+Pj4gKw0KPj4+PiArICAgIGlmICgg ZmZhX3V1aWRfaXNfbmlsKHV1aWQpICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIGlmICgg SVNfRU5BQkxFRChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+Pj4+ICsgICAgICAgICAgICB2bV9j b3VudCA9IGdldF9mZmFfdm1fY291bnQoKTsNCj4+Pj4gKyAgICAgICAgZWxzZQ0KPj4+PiArICAg ICAgICAgICAgdm1fY291bnQgPSAxOyAvKiBDYWxsZXIgVk0gb25seSAqLw0KPj4+PiArICAgIH0N Cj4+Pj4gKw0KPj4+PiArICAgIHJldCA9IGZmYV9nZXRfc3BfY291bnQodXVpZCwgJnNwX2NvdW50 KTsNCj4+Pj4gKyAgICBpZiAoIHJldCApDQo+Pj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiAr DQo+Pj4+ICsgICAgdG90YWxfY291bnQgPSBzcF9jb3VudCArIHZtX2NvdW50Ow0KPj4+PiArDQo+ Pj4+ICsgICAgaWYgKCB0b3RhbF9jb3VudCA9PSAwIHx8IHN0YXJ0X2luZGV4ID49IHRvdGFsX2Nv dW50ICkNCj4+Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRfSU5WQUxJRF9Q QVJBTUVURVJTOw0KPj4+PiArICAgICAgICBnb3RvIG91dDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsN Cj4+Pj4gKyAgICBpZiAoIHN0YXJ0X2luZGV4IDwgc3BfY291bnQgKQ0KPj4+PiArICAgICAgICBu dW1fZW50cmllcyA9IGZmYV9nZXRfc3BfcGFydGluZm9fcmVncyh1dWlkLCBzdGFydF9pbmRleCwg Jm91dF9yZWdzWzNdLA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGRkFfUEFSVElORk9fUkVHX01BWF9FTlRSSUVTKTsNCj4+Pj4gKw0KPj4+PiAr ICAgIGlmICggbnVtX2VudHJpZXMgPCBGRkFfUEFSVElORk9fUkVHX01BWF9FTlRSSUVTICkNCj4+ Pj4gKyAgICB7DQo+Pj4+ICsgICAgICAgIHVpbnQzMl90IHZtX3N0YXJ0ID0gc3RhcnRfaW5kZXgg PiBzcF9jb3VudCA/DQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnRfaW5k ZXggLSBzcF9jb3VudCA6IDA7DQo+Pj4+ICsgICAgICAgIHVpbnQzMl90IGZpbGxlZCA9IDA7DQo+ Pj4+ICsgICAgICAgIHZvaWQgKnZtX2RzdCA9ICZvdXRfcmVnc1szICsgbnVtX2VudHJpZXMgKiAz XTsNCj4+Pj4gKyAgICAgICAgdm9pZCAqdm1fZW5kID0gJm91dF9yZWdzWzE4XTsNCj4+Pj4gKw0K Pj4+PiArICAgICAgICByZXQgPSBmZmFfZ2V0X3ZtX3BhcnRpbmZvKHV1aWQsIHZtX3N0YXJ0LCAm ZmlsbGVkLCAmdm1fZHN0LCB2bV9lbmQsDQo+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc2l6ZW9mKHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xKSk7DQo+Pj4+ICsg ICAgICAgIGlmICggcmV0ICE9IEZGQV9SRVRfT0sgJiYgcmV0ICE9IEZGQV9SRVRfTk9fTUVNT1JZ ICkNCj4+Pj4gKyAgICAgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiArDQo+Pj4+ICsgICAgICAgIG51 bV9lbnRyaWVzICs9IGZpbGxlZDsNCj4+Pj4gKyAgICB9DQo+Pj4+ICsNCj4+Pj4gKyAgICBpZiAo IG51bV9lbnRyaWVzID09IDAgKQ0KPj4+PiArICAgIHsNCj4+Pj4gKyAgICAgICAgcmV0ID0gRkZB X1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7DQo+Pj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4+PiAr ICAgIH0NCj4+Pj4gKw0KPj4+IA0KPj4+IFdoYXQgaWYgdGhlIHRhZyByZWFkIHdpdGggZmZhX3Bh cnRpbmZvX2dldF90YWcoKSBoYXMgY2hhbmdlZD8NCj4+IA0KPj4gQXMgc2FpZCB0aGlzIGlzIGEg YmVzdCBlZmZvcnQsIHdlIHByb3ZpZGUgYSBzbmFwc2hvdC4NCj4+IE5vdyBpIGNvdWxkIGNoZWNr IGFuZCBjb21wYXJlIHRoZSB0YWcgYXQgdGhlIGVuZCB0byBoYW5kbGUgdGhpcyBjYXNlLg0KPj4g DQo+PiBJIHdpbGwgY2hlY2sgaWYgaSBjYW4gbWFrZSB0aGlzIGEgYml0IHN0cm9uZ2VyIGJ5IGNv bXBhcmluZyB0aGUgdGFnIGF0IHRoZQ0KPj4gYmVnaW5uaW5nIGFuZCB0aGUgZW5kIG9yIHRyeSB0 byBoYW5kbGUgaXQgZGlmZmVyZW50bHkgKGdldCBpdHMgdmFsdWUgd2hpbGUgd2UNCj4+IGhhdmUg dGhlIHJ3bG9jayBvbiB0aGUgbGlzdCBvZiBWTXMgbWF5YmUpLg0KPiANCj4gQ2hlY2tpbmcgdGhl IHRhZyBhdCB0aGUgZW5kIHRvIGxldCB0aGUgY2FsbGVyIHJldHJ5IG1pZ2h0IGJlIGVub3VnaC4N Cg0KaSB3aWxsIGdpdmUgdGhhdCBhIHRyeSBpbiB2Mi4NCg0KVGhhbmtzIGEgbG90IGZvciB0aGUg cmV2aWV3Lg0KSSB3aWxsIHRyeSB0byBwdXNoIHYyIGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB3ZWVr IGlmIG5vdCBzb29uZXIuDQoNCkNoZWVycw0KQmVydHJhbmQNCg0KPiANCj4gQ2hlZXJzLA0KPiBK ZW5zDQo+IA0KPj4gDQo+PiBDaGVlcnMNCj4+IEJlcnRyYW5kDQo+PiANCj4+PiANCj4+PiBDaGVl cnMsDQo+Pj4gSmVucw0KPj4+IA0KPj4+PiArICAgIG91dF9yZWdzWzBdID0gRkZBX1NVQ0NFU1Nf NjQ7DQo+Pj4+ICsgICAgb3V0X3JlZ3NbMl0gPSAoKHVpbnQ2NF90KXNpemVvZihzdHJ1Y3QgZmZh X3BhcnRpdGlvbl9pbmZvXzFfMSkgPDwgNDgpIHwNCj4+Pj4gKyAgICAgICAgICAgICAgICAgICgo dWludDY0X3QpdGFnX291dCA8PCAzMikgfA0KPj4+PiArICAgICAgICAgICAgICAgICAgKCh1aW50 NjRfdCkoc3RhcnRfaW5kZXggKyBudW1fZW50cmllcyAtIDEpIDw8IDE2KSB8DQo+Pj4+ICsgICAg ICAgICAgICAgICAgICAoKHVpbnQ2NF90KSh0b3RhbF9jb3VudCAtIDEpICYgR0VOTUFTSygxNSwg MCkpOw0KPj4+PiArDQo+Pj4+ICsgICAgZm9yICggbiA9IDA7IG4gPCBBUlJBWV9TSVpFKG91dF9y ZWdzKTsgbisrICkNCj4+Pj4gKyAgICAgICAgc2V0X3VzZXJfcmVnKHJlZ3MsIG4sIG91dF9yZWdz W25dKTsNCj4+Pj4gKw0KPj4+PiArICAgIHJldHVybjsNCj4+Pj4gKw0KPj4+PiArb3V0Og0KPj4+ PiArICAgIGlmICggcmV0ICkNCj4+Pj4gKyAgICAgICAgZmZhX3NldF9yZWdzX2Vycm9yKHJlZ3Ms IHJldCk7DQo+Pj4+ICt9DQo+Pj4+ICsNCj4+Pj4gc3RhdGljIGludDMyX3QgZmZhX2RpcmVjdF9y ZXFfc2VuZF92bSh1aW50MTZfdCBzcF9pZCwgdWludDE2X3Qgdm1faWQsDQo+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IG1zZykNCj4+Pj4gew0KPj4+PiBk aWZmIC0tZ2l0IGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oIGIveGVuL2FyY2gvYXJt L3RlZS9mZmFfcHJpdmF0ZS5oDQo+Pj4+IGluZGV4IDFhNjMyOTgzYzg2MC4uYzI5MWYzMmI1NmZm IDEwMDY0NA0KPj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wcml2YXRlLmgNCj4+Pj4g KysrIGIveGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oDQo+Pj4+IEBAIC0yODksNyArMjg5 LDcgQEANCj4+Pj4gI2RlZmluZSBGRkFfTVNHX1NFTkQyICAgICAgICAgICAgICAgICAgIDB4ODQw MDAwODZVDQo+Pj4+ICNkZWZpbmUgRkZBX0NPTlNPTEVfTE9HXzMyICAgICAgICAgICAgICAweDg0 MDAwMDhBVQ0KPj4+PiAjZGVmaW5lIEZGQV9DT05TT0xFX0xPR182NCAgICAgICAgICAgICAgMHhD NDAwMDA4QVUNCj4+Pj4gLSNkZWZpbmUgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9SRUdTICAgICAw eDg0MDAwMDhCVQ0KPj4+PiArI2RlZmluZSBGRkFfUEFSVElUSU9OX0lORk9fR0VUX1JFR1MgICAg IDB4QzQwMDAwOEJVDQo+Pj4+ICNkZWZpbmUgRkZBX01TR19TRU5EX0RJUkVDVF9SRVEyICAgICAg ICAweEM0MDAwMDhEVQ0KPj4+PiAjZGVmaW5lIEZGQV9NU0dfU0VORF9ESVJFQ1RfUkVTUDIgICAg ICAgMHhDNDAwMDA4RVUNCj4+Pj4gDQo+Pj4+IEBAIC00NTIsNiArNDUyLDggQEAgYm9vbCBmZmFf cGFydGluZm9faW5pdCh2b2lkKTsNCj4+Pj4gaW50MzJfdCBmZmFfcGFydGluZm9fZG9tYWluX2lu aXQoc3RydWN0IGRvbWFpbiAqZCk7DQo+Pj4+IGJvb2wgZmZhX3BhcnRpbmZvX2RvbWFpbl9kZXN0 cm95KHN0cnVjdCBkb21haW4gKmQpOw0KPj4+PiB2b2lkIGZmYV9oYW5kbGVfcGFydGl0aW9uX2lu Zm9fZ2V0KHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKTsNCj4+Pj4gK3ZvaWQgZmZhX2hhbmRs ZV9wYXJ0aXRpb25faW5mb19nZXRfcmVncyhzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncyk7DQo+ Pj4+ICt2b2lkIGZmYV9wYXJ0aW5mb19pbmNfdGFnKHZvaWQpOw0KPj4+PiANCj4+Pj4gaW50MzJf dCBmZmFfZW5kcG9pbnRfZG9tYWluX2xvb2t1cCh1aW50MTZfdCBlbmRwb2ludF9pZCwgc3RydWN0 IGRvbWFpbiAqKmRfb3V0LA0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3RydWN0IGZmYV9jdHggKipjdHhfb3V0KTsNCj4+Pj4gLS0NCj4+Pj4gMi41Mi4wDQoNCg0K From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:19:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:19:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244163.1543623 (Exim 4.92) (envelope-from ) id 1vx1It-0005dj-0F; Mon, 02 Mar 2026 11:19:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244163.1543623; Mon, 02 Mar 2026 11:19:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1Is-0005da-Td; Mon, 02 Mar 2026 11:19:10 +0000 Received: by outflank-mailman (input) for mailman id 1244163; Mon, 02 Mar 2026 11:19:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1Is-00056V-2K for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:19:10 +0000 Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a181654d-1629-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:19:09 +0100 (CET) Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.phl.internal (Postfix) with ESMTP id D07FEEC0572; Mon, 2 Mar 2026 06:19:07 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Mon, 02 Mar 2026 06:19:07 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Mar 2026 06:19:06 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a181654d-1629-11f1-b164-2bf370ae4941 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=1772450347; x=1772536747; bh=bY05i/GjZaw5/I4RKcGeiDPQv4mupjxmU/TsxnBo4pg=; b= FAViYZk7P8cQ5QKQj5oTiJqlHbUBrgabRd2dqSXJWnGT+3G6sm23c8bZBmB4FUoZ 5NJaPVUZ4lBZERUFgbS0Qw9/xhEASUEpaR2eUtOtkyrlc9BsaDU9aXN91OoLQFXU 0ZUPFM+2gEGHJ6L/YhhhieLTIEFyCw6XYmBZeCj43/D6UlpwhKsq4wDfNL6n1ugT MMWTGVkD6D4pcJRn/lJUdIvHnG83OFkmcMcPS/JtLEmUJfcrXjiU1bjbzmU+bCqE Ql7gRUiSJL/qBSL+offf65xVdDgqtyPN5X8g+AAss9gUhBhkfF4m+ao+XPTBNvYN hy46qXtzdk/EwI41jznchw== 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=fm1; t= 1772450347; x=1772536747; bh=bY05i/GjZaw5/I4RKcGeiDPQv4mupjxmU/T sxnBo4pg=; b=zROQEehHXc0vtPL8x5aYaOHzP2+SbHMvp3iLw3IvbcwvMTViksk BqRjwJgp6SXgVVqcRC1LK9LNpK8/GcbalaSXWZQeZi7J/Pg5Ge481kb7HH6k0Otb ee6lwETcmzT8tuFi9EBBr6lKE1+b4CmW0AZYUjQpZ/6ldlrVh6QNdGw5rhlWhzNG MBbmt2fHFSTBLIa7MABh1Xux7nNunTJ6/JdKb62m1IzQYPIxdCLi1bhFhZDpjcwb 4Tcf0uCwr9wV49+63wuN2Yz7FafZRl2tUSWYQgIvaFnjDidjDmOq2Z21M1OlHhXd JF296+BxBQmeKn/YVvCoyYZUurKkQFC637Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheejheefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnheptdehvedt ffeggeffgeetieevfeelvdfhjeekvdfhgfffvedvuedviedugefguedvnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpqhhusggvshdqohhsrdhorhhgnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepfedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtoh hmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtght rdhorhhgpdhrtghpthhtohepihhnthgvlhdqgigvsehlihhsthhsrdhfrhgvvgguvghskh htohhprdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Mar 2026 12:19:04 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Roger Pau =?utf-8?B?TW9ubsOp?= Cc: xen-devel , intel-xe@lists.freedesktop.org Subject: Re: Graphical glitches (not refreshing?) with Linux's xe driver + Xen 4.19 Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zu0C4HM+umfEjDpa" Content-Disposition: inline In-Reply-To: --zu0C4HM+umfEjDpa Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2026 12:19:04 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Roger Pau =?utf-8?B?TW9ubsOp?= Cc: xen-devel , intel-xe@lists.freedesktop.org Subject: Re: Graphical glitches (not refreshing?) with Linux's xe driver + Xen 4.19 On Tue, Feb 24, 2026 at 04:58:25PM +0100, Marek Marczykowski-G=C3=B3recki w= rote: > On Fri, Feb 13, 2026 at 02:23:06AM +0100, Marek Marczykowski-G=C3=B3recki= wrote: > > On Thu, Feb 12, 2026 at 04:11:50PM +0100, Roger Pau Monn=C3=A9 wrote: > > > On Tue, Feb 10, 2026 at 07:06:20PM +0100, Marek Marczykowski-G=C3=B3r= ecki wrote: > > > > Hi, > > > >=20 > > > > Recently I started testing compatibility with Intel Lunar Lake. Thi= s is > > > > the first one that uses "xe" instead of "i915" Linux driver for iGP= U. > > > > I test it with Qubes OS 4.3, which uses Xen 4.19.4 and PV dom0 runn= ing > > > > Linux 6.17.9 in this test. > > >=20 > > > Not sure it's going to help a lot, but does using a PVH dom0 make any > > > difference? > >=20 > > Ok, now with the correct Xen version, it's better with PVH dom0. At > > least on the login screen and few applications (from both dom0 and domU) > > I don't see the glitches anymore. I can't do a full test, because PCI > > passthrough doesn't seem to work with PVH dom0 on Xen 4.19 - and I need > > it to start most VMs. > >=20 > > So, if the above test is representative, it's only about PV dom0. >=20 > Some further observations: >=20 > 1. My initial impression that Xen 4.17.6 is not affected is false. > Apparently I got lucky and didn't waited long enough for glitches to > appear. Unfortunately this means I have no way to bisect this... >=20 > 1a. Updated test procedure - either: > - start Qubes OS in full (including default system domUs) and try to > open an app in one of them (for example file manager or pdf viewer) > - start Linux up to lightdm login page, log in, log out, click on a > few lightdm menus (session type selector, poewroff menu etc) >=20 > The second version works even if toolstack version in dom0 doesn't match > Xen version. If no glitches are observed after doing either of those > procedures, assume it's good. >=20 > 2. Xen staging is affected too. As well as Xen staging-4.19 without > any qubes patches. >=20 > 3. After enabling CONFIG_DEBUG in Xen, the xe.ko fails to load firmware: >=20 > xe 0000:00:02.0: [drm] Tile0: GT0: Using GuC firmware from xe/lnl_guc= _70.bin version 70.53.0 > xe 0000:00:02.0: [drm] *ERROR* Tile0: GT0: load failed: status =3D 0x= 40000056, time =3D 0ms, freq =3D 1850MHz (req 1850MHz), done =3D -1 > xe 0000:00:02.0: [drm] *ERROR* Tile0: GT0: load failed: status: Reset= =3D 0, BootROM =3D 0x2B, UKernel =3D 0x00, MIA =3D 0x00, Auth =3D 0x01 > xe 0000:00:02.0: [drm] *ERROR* Tile0: GT0: firmware production part c= heck failure > xe 0000:00:02.0: [drm] *ERROR* Tile0: GT0: Failed to initialize uC (-= EPROTO) > xe 0000:00:02.0: probe with driver xe failed with error -71 >=20 > CONFIG_DEBUG is the only change between "xe.ko loads fine but there are > glitches later on" and "xe.ko fails to load at all". Full console logs: > https://gist.github.com/marmarek/47b5e62a2cdbae6678c2aecc5283cd3f, there > are 3 files: > - CONFIG_DEBUG=3Dn > - CONFIG_DEBUG=3Dy > - CONFIG_DEBUG=3Dy + iommu=3Ddebug >=20 > 4. Updating to Linux 7.0-rc1 doesn't help, for example: > https://openqa.qubes-os.org/tests/168119#step/desktop_linux_manager_creat= e_qube/11 >=20 > Generally, it does feel like a bug in xe.ko, but I can't exclude some iss= ue > on Xen side too (especially given point 3 above). After waiting some time (Linux 6.19.5 this time), Xen CONFIG_DEBUG=3Dn, I g= et some timeout messages: [ 8.122120] xe 0000:00:02.0: [drm] [ENCODER:204:DDI A/PHY A] failed = to retrieve link info, disabling eDP [ 8.148476] xe 0000:00:02.0: [drm] Tile0: GT0: Using GuC firmware fr= om xe/lnl_guc_70.bin version 70.53.0 [ 8.803845] xe 0000:00:02.0: [drm] Tile0: GT0: ccs1 fused off [ 8.804208] xe 0000:00:02.0: [drm] Tile0: GT0: ccs2 fused off [ 8.804556] xe 0000:00:02.0: [drm] Tile0: GT0: ccs3 fused off [ 8.822426] xe 0000:00:02.0: [drm] Tile0: GT1: Using GuC firmware fr= om xe/lnl_guc_70.bin version 70.53.0 [ 8.827140] xe 0000:00:02.0: [drm] Tile0: GT1: Using HuC firmware fr= om xe/lnl_huc.bin version 9.4.13 [ 8.829478] xe 0000:00:02.0: [drm] Tile0: GT1: Using GSC firmware fr= om xe/lnl_gsc_1.bin version 104.0.5.1429 [ 8.852923] xe 0000:00:02.0: [drm] Tile0: GT1: vcs1 fused off [ 8.853513] xe 0000:00:02.0: [drm] Tile0: GT1: vcs2 fused off [ 8.854090] xe 0000:00:02.0: [drm] Tile0: GT1: vcs3 fused off [ 8.854706] xe 0000:00:02.0: [drm] Tile0: GT1: vcs4 fused off [ 8.855310] xe 0000:00:02.0: [drm] Tile0: GT1: vcs5 fused off [ 8.855904] xe 0000:00:02.0: [drm] Tile0: GT1: vcs6 fused off [ 8.856495] xe 0000:00:02.0: [drm] Tile0: GT1: vcs7 fused off [ 8.857079] xe 0000:00:02.0: [drm] Tile0: GT1: vecs1 fused off [ 8.857675] xe 0000:00:02.0: [drm] Tile0: GT1: vecs2 fused off [ 8.858272] xe 0000:00:02.0: [drm] Tile0: GT1: vecs3 fused off [ 8.975881] xe 0000:00:02.0: [drm] Registered 3 planes with drm panic [ 8.976586] [drm] Initialized xe 1.1.0 for 0000:00:02.0 on minor 0 [ 8.980882] ACPI: video: Video Device [GFX0] (multi-head: yes rom: = no post: no) [ 9.033754] xe 0000:00:02.0: [drm] Tile0: GT1: found GSC cv104.1.0 ... [ 1218.319232] xe 0000:00:02.0: [drm] Tile0: GT0: Engine reset: engine_= class=3Drcs, logical_mask: 0x1, guc_id=3D3 [ 1218.319890] xe 0000:00:02.0: [drm] Tile0: GT0: Timedout job: seqno= =3D9883, lrc_seqno=3D9883, guc_id=3D3, flags=3D0x0 in Xorg [3245] [ 1218.320736] xe 0000:00:02.0: [drm] Xe device coredump has been creat= ed [ 1218.321140] xe 0000:00:02.0: [drm] Check your /sys/class/drm/card0/d= evice/devcoredump/data [ 1222.285626] xe 0000:00:02.0: [drm] *ERROR* [CRTC:88:pipe A] flip_don= e timed out [ 1232.525685] xe 0000:00:02.0: [drm] *ERROR* flip_done timed out [ 1232.526280] xe 0000:00:02.0: [drm] *ERROR* [CRTC:88:pipe A] commit w= ait timed out [ 1242.765717] xe 0000:00:02.0: [drm] *ERROR* [CRTC:88:pipe A] flip_don= e timed out [ 1253.005696] xe 0000:00:02.0: [drm] *ERROR* flip_done timed out [ 1253.006248] xe 0000:00:02.0: [drm] *ERROR* [CRTC:88:pipe A] commit w= ait timed out [ 1263.245599] xe 0000:00:02.0: [drm] *ERROR* [CRTC:88:pipe A] flip_don= e timed out The glitches appear much earlier, though. Would content of /sys/class/drm/card0/device/devcoredump/data be useful for debugging this? Full log at https://openqa.qubes-os.org/tests/168813/file/serial0.txt (warning, almost 200MB of those errors...) --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --zu0C4HM+umfEjDpa Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmlcigACgkQ24/THMrX 1yxbnAf8CLqovdVUHy5Z9g4mb1xXRlYtk5W3BzX2l8m7XATXQU50WCZ70jFB3IVI 731vgifDlcnRiY1/bHU851bc1fHHKKq1KeqL+jmSYEVlxixO9N7Et/o1VDVJdsql wq6sWj2BByyyFvbhOxfUmIfPG/aOqJrBNxMH2QVhTnyUrnWEyX6oUI9jXiA8FX7h a836dOQOkY+zTaypRg85iXbHBjxjj7Kyj8qPFGfyFj5TRw/vgtiMfU1yzPxOo7QT /t47KCoDCwcz4g99iacx3Ly60/x18oyvebrov4KGvAHW75VVlJSG9Zob2as4GH+X wySLcUiG8BkWOu9O57PwH3xGv04dww== =pqlU -----END PGP SIGNATURE----- --zu0C4HM+umfEjDpa-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:19:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:19:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244172.1543634 (Exim 4.92) (envelope-from ) id 1vx1JX-00069X-8s; Mon, 02 Mar 2026 11:19:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244172.1543634; Mon, 02 Mar 2026 11: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 ) id 1vx1JX-00069Q-5V; Mon, 02 Mar 2026 11:19:51 +0000 Received: by outflank-mailman (input) for mailman id 1244172; Mon, 02 Mar 2026 11:19:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1JV-00056V-TD for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:19:49 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b9930178-1629-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:19:49 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-439b78b638eso830408f8f.2 for ; Mon, 02 Mar 2026 03:19:49 -0800 (PST) Received: from [10.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-439b0549600sm12199623f8f.35.2026.03.02.03.19.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:19:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b9930178-1629-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772450388; x=1773055188; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=GU9opBkaf7BDbY884PlXLT1seZFwGlMBcHTY2nf6ZP0=; b=ViJ6Ieu48uJDqEfzAagSZW1AJK3GjBK/ivleYWHHSv/G5skdxquc8ZS0tAJW3LVlNK a0hffAz4pGlgGnduU7f/3jVjICeOCb6iqQlryMCcqg3NI3IQrmC645ZrCxNxCqFiZ7Ca MSLUBtfbq36UyfJ9FRdOKLIkDKva2CaRX0hMGrFAoXHWOq7CCLIVlNaLdesdamrrXsm8 gOf6Q4ZXrUTqDn4buIKfP0ynHpvx/DtLoD+ubnJMp9ajM+pd3QP0kE+FFikiNdhUc/dN 3U8lZjfBDWtZJXgrVhPDGbs+XOmlSTix1JFRr4v4mhxJ4wOQ3G7toQ0n/3xMhn8zwMiX I/HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772450388; x=1773055188; h=content-transfer-encoding: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; bh=GU9opBkaf7BDbY884PlXLT1seZFwGlMBcHTY2nf6ZP0=; b=Fhl46YiIbmAJcC7eFzD3T+8V0S9tBFZ6oh+6yuDh5m60oOU9UVb0URultPSuXyXSxu bty8globTDMefi0mGj8sfKkUAg1rLdTxd/aLzkbLgD5ARwENHRPzJ3Jf5+ufxNssmpRA PiaYGgc5mkP2KlYeDKFzz2qwZ4PuM+2Kka/z5LuDSRtlsFhv6QGMq4x//LIvbSzopxz5 jIEKqDqI/QEQE5RcVoa726bGpXlEilnsYO6sSsg3vOjMaFaM/cT68JIutllpIBRv/ysN aNAVBKHgCC3hwN55vYNbj4eTGFWUOFlaHG/vfXpbIqLe98nd3CFIFjoJIvkFuieXiZHi 3m7w== X-Forwarded-Encrypted: i=1; AJvYcCWYMUrMCESVwRXEZCkcrM/tpwij/oHRAcUYXBumUu26n+FgxU6KudjulFT2f+5b7URvODq3rzgWwOg=@lists.xenproject.org X-Gm-Message-State: AOJu0YykayCwSfYBo0j2XBzEP/VXHRymLu+1o1nm+Xa4kCTrppi8tIdL cliqCS+34gzxCMX7D6xq0Q10/JjqmsDLlAZ2of3n/o9OAmAHewTALiGTAZe+JEAcSA== X-Gm-Gg: ATEYQzynzCUND3LsAOUxJM4WaAeIQ8PEXNMrC+4RlUd3cwGimsZEvq7xVjaStCGdjCL ALFGGTtK/MUpm5xrSr8SsO6wCvwFF1GbRJWGFOwfLFT9Vqs8U8uGbLeONM9CNkUG3eGRuji54JX 25QlW15vYfyjGYTMMV0KZ0zEoq8V5vnWhJpUfzmwEMDrN6sIAIiVLoegkSO0nw31MpTNRxmZ9MC su/NFJoujNkA4qgbu5MLJDZpH0Qq1n6VnXZwwQoce5ZwV3EPhLUv+3+w4C0Yc7DaGZTLAQZX3r0 BCvnmLeKqXgfW1gKPTyf/EtFgMoAh0WguWHQR2Il5s8F+ApE8hv3V0ou8m5xPXAuimDUzOOB/IN HL3mFCTXgRzYCojau77qwiJMJSLAer8HL4jrK0A1ZJvTthW3Z+HuPWAbSmrdYQSFF2sLR7PCMW1 AIrkGnZWvqqMuiBr7GbX7D30tajT2nK3zAl4URub5IfxkR12VU7jS5GyYEQxyBlwwlFG1lhJTA8 m0ICewPCFQ+4k4= X-Received: by 2002:a5d:588c:0:b0:439:b60a:b403 with SMTP id ffacd0b85a97d-439b60ab61emr6796477f8f.34.1772450388099; Mon, 02 Mar 2026 03:19:48 -0800 (PST) Message-ID: <4052793e-094d-449b-af97-e2d068836366@suse.com> Date: Mon, 2 Mar 2026 12:19:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/14] docs/guest-guide: Describe the PV traps and entrypoints ABI To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-3-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > ... seeing as I've had to thoroughly reverse engineer it for FRED and make > tweaks in places. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich > --- /dev/null > +++ b/docs/guest-guide/x86/pv-traps.rst > @@ -0,0 +1,123 @@ > +.. SPDX-License-Identifier: CC-BY-4.0 > + > +PV Traps and Entrypoints > +======================== > + > +.. note:: > + > + The details here are specific to 64bit builds of Xen. Details for 32bit > + builds of Xen, are different and not discussed further. Nit: Stray comma? > +PV guests are subject to Xen's linkage setup for events (interrupts, > +exceptions and system calls). x86's IDT architecture and limitations are the > +majority influence on the PV ABI. > + > +All external interrupts are routed to PV guests via the :term:`Event Channel` > +interface, and not discussed further here. > + > +What remain are exceptions, and the instructions which cause a control > +transfers. In the x86 architecture, the instructions relevant for PV guests > +are: > + > + * ``INT3``, which generates ``#BP``. > + > + * ``INTO``, which generates ``#OF`` only if the overflow flag is set. It is > + only usable in compatibility mode, and will ``#UD`` in 64bit mode. > + > + * ``CALL (far)`` referencing a gate in the GDT. > + > + * ``INT $N``, which invokes an arbitrary IDT gate. These four instructions > + so far all check the gate DPL and will ``#GP`` otherwise. > + > + * ``INT1``, also known as ``ICEBP``, which generates ``#DB``. This > + instruction does *not* check DPL, and can be used unconditionally by > + userspace. > + > + * ``SYSCALL``, which enters CPL0 as configured by the ``{C,L,}STAR`` MSRs. > + It is usable if enabled by ``MSR_EFER.SCE``, and will ``#UD`` otherwise. > + On Intel parts, ``SYSCALL`` is unusable outside of 64bit mode. > + > + * ``SYSENTER``, which enters CPL0 as configured by the ``SEP`` MSRs. It is > + usable if enabled by ``MSR_SYSENTER_CS`` having a non-NUL selector, and > + will ``#GP`` otherwise. On AMD parts, ``SYSENTER`` is unusable in Long > + mode. The UD family of insns is kind of a hybrid: They explicitly generate #UD, and hence do a control transfer. Same for at least BOUND. It's not quite clear whether they should be enumerated here as well. > +Xen's configuration > +------------------- > + > +Xen maintains a complete IDT, with most gates configured with DPL0. This > +causes most ``INT $N`` instructions to ``#GP``. This allows Xen to emulate > +the instruction, referring to the guest kernels vDPL choice. > + > + * Vectors 3 ``#BP`` and 4 ``#OF`` are DPL3, in order to allow the ``INT3`` > + and ``INTO`` instructions to function in userspace. > + > + * Vector 0x80 is DPL3 in order to implement the legacy system call fastpath > + commonly found in UNIXes. Much like we make this DPL0 when PV=n, should we perhaps make vectors 3 and 4 DPL0 as well in that case (just for formality's sake)? Maybe 4, like 9, would even want to be an autogen entry point then? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:33:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:33:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244190.1543647 (Exim 4.92) (envelope-from ) id 1vx1Wg-0000oY-E7; Mon, 02 Mar 2026 11:33:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244190.1543647; Mon, 02 Mar 2026 11:33:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1Wg-0000oR-Af; Mon, 02 Mar 2026 11:33:26 +0000 Received: by outflank-mailman (input) for mailman id 1244190; Mon, 02 Mar 2026 11:33:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1We-0000oL-Md for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:33:24 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9f0ea1fb-162b-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:33:23 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4836e3288cdso29871385e9.0 for ; Mon, 02 Mar 2026 03:33:23 -0800 (PST) Received: from [10.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-483c3b4a121sm274266195e9.8.2026.03.02.03.33.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:33:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f0ea1fb-162b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772451203; x=1773056003; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=aqoJzViB893XGgdMEvONv6B6m5eJ+Ze2n/2VeDTpwkc=; b=Ub3P1ExU3YLDRBUzbZOoTKEPER+hntdjEceP22IAydNwwxD49R+KZ+N8XwIX/lg1we bmZT4fjl+5td5+bfLVmf9goz1Mm0NsCANRHbJnApFOpDWbfAejFNeqi+0xxkOpO4U9nR 2m4RQicc+00bx8xI/c2Rg93q7tdb0T0Y2/UGRVRGXipfDMylZ7LuzZGVYyuhGo8HVzum koH/pV7OP7lHsy7rQgpj/czkF2bdOYj/9MmCbw2rMP36KKBCQoXXhp7FUtSu0HLXlAdM 7yGGO2redKVUJ+mKVN/npuGAT/LF1vitFAeYIC4A8qQYFZVvrSxzpgq7k2VSM9sYTQbB GPdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772451203; x=1773056003; h=content-transfer-encoding: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; bh=aqoJzViB893XGgdMEvONv6B6m5eJ+Ze2n/2VeDTpwkc=; b=QER9yZyNe6QSb8csfJjnVdRao8TKEPSDgXHRtoFzI/zvu6GDhOUZCgEHiKbw1QEfaw UswbjvzORKGHDvPmE7LnX1VZ6RiUwRtxjuM96tGyExPkVO0A3AKsZlxhJxbuf97k3trB j8+2X7tvRVm2XVXgZ1TSOqmq96X0Tdwt5Roz0sRyLlnm6et3dvIbDqVtSxirgKQpuQF3 d9uD3t1cf84/BRJnGa7tPqXIUw2wdvCDKpX/FX91yI8jGpOBI1+gU41y2SQmvjbmKmhL /ikhfyFQXupfH452FaV1D1pnYLKfwg7dt7bl1vPjHJsw4anyvIIbtQJrg7lDZetGCLF3 Tf5Q== X-Forwarded-Encrypted: i=1; AJvYcCVqQOE0Dl8aFIgVr4LfdU+kBaGkb8ePueAnWVns2/WkRRzoDkeGPzOCzUIKIOumQn1TsdX8jY+A6qU=@lists.xenproject.org X-Gm-Message-State: AOJu0YzNiiXeg9sSG3FOqfKq+0zmy99Uf3zKZR43Yhkkf9xO0DkCDBqX 5rM3WiHU4M5vB4a5BHiOEF6HuKSIBfTTsQZbR9aO+Ie2k2kwG4aUNpw4X9cYONM31w== X-Gm-Gg: ATEYQzzW/pDOUzFQvH/ttKbOojSgoJQSkizrmHM8KxyLLZirqwmhEzikcTRLrvzmydI u8BTO1ObJ8mQqp3xjf9nODvR2Tyu261lNiZt3fSIpiw0bMQAnkGSKLEyib1v45DKcRpbdDdMmXG r4Y80hG1IGlwrjrBxdHQwOCiuD2Ksf+UkZ6FvdwlRj5MWM7M19C0GosSIC+6J/+cKTkGoWHa+PM M9CcN2KcWRUEUv+QObvjlMKRcYnpHLukV990wucJjKsDbEsHMObaZ/uKa536P7Rr/bqJT/XZLNE 9AMTGJZYGtnxJlNpuaBerfnTGwlNT8aQbwp/u/ZqbtsOnlnQtfYE4DJf+U4l9txFUWgfPkSbPNM xd0DacFdFuagH39fcZBdqmm0sRBovozQEZeAq9rfSCnlkqw5YAxo3ik8AD74uu4lFshe9sZqstM 2O6xLMeWrIe9T+YKwL2muN1bPq5f6AkeKEAVy1wg4kxpgbXD3C3nZgTWNOG6GzvGjJ6tvZaqia2 nXwoZhiepaV2sM= X-Received: by 2002:a05:600c:8509:b0:483:6d9e:e4f5 with SMTP id 5b1f17b1804b1-483c990bddfmr215547965e9.5.1772451202745; Mon, 02 Mar 2026 03:33:22 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 12:33:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 03/14] x86/boot: Move gdt_l1e caching out of traps_init() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-4-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > Commit 564d261687c0 ("x86/ctxt-switch: Document and improve GDT handling") put > the initialisation of {,compat_}gdt_l1e into traps_init() but this wasn't a > great choice. Instead, put it in smp_prepare_cpus() which performs the BSP > preparation of variables normally set up by cpu_smpboot_alloc() for APs. > > This removes an implicit dependency that prevents traps_init() moving earlier > than move_xen() in the boot sequence. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > I'm on the fence about the ASSERT(), but I'm getting rather tired of unstated > dependencies. For a PV64 guest using SYSEXIT to enter the guest, it's the > first interrupt/exception which references the GDT, which could be after the > guest is running. I think that's okay to have there. "Unstated dependencies" is of course a wide field, and going too far with assertions is also a risk. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:35:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:35:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244198.1543656 (Exim 4.92) (envelope-from ) id 1vx1Ya-0001LW-ON; Mon, 02 Mar 2026 11:35:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244198.1543656; Mon, 02 Mar 2026 11: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 ) id 1vx1Ya-0001LP-Ln; Mon, 02 Mar 2026 11:35:24 +0000 Received: by outflank-mailman (input) for mailman id 1244198; Mon, 02 Mar 2026 11:35:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1YZ-0001LH-PT for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:35:23 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e614f806-162b-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:35:22 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-439b6d9c981so618980f8f.1 for ; Mon, 02 Mar 2026 03:35:22 -0800 (PST) Received: from [10.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-4399c75a523sm26519437f8f.19.2026.03.02.03.35.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:35:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e614f806-162b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772451322; x=1773056122; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=WJyBeGqzIMoxG7CgU0XCO3cXTmKg85QI+6wcIlFdMno=; b=MLgvt1pB/4Z6oENcuLNw/dE7XK00txv+LKUj5jmX5bTvoWKKl+qVWQlEinegov32gr l6VCSYKx5v6giV+OFwRdWLlih954vqs659U91XLHkFEbVAO0rp5uD2vzn7nXjVE8O1pJ OBxNm1oz32AA/s8tVMzMVBEesgKkh5Sji81OhtEbMkqo7Ibd5lmJpTsW2+Qw3z/2xIHr 2J7KRXwPe73Qgq6wWOIAs7Z0M5TLzNZKqm3M0solLoTpFbjCUfhV3KJg7WVhGEliTqyN Asgi8YemWeFUn9R8geOm4OQmL+J66fXohC7u1JytKsIRdIg1+frNt6JYgyIvQn0Ruish XVYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772451322; x=1773056122; h=content-transfer-encoding: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; bh=WJyBeGqzIMoxG7CgU0XCO3cXTmKg85QI+6wcIlFdMno=; b=rjhsKBG9NiaJZRj4dPnlsjmTmGLGaT6ttNQnV6I+HXFpUoGt8cVE2rCjdgS2k+6bIN ox+xRoOV6ZMgs5hQj3C9ccqzbSF3rka2l3QGUIzXt3MCoFGfPwQmEf2ebNzxlxjDWSli HVXe46lvT3YqK6m3FNWaZWqn6mN1Pc0hcP+5B/w0ntZp4m2PtDKHGO+aymCSseP2s0D5 TdWTqfkJNKNFK/k0BKuFMqX/KHyOXncO+CPl9ntK5F1zdMBVrsH0t/n0+62v+Xayo+5e L4Vxx+rqOrWVr8fJseLF7+dG0QXmpsbKYxV9huDxuyIPxbS1nGFP5jqfHAruRFK7ObtG sgMg== X-Forwarded-Encrypted: i=1; AJvYcCWHpgmmDK/pgg55HiPAoTga1f32NFBaeHtf0HtJXoQIS3zAvnsSB/RYGDNU1zXjt3wVf0ww2OCPN8k=@lists.xenproject.org X-Gm-Message-State: AOJu0YwRGIPGZJ/NGXKowiwTug4JESjTLUzJtlv3iVWpbWLGu8BQZoVf DaBJU8P2/YDeUlxBbE/QiVnTjmupEdQkPsZ6GRAN0iwtPlOktqHFAOOzPxLh2/A53OB3acW3z2a KVnI= X-Gm-Gg: ATEYQzz602DVUf+vkioD7IgLqq9Mm9EiJeQANrd0oJwe2el02aZ6XI7u2GgDGU5NJOf rjUTbIW1fcH0AxFkCGN/wFy5fzokOYVlreHnMDcBH6y1CIPEGccsC2xgmgcQQSReuC7Jp56sY0u L8IUpAWm2zE6/wQBQzDxvk9ajhJgQnAqO7ECtXobAyf7zo6WQMXfSFSJXqJ6bbeplB+Qxx/m6EC Fs6wyCph0R0ym+rIb0gfMiNKm2Hw1upuBe1U2ArbaG2XDfxK4nGkdWVaYxq4mrr04lgFYfTReKz vHkzWraG2kvEDE0QMOFwruMwfdIDgkyDfst3ttN/ouBL+BxJhb6SdrDiQq7Cg7DZH3533mzCd9/ Kk++04fPwiDuOTGAQFcK2M6QGi5BVQClF2sfDjzmGl0xYKyVXkBlX/7asncUsjMy8iEHVRu4cCl nI4xHWxwTe9qoxe77OZhb52pCLM1sD9/JZeQUO9Dvrgx0kjoq6yfqC6nNt8DU/0glDr1WRjsN4D hxt1UL1Xa0sE9M= X-Received: by 2002:a05:6000:2903:b0:439:b5d4:249b with SMTP id ffacd0b85a97d-439b5d42936mr6785019f8f.21.1772451321845; Mon, 02 Mar 2026 03:35:21 -0800 (PST) Message-ID: <75710720-f2f1-4b2a-99e1-b5e3ff0191fe@suse.com> Date: Mon, 2 Mar 2026 12:35:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 04/14] x86/boot: Document the ordering dependency of _svm_cpu_up() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-5-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > Lets just say this took an unreasoanble amount of time and effort to track > down, when trying to move traps_init() earlier during boot. > > When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the > BSP, the first context switch into PV uses svm_load_segs() and clobbers the > later-set-up linkage with the 0's cached here, causing hypercalls issues by > the PV guest to enter at 0 in supervisor mode on the user stack. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244210.1543666 (Exim 4.92) (envelope-from ) id 1vx1cK-0002HA-9p; Mon, 02 Mar 2026 11:39:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244210.1543666; Mon, 02 Mar 2026 11:39:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1cK-0002Gy-7G; Mon, 02 Mar 2026 11:39:16 +0000 Received: by outflank-mailman (input) for mailman id 1244210; Mon, 02 Mar 2026 11:39:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1cI-0002GE-9R for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:39:14 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ec09583-162c-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 12:39:11 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48373a4bca3so25727855e9.0 for ; Mon, 02 Mar 2026 03:39:11 -0800 (PST) Received: from [10.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-439b4175fd2sm10883937f8f.14.2026.03.02.03.39.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 03:39:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6ec09583-162c-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772451551; x=1773056351; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=KSkLSaaf6zn/E68TTmUwv+2Blx8aX8BKatFDwkdS8FA=; b=FviktDeUu3S5aZ2N6dtSrkpAkOcDf6Sk1b+oIoZsPfMBYbiQUDyrYv/r9G3WewQnHF AHeH6LtTVI9HTJjwxBKfKWynum8iHMS5D2mc1Zc1SugTQkF7cKjM5vs+CTX4UQjM49uF M8oidgNZhKdjK+1KQB5KMgHKtYkNpc1ZSYzYG1yHE9fkj7dpKF9AMom6MB1Im2QQBQNI Dpsf/WQAjI1Wy/NQJzJGOiFy16QCZSUe6J4gEJDmlFhk3W9Lu5M/ENhcH/fBSZ1TwKFj 3Z/XhVx6ad+dFobDqe4qY90f4nUvynlQlh2/IQRWSrPg31yV3SNbV1MACoMC55Up+5B+ hSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772451551; x=1773056351; h=content-transfer-encoding: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; bh=KSkLSaaf6zn/E68TTmUwv+2Blx8aX8BKatFDwkdS8FA=; b=MzMFw0fKLRJsbyD3pqetZFBH3R713lRg1T8nZOwuVxoSHp9EdgmFzDuDVpemKoej6l uNk7Da+uezQx4OvKKGTOn9uWIOrvLVJWFAoY2vd9grK9izQy8g+yCHs/VApjbz8ohaIF I0szL/FGG6/nfiNm/HzJ1xBlibBeNOMpYgH3NjMBRP2SmDxSQx2n1/U/l+xm349dX1aQ AGFTuND/Dp9ujKK9NHjrvUVaDpZi997XPxaFKb86hMBosmx4DVU9N4L0Q3bYOTfxjUzl rlWDy3xXq7TM4mbMjMbpK1FoD+glR+rxQdYM3thn0ebvDA6lhRwxMVlx9HUsfZMQWfKB JVuA== X-Forwarded-Encrypted: i=1; AJvYcCXy+xdWZUmHsbEHePlNe08rvBC8lyxwr3L8bBY/ufj0JjT3hFF0xuiudRagS15XuIx6CjE8UwnoBNU=@lists.xenproject.org X-Gm-Message-State: AOJu0YyLY+W/kAWfTpqWVNMulNXLdfUakRPOG52+pgut/dbR04Aaq+Ec EiqiTdr6fv7KzQGOR7C+IjPdi8O3DKAw4SNY6oGlS7EsE6MA5kWrl9GNoMU1LVfCKw== X-Gm-Gg: ATEYQzzxU9Y71cqAC+fNwwm5efDV1wyoP6yPuMFAP05eDKO3mG5+NAMiw001m3hNlo8 1KjQhMHTVCEVlDtH7WxUYhhHGmeS+V0yuLLy2fklQMtUIQcNJTk+gxv9PTF1yq+mV9onvFqDDrG Vg89nfEKqwDkSiYMoHXPJCHLsGAshgKFukvRiCYx3CJbxBI4WQL8bnuSnarE/Nge/uiZkk7d+55 toSrdYqj0pG+LK1ExrVoZhHNi7aqiSewJlblRkac3cjzN8+47LbCgoX40VQXjWrdSxf8xmXEob2 E56KvN8DWSTOXUXX8+/me0pfvo63W2eU66IoR0geROmtL5fHJOokeOxJfZJCfomiq54rXIiKnjU xdgyuZLNUxMmp5v8dvh46PwLfnvPJJk+a3LV2waeIflNOhdyepbRhnrYADYSV/xHyD0540pg/ZB Mdm4me7ug3go6IfkriXONVQHF7PgJkwaYeysk8Kn3soFJQ9Eg2WNbNNYSJynbkLXo5VB/fnaGQw QHhg9knpkZqkiLeKkrSdq8dng== X-Received: by 2002:a05:600c:6385:b0:477:54f9:6ac2 with SMTP id 5b1f17b1804b1-483c9b53c9cmr228004325e9.0.1772451551256; Mon, 02 Mar 2026 03:39:11 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 12:39:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 05/14] x86/traps: Move traps_init() earlier on boot To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-6-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-6-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > We wish to make use of opt_fred earlier on boot, which involves moving > traps_init() earlier, but this comes with several ordering complications. > > The feature word containing FRED needs collecting in early_cpu_init(), and > legacy_syscall_init() cannot be called that early because it relies on the > stubs being allocated, yet must be called ahead of cpu_init() so the SYSCALL > linkage MSRs are set up before being cached. > > Delaying legacy_syscall_init() is easy enough based on a system_state check. > Reuse bsp_traps_reinit() to cause a call to legacy_syscall_init() to occur at > the same point as previously. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Irrespective ... > @@ -359,7 +363,13 @@ void __init bsp_traps_reinit(void) > */ > void percpu_traps_init(void) > { > - legacy_syscall_init(); > + /* > + * Skip legacy_syscall_init() at early boot. It requires the stubs being > + * allocated, limiting the placement of the traps_init() call, and gets > + * re-done anyway by bsp_traps_reinit(). > + */ > + if ( system_state > SYS_STATE_early_boot ) > + legacy_syscall_init(); ... I wonder if simply pulling this out of this function wouldn't be slightly neater. To me at least, syscall/sysenter are only a remote from of "trap". Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 11:44:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 11:44:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244219.1543677 (Exim 4.92) (envelope-from ) id 1vx1gw-0003mE-SF; Mon, 02 Mar 2026 11:44:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244219.1543677; Mon, 02 Mar 2026 11: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 ) id 1vx1gw-0003m7-Om; Mon, 02 Mar 2026 11:44:02 +0000 Received: by outflank-mailman (input) for mailman id 1244219; Mon, 02 Mar 2026 11:44:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx1gv-0003m1-UU for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 11:44:01 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1a8ab18d-162d-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 12:44:00 +0100 (CET) Received: from IA1PR03MB8288.namprd03.prod.outlook.com (2603:10b6:208:59e::6) by PH0PR03MB6463.namprd03.prod.outlook.com (2603:10b6:510:bb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.16; Mon, 2 Mar 2026 11:43:54 +0000 Received: from IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::b5ee:28c6:e04b:5599]) by IA1PR03MB8288.namprd03.prod.outlook.com ([fe80::b5ee:28c6:e04b:5599%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 11:43:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a8ab18d-162d-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XMBDs639lkP+09vycFAWTBFVcfFSnuUofY4Af+mSBv7ziicDbkl+voCcz1nbgLCGgOWpgAZphhZGZIm54GlZIqmKrUsgtetVczwxBkrQW8XpSCBd36HvuJxZZX0GHoVLGrTMs+LrKZLbEt6tMJhuuUGA4bkjJP0g6yh63hrWfdcb0NYY06R8HpRwa0hYGpysgTupmaqN3ZRrDoDfwSxWu6C0YLcOxAVZY2dvN6MDTTt8O9fjsdc0V+x7Aax4/c6uZ762yT8azGn2qA1jRyHp5ilLQa40Te47+QsiI40SJxxz9/HfWmZL7vLn8V3H4UgHf4w+ntwqizCQqP9doHROSg== 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=AdKqbfApDT1CGXFK/RBEqtP1Ct6LWFNhZV5lNBvvAYw=; b=bDWWY+OMkgvuKkdiXfs9q58q/T+RvDFT2g/vcqteT957+myjBU3wtjjkuoscXDZQvxj/XjZK6765Lb530FU47W3qrPyCtLZ20Ly2jXkW+GOyt9LlfaJKStHATjLtqNJ2FSdGpzuROiOmnkSmoPffh/6CYjY2W4+mFjgFWDYJ9tW42qqE9w4ZWe5ewbNGnr8JLhTalV7ncum5l0jeikFChDgBdzspzQG2a7sNiAydDnwJ3bGutUBXbLDsHT6aS1sOVRiNsGhVWzY4wYLg6oiL6eFkdcL2I/0wHawl8UgL8glT4qKVbQSjg9BvH9racQx5OZXPsXVmNM5TRGxMfRvhFA== 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=AdKqbfApDT1CGXFK/RBEqtP1Ct6LWFNhZV5lNBvvAYw=; b=PwCNMQo/qQvtPdY1LmqA+asq9P8xQn4PFV88BTTFDMQSYvldTDslxrILs8iIAvkMPJoRfTcm4zjtWtEkhDhNAub59qdgejoQLuD9TnNyS+5beckEm35xd5TgkOIOEM3CNBebv6ZPEnEmi0qP+vgpBoQgXweYudbAs8nFhOMXbKY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 2 Mar 2026 11:43:31 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 01/14] x86/pv: Don't assume that INT $imm8 instructions are two bytes long To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-2-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0423.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18b::14) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA1PR03MB8288:EE_|PH0PR03MB6463:EE_ X-MS-Office365-Filtering-Correlation-Id: 6f3976f2-ae79-4d83-e478-08de7850f551 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: sylWef5OMXMuWyo4wZoZT++iQemLLiJt2t3kjihcpXl0099qIBKEwRzmuzd4q/7YWIfJbS63mBMDZntSW978osqLhFmbyD9QMkjhYrUO40O+A18NyXzHaaYqNGHtjTKN1WMf8GIslNUqkKxgYFxusToRgRrn4MNhrHqHlEv/esRg4RfUeoV6yfyRksbNsCxEfvGtT3cZmgWckbi+pwRshVre4gvH9HNvC/GFfv2EhzrlTCAVIK02nGGp7PRk4RYaXnw8lNuCdArT+aMxSd/uYoIIp89lGzbO0hlTJLMK72xpbAOnZbYfXh16G/OnEo9F6qxjmcmDFCi/YkwHm6KJsFrg+6PT1Y9OTkE+rNbPqLl+zlMNy726glBiE0ZT/VBXIX1Lny3JCmA/+SDHIQYrqQNpqiHZUF8a5z/Fb8iI4BU9mLbBi2LaAFcStpPfaCQnJR1PtHf7js3QZOjMSZPU/klxl8bTgomEvpATUnakgpbPtFxdBQfb71myATGKlSh6cf5Cms+03pe+HI5PGRbs+3tj/u+A3og8wtdkbdQ3yIKfWUAlMF6PwnRoqb6i2wpWAJ+KrKzPP+k6yz5vv2nXkvc1kBIL5KY5d6BiAwTUdG4z4l3wDjpNl9DlRn3fOuiIY1SoedYIBW+OI8SxokPVGXl5rBXj5HGcvYVdUt5NzZVh77KLDs2qZVFBPhCcxDhNlB8HJXU2S+jt6Ov7DiF7nOVls+MsQruw66iyq6GfDrw= 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)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OVI2bGdyREU4bjJJeUpTQTRScG43emRaUE9qcmlCN3JUNzhOVkl2dVNwMFMz?= =?utf-8?B?WmMyKy90aXAwaUN5VFFYZHBGNkNBQ0hPU3RmaXF5K1JzS0g1UjQ4TDZkQ2kz?= =?utf-8?B?TWsxejV3aTFMSkZ4UjNzQWtQMUY3VWJQeHg2a21HRVlKeDFVTkNJcEI2VFha?= =?utf-8?B?VmQ2aTFucGFUWkNNemdqTFBKSFFQc1pCTVlGclZuZzF1aGtqSzUzM2E2NFBx?= =?utf-8?B?T0JiSVdIM1dJTm8vZFZ5VVVrT3NINVcrR0pkVGE5OXhOd1RBODlYZTI4SzAr?= =?utf-8?B?cTZpUld5MjhQaGIvejZwUkp1Ym9ESXI0ZXJoeWxYZkVWZ2ZUN2w2bkpCRE1h?= =?utf-8?B?Y2twb1lZVVJ0dFZRK3NhRG10eXFSS0tiZ0tkbDBEYklseG5QL0c4d1owZzdr?= =?utf-8?B?MkF0aEd2K0Z2RkpkZGV2WTRTaitZWEFRTDQ4RWJtTVh2aldWUDdSZC9CZnN2?= =?utf-8?B?MnVtQlV0N2xFVHZnZGs0azRZUjNqSFVtWUF1VENqQm11MTZ5ajRuUHhyTzFi?= =?utf-8?B?d29mS1hEYzVyay9TWFFRSXcrK2JOYy9HVGpJc3l1VGcySU9KY2J2V0ZZdmpD?= =?utf-8?B?R2doK3BYTVRLODBuSEkwK2I3MG1NbC8rN1dyV2k4UDRYbHpubVFJMXZNNnVH?= =?utf-8?B?YVVTYUNMeW9RS1h0T1E4L3JqMVVLRHNMRE5NdTNxRXhTODhORk12a2hpNGtK?= =?utf-8?B?RXRNN214TW5SeEFUWklCQmtBZzBFeUhiUUpkNU9GcFpwUTB1dFdWcWdObFpC?= =?utf-8?B?ajk1aFBrbWxqN2dsNmNPMFlEczMzaGNlQVlpNGJhRTQwWm1jNXZ1RFBja3Fi?= =?utf-8?B?N2t0UVNYd1d1VDBsbTZpU0NRNWZpMUwzd1h4Q1M0aDM2YzZKZ0dvVk5OTUhH?= =?utf-8?B?MzdsSStUb2NzVzU4NTdLSGNEbFliYmxBeDZ5a3NScDZjNlNaYTNiU1J4enRz?= =?utf-8?B?Mll3VVMvTWI0U0g0RVFVNmQ1a3R0dUlaNURkRU9WMGV6ZUg3aEFEWEdsUC9i?= =?utf-8?B?SkI3UDVIcGFhYXZCRDA4UG9uVlJUbEVraHJVZ3ZzZzdhUzk4VzlJZldtUVpK?= =?utf-8?B?a3c3VGdPbUp2MHhHSU1GM01lSXRTV1hzYnBzakw5Ti9mcXVOTjRXSjFhK3pL?= =?utf-8?B?VFdWbTl1Z3gzdENGc0ZBRnNMZ3hUQ3dNM3RrK0xybXFhTEhJRUx3Tko4VTNk?= =?utf-8?B?KzJIL29wM0xsaWFkNlNzS1FWUS9RZVo3Zm1zTy9EVjR0MnByZUhXMitqSFpU?= =?utf-8?B?bEw4ZWhuWlZOd28xaURKamV6SmUrL0Z5a1RiVE85ZS9yNGtBNGNCNklRcVFQ?= =?utf-8?B?QTQ4TlZHdXpJNXN4UWpWdXk1cGlBV0VwWHpsMk9BRGczL3FFdFl6SVBhUlM4?= =?utf-8?B?bmRZckNCamc5T0pvakZrN0gvQTNVNC94bWxrcjBtSmoza1VCR3lHcjdrbnZr?= =?utf-8?B?OUYvVGVLV0VUdTJ0ZGF3dWFMZHNuLzhtU3h5LzFoK1dYTUZWYzBjMWJmMFAx?= =?utf-8?B?UlJEMVZFdVJpL09QbGpSTVVVcWw1dlNCYXQwelJvNEgxWGQzTDVzWjllOFZx?= =?utf-8?B?azhZakJNZTdUQ2JDRnZmQ0pkcXdORmswY3ZpS3A1bzhsbEJ5aFMvck1JS1ZL?= =?utf-8?B?a3g4V0FBTlZjY2h2b3hiYStRVVV0R0x6ZG5ZT3o1ejZuNkNhaldTY1hGNWFn?= =?utf-8?B?Tm80SXRyeEV2UWc2cTFCLzBTMld2T09CWXp4YlNTSzNjdmxzOThDNWZJNVlB?= =?utf-8?B?Sy9BbU5YcnpVeEZCMDRFT1NrY1pRa3lXcTJxeGtGV0UwSGlsTThGZ2Q1Vjdh?= =?utf-8?B?ckRWOENWUjF1MEM5OWUzTWMxdlJOdlZ5cTNndHllbmFEdFlIdTRJeitNSGpw?= =?utf-8?B?VEpQZDcxejhodFFsTDBOaHduTE9mSEcyb1daNnJOTEdUNllxTVVBS1BJYll0?= =?utf-8?B?MnpqYXZZQU5VTXgzM2tWMFFYZkw4aEE4cUpNZWl0U0JsRW5UYU1HNWdQb3c4?= =?utf-8?B?UHRpdUk4S2JaZG8zWEg0RWk2TytKa3RYVm53Wi9ibTVvem5KVEI4RGhBQWxi?= =?utf-8?B?VytVN042UDBER3ZEdVlKeDh2K3dOdkNzcElhQUN6aWIwQUJnaGJJK1RNQ1V2?= =?utf-8?B?dkpUYlprSlJsS3o5QUNPVGlieVpOTHZwYllDSGtIZGRXRzV1dXdIMXZUTVlG?= =?utf-8?B?eHJaemxrMlhwMEgvV24xR3p4MjdzR2dtcENJeVNBNHYzL0J5cU1UQnY1c09s?= =?utf-8?B?SUU0S2t1N3AzanhJdU50K1ZKdk9HNDREVkxCaGxJT0FnTG1NSERnVktSOHE5?= =?utf-8?B?ZGpHVGcwTjAxaUlvM0hzNnFlMXl4ZXJhTnlpOEliTnlmY2hSemlzZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f3976f2-ae79-4d83-e478-08de7850f551 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 11:43:53.8145 (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: 4EDIXpIhP5YvU4SHWNMNBwuX8hvfYf4nu9il/0BoW6juFdfGCzJ/Y6SS7D+6Ic1vtbeFTKWoU8ya+EhzChh3FvVsoIWF0VV802r6wx2mFTw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6463 On 02/03/2026 11:03 am, Jan Beulich wrote: > On 28.02.2026 00:16, Andrew Cooper wrote: >> For INT $N instructions (besides $0x80 for which there is a dedicated fast >> path), handling is mostly fault-based because of DPL0 gates in the IDT. This >> means that when the guest kernel allows the instruction too, Xen must >> increment %rip to the end of the instruction before passing a trap to the >> guest kernel. >> >> When an INT $N instruction has a prefix, it's longer than two bytes, and Xen >> will deliver the "trap" with %rip pointing into the middle of the instruction. >> >> Introduce a new pv_emulate_sw_interrupt() which uses x86_insn_length() to >> determine the instruction length, rather than assuming two. >> >> This is a change in behaviour for PV guests, but the prior behaviour cannot >> reasonably be said to be intentional. >> >> This change does not affect the INT $0x80 fastpath. Prefixed INT $N >> instructions occur almost exclusively in test code or exploits, and INT $0x80 >> appears to be the only user-usable interrupt gate in contemporary PV guests. > Whereas for the slow path, while the subtracting of 2 from %rip there isn't > quite right either, the insn size determination here would then simply yield > 2 as well, so all is good for that case as well. I've covered that in the docs patch (patch 2).  Because INT $0x80 is DPL3 and therefore traps, this is the best we can do. > >> @@ -1401,6 +1402,53 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs) >> return 0; >> } >> >> +/* >> + * Hardware already decoded the INT $N instruction and determinted that there >> + * was a DPL issue, hence the #GP. Xen has already determined that the guest >> + * kernel has permitted this software interrupt. >> + * >> + * All that is needed is the instruction length, to turn the fault into a >> + * trap. All errors are turned back into the original #GP, as that's the >> + * action that really happened. >> + */ >> +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) >> +{ >> + struct vcpu *curr = current; >> + struct domain *currd = curr->domain; >> + struct priv_op_ctxt ctxt = { >> + .ctxt.regs = regs, >> + .ctxt.lma = !is_pv_32bit_domain(currd), > The difference may not be overly significant here, but 64-bit guests can run > 32-bit code, so setting .lma seems wrong in that case. As it ought to be > largely benign, perhaps to code could even be left as is, just with a comment > to clarify things? LMA must be set for a 64bit guest.  Are you confusing it with %cs.l ? What's potentially wrong is having LMA clear for a 32bit guest, but this is how pv_emulate_privileged_op() behaves.  LMA is active in real hardware when running in a compatibility mode segment. I don't think anything actually cares about LMA.  pv_emul_read_descriptor() doesn't audit L and instead relies on us not permitting a PV32 guest to write a 64bit code segment. > >> + }; >> + struct x86_emulate_state *state; >> + uint8_t vector = regs->error_code >> 3; >> + unsigned int len, ar; >> + >> + if ( !pv_emul_read_descriptor(regs->cs, curr, &ctxt.cs.base, >> + &ctxt.cs.limit, &ar, 1) || >> + !(ar & _SEGMENT_S) || >> + !(ar & _SEGMENT_P) || >> + !(ar & _SEGMENT_CODE) ) >> + goto error; >> + >> + state = x86_decode_insn(&ctxt.ctxt, insn_fetch); >> + if ( IS_ERR_OR_NULL(state) ) >> + goto error; >> + >> + len = x86_insn_length(state, &ctxt.ctxt); >> + x86_emulate_free_state(state); >> + >> + /* Note: Checked slightly late to simplify 'state' handling. */ >> + if ( ctxt.ctxt.opcode != 0xcd /* INT $imm8 */ ) >> + goto error; >> + >> + regs->rip += len; >> + pv_inject_sw_interrupt(vector); >> + return; >> + >> + error: >> + pv_inject_hw_exception(X86_EXC_GP, regs->entry_vector); > DYM regs->error_code here? Oh.  I'm sure I fixed this bug already.  I wonder where the fix got lost. Yes, it should be regs->error_code. > Might it alternatively make sense to return a > boolean here, for ... > >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> @@ -1379,8 +1379,7 @@ void do_general_protection(struct cpu_user_regs *regs) >> >> if ( permit_softint(TI_GET_DPL(ti), v, regs) ) >> { >> - regs->rip += 2; >> - pv_inject_sw_interrupt(vector); >> + pv_emulate_sw_interrupt(regs); >> return; > ... the return here to become conditional, leveraging the #GP injection at > the bottom of this function? To make this bool, I need to insert a new label into the function.  I considered that, but delayed it.  do_general_protection() wants a lot more cleaning up than just this, and proportionability is a concern. What I was actually considering was splitting out a new pv_handle_GP() function to remove the ifdef-ary, and doing a wholesale rework at that point. ~Andrew P.S. Something I'm still trying to figure out is how to make guest_mode() able to DCE based on the caller being entry_from_{xen,pv}(), because the function can be bifurcated for FRED.  It doesn't appear that the assume() constructs work, probably because do_general_protection() can't be inlined due to IDT mode. From xen-devel-bounces@lists.xenproject.org Mon Mar 02 12:57:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 12:57:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244243.1543687 (Exim 4.92) (envelope-from ) id 1vx2q3-0004qB-20; Mon, 02 Mar 2026 12:57:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244243.1543687; Mon, 02 Mar 2026 12: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 ) id 1vx2q2-0004q4-VM; Mon, 02 Mar 2026 12:57:30 +0000 Received: by outflank-mailman (input) for mailman id 1244243; Mon, 02 Mar 2026 12:57:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx2q1-0004py-UV for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 12:57:29 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5dbe07b9-1637-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 13:57:27 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439b6d9c981so686029f8f.1 for ; Mon, 02 Mar 2026 04:57:27 -0800 (PST) Received: from [10.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-439b4175fd2sm11373336f8f.14.2026.03.02.04.57.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 04:57:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5dbe07b9-1637-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772456247; x=1773061047; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=A4sw1FqBMT7nXxPURsGhVu+Kxp3Tqh0F1/FVVl4vg/s=; b=R8wr9T6qkWH35/X6Ret9N3t8KCWDW0CPwmZpTtyCnsIs3VmaPjJLbkiWOvUCnVh6Js fwLVqFFx8025POlCn5jkJhDXrmEThRuO4eUMfFEPQDb+UER12pl4csmPD84g/mqPRDkP MaB/zKQ8qLirIyK6P4chXDe5DUJl2JvXzhYemzgUh4ThgGC3cnLP0RqqefU4renniRnT WHpWBTcymfo+fpuyv5tD/V6T8Nv7MKU/m2la5Kmqz3aqJVUy9ST9Fd6rkRhQ0pMhTzoj rpFadWEA8Ocj2GscdNmOZEakuUNxc/ENqbJXt1vkMtOqkzS0vuPRiRzVkX8JLJnhCtFL AlcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772456247; x=1773061047; h=content-transfer-encoding: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; bh=A4sw1FqBMT7nXxPURsGhVu+Kxp3Tqh0F1/FVVl4vg/s=; b=PPYRD90DAgmxvTYWfld7do+dCZYafzgSPlRo0Jynfxf31bJlmR2DNNo2g/m5tGyKQN jSSeXbJ7pnfdtGnGfkO5jW5vWLxazKQDelXEs7l5kgzA7GwfYXpas2x4Mg+KiH4ScfIL RxeRLrFxaaHzfsx0pCcAJUzKJFs3ODtt+Tb4C+fpgumOms4VH5Lrl0VPyAw9fpwfiSRY PLCNBCbNYDmWcJnENXKXHoYpV4VapIIXBXDMGxsCz6GTZCfXmUfj747T2jMlz/R+VIY+ +XfKB1eVI0Jqwjbdg7mYMU5s84bmQMDd/lEb8KKdHYNsB1ekF2Xq/m4KPPp904t3eNBo eHhA== X-Forwarded-Encrypted: i=1; AJvYcCX5j4TX29SjS6G2OjY03Bbnzwo3hifndnoZjQRtbLC9TGvdEyVgK86z3Gov2C6s2/QJnC4mGA47vJY=@lists.xenproject.org X-Gm-Message-State: AOJu0YyI1ho3wq6tz+8/Z6bOzLUuabXjXeD17O9el6uPZ3/p//RRcsyg bYc0mnST+KgR7XdQOnVcZ1B5N45pmc050WV7o675qeTUMqJY15Qp4ERflwQCjVN+SbT1wkaLAh6 18v0= X-Gm-Gg: ATEYQzxPDbpzJVi2ur8ZCaI2QucdBXmAf/akQ1lKj0m021Lw68PcQIS9EjkZxLbjNXG MeAwHF0N4PAiNo3lcu7DWO/lyhJ7BwMlLdkFpSDnkL+wzmTevP1DUtMg2PHd8w7RpeFG0rDDs+/ YFtZu5Did6TtuBn+HngBJsoW6kEDe5l0cQfJ/QAA08Xr4ZHRHnEHwnSyuofWqoBW6USdZN6zZdL 5UXTTwuBBaT0EOntaAPXNuqzPF3oUi5lwpZWFIuuFpMNxjY3BUx4uCszwawN6xKj+M3Rmvdyzpc O3gRc0+kmMUy0/O5bL1Olr2O4fjqzZTqeAo3FKFKDBYKAiAiJD+1kP10j1PFyb5hjDDy27KMdxF Wln/9qaRw0rEWo3NP90N9/5mDXk8hqLF2shRKRowxRDaV+1/4HiRmOLXuJMwFODpMSxybIj6IYU Q8K7hslajRRaHvp3pQEsoJb4Tpu7UKqwiX0a02pC41TFC9fAjjmC8+5hvtDzmSO0cHNWsQgUUGd NRBcix6HR5TtWc= X-Received: by 2002:a05:6000:2c06:b0:439:8559:98b with SMTP id ffacd0b85a97d-4399d97f826mr19942122f8f.9.1772456247038; Mon, 02 Mar 2026 04:57:27 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 13:57:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/14] x86/pv: Don't assume that INT $imm8 instructions are two bytes long To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-2-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.03.2026 12:43, Andrew Cooper wrote: > On 02/03/2026 11:03 am, Jan Beulich wrote: >> On 28.02.2026 00:16, Andrew Cooper wrote: >>> @@ -1401,6 +1402,53 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs) >>> return 0; >>> } >>> >>> +/* >>> + * Hardware already decoded the INT $N instruction and determinted that there >>> + * was a DPL issue, hence the #GP. Xen has already determined that the guest >>> + * kernel has permitted this software interrupt. >>> + * >>> + * All that is needed is the instruction length, to turn the fault into a >>> + * trap. All errors are turned back into the original #GP, as that's the >>> + * action that really happened. >>> + */ >>> +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) >>> +{ >>> + struct vcpu *curr = current; >>> + struct domain *currd = curr->domain; >>> + struct priv_op_ctxt ctxt = { >>> + .ctxt.regs = regs, >>> + .ctxt.lma = !is_pv_32bit_domain(currd), >> The difference may not be overly significant here, but 64-bit guests can run >> 32-bit code, so setting .lma seems wrong in that case. As it ought to be >> largely benign, perhaps to code could even be left as is, just with a comment >> to clarify things? > > LMA must be set for a 64bit guest.  Are you confusing it with %cs.l ? Indeed I am, sorry. >>> + struct x86_emulate_state *state; >>> + uint8_t vector = regs->error_code >> 3; >>> + unsigned int len, ar; >>> + >>> + if ( !pv_emul_read_descriptor(regs->cs, curr, &ctxt.cs.base, >>> + &ctxt.cs.limit, &ar, 1) || >>> + !(ar & _SEGMENT_S) || >>> + !(ar & _SEGMENT_P) || >>> + !(ar & _SEGMENT_CODE) ) >>> + goto error; >>> + >>> + state = x86_decode_insn(&ctxt.ctxt, insn_fetch); >>> + if ( IS_ERR_OR_NULL(state) ) >>> + goto error; >>> + >>> + len = x86_insn_length(state, &ctxt.ctxt); >>> + x86_emulate_free_state(state); >>> + >>> + /* Note: Checked slightly late to simplify 'state' handling. */ >>> + if ( ctxt.ctxt.opcode != 0xcd /* INT $imm8 */ ) >>> + goto error; >>> + >>> + regs->rip += len; >>> + pv_inject_sw_interrupt(vector); >>> + return; >>> + >>> + error: >>> + pv_inject_hw_exception(X86_EXC_GP, regs->entry_vector); >> DYM regs->error_code here? > > Oh.  I'm sure I fixed this bug already.  I wonder where the fix got lost. > > Yes, it should be regs->error_code. Then (plus with my confusion above sorted) Reviewed-by: Jan Beulich >> Might it alternatively make sense to return a >> boolean here, for ... >> >>> --- a/xen/arch/x86/traps.c >>> +++ b/xen/arch/x86/traps.c >>> @@ -1379,8 +1379,7 @@ void do_general_protection(struct cpu_user_regs *regs) >>> >>> if ( permit_softint(TI_GET_DPL(ti), v, regs) ) >>> { >>> - regs->rip += 2; >>> - pv_inject_sw_interrupt(vector); >>> + pv_emulate_sw_interrupt(regs); >>> return; >> ... the return here to become conditional, leveraging the #GP injection at >> the bottom of this function? > > To make this bool, I need to insert a new label into the function. Why would that be? Simply skipping the return and falling through will do, afaics. >  I > considered that, but delayed it.  do_general_protection() wants a lot > more cleaning up than just this, and proportionability is a concern. Whatever you exactly mean with this. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 14:26:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 14:26:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244261.1543698 (Exim 4.92) (envelope-from ) id 1vx4DV-0007bH-3F; Mon, 02 Mar 2026 14:25:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244261.1543698; Mon, 02 Mar 2026 14:25:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4DU-0007b9-Vi; Mon, 02 Mar 2026 14:25:48 +0000 Received: by outflank-mailman (input) for mailman id 1244261; Mon, 02 Mar 2026 14:25:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4DT-0007b2-TI for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 14:25:47 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id acc85e85-1643-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 15:25:35 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fPh6j3NX6z35hTTc for ; Mon, 2 Mar 2026 14:25:33 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 60e17a7ffa8142d7a53ab178543b7c2f; Mon, 02 Mar 2026 14:25:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: acc85e85-1643-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772461533; x=1772731533; bh=mdLDX9eD5d+3ZMlNItmrm+QdS3R/t0XHGWI+EnCSP1g=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=KaI7wtHnMo0ypLIdipwCjPKvaGtNo7KC8Pmw/PWpfbZGtBPjXZDvRg2FKB9Cg9tKY hWoEjNl6gOeWqnFRJIJ3V2SukkmHkxdpkEob3AQej4JG6QYD/QlPxUZiw2WJ2aVLa2 tFTxT/Qe3Aq0Gc9hgOnt1nWZMkia7FK1kpEbpFCLU2u37SUu5fmI1tKINFZLMBd/6I 0cceDis5dJ/gfpHU7Y36TbFLok0BbqSI+rGhFcD1FTvptciM6gHcna6yAIDGBUQnDu UGIvvJSgj6u8ls8MXL61YN67aRFNg/s3vb718rR5/QIiQsjbFUv9tRn/uNAjDQuziC uNIDoaNkqrFnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772461533; x=1772722033; i=anthony.perard@vates.tech; bh=mdLDX9eD5d+3ZMlNItmrm+QdS3R/t0XHGWI+EnCSP1g=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=iqAz9FYIDqvVI/1HAeahqPtHW5joc7hlpMAF4WfxQ+b5PbpXh1fTe2pH2rt3GaMcd wJaGV49sotUgpkeJUIkU6m47e6ni0KkixhZUj+FwKMJbD8e/qoM6wDgIxF8ebWhKDm a8S1z/GXMRrtR8/G3dxWiXxnNmQ37HNx/YgER2nItm50dHVVZkNQhOvQ9mr9zSLZ/x oKJtv/2+ShOpo2bbIquUzNkUaFhAwiew0hIa75UdtiQ5U1ZPfMhrQjl5lFQ1jpgWrO z/nN4wCgebzq5vblBO4MyOhDUfficquj523J68FtktIDhmoHv2etLUKjQRBpQ/8vgD GD3D93oAK4B7A== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v5]=20xen/domain:=20introduce=20DOMID=5FANY?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772461531919 To: dmukhin@ford.com Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org Message-Id: References: <20260205235126.3764953-1-dmukhin@ford.com> In-Reply-To: <20260205235126.3764953-1-dmukhin@ford.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.60e17a7ffa8142d7a53ab178543b7c2f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260302:md Date: Mon, 02 Mar 2026 14:25:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Thu, Feb 05, 2026 at 03:51:26PM -0800, dmukhin@ford.com wrote: > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c > index bfc9149096a3..714e71441498 100644 > --- a/tools/libs/light/libxl_create.c > +++ b/tools/libs/light/libxl_create.c > @@ -676,15 +676,14 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, > if (ret < 0) > break; > > - v &= DOMID_MASK; > - if (!libxl_domid_valid_guest(v)) > - continue; > - > - local_domid = v; > + local_domid = v & DOMID_MASK; > } else { > local_domid = info->domid; /* May not be valid */ > } > > + if (!libxl_domid_valid_guest(local_domid)) > + local_domid = DOMID_ANY; Well, that make it possible to have DOMID_ANY selected when a "random" domid was asked for, and this value is more likely than any other domid. I don't think it's wise to change that. The domid generated in the random case was already valid, no need to check again. Coud you move the new validity check into the case where domid isn't "random" or introduce a new case in the if/else chain ? (something like that for the second option: if (domid==random) elif (domid.is_valid) else (use domid)) Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 02 14:48:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 14:48:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244271.1543707 (Exim 4.92) (envelope-from ) id 1vx4Yt-00022A-Of; Mon, 02 Mar 2026 14:47:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244271.1543707; Mon, 02 Mar 2026 14:47:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4Yt-000223-Lu; Mon, 02 Mar 2026 14:47:55 +0000 Received: by outflank-mailman (input) for mailman id 1244271; Mon, 02 Mar 2026 14:47:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4Ys-00021v-BQ for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 14:47:54 +0000 Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azlp170100005.outbound.protection.outlook.com [2a01:111:f403:c005::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c718f7ea-1646-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 15:47:48 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV4PR03MB8283.namprd03.prod.outlook.com (2603:10b6:408:2da::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.21; Mon, 2 Mar 2026 14:47: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%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 14:47:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c718f7ea-1646-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Lk0l+qY9hr2oIpYOWZtB/razWGAC6pzilt7De7ajta4Z80TIy9AZd+AVmgUVWzzWL/Cys8ijVnZe0FBhWYPRq9CjAXN0JckWfG/y/GlrVOW9v6jE8S4rl0qcVtBGL3ikDMuqyn6mpe+0vkl+vKVM+G+vLq9GTsQxclH5CPnphwLYklgd2XSC5Wf5zwNYwKDveMhtfytZ2FFkNa2Qyl/bC7RJv4BSXOIOb8jRp2STvEcvntxnbSLqDL0PXjQHUBOJcdobe/8MPTGeOcFyl5FiV9W6uJeBHjFkUNC8GCe3E6AGSIQoORO5mLKpXr8zWPd5ftwzrNZ5nf4fjIU3KVEOkQ== 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=YUgR0VA1hI3ReBjqil9zWhw2fV2myELZil2IMNxGz2E=; b=yzn6VaV6KTfI6fWEoL52IvgTGuEtyxPfqYAOJ0KKPHSGBpK+LMQh5GMnFztkglDv/Pe1C9e/jWgKuj95LrIUS1tqnTESkwSMjwpJ+ZqIt6ob3sGodfsZrw3YdbBuoo81ew574au/de4d9tW/92scbbs4M3Iwt52Lvf8oSuiQx06iqL4DqVgCCOGlkj6avo0DLKoUlWXwR5/Ae5mdycL0Qua1JkVRVG5mw2TWHwGVFDd7WP11V3s3qGVL/GQxlOCwocekcrKxuEdoadjElRgBc4rgzaT7nti8Y77TgKHBecEHbX+S9EwP/gMf+uUgJbQVujGSvCk9uEG6l45EzYoSNA== 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=YUgR0VA1hI3ReBjqil9zWhw2fV2myELZil2IMNxGz2E=; b=xY8vP6H4UO3YYzhqMeZfkOFJmvx/5viIohabCsZ/alC9ai549wlvfgnwvvPXmgE/KaHYbARBQ6485NQuiVItFtHNT4h2ZQmlOyA9so/ozy9dv839viHZNwVwIajxuZ9/Edv6hbrBjd1NvyO9uSnyECuam6Sb33G2FhALOoFtCuM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 2 Mar 2026 14:47:41 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 02/14] docs/guest-guide: Describe the PV traps and entrypoints ABI To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-3-andrew.cooper3@citrix.com> <4052793e-094d-449b-af97-e2d068836366@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4052793e-094d-449b-af97-e2d068836366@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0034.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:2fe::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_|LV4PR03MB8283:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c6b6e7f-a237-4a7b-79c6-08de786aa9d2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: NkfcPSBy+VfHocfs0hOs2xkLYhC1+UlE8MRuvNqDBMZ6B3bc6A4j7i/l4r/86sjfcXrZMakbN8era7bztwJDrgojrWGB9UkCg4/eQTBX78awXzNf5r7buZhIcmwBxJan+eknLaLtCQmbJeUm7IXeFs0gGX8wkMEyl2KqJVEIo6JQupsWk8l5mcF5dhEslzmuzvYeH4BQow6P12J9hOZCBn+2ChiVlZr6RafVALn5I78zoFfrcJBr2gz/4M2XcGKJsaHJsDt4X2C27HJAvu+gY08+SqLHWQSdmk1eFB6TjKFqiYokOMsctysq6osJUT3N0WaJ63ex2/jzAefwFpt0saus3LtNfwjbCPSjALeFVs17lL6kYEOezrwPje0RNuuVjjWlDzJKOH5+WHIhf+Uy3QWMQtBRbEKI1l0cSIq7f4k4oJ5bJpRi51rVNrjK+fN58maKSiClp6VkiJyELYRhVfANrXQx6nMJPEdc5JpsauFi7MQ7GThSycLeOw9490ru/dW5Ck1iHH6vpW3rWA5sjL4XkYUoMaqVZamDqLVoetlNj875YONGkYvpQMAPXsysDck7r8yq3szD9WRFwRuHPx4FrZvBB8mFbnK9JFJ8MZT95aKZ/0da/5FM9MLui0OcQMQGeOl7T+cBvh3vVLxYhNO6y9ItO3oxmRxkWM9Iad78HCvk2/PlHKMweUkJv1BPVuu550CfQeI0KhO4AjtJ3cNQQeX5rsMgtKGPqNSgzM0= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eDJneXAvRDZZRWNKOTYzSURPaStvTUI2UE5rRlVoZEIrSG1QUjU3ZFMrYmll?= =?utf-8?B?bXRZOUJoRXBWVHlQUjJncVB4c2c1b0pJeDBJWU14d3F2cHZJZzQ3N1ZzL0w0?= =?utf-8?B?VmNORnpYZm03VS8vUVMzTXd4b0xDSWtzd1VGaVU0QlptcFpacXQ3bGdBdXdn?= =?utf-8?B?ZVo2elhWeW5iS1laRE9EanFMbkMwMS9zOEFPQVlCdHZLM2dsM3NYaEJ0TzhU?= =?utf-8?B?RjJZenRrVnhPcGhwVjRuUHJjOWZJczhTRXJTbldCUTNBcUV5WEV1b1JEcUpE?= =?utf-8?B?UGlFVmxVU3dOcmhyVVJVTHdqL2RGL244L3Rla09ISTRNNGxETnZRTWVIcjdv?= =?utf-8?B?eGpZRzJ6MHgxUXZGaFNNaFBXVGxlT0h1SjJ2NDZtVGgzaWZ2Qnp2aFN6RVRH?= =?utf-8?B?ZGxVMDErSEdVOHFjZ0YzWTdTWkxQOVVxUk15MlB0OEFSdSsyYXVMUktXZnJw?= =?utf-8?B?QXYzaE9iVDk3cFNVOUpia1QzcWpYSitnd3VQQmZ6MEFsKzNXVHhhV2JmSWkw?= =?utf-8?B?OG1iNTFnbW1pZ2dDTmVFKzNYTVhYQjZEZ3Z5RjNzdGlNMFVSNUZQZVdvMVly?= =?utf-8?B?MnRCYWx5YjZiNExEaGVnZjZybVFDbkQ3VnNVRTFiZVI4cVNYQURyMUY2WXdq?= =?utf-8?B?clZrUzhCUTZSenhmQzFxb3Rybno1NnE3MnAwS2k4UkV4K3ZiTFp5My9KREtE?= =?utf-8?B?cUVPZ2RqUXhoODk4QUNUVElxOHQ0SHNOemIzL1lIRjY5SjVkTjliM0JDVWZy?= =?utf-8?B?WEVycmN5MElqSjZaekZOM1hQY1RkMks4dUk1R1pPSnFqbHB1QU1LV28xdVpk?= =?utf-8?B?VWRYZUx3Z3hCb2VGeGRuSkt5TjRaSnRObS9FNjkrV2tJalI3UDEyM3QwdGdp?= =?utf-8?B?blZnRFJzRmtMM0l5Uis2M1RsbXBmV2xEdUIxMm9XMVZlQnRibVpKZHVERU1y?= =?utf-8?B?K3NORFdxcnBteEUvSWsyb2lKcjg4S1Z5WjYvK21OOHE5ZWJOaUQxVlJaejA0?= =?utf-8?B?djJDRnl6OUMyZkMrTVFiTCtkMTRIYUU5UmthN0gzblg2VFdZY3djT0puYVp2?= =?utf-8?B?TGdDdkNkWkVGcGhSS3lQQ3c0RTVzVDMxaURYTHFLRnY0K2tPYkdTRy9uWG4y?= =?utf-8?B?KzE1U0VVSDRiMUR4U1hOb3ZXeWdFWVhCN1B2ZG9mSW4xZnJFUFVqdWF0aTI5?= =?utf-8?B?L0xOcDZkcno1RmVXMERIUWxaYXlTV0Viamw5aTdaUlZ4a0Z6bitkMzBCdWJX?= =?utf-8?B?TTVrOXFpM0owNWpNSDF0ZTZUSm0zRDdBMnpZdWhMQUcvL0cwdnlodzB0cVE2?= =?utf-8?B?MnpYbjBNUW5oYVJ5UlB6VGFodlRQVEpXek5sb200bWVhQ3pHazZoQ0lCcTlQ?= =?utf-8?B?QlprQVBaZVI0dE5GNVBJeWt6VjFvNzJMQithVmdZRm9lcmlUUW90c21EMW9W?= =?utf-8?B?eTlqbVA3SlRFbmxzNGpPTnBkVkVVaDllSjdkV3VVQ2w1Z3ErQ0tKNmxYK3VJ?= =?utf-8?B?NFJudnVRS2FrMkRwNGZ5MEcrdXNsZGZBYk0vQWxyVWVnK2d2RlI0Qm0xVVBi?= =?utf-8?B?dVRKaFVidjNmeTVlam9KRUdLaGxqR2VXWGdBbjVmT1hUVkErWEtsc0tNYUZr?= =?utf-8?B?YVNyeFUzUDhkdEFWcWxLWWkzclZURUxnTUZzUjIrSEZhOVRIQVFpNnZEZ1ky?= =?utf-8?B?OHp2M2RZdjZVaXlmVml1RzFpRTJuTlh1OVJPSTNhdDJYR0FtclhFdGRlaXJy?= =?utf-8?B?clo1bis3RzNlUVJGSG5iK0ZlSkh1akFzcnBkakREK050VllQc0VORlNKRmVC?= =?utf-8?B?TUlJOUs2SlNxMHlCS3p0LzFVMUhJNGUzenZCa3hQOHRvaTVsYllTUGNZaWxU?= =?utf-8?B?dUQ3V1ZvZ295UzFPVGVjOGVPTGtPcHVISTN1MDhtNUdzM25HWVN3NzdHVkV1?= =?utf-8?B?bGlOYzBmWGRmV0FTNWVwNkN0elJrdGh3aDV0WHoraU42U20wclFVMHBwMTZz?= =?utf-8?B?a0lLN3RoSlk0aVhybS8yZDdNV0M0OGtvMkdackZ4YkxacVd5YUNMdENsaDE4?= =?utf-8?B?NjZuMjczeHZEWVJ1NThtZWxYUktKbExUZ211MXpHbUR4aGdUdTFhRmd2M1Uy?= =?utf-8?B?RFdZeFFZc09VcWJkMnQvS2ZUWGlCWWJ6NzFpcloxYTF1Z0xDTFRGK1VOZFJX?= =?utf-8?B?Y1h0OTRUOWlLL1ZZQnpRK0xSQ2F4K2RuUDI2dmd6dTJydmkrb2lRYzJMaG45?= =?utf-8?B?RFZ5Qy9qV0tOTDZnTUw4eEVnY1F5ODQwYU1zdEpneWl0S1FHZy85bkh4SFFi?= =?utf-8?B?ZnplemVFNlFRc1BTQk4wUHRWRjZiQzhZdGN4RFFSUW9BZEs4MkVaQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c6b6e7f-a237-4a7b-79c6-08de786aa9d2 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 14:47:44.5098 (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: 591JOMu4Pbp/HGz4uWZmX/m5eN4upOhJs0W9drrdR2FGZ6lUB3Hy9fGqnNdOXNOpIk5qHBS/X2yqwPiBiwVrI9Paokh+ierGIS5OhsZU6XI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PR03MB8283 On 02/03/2026 11:19 am, Jan Beulich wrote: > On 28.02.2026 00:16, Andrew Cooper wrote: >> ... seeing as I've had to thoroughly reverse engineer it for FRED and make >> tweaks in places. >> >> Signed-off-by: Andrew Cooper > Acked-by: Jan Beulich Thanks. > >> --- /dev/null >> +++ b/docs/guest-guide/x86/pv-traps.rst >> @@ -0,0 +1,123 @@ >> +.. SPDX-License-Identifier: CC-BY-4.0 >> + >> +PV Traps and Entrypoints >> +======================== >> + >> +.. note:: >> + >> + The details here are specific to 64bit builds of Xen. Details for 32bit >> + builds of Xen, are different and not discussed further. > Nit: Stray comma? Yes.  From a sentence refactor.  Will drop. > >> +PV guests are subject to Xen's linkage setup for events (interrupts, >> +exceptions and system calls). x86's IDT architecture and limitations are the >> +majority influence on the PV ABI. >> + >> +All external interrupts are routed to PV guests via the :term:`Event Channel` >> +interface, and not discussed further here. >> + >> +What remain are exceptions, and the instructions which cause a control >> +transfers. In the x86 architecture, the instructions relevant for PV guests >> +are: >> + >> + * ``INT3``, which generates ``#BP``. >> + >> + * ``INTO``, which generates ``#OF`` only if the overflow flag is set. It is >> + only usable in compatibility mode, and will ``#UD`` in 64bit mode. >> + >> + * ``CALL (far)`` referencing a gate in the GDT. >> + >> + * ``INT $N``, which invokes an arbitrary IDT gate. These four instructions >> + so far all check the gate DPL and will ``#GP`` otherwise. >> + >> + * ``INT1``, also known as ``ICEBP``, which generates ``#DB``. This >> + instruction does *not* check DPL, and can be used unconditionally by >> + userspace. >> + >> + * ``SYSCALL``, which enters CPL0 as configured by the ``{C,L,}STAR`` MSRs. >> + It is usable if enabled by ``MSR_EFER.SCE``, and will ``#UD`` otherwise. >> + On Intel parts, ``SYSCALL`` is unusable outside of 64bit mode. >> + >> + * ``SYSENTER``, which enters CPL0 as configured by the ``SEP`` MSRs. It is >> + usable if enabled by ``MSR_SYSENTER_CS`` having a non-NUL selector, and >> + will ``#GP`` otherwise. On AMD parts, ``SYSENTER`` is unusable in Long >> + mode. > The UD family of insns is kind of a hybrid: They explicitly generate #UD, > and hence do a control transfer. Same for at least BOUND. It's not quite clear > whether they should be enumerated here as well. UDn and BOUND are strictly faults, not traps.  They're type 3 (hardware exception) and provide no instruction length. The simplest implementation of UDn is nothing.  The decoder already needs a signal for "not an instruction I know" which is wired into #UD.  All the manual does by defining these "instructions" is promise that nothing else will be allocated in that opcode space. BOUND is weird.  I'm not sure what more can be said about it. Either way, #UD and #BR are not interestingly different from e.g. #PF from a PV guest's point of view. > >> +Xen's configuration >> +------------------- >> + >> +Xen maintains a complete IDT, with most gates configured with DPL0. This >> +causes most ``INT $N`` instructions to ``#GP``. This allows Xen to emulate >> +the instruction, referring to the guest kernels vDPL choice. >> + >> + * Vectors 3 ``#BP`` and 4 ``#OF`` are DPL3, in order to allow the ``INT3`` >> + and ``INTO`` instructions to function in userspace. >> + >> + * Vector 0x80 is DPL3 in order to implement the legacy system call fastpath >> + commonly found in UNIXes. > Much like we make this DPL0 when PV=n, should we perhaps make vectors 3 and 4 > DPL0 as well in that case (just for formality's sake)? Maybe 4, like 9, would > even want to be an autogen entry point then? We could, but does that gain us anything? For 0x80, we get another vector to use for regular interrupts, but that doesn't work for the vectors below 0x10. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 14:50:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 14:50:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244279.1543717 (Exim 4.92) (envelope-from ) id 1vx4bg-0003Wo-4g; Mon, 02 Mar 2026 14:50:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244279.1543717; Mon, 02 Mar 2026 14:50:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4bg-0003Wh-1U; Mon, 02 Mar 2026 14:50:48 +0000 Received: by outflank-mailman (input) for mailman id 1244279; Mon, 02 Mar 2026 14:50:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4bf-0003Wb-8X for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 14:50:47 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2f40d36c-1647-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 15:50:41 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-439b7a87fb5so640404f8f.3 for ; Mon, 02 Mar 2026 06:50:41 -0800 (PST) Received: from [10.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-439b503424fsm11376873f8f.22.2026.03.02.06.50.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 06:50:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2f40d36c-1647-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772463041; x=1773067841; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=olwvB+jj70z4Qp6+y38rWMh4PGJTz8qqZg+5vvB8Bi4=; b=bj+t/u+heQkUWn8jBSONrdWeVm2YBqQ3T0ZD5zAqWwi6gMXksX/64ftHwqHFNd3vmK 1Y+EZV4OBZWWYZclU63Fo1kH87SdoktvDc/nh67PyrhqvKCMGAcHTWn8bGibndAKg92d ufkaPR2ySZv6a4mUCYJdu8qVQks9j4dD8eujZ4Mwiqm4GTQZ+aoOJiB9VD6iLb0uacz3 4ABs70grZfaB52Bc5B9KzKkJOMyh/JpDaF5h4GmGgO4vLOtT35ijLMD2ZwUKGieUQ/sj Ji2vzcBtNEMXCGgAOLxCU1UO7FziL6sPTUgSoOsVqj+lGpVqh+5WklwDnDAAZQdInF7x nMFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772463041; x=1773067841; h=content-transfer-encoding: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; bh=olwvB+jj70z4Qp6+y38rWMh4PGJTz8qqZg+5vvB8Bi4=; b=PQMvGBE8QWgMQjaZ7EtoaSdAhtCRh65Ek3prNtX7gLag1qGI+t6WqoAKSf4mfcUm6F RBxV6pEV5fsISDVG1Bt6FQ8I9YE7zot6BjY8qRGC9vK+siR6MoR/emUdA/91vX6Bt1e3 uuUzMgLpV9/sIQdRt1m/ya0Bam2ZGgtHYnF2g7J8BFfyTwTDCCU5QW6rKv5uM4n3Kxzk 5e4LkAvbGsez3775G/MdNYMRUD3+1TAQLDDrKzZGBP08pLW0wKzS5Ky0s/8uPW71P6KQ 0EEycPG2q6nbOWuduqJj3R4wc5TLBeZhyDNWZUzQ5IxOy3Ft9oEnNYzHrznGqy/VR5E8 xayw== X-Forwarded-Encrypted: i=1; AJvYcCUV9xMabRSrkTWd3B4ilbrUHgUP8GJviADTRfVHFqTjw0Ug6UdJX/l1YXga7egc+oUpZopaqq/lInQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw9c/5pwv+9Z9//fkd4zvlgnYBisaR1XfRqVSNCT4p398K+rU+A GUS4Zhee7ltbqCO4Dnd46YWkgsD/9yAarIWdkKn1rZWJI/Huy1XPnVhQRq8rIU3FLw== X-Gm-Gg: ATEYQzwsxVErkoLhcIGMcUuDugB++4PG0C7RwMMqKR5pG0eq5bM56EKjaseMZIuqTAR hK4zsSKExUWyPe20+j/YcdT68Od1d8Tx6yHNMrsImBfL6HjKJtwnZnRkAOgJT2aUfMj8CHTnc9o ATUxMbXirPzSwu0dwdsZImt9vGIkR+P7qWMMoKlNBcS2pArcOYrT81fFzBwLlNxupKl+Ct2MjiN VLZgroLAMNAZioJHwLQ3kRGx/N6VUMelR78pfLOAkJuM2/xCr36cVtBvT4+zvnhrU6wSu49pAoD 9K2ht38VVsCTPL9uzyyA7CTmFBgJDfSuhaeLWiBBBF5RBkIpl/McXfs4VHOYgWb7vddOOUurohQ 3tGAwlZeQlK5SvnElUd1wPI6vQGNPxGloGhxorsgnkLfyJMCE0Zgeu2JnZA8WGVqVt1Sa96LO3C S++R/0jfuexFvfMHSAWrWY17A+d5k4IRb06Kun8mG4wIX6Bad37BMjdn0r80dkrU00/RoQ8jUZJ KNrSDAX+ce+pa0= X-Received: by 2002:a05:6000:2001:b0:439:b4c9:9061 with SMTP id ffacd0b85a97d-439b4c99198mr8946651f8f.5.1772463041130; Mon, 02 Mar 2026 06:50:41 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 15:50:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 06/14] x86/traps: Don't configure Supervisor Shadow Stack tokens in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-7-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-7-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > FRED doesn't use Supervisor Shadow Stack tokens. This means that: > > 1) memguard_guard_stack() should not write Supervisor Shadow Stack Tokens. > 2) cpu_has_bug_shstk_fracture is no longer relevant when deciding whether or > not to enable Shadow Stacks in the first place. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > The SDM explicitly points out the shstk fracture vs FRED case, yet PTL > enumerates CET-SSS (immunity to shstk fracture). I can only assume that there > are other Intel CPUs with FRED but without CET-SSS. Isn't CET-SSS still relevant to OSes not using FRED (much like you do for the fred=no case)? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 14:54:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 14:54:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244291.1543728 (Exim 4.92) (envelope-from ) id 1vx4fA-00048b-No; Mon, 02 Mar 2026 14:54:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244291.1543728; Mon, 02 Mar 2026 14:54:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4fA-00048U-Jw; Mon, 02 Mar 2026 14:54:24 +0000 Received: by outflank-mailman (input) for mailman id 1244291; Mon, 02 Mar 2026 14:54:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4f9-00048O-KI for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 14:54:23 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id afbeb498-1647-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 15:54:17 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id A22D760008; Mon, 2 Mar 2026 14:54:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D656BC19423; Mon, 2 Mar 2026 14:54:14 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: afbeb498-1647-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772463256; bh=xdku5nig+Gpe25ps3dCqYirfeqxPb+5bKOKhCRkUJYg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=UPpsNxCTCH2blvH4w0w/jJ1uNxzlymqn7amt368g6EWM8QvGvID3bObS60ccOpyND HAIkiYw4t2sxYLmPVF+fHrlSfknoUysycFnsYeg2bwQNQ75N07g9A2072I8QKx1a81 gVJg1SzyUdP2vkCKMC1exl2KjMgBLttDCBDqICh0qCoFV251Ad2TpvLANGUlbvQzqY jilHRz6FHN7uCWt2iHKsuYftP8aVE9eMDcdEldNQpdBQSQ3aHnLKRckGzN+kixQ/rG mVfbKvteJbqXhTZv1DelJq2Edh3ST8tmhSv4X8cncYmcfdELLBhEAglEtkzeNNhARn ha6UbtSzTkLwA== Message-ID: <663cff60-8181-4a47-beff-204bfe01bb06@kernel.org> Date: Mon, 2 Mar 2026 15:54:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , Vlastimil Babka References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> From: "David Hildenbrand (Arm)" 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > >> Whatever leaves the buddy shall be zeroed out. If there is a >> double-zeroing happen, the latter could get optimized out by checking >> something like user_alloc_needs_zeroing(). >> >> See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we >> avoid double-zeroing. > > It isn't just reducing double-zeroing to single zeroing. It's about > avoiding zeroing such pages at all. If a domU is started with > populate-on-demand, many (sometimes most) of its pages are populated in > EPT. The idea of PoD is to start guest with high static memory size, but > low actual allocation and fake it until balloon driver kicks in and make > the domU really not use more pages than it has. When balloon driver try > to return those pages to the hypervisor, normally it would just take > unallocated page one by one and made Linux not use them. But if _any_ > zeroing is happening, each page first needs to be mapped to the guest by > the hypervisor (one trip through EPT), just to be removed from them a > moment later... The same is true for most balloon drivers, including virtio-balloon. So far nobody really cared about that, though, as init_on_free usually comes with such a high performance price tag that people in cheap VMs (where you overcommit etc) don't enable it. __GFP_BALLOON_OUT is just nasty. We could probably have a special allocation interface (not exposed to arbitrary kernel modules) and have things like mm/balloon.c consume that. IIUC, xen balloon does not use the memory balloon infrastructure, though. So we'd need some EXPORT_SYMBOL_FOR_MODULES() magic. Like an struct page *alloc_balloon_pages(gfp_t gfp, unsigned int order); Where we only support a subset of gfp flags, for example, to now having to deal with mempolicy. But it needs a bit of code to make it fly, so I am not sure if the page allocator wants to support that. -- Cheers, David From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:11:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:11:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244302.1543737 (Exim 4.92) (envelope-from ) id 1vx4vQ-00071a-Tm; Mon, 02 Mar 2026 15:11:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244302.1543737; Mon, 02 Mar 2026 15:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4vQ-00071T-Qu; Mon, 02 Mar 2026 15:11:12 +0000 Received: by outflank-mailman (input) for mailman id 1244302; Mon, 02 Mar 2026 15:11:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4vQ-00071N-0N for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:11:12 +0000 Received: from fout-b6-smtp.messagingengine.com (fout-b6-smtp.messagingengine.com [202.12.124.149]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 09dfad83-164a-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:11:08 +0100 (CET) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id 4C57C1D00231; Mon, 2 Mar 2026 10:11:06 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 02 Mar 2026 10:11:06 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Mar 2026 10:11:04 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 09dfad83-164a-11f1-b164-2bf370ae4941 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=1772464266; x=1772550666; bh=G24RGZBjHPFOcShGwGjtJ8caC1FzHlA/t0hF5wZgn9c=; b= bv1cihPJhnbx3v8DhHB79R5TJpJVuiU8OxBRgcisWXPnWAzwq7uBh/hdDfN4Ae3X C2seMVC7kxmEO9BbMEQu80P/Dnj+NttxSLMlNdBGypCOpAmedaXG6N0lUUUpB+Cj q43QNt1hnX7nkxtns4wkWVjc7C+VGAj3Wgz896nEM5xoHflPY5hspRRKBxDLAVXG z3hyGypHxksDyYAQO2lSRnaqluqgHGoQysr/2HZuS4S7UrCuNYpchPT3IYYd15rW GfK++/ZJrCa/B1N/aEaIc9+Cb92iIFeLKhqviT+TPYj91s8JkXL7XeOH64thER+H xEebQpaFpIhU/6yJCZu8Pg== 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=fm1; t= 1772464266; x=1772550666; bh=G24RGZBjHPFOcShGwGjtJ8caC1FzHlA/t0h F5wZgn9c=; b=RzaYC7Vh/wmZhzD40BszbqWPqEsg6FNcOJ3gDqILrdiCUd3De62 oBk0QpWJFrhJfBQRWs3GywP8gYLaLD0EFuoLv2bm/To7bthv6/vIrdPB6AypB7ga jy5gXdHL9D7R9uMtaS3ZCjvV8vTHbPb5KXT0icjeGMGu9bc5Msp5Xq3i/K0AEc25 UiBIFdICkA4FkWPjbM0naS5AnHHVhlR0giMSohwJKG0dcWDYsEqaRonnvXvk6Y/j UbYwGtzcWfMDB+3iT6tn+0nwQHUfd+BQSgfg1hzijj4AEeAfxKB8HSYNZVKCDiQj 8YhRUZjAOXZ1oZGxLREmdSJT3b0yXD1if9g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheektddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrvhhiugeskhgvrhhnvghlrdhorhhg pdhrtghpthhtohepjhhgrhhoshhssehsuhhsvgdrtghomhdprhgtphhtthhopeigvghnqd guvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopegs ohhrihhsrdhoshhtrhhovhhskhihsehorhgrtghlvgdrtghomhdprhgtphhtthhopegrkh hpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtghpthhtohepvhgsrggs khgrsehsuhhsvgdrtgiipdhrtghpthhtoheplhhinhhugidqmhhmsehkvhgrtghkrdhorh hg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Mar 2026 16:11:02 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: "David Hildenbrand (Arm)" Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) Message-ID: References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> <663cff60-8181-4a47-beff-204bfe01bb06@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MpPnWTvKkkn2ESlm" Content-Disposition: inline In-Reply-To: <663cff60-8181-4a47-beff-204bfe01bb06@kernel.org> --MpPnWTvKkkn2ESlm Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2026 16:11:02 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: "David Hildenbrand (Arm)" Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , xen-devel , Boris Ostrovsky , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) On Mon, Mar 02, 2026 at 03:54:12PM +0100, David Hildenbrand (Arm) wrote: > >=20 > >> Whatever leaves the buddy shall be zeroed out. If there is a > >> double-zeroing happen, the latter could get optimized out by checking > >> something like user_alloc_needs_zeroing(). > >> > >> See mm/huge_memory.c:vma_alloc_anon_folio_pmd() as an example where we > >> avoid double-zeroing. > >=20 > > It isn't just reducing double-zeroing to single zeroing. It's about > > avoiding zeroing such pages at all. If a domU is started with > > populate-on-demand, many (sometimes most) of its pages are populated in > > EPT. The idea of PoD is to start guest with high static memory size, but > > low actual allocation and fake it until balloon driver kicks in and make > > the domU really not use more pages than it has. When balloon driver try > > to return those pages to the hypervisor, normally it would just take > > unallocated page one by one and made Linux not use them. But if _any_ > > zeroing is happening, each page first needs to be mapped to the guest by > > the hypervisor (one trip through EPT), just to be removed from them a > > moment later... >=20 > The same is true for most balloon drivers, including virtio-balloon. >=20 > So far nobody really cared about that, though, as init_on_free usually > comes with such a high performance price tag that people in cheap VMs > (where you overcommit etc) don't enable it. >=20 > __GFP_BALLOON_OUT is just nasty. >=20 > We could probably have a special allocation interface (not exposed to > arbitrary kernel modules) and have things like mm/balloon.c consume that. >=20 >=20 > IIUC, xen balloon does not use the memory balloon infrastructure, > though. Is there some fundamental reason for that? By looking at the code, the migration to use mm/balloon.c shouldn't be that hard (famous last words...). > So we'd need some EXPORT_SYMBOL_FOR_MODULES() magic. Then this wouldn't be necessary. > Like an >=20 > struct page *alloc_balloon_pages(gfp_t gfp, unsigned int order); >=20 > Where we only support a subset of gfp flags, for example, to now having > to deal with mempolicy. >=20 > But it needs a bit of code to make it fly, so I am not sure if the page > allocator wants to support that. PS adding linux-mm, which I forgot initially... --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --MpPnWTvKkkn2ESlm Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmlqIYACgkQ24/THMrX 1yzgLAf/ZIEUT6k9z5/fgbuUUNXHUz/cYZVPQQ7+FxWEUSulVLSDU11knsr8AE8V KxL6265ebqfUlsCxJC/wi4zFN29L+Dy9JHUy5hMAPUSoQF2DPjKjG6JKvFYixjiA pT/r6IV65IORZtyKlkkhrcoXI/hKSWclI05axyUwS1xvtEtEmoS1Mb8bZy3jlOue N9tMSkq7MECf8cTg6CXK+koIG3A3WZDS1ZN3jZy7sF9/tKhQILstDQnsBsm8unfb +vOUYUGxftpEGYeJLBHcq/ExwQS9E6FX4aaDF/ISzt8Z06KWRxyROBQYFXvPkftN zhM67qb2vVV2kFIVpKHV6mat3UONCg== =sXTT -----END PGP SIGNATURE----- --MpPnWTvKkkn2ESlm-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:12:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:12:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244310.1543747 (Exim 4.92) (envelope-from ) id 1vx4x8-0007Vj-7f; Mon, 02 Mar 2026 15:12:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244310.1543747; Mon, 02 Mar 2026 15:12:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4x8-0007Vc-47; Mon, 02 Mar 2026 15:12:58 +0000 Received: by outflank-mailman (input) for mailman id 1244310; Mon, 02 Mar 2026 15:12:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx4x7-0007VU-0G for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:12:57 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 49e04c48-164a-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:12:55 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fPj9K6ZQHz35hTRY for ; Mon, 2 Mar 2026 15:12:53 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id fb2ad6a223ec4fbc99e8451c1e815e95; Mon, 02 Mar 2026 15:12:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 49e04c48-164a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772464373; x=1772734373; bh=RTaZqS3PvGkavhrM8JFJRLxcqXxTqAdbTc8WRXPL040=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=eFAB9KXU6usOD9CQKV3G68e0fgqxb1OWyn7ybo1vFX8TIkvOMBSEHux/JcHVpXAOc rqiI3+Oi7N/B7d6V4qfsEdlTGjyP90jVJ12DYu+UZcCOBDlfcpccoNnOqUMVM7ZNTH F2isDDKQziO0QVMyK45Y7oPZqK66klboYL8JIwg1pRjx+ZX5VPT78ZWuaWfx/VTFcw oJkdMSlt+T+k2I/bcaivm19TRmPUValhahmwXvJNhPcLo4VmcebsWFJBJJBj54stZ2 VMWF/lUqHK6wKRxFo+AXA3rTa1xAA1ci5BriHx4LFTZxuq9quw7kZ/LjtRkYrUJcQ+ 4WjWXG1uQ8RbQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772464373; x=1772724873; i=anthony.perard@vates.tech; bh=RTaZqS3PvGkavhrM8JFJRLxcqXxTqAdbTc8WRXPL040=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=W3YmwKPyca4ki2flYBzM934IYBPtdaS87ix0hAGyHZ0rZfJkyTforXi0cLHcnNNCO wFdl2Ch8EfQ9HNOpZO6c+tpu7w66xmLtYrg2ME1mPJbK0tcMDyZvh+HIdNY5LTI5Yl f/Oxm2FWHeyUJNq6d+HsG6alvrjDJ4W2qPc/9VqD6z5pbEZvdKawTuIRWoEKaOJdEz uNwjnI1KIL6YpEGYiyZOmMqjTom9BSGJv4iLmKUnZOgjGLdW7dWbMdRMJD4fgJfyAE E1xTQ9GmS97jpKiEwITvq7PzZavd94rEJDD4grBv+P3rnrZ+1Rapk3LuxpBP87COLY uAuYpfLwwL1Wg== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v8=201/2]=20libxc:=20Report=20consistent=20errors=20in=20xc=5Fresource=5Fop?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772464373342 To: "Teddy Astie" Cc: xen-devel@lists.xenproject.org, "Juergen Gross" Message-Id: References: In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.fb2ad6a223ec4fbc99e8451c1e815e95?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260302:md Date: Mon, 02 Mar 2026 15:12:53 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, Feb 27, 2026 at 05:00:05PM +0000, Teddy Astie wrote: > xc_report_op doesn't update errno in some error conditions. > Make sure it reports -ENOMEM in out of memory errors and -EINVAL > in invalid usages errors. > > Signed-off-by: Teddy Astie > --- > v7: Introduced > v8: Use errno to report errors > > tools/libs/ctrl/xc_resource.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/tools/libs/ctrl/xc_resource.c b/tools/libs/ctrl/xc_resource.c > index cb6a97202b..ac1524d1bd 100644 > --- a/tools/libs/ctrl/xc_resource.c > +++ b/tools/libs/ctrl/xc_resource.c > @@ -28,7 +28,10 @@ static int xc_resource_op_one(xc_interface *xch, xc_resource_op_t *op) > XC_HYPERCALL_BUFFER_BOUNCE_BOTH); > > if ( xc_hypercall_bounce_pre(xch, entries) ) > + { > + errno = ENOMEM; Looking at xc_hypercall_bounce_pre(), it's looks like `errno` should already be set. On Linux, that would be `mmap()` or `madvise()` updating it. > return -1; > + } > > platform_op.cmd = XENPF_resource_op; > platform_op.u.resource_op.nr_entries = op->nr_entries; > @@ -54,11 +57,15 @@ static int xc_resource_op_multi(xc_interface *xch, uint32_t nr_ops, xc_resource_ > call_list = xc_hypercall_buffer_alloc(xch, call_list, > sizeof(*call_list) * nr_ops); > if ( !call_list ) > + { > + errno = ENOMEM; Here, xc_hypercall_buffer_alloc() should already have updated `errno`. (It's a function called by xc_hypercall_bounce_pre(), so we've got the same culprit updating `errno`.) > return -1; > + } > > platform_ops = xc_hypercall_buffer_array_create(xch, nr_ops); > if ( !platform_ops ) > { > + errno = ENOMEM; Here, xc_hypercall_buffer_array_create() calls `calloc()` and `malloc()` which will update `errno`. > rc = -1; > goto out; > } > @@ -66,6 +73,7 @@ static int xc_resource_op_multi(xc_interface *xch, uint32_t nr_ops, xc_resource_ > entries_list = xc_hypercall_buffer_array_create(xch, nr_ops); > if ( !entries_list ) > { > + errno = ENOMEM; Same as above. > rc = -1; > goto out; > } > @@ -81,6 +89,7 @@ static int xc_resource_op_multi(xc_interface *xch, uint32_t nr_ops, xc_resource_ > platform_op, sizeof(xen_platform_op_t)); > if ( !platform_op ) > { > + errno = ENOMEM; With xc_hypercall_buffer_array_alloc(), `errno` is updated by `mmap` or `madvise`, like the first case. > rc = -1; > goto out; > } > @@ -90,6 +99,7 @@ static int xc_resource_op_multi(xc_interface *xch, uint32_t nr_ops, xc_resource_ > entries, entries_size); > if ( !entries) > { > + errno = ENOMEM; Same as above. > rc = -1; > goto out; > } > @@ -137,6 +147,7 @@ int xc_resource_op(xc_interface *xch, uint32_t nr_ops, xc_resource_op_t *ops) > if ( nr_ops > 1 ) > return xc_resource_op_multi(xch, nr_ops, ops); > > + errno = EINVAL; Ha! This one was missing indeed. The patch description will need to be updated with all the chunk be one been dropped. Thanks, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:20:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:20:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244320.1543757 (Exim 4.92) (envelope-from ) id 1vx54L-0000ld-UE; Mon, 02 Mar 2026 15:20:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244320.1543757; Mon, 02 Mar 2026 15:20:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx54L-0000lW-Rd; Mon, 02 Mar 2026 15:20:25 +0000 Received: by outflank-mailman (input) for mailman id 1244320; Mon, 02 Mar 2026 15:20:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx54K-0000lQ-Lz for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:20:24 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5413e994-164b-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:20:22 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by CH7PR03MB7836.namprd03.prod.outlook.com (2603:10b6:610:24d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.16; Mon, 2 Mar 2026 15:20:18 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 15:20:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5413e994-164b-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GCVQmWzyHfIo486Eu4WQRMNKDu5qqMMeQ+ZVVwHMCnmQKSnRq79yZ/+SEPGakf5ZPm6AySOzmO0eIB+P90EBBGHgEmD/yQGtY37zb0PYKadHEzfF9Rg79SmASWfN6qAq9ReE8PEseXYgOOhNCuEa+/z0UT7kwjkv4dKBuChlK1scjBCwBmRAjQkoUQbh44dL7KU1IDvB3rwtlfzG3QMIRvUCLLTxhpSsnguEtm1yWteDpojgX9dp1mdHgMzVym6N+tlq+sTE6jv8BctcETW6kSE0/hUvuDYUeL2fb/oQNX7cF5lf1IE8OAWAovAL0j1e52JTnUB+JLWlcTFM6kkiFA== 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=5wOCTqxj/1SxmDnjiqGn6uc06WnJkoCDJt/Ihes/upw=; b=B/9uMl39sSPTd1MU4LsmrUdaevR7VYFC+70+49uJco2w2gvsXH8v0LpVkys9pQadPYa5164eDU6xHzZXX6RAPkk9sldujPCK8Xd+mZqsjmrUyWWd5ca9vu5NqDYmjohE6/atlLKfap6CxxCZJm6UYjuUXgG0pQvav5X3kB+qYqHFIWbCrPEuJolWZO+AILPK7QgpKiCafkf6vJMihqBWt+o5iOsFiKToEHwOet/dk3v4NnHGw7BUgegNUMYtLq0aX7Ru5VVxCz9mf3c3LdgAQXZGakcvPbLgSx529LUxrpJKqy8XtGcD71eU3vvPmxbYVBue3kK6rtxJgbEpT2roVg== 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=5wOCTqxj/1SxmDnjiqGn6uc06WnJkoCDJt/Ihes/upw=; b=RKLtHFfQNDyTN2XEjE4N38Xl9skIAWHIQbGRcbcglcNBj07EHuSHREye/Lt3U8VmQmEBcFRVdO42NcsRW+1ALd+izMq4Wdgb2Ib50cwW9y+mJKulMP6l9E/6wt4DgHh/uXKl3R6SyXQAhPQRftN3H8K2PqmvEfU5PV/UJqP7nTM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 2 Mar 2026 15:20:14 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v4 04/14] x86/boot: Document the ordering dependency of _svm_cpu_up() To: Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-5-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260227231636.3955109-5-andrew.cooper3@citrix.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_|CH7PR03MB7836:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c6592c5-3487-47c5-a4ce-08de786f360d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: ztzEAuidVpFfrBHAGuausN+x0kxBNuWrnt45ncDMpWKPiO9tFUdruwESCNndEMs3enRLzwaj05X0NUSVrnsSREcPfCBDlT5dPSdTgsKQMccBDENPS91V+tpQWv54Hc0YbkoIoynvdw7uRkXGXa/I1NwBxC2KL5t6sxYHboA+G9IprMpMxNbRbBbUZnygxSJV4O5I8Bik2xsBsfboBCyqZuwFme8W9aBlPdUHk460Z7L7M3N786/uXugryHB1wdbTQtHu0P0eL2QhwPk4LGYNXeALAQQEA37V7Wu4uVCYbQXnjvN1ZuLmd8PqcGLIBCihpLUGQiz9++ETosAXZ1Gh1wBNpjW028ytCMbpMQ2+u1RJVnVdfFYpx2YDr5nzCcr5zzf8Pirv7g3YaMKoY1GL7cbRQtH50OtRqHqh5v4lx2g+z4OLqgeUwMwGAm/UID5fWoVKCFUSMQCkt35q9mSUoKjNmfVDJoB46xCiLHdogULt5fRTplEdEYFp+aqlxXAWsn54KoT7pddkAPmy0bFAILJHa2X6FFkuDp692Dt4u3DEznD4QuDKcBuQqeP8mRa5FThm8I9HdtVnSjnK/MlVqp3f+OuLNcaNvcaw3YRbrEj+T1WfJFHUZVdSnmTwo3s0fMRcKnAOGBIJCVFqa4le5LS6oiLnohfZkMHSTTsJJsMbj/+TD2dLR4v2nI6dOb+xvOKDviSL+xpDaJv3dvRBs5+gTnqhk3/5bquJh6zx6Fc= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZS9lUGxzd0w5VjQybkNYQWJuWHhMWUhXa1BXR05ydHJLNHdYQnVyaUwzdDEw?= =?utf-8?B?WkZrSHRhc3dabGt3NXFVY1h0ZHNXMUdnaWRpV2MvNW4vblVXaCtmZDJJS2RI?= =?utf-8?B?L29jNGw1d1gxZm5VekRiL1Y3ZDlYYmJWSUYxd05SNjVKS2lmeXB1MVg3Um9w?= =?utf-8?B?NmxjeitRUmcwMlBnczNqN01BbWt6N0lBK1lEcDNIMnRSL1dPT2l5bWZIay9r?= =?utf-8?B?Yms1cTVrNE12bVhOTjRvZ2N6bDhWMlNtWWxXVFZSUHE5UnRFTEY2QUJVK1l3?= =?utf-8?B?RWdxbnd1MGhrbGhncGxZRWFHYU9yTVA1NVBTZ0paZGNRMnI4QjNtdFZJWlZR?= =?utf-8?B?SG4rWUxEd251cEpxTnRhOFZCdHZ0OHJOdVdTRTU4Ymc2N2RXNjVQb1h2Tkk1?= =?utf-8?B?L1RuQ2UyeVNpU3NCZzZ4NXhlN2hWQW5tWTkxNFFyTTVUQWZnT21HREdNbWRQ?= =?utf-8?B?S3VZdWxRTFY4d2dkb0tZK3lTc3BSanFWN01qQ29zbVNUSytmSjE4NzU0SXVN?= =?utf-8?B?ZVA1QXIwZTdld2VPQ1ByWWNkdjdVMGxKQlVvcFN6UGNwQXZleW82ajdZZGMx?= =?utf-8?B?Q0NDTGJVVGd4RkQxNEZjRFMrbm5mcHNTbWVva3ZUV2pFSWcxK08rd2txQmg5?= =?utf-8?B?L0liTFY5VUc5Ump4dWNCVWh5L2Q1KzlOY252WmNpb1lWdXJvL3VCYjJKWDJK?= =?utf-8?B?ZURTcVMwdXRUZjdRVWpNQWhYUjJqUzkxZ3oyMk9yeE9FamUyM1dKOFo2WGds?= =?utf-8?B?WWFwUnhKM0FvTnpDdlVPZ25BRVpzbDVsdmo2L0d0Ukd4MUhlZUhnNjd2aUZi?= =?utf-8?B?d1JtYWUrR0x0Y1hUWm42ZHk0NzF4MmlyU3JsUXJ3SWw5WXd5S1YvcUEzMVI0?= =?utf-8?B?bnRVbDVtMXA5cHp4RFBHZGNURW93c0doUzA5QXVLZzcxZnlZMTBUd1g0T0ZL?= =?utf-8?B?cGVaajBrRHlvMlR4L2R0R1YvQjZQMlhkVDJLU2IxV0RNVnp5RWZtTmJ0WlZC?= =?utf-8?B?R2JOdWhxUG80TmJQVHNjRldtRC9xRG5mNTFvOWZka1FFTndVbVFxWmNkZEw0?= =?utf-8?B?ZmQzcGRCbUdVODhGcXFNRy9ZWU9SdGt4ZWNVTU1JT1AwRHhNOXBBRE5wR20v?= =?utf-8?B?VnJJY1NSSmtsaVFtTmpvMDZ0eHMxck1BcUVsT0p3R3ptZGttR1JacXp1K2ZZ?= =?utf-8?B?ZndlOXJYZkJhS0htS0FkNVJ5bkEwMjNXbFVvMEhiaVpOK2NsZmZnWGprRU5V?= =?utf-8?B?dkVGRG9uNFhmWjV6dnpDUGk0bEpXak9NNEtpcG56ckcyVjg4bVdqVHVaejFY?= =?utf-8?B?dVZwT0s0RlB1M2JJR1F6NFBPaFZDcVBHT0hXOTlXQmFTeTJWM0ZwV1VhUXh0?= =?utf-8?B?OHlFeFowN3hKRlZVZmlhcTRxZE1tQm5WcE54MWxieTdxSlFINnlwTnlxSVYy?= =?utf-8?B?bFhscjhrWWlQS0JERTR0R3Rkc0VaQWg4T1J6RnNxWUcvTkgrNmNCS0xrU0Na?= =?utf-8?B?TUhLVUNtUEdwQXRqNEl2Tm5wajNwYXBGZEVkWXB0ekFCeGN3ZGNxUktrL3dl?= =?utf-8?B?aW4vQXUzZUh6QnNQaU13bEVYRllsaEtEN3B3ZE1IY3R0OWdxbnEvbFRMS1pV?= =?utf-8?B?Um5zbU8vMVcwWGJSdUFoNWxJRW1tK0kwOFg4ZURrL2R0c2NxRGhLanlyWDhF?= =?utf-8?B?TVlGSVZqVUFZVkFodXFyTHFjcklFdDlvbFFXU25KZFhUeFFWc3FwL2ZYeWVh?= =?utf-8?B?cXBNL2xyNW0zZjZObVlBbE9NYWtVT21LcUplMmxHVnNvKzNsWnRZeCtIWUVt?= =?utf-8?B?QXRDUVJRSk1NakRKWnExMmp2b1Y5b2FvRHR4c2ozZnFCSXFRblhKb3VneXpR?= =?utf-8?B?dDJJYkFZV2NVSXVWNnhzVUc0M1ZuT3dKblpLUEFXSVQ5aVlReEVicFE5Y09E?= =?utf-8?B?MzIzTXhIUEFsVDdHemFqTVRqOVF4cFVuWHZXbkVtZDYxc0NJNGtzNk91dG00?= =?utf-8?B?VFoza0gyUms1bW12M3N6ZmlHY2dMZ2pINU84dmFJbzZzZU41Szl0MWZFL2VX?= =?utf-8?B?MEI2OFFiL0g1Sm1naVNTTENtaVlDbStJaDk5aHNDd3Y1VUM0MGcxNVRwaWEx?= =?utf-8?B?VkhuWENPdG5UemhnamRncHgreFFOT09VQis1MkowaTRpbTZOcnFCMmVneTAy?= =?utf-8?B?aEs4RkljYUdGeGt0N1c1c2xwazExb2ZhdjMrblh0Q0ZPWUdqSWdzekQ5MnBF?= =?utf-8?B?NW9OTGZHZFBXZlhsZFBLVDdBV1dKWWFsUVl6cXAzd0x3K2N2RnVlblhLNFVz?= =?utf-8?B?VmNjN1htNkJMNGlvY1NyOWFNNFpYL3hWU2I0VkQ1c3VNYWx5UGY5QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c6592c5-3487-47c5-a4ce-08de786f360d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 15:20:17.8348 (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: FG6QsstMdgRmenaFGgdANWvJy4G/9rq5uR4l2SZNIrZ4RBg+0DHo3gadY5wy2jWtmEhUdhEfvl7hjvmT6oiMQyJatU5/XRgW7ImWS0/DygI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH7PR03MB7836 On 27/02/2026 11:16 pm, Andrew Cooper wrote: > Lets just say this took an unreasoanble amount of time and effort to track > down, when trying to move traps_init() earlier during boot. > > When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the > BSP, the first context switch into PV uses svm_load_segs() and clobbers the > later-set-up linkage with the 0's cached here, causing hypercalls issues by > the PV guest to enter at 0 in supervisor mode on the user stack. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v4: > * New > > It occurs to me that it's not actually 0's we cache here. It's whatever > context was left from prior to Xen. We still don't reliably clean unused > MSRs. > --- > xen/arch/x86/hvm/svm/svm.c | 16 ++++++++++++++++ > xen/arch/x86/setup.c | 2 +- > 2 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 18ba837738c6..f1e02d919cae 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -35,6 +35,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -1581,6 +1582,21 @@ static int _svm_cpu_up(bool bsp) > /* Initialize OSVW bits to be used by guests */ > svm_host_osvw_init(); > > + /* > + * VMSAVE writes out the current full FS, GS, LDTR and TR segments, and > + * the GS_SHADOW, SYSENTER and SYSCALL linkage MSRs. > + * > + * The segment data gets modified by the svm_load_segs() optimisation for > + * PV context switches, but all values get reloaded at that point, as well > + * as during context switch from SVM. > + * > + * If PV guests are available (and FRED is not in use), it is critical > + * that the SYSCALL linkage MSRs been configured at this juncture. > + */ > + ASSERT(opt_fred >= 0); /* Confirm that FRED-ness has been resolved */ > + if ( IS_ENABLED(CONFIG_PV) && !opt_fred ) > + ASSERT(rdmsr(MSR_LSTAR)); It has occurred to me that this is subtly wrong.  While FRED doesn't use LSTAR/SFMASK, it does reuse STAR. So this needs to be:     if ( IS_ENABLED(CONFIG_PV) )         ASSERT(rdmsr(MSR_STAR)); with the include dropped, as the final sentence adjusted to say "even with FRED". ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:21:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:21:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244328.1543767 (Exim 4.92) (envelope-from ) id 1vx55i-0001J9-Az; Mon, 02 Mar 2026 15:21:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244328.1543767; Mon, 02 Mar 2026 15: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 ) id 1vx55i-0001J2-78; Mon, 02 Mar 2026 15:21:50 +0000 Received: by outflank-mailman (input) for mailman id 1244328; Mon, 02 Mar 2026 15:21:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx55g-0001Is-OQ for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:21:48 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 87279418-164b-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:21:47 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4837584120eso33136355e9.1 for ; Mon, 02 Mar 2026 07:21:47 -0800 (PST) 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-483bd75df9fsm491001415e9.13.2026.03.02.07.21.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 07:21:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 87279418-164b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772464907; x=1773069707; darn=lists.xenproject.org; h=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; bh=ETlvC185db5TbfgIdZN3woKwjLCVJdZ9mMDN+oYJ5tI=; b=OsEeR0/UnBedT/WH4A/AZFgpZeOKUA/viGv0q/jMAh91XZORd5vBs/8swBe75PklDK nURCX/IUMTuwilWq0+ZKduj+YHo+aULzjFal7nVZcv+I4D4qonxqy0ip89i/7HmuLp5N DR9EcN3G4rnZhSeMxoBjm9H6YPavOQIDsHTu2+cTKRSRCA/1QEsUPRaDR6oTgyRyxXRg mt8MD4al4HKI2R6aVc+0sDgXVffg2/QB2j1xn1g3OXdhcqZVnk0OPK/BogTeGQz0bg+z bbUPN7K8Ig6A0bdbZpn7BIfJ89FWWjIvgvcSX7IFZ6WXM7qPsVnL5gywq9Iefl22Mvsh yCIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772464907; x=1773069707; h=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; bh=ETlvC185db5TbfgIdZN3woKwjLCVJdZ9mMDN+oYJ5tI=; b=DcdJUtgIPhhgeui6FSpe3Hbg7fHRjGlV1KAJMDs0iJBwtu9yeYNfJEYXd+kGSo9v3W iY0aV41ffFgRY2pTqGF+ibOETAy+W38XeU6/tf6+ThpbTC4oGau4YKQ3mO9d9R1u/pqY YfCZS4XQGBHtgNNVcjirhWbuAZkOERv2JsPL2zxOEpmaz0D2Jv9KpndQT61jcNvJeLBd 3UIXErQX+XcipQ8nTVMhNRXp84nPN3yg0xGUjs8ttPqiEU0GmyDaFPmsMLe+Cx5f6gJH KGxITmcXph9RYw2350l+TRw6idtErPSVuwWiYd/JF65Vm62teWMKUEYjqOstL46C4EQE T+SQ== X-Gm-Message-State: AOJu0Yx9EyhDIp7Oi0gUaW5Np4ZO9R1/mtPwaFWBnLTchhZVW73uayZt NU7pfevhhAfqezy9FHcnmUZDK8JdKYoOPV38XMExMZ1OsxQwH+UiFcMDAqaZm78rRn8= X-Gm-Gg: ATEYQzztJTcavlUNdJmKi1SIKrjGhhFUGk4XQCpCoU3orei8TAbYhJ9HES9vrkm6SGo itjlFiLcT7gnGuFlPwvJhXGL1a1LKcBx99IbQZgI4cfn4PtAZfA8i95GPedCX5YCjAeWq7/ypFY i5HXj694J7HHEOgwActyVtFRa+G6ItUVpnt049vK3snIqLfCB2YRnhCh6eCME8rwC5hWPiE71UN ptv8X54ejOp86sZT5L/Snf2LTs6qFaUXM39GBfzCjQHYGPJuxC/d4PmUyDOmpUNVd1i3H1akc37 It0tm/BkaCf0t3DQqAa0qKJUi+5jwQ+U5+Fp+xyx6hw7CkGrZ/4YWMSWkiQPGefrTBxqbe4Ps7Y b+HsYirZdDLuUNnNsvGw/7mFhL/aoW9wtW1z94I355rHCb3C9h7Lx5cid2cXbkLnKB/wRZsfwZe JSxaZ8CJG4IicZ3xnhWPTPlSBdSATB8rdLJQgOVvBId1D5h7y4typJ1/R/5lvyOtCPl8VUgrF1j 19Pd1gsjDSdNrijJFTGwpk0cztbMirjgYldjBTi5dhdHvHVhG+EiowxK7q0gbWn X-Received: by 2002:a05:600c:1e89:b0:483:badb:618b with SMTP id 5b1f17b1804b1-483c9bc55e1mr209049255e9.24.1772464906439; Mon, 02 Mar 2026 07:21:46 -0800 (PST) Message-ID: <9d30d9ea-c080-45ff-a77d-30f79d4e800e@suse.com> Date: Mon, 2 Mar 2026 16:21:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , "David Hildenbrand (Arm)" Cc: xen-devel , Boris Ostrovsky , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> <663cff60-8181-4a47-beff-204bfe01bb06@kernel.org> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------y09wBeURikoDRh6YDGjmJ4El" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------y09wBeURikoDRh6YDGjmJ4El Content-Type: multipart/mixed; boundary="------------e1DxIpki1MRw3sNDu0gCKGiO"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , "David Hildenbrand (Arm)" Cc: xen-devel , Boris Ostrovsky , Andrew Morton , Vlastimil Babka , linux-mm@kvack.org Message-ID: <9d30d9ea-c080-45ff-a77d-30f79d4e800e@suse.com> Subject: Re: Excluding init_on_free for pages for initial balloon down (Xen) References: <513e624f-35c1-4d43-ba3f-c96af613d400@suse.com> <224968e6-7236-4efe-bcc0-ab39ac0c6c45@kernel.org> <663cff60-8181-4a47-beff-204bfe01bb06@kernel.org> In-Reply-To: --------------e1DxIpki1MRw3sNDu0gCKGiO Content-Type: multipart/mixed; boundary="------------v5nbIR44GMrnBS70Yhw0f5mu" --------------v5nbIR44GMrnBS70Yhw0f5mu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDIuMDMuMjYgMTY6MTEsIE1hcmVrIE1hcmN6eWtvd3NraS1Hw7NyZWNraSB3cm90ZToN Cj4gT24gTW9uLCBNYXIgMDIsIDIwMjYgYXQgMDM6NTQ6MTJQTSArMDEwMCwgRGF2aWQgSGls ZGVuYnJhbmQgKEFybSkgd3JvdGU6DQo+Pj4NCj4+Pj4gV2hhdGV2ZXIgbGVhdmVzIHRoZSBi dWRkeSBzaGFsbCBiZSB6ZXJvZWQgb3V0LiBJZiB0aGVyZSBpcyBhDQo+Pj4+IGRvdWJsZS16 ZXJvaW5nIGhhcHBlbiwgdGhlIGxhdHRlciBjb3VsZCBnZXQgb3B0aW1pemVkIG91dCBieSBj aGVja2luZw0KPj4+PiBzb21ldGhpbmcgbGlrZSB1c2VyX2FsbG9jX25lZWRzX3plcm9pbmco KS4NCj4+Pj4NCj4+Pj4gU2VlIG1tL2h1Z2VfbWVtb3J5LmM6dm1hX2FsbG9jX2Fub25fZm9s aW9fcG1kKCkgYXMgYW4gZXhhbXBsZSB3aGVyZSB3ZQ0KPj4+PiBhdm9pZCBkb3VibGUtemVy b2luZy4NCj4+Pg0KPj4+IEl0IGlzbid0IGp1c3QgcmVkdWNpbmcgZG91YmxlLXplcm9pbmcg dG8gc2luZ2xlIHplcm9pbmcuIEl0J3MgYWJvdXQNCj4+PiBhdm9pZGluZyB6ZXJvaW5nIHN1 Y2ggcGFnZXMgYXQgYWxsLiBJZiBhIGRvbVUgaXMgc3RhcnRlZCB3aXRoDQo+Pj4gcG9wdWxh dGUtb24tZGVtYW5kLCBtYW55IChzb21ldGltZXMgbW9zdCkgb2YgaXRzIHBhZ2VzIGFyZSBw b3B1bGF0ZWQgaW4NCj4+PiBFUFQuIFRoZSBpZGVhIG9mIFBvRCBpcyB0byBzdGFydCBndWVz dCB3aXRoIGhpZ2ggc3RhdGljIG1lbW9yeSBzaXplLCBidXQNCj4+PiBsb3cgYWN0dWFsIGFs bG9jYXRpb24gYW5kIGZha2UgaXQgdW50aWwgYmFsbG9vbiBkcml2ZXIga2lja3MgaW4gYW5k IG1ha2UNCj4+PiB0aGUgZG9tVSByZWFsbHkgbm90IHVzZSBtb3JlIHBhZ2VzIHRoYW4gaXQg aGFzLiBXaGVuIGJhbGxvb24gZHJpdmVyIHRyeQ0KPj4+IHRvIHJldHVybiB0aG9zZSBwYWdl cyB0byB0aGUgaHlwZXJ2aXNvciwgbm9ybWFsbHkgaXQgd291bGQganVzdCB0YWtlDQo+Pj4g dW5hbGxvY2F0ZWQgcGFnZSBvbmUgYnkgb25lIGFuZCBtYWRlIExpbnV4IG5vdCB1c2UgdGhl bS4gQnV0IGlmIF9hbnlfDQo+Pj4gemVyb2luZyBpcyBoYXBwZW5pbmcsIGVhY2ggcGFnZSBm aXJzdCBuZWVkcyB0byBiZSBtYXBwZWQgdG8gdGhlIGd1ZXN0IGJ5DQo+Pj4gdGhlIGh5cGVy dmlzb3IgKG9uZSB0cmlwIHRocm91Z2ggRVBUKSwganVzdCB0byBiZSByZW1vdmVkIGZyb20g dGhlbSBhDQo+Pj4gbW9tZW50IGxhdGVyLi4uDQo+Pg0KPj4gVGhlIHNhbWUgaXMgdHJ1ZSBm b3IgbW9zdCBiYWxsb29uIGRyaXZlcnMsIGluY2x1ZGluZyB2aXJ0aW8tYmFsbG9vbi4NCj4+ DQo+PiBTbyBmYXIgbm9ib2R5IHJlYWxseSBjYXJlZCBhYm91dCB0aGF0LCB0aG91Z2gsIGFz IGluaXRfb25fZnJlZSB1c3VhbGx5DQo+PiBjb21lcyB3aXRoIHN1Y2ggYSBoaWdoIHBlcmZv cm1hbmNlIHByaWNlIHRhZyB0aGF0IHBlb3BsZSBpbiBjaGVhcCBWTXMNCj4+ICh3aGVyZSB5 b3Ugb3ZlcmNvbW1pdCBldGMpIGRvbid0IGVuYWJsZSBpdC4NCj4+DQo+PiBfX0dGUF9CQUxM T09OX09VVCBpcyBqdXN0IG5hc3R5Lg0KPj4NCj4+IFdlIGNvdWxkIHByb2JhYmx5IGhhdmUg YSBzcGVjaWFsIGFsbG9jYXRpb24gaW50ZXJmYWNlIChub3QgZXhwb3NlZCB0bw0KPj4gYXJi aXRyYXJ5IGtlcm5lbCBtb2R1bGVzKSBhbmQgaGF2ZSB0aGluZ3MgbGlrZSBtbS9iYWxsb29u LmMgY29uc3VtZSB0aGF0Lg0KPj4NCj4+DQo+PiBJSVVDLCB4ZW4gYmFsbG9vbiBkb2VzIG5v dCB1c2UgdGhlIG1lbW9yeSBiYWxsb29uIGluZnJhc3RydWN0dXJlLA0KPj4gdGhvdWdoLg0K PiANCj4gSXMgdGhlcmUgc29tZSBmdW5kYW1lbnRhbCByZWFzb24gZm9yIHRoYXQ/IEJ5IGxv b2tpbmcgYXQgdGhlIGNvZGUsIHRoZQ0KPiBtaWdyYXRpb24gdG8gdXNlIG1tL2JhbGxvb24u YyBzaG91bGRuJ3QgYmUgdGhhdCBoYXJkIChmYW1vdXMgbGFzdA0KPiB3b3Jkcy4uLikuDQoN Ckkgd2FudGVkIHRvIGRvIHRoYXQgZm9yIHllYXJzLCBidXQgLUVOT1RJTUUuDQoNClBhdGNo ZXMgd2VsY29tZS4gOi0pDQoNCg0KSnVlcmdlbg0K --------------v5nbIR44GMrnBS70Yhw0f5mu 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----- --------------v5nbIR44GMrnBS70Yhw0f5mu-- --------------e1DxIpki1MRw3sNDu0gCKGiO-- --------------y09wBeURikoDRh6YDGjmJ4El 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/Ey8FAmmlqwkFAwAAAAAACgkQsN6d1ii/Ey9f Fwf9EH3eVCcUPnLhmeZGvJl5wVYuyA8jurNChwHN0evqFezznfHweMatiP8h6+gtF0Xv0q9O8DzQ WuEtAbBogZYxsRMqyRrqBhxLPZ5V9BxPF9/Vbw72Sgjm7s5R9jzXfqTKW5MkHnuvtdwTNZ8DKB0T t8rRMZeJfoQgQ3BJ0g8kQemPWTjXTxdg+fI6xZTPtzfZBAzUoIIKG1NjPLC+j9UgBk3XdH6SnKXW Oc1XcKeNQhLkkKUqSBN79tWoWtXU6o6t5rJEHHAAWFVadPuo0ihfTm+67VICHzVrogByCjsZsfEO elF53pC3zyxFRXizLgr1tbyn+o5Jr+Piip8iCw1Z/g== =Qr2j -----END PGP SIGNATURE----- --------------y09wBeURikoDRh6YDGjmJ4El-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:32:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:32:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244343.1543780 (Exim 4.92) (envelope-from ) id 1vx5G8-000392-96; Mon, 02 Mar 2026 15:32:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244343.1543780; Mon, 02 Mar 2026 15: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 ) id 1vx5G8-00038v-5d; Mon, 02 Mar 2026 15:32:36 +0000 Received: by outflank-mailman (input) for mailman id 1244343; Mon, 02 Mar 2026 15:32:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5G7-00038p-3u for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:32:35 +0000 Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azlp170100005.outbound.protection.outlook.com [2a01:111:f403:c005::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 053da25b-164d-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 16:32:29 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM4PR03MB6910.namprd03.prod.outlook.com (2603:10b6:8:45::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.21; Mon, 2 Mar 2026 15:32:23 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 15:32:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 053da25b-164d-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ygBhNx6CZ0JUoXJHLOOj5oSdWIskgbL2/921NrTywXf28Jw5QO25znUzUJ8b5nj4OsfNAmIM6MzQ2myA83Jq5iKhfQPIRqvo6teA1LdWJcmWV+16h/0veX4WW2A5UEkCAzLNziyiEzTBoBTnrD/Ew6iN41uXwqbp2x+ssl5IumKfsPYdDvKI1I6KOpVR9lB5evCMKjVZqJK/8w18HGA8lSyxnLEJes8YZ9iMiZHLdda6LIKCwUnFzMT2dmpFZelosqdUxshHZaMfhm6Fj/zdfDE2hjMxfEQlyyoaSPHu+GhHwlXHK5euPlp/R5ReOk4Z41Ma+Syu5RCMQtTxTRGYaA== 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=fxurID/PMQliVdMIOqTPv+iWoH0RGormiilKlBtxqpo=; b=ss3N2kApwRRv9mBiOQ966o0zTdNDv2sh1KWXAgDbWUEEh5J5i8z0UNo6VwQZjMC2Q+84HVdvFhbdJXYDYKxLDoFpTPALkCCnCzGSm2Vh3AaFazzMiB5Whl81Wyuwn2N/2p6brnSUBST3dE7/FiJDZzzHAJznFVpx6BsWVtkRNmQnz2wxnPI1ClG266b0N8cn+aGmu/ubX4e4PdcMkkys/6/xKdGIABslaKNoo6dMawOv203rbIYAlOncj4F+6J7h3zA6G3eC7SFT7gVDG2kYMOXaI5wzxu5vKLkxy5Qp2Mdf99S6QKBpN0FzloT7FUjzrqeRAIkupxAImvhN4T1dNg== 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=fxurID/PMQliVdMIOqTPv+iWoH0RGormiilKlBtxqpo=; b=LCMjJa7ILc2+AJnMD5jzW4dse+dppLuEsXgWBAUZvc54cbpPKylqLBUJ3sC1BHNh6zIerXMG6qz0jVrpwnXUz09cJb9QwF9dpQaCT2wC72DLu+NnT9EXjPqmGy7q/YS0ZZ11HiaD93fvGaw7V91N+wvySOXo3/fqdWL2aNdSpTg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 2 Mar 2026 15:32:19 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 05/14] x86/traps: Move traps_init() earlier on boot To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-6-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0184.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:311::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_|DM4PR03MB6910:EE_ X-MS-Office365-Filtering-Correlation-Id: 8837b078-b654-4121-76e8-08de7870e618 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007; X-Microsoft-Antispam-Message-Info: WQx+d1V6XwWtur+xZY5/vaJ4+iOIH/c2DB4Vs6Uzv1J5T8CG+MrJpli1DKpqrvRM9JY82XtTv9OBF6uyvHZZ+Gl+pMjdJNrfW3DvVRs5ksM7uVlnXACGZxpk4oBamwYlrD1oVehqTadrQwhxxEmrRNV898NvoRaLGcJpFHR9QF7V3BlSxYt3qi1nq2C3c7XmygAIVYhsP62VX5IA/q+G4CF32QQFdMi9q6EP+LYnQLPvpSBackOW2N5friyCHXIvyFopDXVTIFcAC8VNeCI+8gNBaQyXJQ6KsZTivVpEJLLpCUjOHX1MGET8EOvnrFb8kpaLACx/QwRjneNHqkhpLJv0mz9aT6d4yaw8f/56Nw+3UAxmVT6fmk1kz/ZzU/bdpaPIHTxchx5aFX47/Vx2e7kvXUxr67yKrMt72yfAZ5GaX4MwtHLW2uN25KgTjTbuWtcEXbb0oDhjHhbBc/o0wXaQV8rdhazUCHedZsQyAO8S16wHsZMrME4KeGpz9pjN1T9qrbpoaXtN/khGf/kWMFTb70FbLIj0XUhOnDHo6qjA0Mt+Wf8QOjgPtHzFhAY8MQh0e4jUujEwcgWKEkzrfLhvRI4kKMTegJQuJEVPMO89E/60HW4vIV9jnDoBtwvrJe62OPofTGmVmiiZ3fc8sDs5lM2y+RD/Lk8y5Fr8MuhQhC77P56JwD8btjfQODVj2SP7e/MZtYtAHiZPr7o+wDlxDVo4dX7OIOzxL1wrgIM= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SE9DbDVtM0tObHJMRUtEaUpNdXRqeHJseUZ4WE0zL3FQNGtJL2tjamtjWG82?= =?utf-8?B?MExXTXl1Q0ZKaWJ6VXIxbVdDcHdvUzlFdzMvVkFlYzRVYnBwa3JWZm9pRFdZ?= =?utf-8?B?a2JLUWVTRkVUZG9rVytSajNwRmJTekRhbWVnazRiQTg5Yjh1L3U0MllPejdm?= =?utf-8?B?eFIwNTRZVkl6S3Q2a0cySkMxSVg4OWQxTDEzQlVRR3Y1dzNTa1NncFdFdnJR?= =?utf-8?B?M21hamc2dGMwVXp2S2w1YUt5SGZVUnBpQ21DWGQyd21PYWowekhPK2ZyOE5C?= =?utf-8?B?Nkl5ZFNjQkVLenU0ZjNBRmR0N2ZhQ0w3SW5hVXp6b25rdjNEdzJPamltVHhD?= =?utf-8?B?ZHFFdDVISE5OSE0wcXpYWDNaOHFML05Pd0sxcVdnOHdrSjZzaE1MYVFrekFt?= =?utf-8?B?ajhvc3lMYlZKREF2TzNJbHNoL1pMZEZ5L0lSV2tBWm8rb3FQUVR4VkluU0NT?= =?utf-8?B?QmprR0EwQW43Qll3TGg1b2ZSaEp1RW5Pdk1WeFlHSTlyS1RUOFJxRm5aTHlR?= =?utf-8?B?SXpHT2krYUxOWUN4QVlzK0FoNjl4K0lCVUlkdXRTV0RyN3dLbEU4eHgrS3ZD?= =?utf-8?B?Y2k4bksvQmxJSmR4V2U5bGd4QU56VXEwYTQvSGUxQ3JxTFZQV1BpaTZhSmdE?= =?utf-8?B?SGNvQnU5b1V3c1k2VmxuZWplV3Zsb21yTnZvUW9TNkpJdGNuWE02TkxpUlBz?= =?utf-8?B?VzVwM0RibjRLcWEyQURmUW4raGE4aGJ5WlVlNGpIeWgzckw4MUJOeWQwSlQx?= =?utf-8?B?TnNOSEsvd2pzQm1iZFpGeTQ5WjBCTVhlcVRvLzlyOXhqZkNtNTcwM1hBTWdH?= =?utf-8?B?MlA5T01rQ3o3NmlrR1FZb1dVVGlJSGRMa0hSNFc1TVExNm5pdlNlUGxCcm55?= =?utf-8?B?N1ZTT1lUWUFjNklHQ1ZZYUhpMTIrekdJaFlKZk1nLyt6TWFrenVtR1ZnSWl2?= =?utf-8?B?cEZ1RXl3c1B2bUhYZEl3TXNDMTd2R3ZOTmsxaDluN2VpbDNqRVNEbXhIM3dS?= =?utf-8?B?UTluOGZJVTRlZDdNOURyL2dZbDVOZWZBSFgwUS9HN3JLbTEyYWNoN1l0UTVQ?= =?utf-8?B?NnpGc3VYYnVxMjlCdkdBSWw2clIvNjUrSGgyUXlxTGRWYVpvMmZlWUlUZHFU?= =?utf-8?B?SmRQS0pUSmxxclltMzZocHJnZnNIK1dQcEllM05EdGkzQkFxdkRwQ0FkYkJz?= =?utf-8?B?N3dYczJ4R1BZV2JvQ25sakU0UzZ3OTdCdHB0dE1Xa3MxSGdlQUZPSi9TNUJi?= =?utf-8?B?VlNRQkY0amZ5dWpNbWErampaQ2VnZFdZK0xJMlBteHBhenh4RGszWkUybDhu?= =?utf-8?B?SFRPWTNhQWlaNkhqRmNlY1IzWU52cXZwbXZ1NjM3TlU3SldTNzlBazNWaGFC?= =?utf-8?B?N3BYQU5XZWNBajlrcWlWQUNzdlB5b2orZE43aEI4VkM0T1hsVlcrazRVbzJ0?= =?utf-8?B?cllJcU5TK2RWeUdvbUFkL29VM2FtWFcwT2UrQ1BoTHJLczBVR3BoUTNlZ0pv?= =?utf-8?B?d2NLKzhsSmhhbjVOMnViQlR1UTZJV0gzcGhWNVFSOUVmb0Q1ZnZNbUUvMkNn?= =?utf-8?B?VStiem1CNGl4c05ta29QeEJWQm1DY1JnNW0vNWR3cTVFc05xZWhFaXc3eW85?= =?utf-8?B?YnNvcElQMHpvUzdDZEZYWFpJKytKNnVjcWpOVnA5bFJwVzg0czJKYWNsbjNv?= =?utf-8?B?aTdzN1MrYlZlalhuVHdlODVDNW1ycWNROTJUc2VkV2FvQjJzVDNXTHBQZVFQ?= =?utf-8?B?bmtJNk93WGdWU0pTS1I5a2NRMWYwRnhPU2l3ZHVUMkF0bWdVdksxempOdXVV?= =?utf-8?B?dHVRbnN3bjNpTUJkT01malpCMlpJUThkSUlkMGZNaHRwS2hwNWZPSk9ncXNF?= =?utf-8?B?ZFVPUzBOZ1BNdFVxdkdTeVhqTnlzSlpDWjJiU1FSOUxNODAybDJJZVZKb2xi?= =?utf-8?B?eCtOV081SDNMZmFCNEFJQ3IxMVhsNTBnR1kvZEc3YTljc2NMRlhrS1NiZDBG?= =?utf-8?B?dU9kRUhOSTdJS1JTTHQxd1RLcUJIZEdqcVE1aFZZWGk5ZTk4cDBXTkdhZkNW?= =?utf-8?B?Z0J0Tm95R0Jtckw2VkhJa0FLSjgwL3lpRHlmbmZrWWM5MDdzOE9xQStGb1R5?= =?utf-8?B?NmYvMVBBYlRtdktESkRsV2tWWk0yeWhtelhqTU1Od0Q5M01SYU9mWG5pSzdY?= =?utf-8?B?NEJzRHpNbWRLSnp2YkpKMlFWeENuN3VOR2FHb3hqNjhUeEs1RmcxanlRbHA3?= =?utf-8?B?cWVaaUVLbTB0dWFlU0Z6cTUxNmxFQlJpQjJoRTRQMzhGT3VjaGpkSGlCbFNB?= =?utf-8?B?dnZRNjVJa2xBbnpWZHVFUU1kU3Q3SG9JdUFUQ2hJOTlFbm9RMlRaQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8837b078-b654-4121-76e8-08de7870e618 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 15:32:22.6725 (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: OsRFWt1ww3ZVKhB/kRsRJW+dkYbAEe1S6jrAnw5f89J8/sjsbYdrBvqqcOyuB1bgUVuXB34snxKJ01JZ0L9jWqwXwm9++UTsJ+HHOwQPIhw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6910 On 02/03/2026 11:39 am, Jan Beulich wrote: > On 28.02.2026 00:16, Andrew Cooper wrote: >> We wish to make use of opt_fred earlier on boot, which involves moving >> traps_init() earlier, but this comes with several ordering complications. >> >> The feature word containing FRED needs collecting in early_cpu_init(), and >> legacy_syscall_init() cannot be called that early because it relies on the >> stubs being allocated, yet must be called ahead of cpu_init() so the SYSCALL >> linkage MSRs are set up before being cached. >> >> Delaying legacy_syscall_init() is easy enough based on a system_state check. >> Reuse bsp_traps_reinit() to cause a call to legacy_syscall_init() to occur at >> the same point as previously. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > > Irrespective ... > >> @@ -359,7 +363,13 @@ void __init bsp_traps_reinit(void) >> */ >> void percpu_traps_init(void) >> { >> - legacy_syscall_init(); >> + /* >> + * Skip legacy_syscall_init() at early boot. It requires the stubs being >> + * allocated, limiting the placement of the traps_init() call, and gets >> + * re-done anyway by bsp_traps_reinit(). >> + */ >> + if ( system_state > SYS_STATE_early_boot ) >> + legacy_syscall_init(); > ... I wonder if simply pulling this out of this function wouldn't be slightly > neater. To me at least, syscall/sysenter are only a remote from of "trap". I'm not a massive fan of how we (well, Linux) uses "traps" when it's different from x86 term of the same name. But, setting up the syscall stub has always been part of traps_init(), and for FRED it's combined. As noted, this changes again as FRED gets plumbed in, so really you need to look at patch 8.  I'm not a massive fan of how it's ended up, but I can't think of anything simpler. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:34:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:34:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244351.1543790 (Exim 4.92) (envelope-from ) id 1vx5He-0003cn-KZ; Mon, 02 Mar 2026 15:34:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244351.1543790; Mon, 02 Mar 2026 15:34:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5He-0003cg-GI; Mon, 02 Mar 2026 15:34:10 +0000 Received: by outflank-mailman (input) for mailman id 1244351; Mon, 02 Mar 2026 15:34:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Hd-0003au-2r for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:34:09 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 40a3549d-164d-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:34:08 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-48373a4bca3so27780255e9.0 for ; Mon, 02 Mar 2026 07:34:08 -0800 (PST) Received: from [10.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-483bfb29715sm306502245e9.0.2026.03.02.07.34.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 07:34:06 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 40a3549d-164d-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772465647; x=1773070447; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=7kKsKmbJttVyNPHZQ95jKceOmtc2K70BiJyvN/p2Qls=; b=anEZcGAGNSq9/KkjiQhj8RVRMj45QJT3jxpg5u32e5xXnJuMRbeGijxf6ZE6h7aSx4 qvAXqGISK47Yw119ZN4J95BixX9lthPRiqC0gVRAgr1nSFiI1C/ayeiGh5B5E6q22xvj WQGJMsovZMncq03guvJtPLbwK2S021tclulXGbAVDgSJgupbnm1zpWIzKIyDzw6nOM1a gEjLY8XOlvyCyzg3UpY31h+pz6ooAAkw6y4GvTa3GYn8elEzlEsm1U1m7YZTOTepHkk1 W9Kbo4vW7ITlfgy6a6ylbBFrVe+S+SlvtBlpALz4rHjMjGDTFqTgnPcK3lClA5FHUiCW B8HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772465647; x=1773070447; h=content-transfer-encoding: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; bh=7kKsKmbJttVyNPHZQ95jKceOmtc2K70BiJyvN/p2Qls=; b=WEgJtQBR3aQ3+C9uXn2zr9S39RWCCODnB+85pFFbA7y+o8bW0x/qH0EnADpVwvYM69 348FMYJOAK0oNesNs7oskWZ+GnkZ9o63FX+y80ehnTe0D/RxuafGLq03W7waqDEHwGQ/ +lt1RVB2Phaa7jMDebVM6dTkfXOmP0P9LWZbBPJRwDO6QoZdW4yM57WQ6srTo2tZFP5p 9Hnjm8Gppbx2GDnLIvMgG+zXJl36tZhDlfRxzGN3933I5xzIddXU83+aITUWCq5H9IQg t/Uk+BfhMb0xHCPG3BZ17CagDJ1LroOFngNbJpG//PzjublRkx7ZwCAZa8OuOJ5Fqcyb YuaQ== X-Forwarded-Encrypted: i=1; AJvYcCWjWLC8+zgxkovejNfTt+1bocgy7AaljeTkKC5/j75a4GfNsPEIvTGHmTXDo0uTPhZzD+HhSgrmv+8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxBXxhI4hvP8YET3o/SaSgEbD+mtZbogbAW6DTZjcfRBDI3i7qE zyJH0wsQcRzf9S3dskc1yf50D1IKlgKsmefxcGqFz/e99bWDBHoL6omARiKhY6L0BA== X-Gm-Gg: ATEYQzwfLHfLlUxo3xBVOxy9juDGVGDoL6rIJR1Bexa4arK01p5hUBViIyzERbo+8+R t5z1o98Oyh+JlFkpVaiNYQ0T+Nit2dL4B1SU8YujTqMfvQG66Ig2Ad//x84rrJ1JvKsADANJJgs 8SCKti5rjQHrLAvLiEYJTVaREJl1gRFz+WW5xZBmyHxxs4Mztmy1LyUg1pMd2/7sJCNyirYZy28 8CV8DZORjxO52RVLxTkBxNd1sHikymRnc0bqglFHmpHumvKzyIwYcR645QZ0R5m4o8G0OtISwCo /bfndPWxpS6S6nVdBLV+Z29gCII5LzbLeYaICPP48jdPJPcgy0oLO4BNCN24eJqOGLCXB8dPbuo FHa0oypygPIvR5FdMclgFKHzZ/7NFBl/WR04/UOOm7xlp5bbrHc2dx7JvY8ZIXXUawGCxkUgGec WCumIMoWS+ulKAMhcQk4BloROJIeg3D/XwfMsVGNQQwGjxMKYSeJc5lWXc1xVNk2FpWqUYSauMp vg2z3Bwk6uSEzvKDQYN0EUBPw== X-Received: by 2002:a05:600c:5289:b0:480:1c53:2085 with SMTP id 5b1f17b1804b1-483c9bbbf1amr228767935e9.19.1772465647418; Mon, 02 Mar 2026 07:34:07 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 16:34:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 04/14] x86/boot: Document the ordering dependency of _svm_cpu_up() To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-5-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 02.03.2026 16:20, Andrew Cooper wrote: > On 27/02/2026 11:16 pm, Andrew Cooper wrote: >> Lets just say this took an unreasoanble amount of time and effort to track >> down, when trying to move traps_init() earlier during boot. >> >> When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the >> BSP, the first context switch into PV uses svm_load_segs() and clobbers the >> later-set-up linkage with the 0's cached here, causing hypercalls issues by >> the PV guest to enter at 0 in supervisor mode on the user stack. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Roger Pau Monné >> >> v4: >> * New >> >> It occurs to me that it's not actually 0's we cache here. It's whatever >> context was left from prior to Xen. We still don't reliably clean unused >> MSRs. Actually, with this, ... >> --- a/xen/arch/x86/hvm/svm/svm.c >> +++ b/xen/arch/x86/hvm/svm/svm.c >> @@ -35,6 +35,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> @@ -1581,6 +1582,21 @@ static int _svm_cpu_up(bool bsp) >> /* Initialize OSVW bits to be used by guests */ >> svm_host_osvw_init(); >> >> + /* >> + * VMSAVE writes out the current full FS, GS, LDTR and TR segments, and >> + * the GS_SHADOW, SYSENTER and SYSCALL linkage MSRs. >> + * >> + * The segment data gets modified by the svm_load_segs() optimisation for >> + * PV context switches, but all values get reloaded at that point, as well >> + * as during context switch from SVM. >> + * >> + * If PV guests are available (and FRED is not in use), it is critical >> + * that the SYSCALL linkage MSRs been configured at this juncture. >> + */ >> + ASSERT(opt_fred >= 0); /* Confirm that FRED-ness has been resolved */ >> + if ( IS_ENABLED(CONFIG_PV) && !opt_fred ) >> + ASSERT(rdmsr(MSR_LSTAR)); > > It has occurred to me that this is subtly wrong.  While FRED doesn't use > LSTAR/SFMASK, it does reuse STAR. > > So this needs to be: > >     if ( IS_ENABLED(CONFIG_PV) ) >         ASSERT(rdmsr(MSR_STAR)); > > with the include dropped, as the final sentence adjusted to say "even > with FRED". ... if we inherit a non-zero value, is the assertion of much use this way? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:42:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:42:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244363.1543799 (Exim 4.92) (envelope-from ) id 1vx5Pc-0005Tl-EG; Mon, 02 Mar 2026 15:42:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244363.1543799; Mon, 02 Mar 2026 15: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 ) id 1vx5Pc-0005Te-BQ; Mon, 02 Mar 2026 15:42:24 +0000 Received: by outflank-mailman (input) for mailman id 1244363; Mon, 02 Mar 2026 15:42:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Pa-0005TY-Ug for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:42:22 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 65b50bb5-164e-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 16:42:20 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by MW4PR03MB6444.namprd03.prod.outlook.com (2603:10b6:303:123::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.16; Mon, 2 Mar 2026 15:42: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%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 15:42:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 65b50bb5-164e-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ZOaPUdh38CXQ1x7ZBEHcLzXhef70LUDoF6s9cLxv0os8Bik8nSFYNenRLy3eK35UdXF9JVFAjwZUjp2oGJ4kT494/Mp9XTyzj5BB5gF/clMxvShaewYnwXK7DHDWAR4B2K4+ZOGfuNT3E07ksvgyC6yH02ifPSqeu9AkoWo18pbvq2yEbLlDKYuwW5Sp26iSaVYU1d93vtO0Nlcq4H7Og5dYU3Bar1SLJGzpI2Wtb3mfFtVJVIE7KYpgDzQ6YbajI7b4KDVCORjTxovtv32UrTE30g+/k4R7ICgHUGx0Iss0EM/4Wl0Md0NIJInKoUJM0qxY9Xuwu5zz6BpECouq6A== 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=FC0BCsAPTshr1gVjROEcLDusm8ZgdIqf4RmZra6rNVk=; b=D51mFj5WxBh42BWcRXh0dbSp3SYg4AQvzmHoCRAoiv0ma/h1ETafLu+ixnOkNWyz4/TU1PPBJd77qDNQmNpTCegTqzUoFL5KhLQ3rb4LgjxyzJTF1YFyVuNxNK7YWd33SpoZE//7yvuyxy4UiYR5w1dmW8WZ9St9f2BuJVfT2b6RKTLeab5uuIiK1t29lmAyBoH2kZlekDsZPDyHzj+x5C1KlAa1dZXiZgp2xnjeLMZliUeuEdnxSuNcvWxS8TsSjroW5Ox6MeO03n7nJhhhHnpM0GJwMDhanOISxgKmrQdFNgBvDNyd4zC6pBat2WCVEw7KJ330Y7LbWX93aB/1jQ== 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=FC0BCsAPTshr1gVjROEcLDusm8ZgdIqf4RmZra6rNVk=; b=ximfNIolbqjotQfW8gDpB4nsOgR2zGF4ewuXLPSU8iw4/xOVUq43/INjTmUV+WTtPfVN8tOZA5HYNRubzrhO4vYwH6JPcmV/D0JFlm1ePbpiL9GU8XujgbYb9dybQqkbqOPkrj6RM8OBTa0ZkDJh8ZOHXmuOWdyjMZTckW/rjko= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3e460f2c-9118-4cd1-9d60-bdfa1f502cd2@citrix.com> Date: Mon, 2 Mar 2026 15:42:14 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 04/14] x86/boot: Document the ordering dependency of _svm_cpu_up() To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-5-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0260.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:194::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_|MW4PR03MB6444:EE_ X-MS-Office365-Filtering-Correlation-Id: bb1f0834-b01e-4789-e60a-08de7872486d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: 22ZNkBCv+6mGi+ejb0g8wP/2FiORBL9+igbMN9kc8DpVJvDk+eijfWqCv+mytN4FD/4x9GdO+j84FmBlrUTfcUZAqP3HTNE+1J3sLF1LlN+5FbyJLDCgY78NADmQ1xYnlzo0arxkgTMPbkp1CamE4E4VfBDaMCpeaGMpvQlhzTlhEOlzhpz96QwO1qZZ0E0xx0G8Jdp1g9KbvF/bE7i3D6wOBsb+xbE5QVat5TPbIrDVnCu9cne6XnT3JFXQVDoA+2VtpIBb6TTLnduG+UiyBXKtPkoIsB+pY2XVpHMb7XA8Ea9J1/2pWagPmiN6ZGREl/J8pZwN/8RvVoAktKSq4cq/Aal1ZghcfaCeyvqEP3pHc08O5fslBUtRH01EL4mouIcOvqtIzQsweplqYV0t+AHXIkb6WDgQGUk8hdNCKd0iE2MWZrvnmID6YgAPiXSocens8w0hEecSgxoPa5XUGgwzAL1ZUQOude8iTnC8aBOGVB8WKDMh0+6X2CN73vVnfyHUcHF8hg5/Vs2GlZk3mbau8lHga5mviK3q9whSqU2DaFdE3J/Gaj+4dx8/jCDD3OxJuDJeYSuxBh8hI0s+zbTmptB+fyJJuKOTN7TvadYhxLYqQCdUymUBzqcJu/5Y7OuuofmcnhMkrda67k/oj1DylkCqrLLOT3OsHk58+UMK+lTqh5R5LVWqeOROISpeGlWBG4djIMbWW13dMoaUZ1QUtio0ocxas6nH+o8XCfA= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b09DUTBzMWpmOTVROWtjdWd5NTRxdVRUM1hBMUFKQXJDelpFWFRodFZYRks2?= =?utf-8?B?bVlVdDJSTmFlS1JMaFlvd0hXK2twWnVQL0Rud0VBZkpwZm43TmJubUdrZEZ2?= =?utf-8?B?SnY4L0poM2dBcUF6NFhiTlB5L0N5d0pVUENkMjV5YllCaFQwU0dJRGhrellW?= =?utf-8?B?ZFkxeFhDQlRSN2JBMWxIK3BGLzZEaTRQTHY0QTk0ci9BeHd3TUkvNXhtMXY2?= =?utf-8?B?Rm1iV0lvYnQxNGpabm9vV3pncTFzbE9TMVl5STdXemVlUGMxOWs1WHBPS1dP?= =?utf-8?B?cUtvdUNFUkYwclZJeGpMWUtLbjNMSitNMUZCdFN2VE85NjdNWGQ1cGtDTXFV?= =?utf-8?B?Tm9VQzF4WU9XMzhOUENWd1dwNEo0dUpCTEhVMkJVQWJ2emNCWmR3RVpvdmJB?= =?utf-8?B?OFlxcHpxZGY3Ry9nUjhPOXNidmlVS2QrempWQk1mS0RiWFRhdGlIU1Y0V1hX?= =?utf-8?B?MkpOSGdDMlhmWVhpSU45Nk9nMXE0Z2xnYTZEOVo4VXMxaXQzSG9jaUY2RXMz?= =?utf-8?B?czh6c1IvSlBvOHhKR2dZdklEVFdla2wzZ2U0YVdtTElZaHBVYm9DbDRzK0hB?= =?utf-8?B?QzgxWXRZbjlwV2JML0JLQ1dBK3dqUXVyaTlpb2w4VTh2QWFKb1luQ3QxSmdB?= =?utf-8?B?aWtJK2tIVDdzNk0reUlTTkIzclJSWXd3R0IvQUFHMVlqaVVRQmt0cmNWWlZR?= =?utf-8?B?eDNXa3lRSnY2dHZrdzd5ODVVQ2pVLzY2dTdLY1FxbDFMSzV3dVN3b2JxYUU3?= =?utf-8?B?UE9VejV0M2x3TEovSndUQVNFQzZsbjRzaDZmMjFhNHF4cmpPZHZrRkpVbi9Z?= =?utf-8?B?UUhkSmpXbkVHRkY1bDJXRkh3N2hTOE1VUGNGQjM2TkdxRHZKSzZMcUw1eGJG?= =?utf-8?B?MHMwQi84VXNzbTNEaDNsK0FjSVdxM1RrcTk2dWczUXpBQXdQY1NsNmJWYVNN?= =?utf-8?B?NUtTWloyTkl3L3Fic1Y4Z20rcUlZMWZJTEo4UGdxd1hmSWlIakhnV08vOE85?= =?utf-8?B?TERZU0RZR0huSlQrLzZiTHpjSm9MU1ZwNWZYQzZycm9HMC8yUHFIOTkrZ3VS?= =?utf-8?B?YXBkUGtIQmJMeEhDRTRUOHRkcjZ0RlNuZGFKalZBT0gxeXUwbEdMam5lWHZB?= =?utf-8?B?azRDZmROY2VBS3JGT2lXbnRKYVpLQ2lCNXd6dExKZkg1bFFUUml3ait1aE5B?= =?utf-8?B?QXpGeWpBUFkxaHB5VWoxdTZKYWV5NndaZDM3b1g0RE9sZFIwbXB1TjY2Q1VF?= =?utf-8?B?bWZFL3BCR21GN1V5YUVTNzhvd3dnWjBvRHpLbnp6VVVFRWQrcG03UmhqS2ZS?= =?utf-8?B?NnpPNlMrTGxtVHd3S3RPWGdkckhIc3J2bU0vUGFjV1hocXpyM1lXTVNSSFRz?= =?utf-8?B?N0VWYXUwS1ZXeVhHTGxmZ1dsZjBQZVZURGJabDMzaXFPWFE3K1NCMm5TSWFJ?= =?utf-8?B?S1hPUzROYlVUdHVWeTNTK2cwWVZhb25BWGZ4ZXdQcFRiTEJzdlhSOGZMbGVG?= =?utf-8?B?V3NHRTlRa0htLzgxd0pNTWVFcSsrNGhaNFVRQXVpSTIvZnpoekVMVGtzV2Vi?= =?utf-8?B?NElwZSt1S256MHNSc21zY2EveHRQbEd4d0Vyc1NIaTl1Umt6dGpPU3Jaa1Yr?= =?utf-8?B?Mk9xeVVFQzF2cjgrcmN4eGdtZlplQk84N0toUURXaWxuNk9aVDh6YnZOc0kr?= =?utf-8?B?RURveEZiMVZkS2xSQ2N2WkEwZjV5OWNpWEM3ZjZPajF5S2xwUkpCVlI3NEU4?= =?utf-8?B?NFNaL2s4c0pUVXV1bjFicFFYK1VaaXkxOENPVXd6K0RHY3B2WEVoMlN1aHZG?= =?utf-8?B?RFE2SSsxRVA0QUVqTFUydStib0FUTkd1MWNjRjdNL3hpdFIxNlFOZmZYODha?= =?utf-8?B?MVdPMElKdDZ2WHYyT0VJWGcxZnNqM0Z4Y0VQUkZXVWI5eHcyYStzSmlOUnBR?= =?utf-8?B?czZtRi9xTE1nd2RYR2NmQVlrZ1pkVXBXU29xWk55QjVkN2kxYkdpdUg1Sytp?= =?utf-8?B?MjBSVk1GeU85RXltWHdrKzRkamc2ZEowV2ZMcCtJRU5WbjhRYnBKbmVMTHpH?= =?utf-8?B?a21HYTE0b0wraGRSSkQvS2RrdnlUVXZiM2JYc1hWRU5kSHVhdkorUFNTaUVo?= =?utf-8?B?MkF2bnBrQTU2bTJGSU9GYlNjaE5JVlo3dkVxK2NGYk91dEQyMVVjbFhUY0E5?= =?utf-8?B?THFzeityRFBLazZUcEpicWtxMlJWRllnNnhWZmZYM1JyVmJUV2hoQ002T3hB?= =?utf-8?B?ZUNqY2I5cnlvQnBZcmNOM1VZWTN6Rk43RkY0cmQ1dTZhTzBxcXpWYmlReUhj?= =?utf-8?B?cCtuVzFDUTRSRlpBbXRlT01hNU8rd3Vmd1V4Z0F6eURubUxVY05GQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bb1f0834-b01e-4789-e60a-08de7872486d X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 15:42:17.0544 (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: IJi2odPro5FbZwHmujlsUlT/sz5QBOCm6nARHlCithWVxPA5g5UCrgGlv/C87g81kmQFzy9fcl1KiP52ZokY+UQZ+bARjYt25NhDbQLaFVk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6444 On 02/03/2026 3:34 pm, Jan Beulich wrote: > On 02.03.2026 16:20, Andrew Cooper wrote: >> On 27/02/2026 11:16 pm, Andrew Cooper wrote: >>> Lets just say this took an unreasoanble amount of time and effort to track >>> down, when trying to move traps_init() earlier during boot. >>> >>> When the SYSCALL linkage MSRs are not configured ahead of _svm_cpu_up() on the >>> BSP, the first context switch into PV uses svm_load_segs() and clobbers the >>> later-set-up linkage with the 0's cached here, causing hypercalls issues by >>> the PV guest to enter at 0 in supervisor mode on the user stack. >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> CC: Roger Pau Monné >>> >>> v4: >>> * New >>> >>> It occurs to me that it's not actually 0's we cache here. It's whatever >>> context was left from prior to Xen. We still don't reliably clean unused >>> MSRs. > Actually, with this, ... > >>> --- a/xen/arch/x86/hvm/svm/svm.c >>> +++ b/xen/arch/x86/hvm/svm/svm.c >>> @@ -35,6 +35,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> >>> @@ -1581,6 +1582,21 @@ static int _svm_cpu_up(bool bsp) >>> /* Initialize OSVW bits to be used by guests */ >>> svm_host_osvw_init(); >>> >>> + /* >>> + * VMSAVE writes out the current full FS, GS, LDTR and TR segments, and >>> + * the GS_SHADOW, SYSENTER and SYSCALL linkage MSRs. >>> + * >>> + * The segment data gets modified by the svm_load_segs() optimisation for >>> + * PV context switches, but all values get reloaded at that point, as well >>> + * as during context switch from SVM. >>> + * >>> + * If PV guests are available (and FRED is not in use), it is critical >>> + * that the SYSCALL linkage MSRs been configured at this juncture. >>> + */ >>> + ASSERT(opt_fred >= 0); /* Confirm that FRED-ness has been resolved */ >>> + if ( IS_ENABLED(CONFIG_PV) && !opt_fred ) >>> + ASSERT(rdmsr(MSR_LSTAR)); >> It has occurred to me that this is subtly wrong.  While FRED doesn't use >> LSTAR/SFMASK, it does reuse STAR. >> >> So this needs to be: >> >>     if ( IS_ENABLED(CONFIG_PV) ) >>         ASSERT(rdmsr(MSR_STAR)); >> >> with the include dropped, as the final sentence adjusted to say "even >> with FRED". > ... if we inherit a non-zero value, is the assertion of much use this way? The inherited case is normally when we're KEXEC'd into.  That doesn't happen very much with Xen, and is more of a concern with Linux. But yes, IMO the assertion is still useful.  CI boots from clean, so the ASSERT() will catch accidental code movement which violates the dependency. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:44:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:44:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244371.1543810 (Exim 4.92) (envelope-from ) id 1vx5Rc-00060R-OW; Mon, 02 Mar 2026 15:44:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244371.1543810; Mon, 02 Mar 2026 15:44:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rc-00060K-Lt; Mon, 02 Mar 2026 15:44:28 +0000 Received: by outflank-mailman (input) for mailman id 1244371; Mon, 02 Mar 2026 15:44:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Ra-00060E-RI for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:44:26 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id ae257be3-164e-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 16:44:21 +0100 (CET) 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 4091514BF; Mon, 2 Mar 2026 07:44:14 -0800 (PST) Received: from C3HXLD123V.arm.com (unknown [10.57.82.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3BAC23F73B; Mon, 2 Mar 2026 07:44:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae257be3-164e-11f1-9ccf-f158ae23cfc8 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v2 0/4] xen/arm: ffa: Add PARTITION_INFO_GET_REGS support Date: Mon, 2 Mar 2026 16:44:09 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series implements FF-A 1.2 PARTITION_INFO_GET_REGS support, providing register-based partition info retrieval as an efficient alternative to the RX buffer-based PARTITION_INFO_GET. The serie is also introducing a caching system for the list of secure partitions to prevent retrieving it on each VM call as we expect it to be static and not changing over time. The patches are organized as follows: - patch 1 is modifying existing code to prepare for GET_REGS support by adding a start_index in the existing internal function - patch 2 is introducing the secure partition list caching - patch 3 is removing the existing suscribers list to directly use the cached secure partition list - patch 4 is adding GET_REGS support Changes since v1 (Jens comments): - rework SP cache handling to enforce 1.1+ structure size - ensure unaligned-safe reads - remove checks for SBZ fields - tighten tag handling Bertrand Marquis (4): xen/arm: ffa: Add start_index to VM partinfo helper xen/arm: ffa: Cache SP partition info at init xen/arm: ffa: Drop SP subscriber lists xen/arm: ffa: Add cached GET_REGS support xen/arch/arm/tee/ffa.c | 23 +- xen/arch/arm/tee/ffa_partinfo.c | 565 ++++++++++++++++++++++---------- xen/arch/arm/tee/ffa_private.h | 4 +- 3 files changed, 410 insertions(+), 182 deletions(-) -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:44:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:44:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244372.1543820 (Exim 4.92) (envelope-from ) id 1vx5Ro-0006Hm-VX; Mon, 02 Mar 2026 15:44:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244372.1543820; Mon, 02 Mar 2026 15:44:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Ro-0006He-Rp; Mon, 02 Mar 2026 15:44:40 +0000 Received: by outflank-mailman (input) for mailman id 1244372; Mon, 02 Mar 2026 15:44:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rn-0006Gr-6s for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:44:39 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b8194af2-164e-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:44:38 +0100 (CET) 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 21967152B; Mon, 2 Mar 2026 07:44:31 -0800 (PST) Received: from C3HXLD123V.arm.com (unknown [10.57.82.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 10B3F3F73B; Mon, 2 Mar 2026 07:44:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b8194af2-164e-11f1-b164-2bf370ae4941 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v2 2/4] xen/arm: ffa: Cache SP partition info at init Date: Mon, 2 Mar 2026 16:44:11 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit FFA_PARTITION_INFO_GET currently queries the SPMC on each call and walks the RX buffer every time. The SP list is expected to be static, so repeated firmware calls and validation are unnecessary. Cache the SPMC partition-info list at init time, keeping only secure endpoints, and reuse the cached entries for SP count and partition-info responses. Initialize the VM create/destroy subscriber lists from the cached list and free the cache on init failure. SP partition info now reflects the init-time snapshot and will not change. Signed-off-by: Bertrand Marquis --- Changes since v1: - removed unneeded NULL assignment after XFREE - remove warned usage and only rely on printk_once to warn on the 15-bit convention - rework ffa_partinfo_init cleanup - ensure we do not do unaligned accesses when building the SP cache - enforce SPMC partinfo size to be at least 1.1 structure size when creating and remove tests when using the cache --- xen/arch/arm/tee/ffa_partinfo.c | 216 +++++++++++++++++++++----------- 1 file changed, 146 insertions(+), 70 deletions(-) diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c index 6a6f3ffb822e..b933becaa55a 100644 --- a/xen/arch/arm/tee/ffa_partinfo.c +++ b/xen/arch/arm/tee/ffa_partinfo.c @@ -6,6 +6,8 @@ #include #include #include +#include +#include #include #include @@ -33,6 +35,10 @@ static uint16_t subscr_vm_created_count __read_mostly; static uint16_t *subscr_vm_destroyed __read_mostly; static uint16_t subscr_vm_destroyed_count __read_mostly; +/* SP list cache (secure endpoints only); populated at init. */ +static void *sp_list __read_mostly; +static uint32_t sp_list_count __read_mostly; +static uint32_t sp_list_entry_size __read_mostly; static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t flags, uint32_t *count, uint32_t *fpi_size) { @@ -79,92 +85,84 @@ static int32_t ffa_copy_info(void **dst, void *dst_end, const void *src, return FFA_RET_OK; } -static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_count) +static uint16_t ffa_sp_entry_read_id(const void *entry) { - uint32_t src_size; - - return ffa_partition_info_get(uuid, FFA_PARTITION_INFO_GET_COUNT_FLAG, - sp_count, &src_size); + return get_unaligned_t(uint16_t, + (const uint8_t *)entry + + offsetof(struct ffa_partition_info_1_0, id)); } -static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_count, - void **dst_buf, void *end_buf, - uint32_t dst_size) +static bool ffa_sp_entry_matches_uuid(const void *entry, struct ffa_uuid uuid) { - int32_t ret; - int32_t release_ret; - uint32_t src_size, real_sp_count; - void *src_buf; - uint32_t count = 0; - bool notify_fw = false; + struct ffa_uuid sp_uuid; - /* We need to use the RX buffer to receive the list */ - src_buf = ffa_rxtx_spmc_rx_acquire(); - if ( !src_buf ) - return FFA_RET_DENIED; + if ( ffa_uuid_is_nil(uuid) ) + return true; - ret = ffa_partition_info_get(uuid, 0, &real_sp_count, &src_size); - if ( ret ) - goto out; - notify_fw = true; + memcpy(&sp_uuid, + (const uint8_t *)entry + + offsetof(struct ffa_partition_info_1_1, uuid), + sizeof(sp_uuid)); + return ffa_uuid_equal(uuid, sp_uuid); +} - /* Validate the src_size we got */ - if ( src_size < sizeof(struct ffa_partition_info_1_0) || - src_size >= FFA_PAGE_SIZE ) +static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_count) +{ + uint32_t count = 0; + uint32_t n; + + for ( n = 0; n < sp_list_count; n++ ) { - ret = FFA_RET_NOT_SUPPORTED; - goto out; + void *entry = sp_list + n * sp_list_entry_size; + + if ( ffa_sp_entry_matches_uuid(entry, uuid) ) + count++; } - /* - * Limit the maximum time we hold the CPU by limiting the number of SPs. - * We just ignore the extra ones as this is tested during init in - * ffa_partinfo_init so the only possible reason is SP have been added - * since boot. - */ - if ( real_sp_count > FFA_MAX_NUM_SP ) - real_sp_count = FFA_MAX_NUM_SP; + *sp_count = count; - /* Make sure the data fits in our buffer */ - if ( real_sp_count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / src_size ) - { - ret = FFA_RET_NOT_SUPPORTED; - goto out; - } + if ( !ffa_uuid_is_nil(uuid) && !count ) + return FFA_RET_INVALID_PARAMETERS; - for ( uint32_t sp_num = 0; sp_num < real_sp_count; sp_num++ ) - { - struct ffa_partition_info_1_1 *fpi = src_buf; + return FFA_RET_OK; +} - /* filter out SP not following bit 15 convention if any */ - if ( FFA_ID_IS_SECURE(fpi->id) ) - { - /* - * If VM is 1.0 but firmware is 1.1 we could have several entries - * with the same ID but different UUIDs. In this case the VM will - * get a list with several time the same ID. - * This is a non-compliance to the specification but 1.0 VMs should - * handle that on their own to simplify Xen implementation. - */ +static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_count, + void **dst_buf, void *end_buf, + uint32_t dst_size) +{ + int32_t ret; + uint32_t count = 0; + uint32_t n; - ret = ffa_copy_info(dst_buf, end_buf, src_buf, dst_size, src_size); - if ( ret ) - goto out; + for ( n = 0; n < sp_list_count; n++ ) + { + void *entry = sp_list + n * sp_list_entry_size; - count++; - } + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) + continue; + + /* + * If VM is 1.0 but firmware is 1.1 we could have several entries + * with the same ID but different UUIDs. In this case the VM will + * get a list with several time the same ID. + * This is a non-compliance to the specification but 1.0 VMs should + * handle that on their own to simplify Xen implementation. + */ + ret = ffa_copy_info(dst_buf, end_buf, entry, dst_size, + sp_list_entry_size); + if ( ret ) + return ret; - src_buf += src_size; + count++; } *sp_count = count; -out: - release_ret = ffa_rxtx_spmc_rx_release(notify_fw); - if ( release_ret ) - gprintk(XENLOG_WARNING, - "ffa: Error releasing SPMC RX buffer: %d\n", release_ret); - return ret; + if ( !ffa_uuid_is_nil(uuid) && !count ) + return FFA_RET_INVALID_PARAMETERS; + + return FFA_RET_OK; } static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_index, @@ -435,6 +433,13 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id, return res; } +static void ffa_sp_list_cache_free(void) +{ + XFREE(sp_list); + sp_list_count = 0; + sp_list_entry_size = 0; +} + static void uninit_subscribers(void) { subscr_vm_created_count = 0; @@ -443,6 +448,63 @@ static void uninit_subscribers(void) XFREE(subscr_vm_destroyed); } +static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, + uint32_t fpi_size) +{ + const uint8_t *src = buf; + uint32_t secure_count = 0; + uint32_t n, idx = 0; + + if ( fpi_size < sizeof(struct ffa_partition_info_1_1) || + fpi_size >= FFA_PAGE_SIZE ) + return false; + + if ( count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / fpi_size ) + return false; + + for ( n = 0; n < count; n++ ) + { + const uint8_t *entry = src + n * fpi_size; + uint16_t id = ffa_sp_entry_read_id(entry); + + if ( !FFA_ID_IS_SECURE(id) ) + { + printk_once(XENLOG_ERR + "ffa: Firmware is not using bit 15 convention for IDs !!\n"); + printk(XENLOG_ERR + "ffa: Secure partition with id 0x%04x cannot be used\n", + id); + continue; + } + + secure_count++; + } + + if ( secure_count ) + { + sp_list = xzalloc_bytes(secure_count * fpi_size); + if ( !sp_list ) + return false; + } + + sp_list_count = secure_count; + sp_list_entry_size = fpi_size; + + for ( n = 0; n < count; n++ ) + { + const uint8_t *entry = src + n * fpi_size; + uint16_t id = ffa_sp_entry_read_id(entry); + + if ( !FFA_ID_IS_SECURE(id) ) + continue; + + memcpy(sp_list + idx * fpi_size, entry, fpi_size); + idx++; + } + + return true; +} + static bool init_subscribers(void *buf, uint16_t count, uint32_t fpi_size) { uint16_t n; @@ -538,7 +600,7 @@ bool ffa_partinfo_init(void) if ( e ) { printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e); - goto out; + goto out_release_rx; } notify_fw = true; @@ -546,15 +608,29 @@ bool ffa_partinfo_init(void) { printk(XENLOG_ERR "ffa: More SPs than the maximum supported: %u - %u\n", count, FFA_MAX_NUM_SP); - goto out; + goto out_release_rx; + } + + if ( !ffa_sp_list_cache_init(spmc_rx, count, fpi_size) ) + { + printk(XENLOG_ERR "ffa: Failed to cache SP list\n"); + goto out_release_rx; } - ret = init_subscribers(spmc_rx, count, fpi_size); + if ( !init_subscribers(sp_list, sp_list_count, sp_list_entry_size) ) + goto out_free_sp_cache; -out: + ret = true; + goto out_release_rx; + +out_free_sp_cache: + ffa_sp_list_cache_free(); + +out_release_rx: e = ffa_rxtx_spmc_rx_release(notify_fw); if ( e ) printk(XENLOG_WARNING "ffa: Error releasing SPMC RX buffer: %d\n", e); + return ret; } -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:44:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:44:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244373.1543824 (Exim 4.92) (envelope-from ) id 1vx5Rp-0006Jp-84; Mon, 02 Mar 2026 15:44:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244373.1543824; Mon, 02 Mar 2026 15:44:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rp-0006JG-3P; Mon, 02 Mar 2026 15:44:41 +0000 Received: by outflank-mailman (input) for mailman id 1244373; Mon, 02 Mar 2026 15:44:39 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rn-0006Gr-Ro for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:44:39 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id b6f7fd03-164e-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:44:36 +0100 (CET) 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 4E77F14BF; Mon, 2 Mar 2026 07:44:29 -0800 (PST) Received: from C3HXLD123V.arm.com (unknown [10.57.82.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5DC4A3F73B; Mon, 2 Mar 2026 07:44:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b6f7fd03-164e-11f1-b164-2bf370ae4941 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v2 1/4] xen/arm: ffa: Add start_index to VM partinfo helper Date: Mon, 2 Mar 2026 16:44:10 +0100 Message-ID: <59113d382b0f31ae51152887a0afaeb10dcf8420.1772464956.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Windowed GET_REGS retrieval needs to emit VM entries starting from an arbitrary index, but ffa_get_vm_partinfo() always starts from index 0. Add a start_index parameter to ffa_get_vm_partinfo() and skip entries until the local index reaches start_index. Update ffa_handle_partition_info_get() to pass start_index=0 to preserve existing behavior. No functional changes. Signed-off-by: Bertrand Marquis Reviewed-by: Jens Wiklander --- Changes since v1: - Add Jens R-b --- xen/arch/arm/tee/ffa_partinfo.c | 61 +++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c index fdb03dae9a0c..6a6f3ffb822e 100644 --- a/xen/arch/arm/tee/ffa_partinfo.c +++ b/xen/arch/arm/tee/ffa_partinfo.c @@ -167,14 +167,15 @@ out: return ret; } -static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t *vm_count, - void **dst_buf, void *end_buf, - uint32_t dst_size) +static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_index, + uint32_t *vm_count, void **dst_buf, + void *end_buf, uint32_t dst_size) { struct domain *d = current->domain; struct ffa_ctx *curr_ctx = d->arch.tee; struct ffa_ctx *dest_ctx; uint32_t count = 0; + uint32_t idx = 0; int32_t ret = FFA_RET_OK; /* * We do not have UUID info for VMs so use the 1.0 structure so that we set @@ -202,17 +203,21 @@ static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t *vm_count, if ( ACCESS_ONCE(curr_ctx->guest_vers) >= FFA_VERSION_1_2 ) { /* Add caller VM information */ - info.id = curr_ctx->ffa_id; - info.execution_context = curr_ctx->num_vcpus; - info.partition_properties = FFA_PART_VM_PROP; - if ( is_64bit_domain(d) ) - info.partition_properties |= FFA_PART_PROP_AARCH64_STATE; - - ret = ffa_copy_info(dst_buf, end_buf, &info, dst_size, sizeof(info)); - if ( ret ) - return ret; + if ( start_index == 0) + { + info.id = curr_ctx->ffa_id; + info.execution_context = curr_ctx->num_vcpus; + info.partition_properties = FFA_PART_VM_PROP; + if ( is_64bit_domain(d) ) + info.partition_properties |= FFA_PART_PROP_AARCH64_STATE; - count++; + ret = ffa_copy_info(dst_buf, end_buf, &info, dst_size, + sizeof(info)); + if ( ret ) + return ret; + count++; + } + idx++; } if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) @@ -231,21 +236,25 @@ static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t *vm_count, if ( dest_ctx == curr_ctx ) continue; - info.id = dest_ctx->ffa_id; - info.execution_context = dest_ctx->num_vcpus; - info.partition_properties = FFA_PART_VM_PROP; - if ( dest_ctx->is_64bit ) - info.partition_properties |= FFA_PART_PROP_AARCH64_STATE; - - ret = ffa_copy_info(dst_buf, end_buf, &info, dst_size, - sizeof(info)); - if ( ret ) + if ( idx >= start_index ) { - read_unlock(&ffa_ctx_list_rwlock); - return ret; + info.id = dest_ctx->ffa_id; + info.execution_context = dest_ctx->num_vcpus; + info.partition_properties = FFA_PART_VM_PROP; + if ( dest_ctx->is_64bit ) + info.partition_properties |= FFA_PART_PROP_AARCH64_STATE; + + ret = ffa_copy_info(dst_buf, end_buf, &info, dst_size, + sizeof(info)); + if ( ret ) + { + read_unlock(&ffa_ctx_list_rwlock); + return ret; + } + count++; } - count++; + idx++; } read_unlock(&ffa_ctx_list_rwlock); } @@ -355,7 +364,7 @@ void ffa_handle_partition_info_get(struct cpu_user_regs *regs) goto out_rx_release; } - ret = ffa_get_vm_partinfo(uuid, &ffa_vm_count, &dst_buf, end_buf, + ret = ffa_get_vm_partinfo(uuid, 0, &ffa_vm_count, &dst_buf, end_buf, dst_size); out_rx_release: -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:44:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:44:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244375.1543840 (Exim 4.92) (envelope-from ) id 1vx5Rr-0006n4-Ip; Mon, 02 Mar 2026 15:44:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244375.1543840; Mon, 02 Mar 2026 15:44:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rr-0006mx-Fx; Mon, 02 Mar 2026 15:44:43 +0000 Received: by outflank-mailman (input) for mailman id 1244375; Mon, 02 Mar 2026 15:44:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rq-00060E-2A for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:44:42 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id b949a518-164e-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 16:44:39 +0100 (CET) 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 F17D21570; Mon, 2 Mar 2026 07:44:32 -0800 (PST) Received: from C3HXLD123V.arm.com (unknown [10.57.82.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E32103F73B; Mon, 2 Mar 2026 07:44:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b949a518-164e-11f1-9ccf-f158ae23cfc8 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v2 3/4] xen/arm: ffa: Drop SP subscriber lists Date: Mon, 2 Mar 2026 16:44:12 +0100 Message-ID: <055bed7c55f298a0916518fb61929bfc7dac6ef2.1772464956.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The init-time SP cache already contains partition properties, but the code still builds separate subscriber arrays for VM created/destroyed notifications. That duplicates state and allocation. Use the cached SP list directly to: - decide which SPs receive created/destroyed notifications - build the per-domain destroy bitmap - skip destroy notifications for SPs not notified on create Also switch cached SP entry field reads in VM create/destroy notification paths to unaligned-safe helpers, as cache entries are variable-size and should not be dereferenced via struct pointers. No functional changes. Signed-off-by: Bertrand Marquis --- Changes since v1: - use unaligned-safe reads for cached SP entry fields (id/partition_properties) in VM create/destroy notification paths --- xen/arch/arm/tee/ffa_partinfo.c | 170 +++++++++----------------------- 1 file changed, 47 insertions(+), 123 deletions(-) diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c index b933becaa55a..419e19510f6f 100644 --- a/xen/arch/arm/tee/ffa_partinfo.c +++ b/xen/arch/arm/tee/ffa_partinfo.c @@ -29,12 +29,6 @@ struct ffa_partition_info_1_1 { uint8_t uuid[16]; }; -/* SPs subscribing to VM_CREATE and VM_DESTROYED events */ -static uint16_t *subscr_vm_created __read_mostly; -static uint16_t subscr_vm_created_count __read_mostly; -static uint16_t *subscr_vm_destroyed __read_mostly; -static uint16_t subscr_vm_destroyed_count __read_mostly; - /* SP list cache (secure endpoints only); populated at init. */ static void *sp_list __read_mostly; static uint32_t sp_list_count __read_mostly; @@ -92,6 +86,14 @@ static uint16_t ffa_sp_entry_read_id(const void *entry) offsetof(struct ffa_partition_info_1_0, id)); } +static uint32_t ffa_sp_entry_read_partition_properties(const void *entry) +{ + return get_unaligned_t(uint32_t, + (const uint8_t *)entry + + offsetof(struct ffa_partition_info_1_0, + partition_properties)); +} + static bool ffa_sp_entry_matches_uuid(const void *entry, struct ffa_uuid uuid) { struct ffa_uuid sp_uuid; @@ -440,14 +442,6 @@ static void ffa_sp_list_cache_free(void) sp_list_entry_size = 0; } -static void uninit_subscribers(void) -{ - subscr_vm_created_count = 0; - subscr_vm_destroyed_count = 0; - XFREE(subscr_vm_created); - XFREE(subscr_vm_destroyed); -} - static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, uint32_t fpi_size) { @@ -505,79 +499,6 @@ static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, return true; } -static bool init_subscribers(void *buf, uint16_t count, uint32_t fpi_size) -{ - uint16_t n; - uint16_t c_pos; - uint16_t d_pos; - struct ffa_partition_info_1_1 *fpi; - - if ( fpi_size < sizeof(struct ffa_partition_info_1_1) ) - { - printk(XENLOG_ERR "ffa: partition info size invalid: %u\n", fpi_size); - return false; - } - - subscr_vm_created_count = 0; - subscr_vm_destroyed_count = 0; - for ( n = 0; n < count; n++ ) - { - fpi = buf + n * fpi_size; - - /* - * We need to have secure partitions using bit 15 set convention for - * secure partition IDs. - * Inform the user with a log and discard giving created or destroy - * event to those IDs. - */ - if ( !FFA_ID_IS_SECURE(fpi->id) ) - { - printk_once(XENLOG_ERR - "ffa: Firmware is not using bit 15 convention for IDs !!\n"); - printk(XENLOG_ERR - "ffa: Secure partition with id 0x%04x cannot be used\n", - fpi->id); - } - else - { - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_CREATED ) - subscr_vm_created_count++; - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_DESTROYED ) - subscr_vm_destroyed_count++; - } - } - - if ( subscr_vm_created_count ) - subscr_vm_created = xzalloc_array(uint16_t, subscr_vm_created_count); - if ( subscr_vm_destroyed_count ) - subscr_vm_destroyed = xzalloc_array(uint16_t, - subscr_vm_destroyed_count); - if ( (subscr_vm_created_count && !subscr_vm_created) || - (subscr_vm_destroyed_count && !subscr_vm_destroyed) ) - { - printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n"); - uninit_subscribers(); - return false; - } - - for ( c_pos = 0, d_pos = 0, n = 0; n < count; n++ ) - { - fpi = buf + n * fpi_size; - - if ( FFA_ID_IS_SECURE(fpi->id) ) - { - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_CREATED ) - subscr_vm_created[c_pos++] = fpi->id; - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_DESTROYED ) - subscr_vm_destroyed[d_pos++] = fpi->id; - } - } - - return true; -} - - - bool ffa_partinfo_init(void) { bool ret = false; @@ -617,52 +538,39 @@ bool ffa_partinfo_init(void) goto out_release_rx; } - if ( !init_subscribers(sp_list, sp_list_count, sp_list_entry_size) ) - goto out_free_sp_cache; - ret = true; goto out_release_rx; -out_free_sp_cache: - ffa_sp_list_cache_free(); - out_release_rx: e = ffa_rxtx_spmc_rx_release(notify_fw); if ( e ) printk(XENLOG_WARNING "ffa: Error releasing SPMC RX buffer: %d\n", e); - + if ( !ret ) + ffa_sp_list_cache_free(); return ret; } -static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start, - uint16_t end, uint16_t sp_id) +static void vm_destroy_bitmap_init(struct ffa_ctx *ctx, + unsigned int first_unnotified) { unsigned int n; - for ( n = start; n < end; n++ ) + for ( n = 0; n < sp_list_count; n++ ) { - if ( subscr[n] == sp_id ) - return true; - } - - return false; -} + const void *entry = sp_list + n * sp_list_entry_size; + uint32_t partition_props = + ffa_sp_entry_read_partition_properties(entry); -static void vm_destroy_bitmap_init(struct ffa_ctx *ctx, - unsigned int create_signal_count) -{ - unsigned int n; + if ( !(partition_props & FFA_PART_PROP_NOTIF_DESTROYED) ) + continue; - for ( n = 0; n < subscr_vm_destroyed_count; n++ ) - { /* * Skip SPs subscribed to the VM created event that never was * notified of the VM creation due to an error during * ffa_domain_init(). */ - if ( is_in_subscr_list(subscr_vm_created, create_signal_count, - subscr_vm_created_count, - subscr_vm_destroyed[n]) ) + if ( (partition_props & FFA_PART_PROP_NOTIF_CREATED) && + n >= first_unnotified ) continue; set_bit(n, ctx->vm_destroy_bitmap); @@ -671,32 +579,42 @@ static void vm_destroy_bitmap_init(struct ffa_ctx *ctx, int32_t ffa_partinfo_domain_init(struct domain *d) { - unsigned int count = BITS_TO_LONGS(subscr_vm_destroyed_count); + unsigned int count = BITS_TO_LONGS(sp_list_count); struct ffa_ctx *ctx = d->arch.tee; unsigned int n; + unsigned int first_unnotified = sp_list_count; int32_t res; - if ( !ffa_fw_supports_fid(FFA_MSG_SEND_DIRECT_REQ_32) ) + if ( !ffa_fw_supports_fid(FFA_MSG_SEND_DIRECT_REQ_32) || !sp_list_count ) return 0; ctx->vm_destroy_bitmap = xzalloc_array(unsigned long, count); if ( !ctx->vm_destroy_bitmap ) return -ENOMEM; - for ( n = 0; n < subscr_vm_created_count; n++ ) + for ( n = 0; n < sp_list_count; n++ ) { - res = ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_id(d), + const void *entry = sp_list + n * sp_list_entry_size; + uint32_t partition_props = + ffa_sp_entry_read_partition_properties(entry); + uint16_t id = ffa_sp_entry_read_id(entry); + + if ( !(partition_props & FFA_PART_PROP_NOTIF_CREATED) ) + continue; + + res = ffa_direct_req_send_vm(id, ffa_get_vm_id(d), FFA_MSG_SEND_VM_CREATED); if ( res ) { printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %u to %u: res %d\n", - ffa_get_vm_id(d), subscr_vm_created[n], res); + ffa_get_vm_id(d), id, res); + first_unnotified = n; break; } } - vm_destroy_bitmap_init(ctx, n); + vm_destroy_bitmap_init(ctx, first_unnotified); - if ( n != subscr_vm_created_count ) + if ( first_unnotified != sp_list_count ) return -EIO; return 0; @@ -711,18 +629,24 @@ bool ffa_partinfo_domain_destroy(struct domain *d) if ( !ctx->vm_destroy_bitmap ) return true; - for ( n = 0; n < subscr_vm_destroyed_count; n++ ) + for ( n = 0; n < sp_list_count; n++ ) { + const void *entry; + uint16_t id; + if ( !test_bit(n, ctx->vm_destroy_bitmap) ) continue; - res = ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_vm_id(d), + entry = sp_list + n * sp_list_entry_size; + id = ffa_sp_entry_read_id(entry); + + res = ffa_direct_req_send_vm(id, ffa_get_vm_id(d), FFA_MSG_SEND_VM_DESTROYED); if ( res && printk_ratelimit() ) printk(XENLOG_WARNING "%pd: ffa: Failed to report destruction of vm_id %u to %u: res %d\n", - d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res); + d, ffa_get_vm_id(d), id, res); /* * For these two error codes the hypervisor is expected to resend @@ -734,7 +658,7 @@ bool ffa_partinfo_domain_destroy(struct domain *d) clear_bit(n, ctx->vm_destroy_bitmap); } - if ( bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count) ) + if ( bitmap_empty(ctx->vm_destroy_bitmap, sp_list_count) ) XFREE(ctx->vm_destroy_bitmap); return !ctx->vm_destroy_bitmap; -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:44:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:44:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244378.1543849 (Exim 4.92) (envelope-from ) id 1vx5Rt-00073Y-R2; Mon, 02 Mar 2026 15:44:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244378.1543849; Mon, 02 Mar 2026 15:44:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rt-00073O-Nr; Mon, 02 Mar 2026 15:44:45 +0000 Received: by outflank-mailman (input) for mailman id 1244378; Mon, 02 Mar 2026 15:44:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5Rr-00060E-UU for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:44:44 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-flk1.inumbo.com (Halon) with ESMTP id ba4f9867-164e-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 16:44:41 +0100 (CET) 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 AECAA152B; Mon, 2 Mar 2026 07:44:34 -0800 (PST) Received: from C3HXLD123V.arm.com (unknown [10.57.82.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A35133F73B; Mon, 2 Mar 2026 07:44:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ba4f9867-164e-11f1-9ccf-f158ae23cfc8 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Cc: Volodymyr Babchuk , Jens Wiklander , Stefano Stabellini , Julien Grall , Michal Orzel Subject: [PATCH v2 4/4] xen/arm: ffa: Add cached GET_REGS support Date: Mon, 2 Mar 2026 16:44:13 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit FF-A v1.2 defines PARTITION_INFO_GET_REGS for register-based partition info retrieval, but Xen currently only supports the buffer-based GET path for guests. Implement GET_REGS using the cached SP list and VM entries, including the register window layout and input validation. Track VM list changes via the partinfo tag and use it to validate GET_REGS tag inputs. Ensure that when a non-Nil UUID is specified, the UUID fields in both GET and GET_REGS results are MBZ as required by the specification. PARTITION_INFO_GET_REGS is available to v1.2 guests, returning cached SP entries and VM entries with UUIDs zeroed for non-Nil UUID queries. Also publish VM membership updates (VM count, ctx list, and partinfo tag) under the same write-locked section so GET_REGS sees coherent state and concurrent changes are reliably reported via RETRY. Signed-off-by: Bertrand Marquis --- Changes since v1: - ignore x4-x17 not being zero and x3 bits 63-32 not being zero (defined as SBZ in the spec) - detect tag changes during GET_REGS handling and return RETRY - remove strict check of sp_list_entry_size, larger cache entry sizes will now be accepted - publish VM count, ctx list, and partinfo tag updates under ffa_ctx_list_rwlock for coherent visibility --- xen/arch/arm/tee/ffa.c | 23 +++- xen/arch/arm/tee/ffa_partinfo.c | 200 ++++++++++++++++++++++++++++++++ xen/arch/arm/tee/ffa_private.h | 4 +- 3 files changed, 223 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c index aa43ae2595d7..d6cae67e1a48 100644 --- a/xen/arch/arm/tee/ffa.c +++ b/xen/arch/arm/tee/ffa.c @@ -44,6 +44,11 @@ * - doesn't support signalling the secondary scheduler of pending * notification for secure partitions * - doesn't support notifications for Xen itself + * o FFA_PARTITION_INFO_GET/GET_REGS: + * - v1.0 guests may see duplicate SP IDs when firmware provides UUIDs + * - SP list is cached at init; SPMC tag changes are not tracked + * between calls + * - SP list is capped at FFA_MAX_NUM_SP entries * * There are some large locked sections with ffa_spmc_tx_lock and * ffa_spmc_rx_lock. Especially the ffa_spmc_tx_lock spinlock used @@ -183,10 +188,11 @@ static bool ffa_negotiate_version(struct cpu_user_regs *regs) if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) { - /* One more VM with FF-A support available */ - inc_ffa_vm_count(); write_lock(&ffa_ctx_list_rwlock); + /* Publish VM membership changes atomically with tag updates. */ + inc_ffa_vm_count(); list_add_tail(&ctx->ctx_list, &ffa_ctx_head); + ffa_partinfo_inc_tag(); write_unlock(&ffa_ctx_list_rwlock); } @@ -341,6 +347,12 @@ static void handle_features(struct cpu_user_regs *regs) case FFA_FEATURE_SCHEDULE_RECV_INTR: ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0); break; + case FFA_PARTITION_INFO_GET_REGS: + if ( ACCESS_ONCE(ctx->guest_vers) >= FFA_VERSION_1_2 ) + ffa_set_regs_success(regs, 0, 0); + else + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); + break; case FFA_NOTIFICATION_BIND: case FFA_NOTIFICATION_UNBIND: @@ -402,6 +414,9 @@ static bool ffa_handle_call(struct cpu_user_regs *regs) case FFA_PARTITION_INFO_GET: ffa_handle_partition_info_get(regs); return true; + case FFA_PARTITION_INFO_GET_REGS: + ffa_handle_partition_info_get_regs(regs); + return true; case FFA_RX_RELEASE: e = ffa_rx_release(ctx); break; @@ -625,9 +640,11 @@ static int ffa_domain_teardown(struct domain *d) if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && ACCESS_ONCE(ctx->guest_vers) ) { - dec_ffa_vm_count(); write_lock(&ffa_ctx_list_rwlock); + /* Publish VM membership changes atomically with tag updates. */ + dec_ffa_vm_count(); list_del(&ctx->ctx_list); + ffa_partinfo_inc_tag(); write_unlock(&ffa_ctx_list_rwlock); } diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_partinfo.c index 419e19510f6f..16da5ee567db 100644 --- a/xen/arch/arm/tee/ffa_partinfo.c +++ b/xen/arch/arm/tee/ffa_partinfo.c @@ -29,10 +29,39 @@ struct ffa_partition_info_1_1 { uint8_t uuid[16]; }; +/* Registers a3..a17 (15 regs) carry partition descriptors, 3 regs each. */ +#define FFA_PARTINFO_REG_MAX_ENTRIES \ + ((15 * sizeof(uint64_t)) / sizeof(struct ffa_partition_info_1_1)) + /* SP list cache (secure endpoints only); populated at init. */ static void *sp_list __read_mostly; static uint32_t sp_list_count __read_mostly; static uint32_t sp_list_entry_size __read_mostly; + +/* SP list is static; tag only moves when VMs are added/removed. */ +static atomic_t ffa_partinfo_tag = ATOMIC_INIT(1); + +void ffa_partinfo_inc_tag(void) +{ + atomic_inc(&ffa_partinfo_tag); +} + +static inline uint16_t ffa_partinfo_get_tag(void) +{ + /* + * Tag moves with VM list changes only. + * + * Limitation: we cannot detect an SPMC tag change between calls because we + * do not retain the previous SPMC tag; we only refresh it via the mandatory + * start_index=0 call and assume it stays stable while combined_tag (our + * VM/SP-count tag) is used for guest validation. This means SPMC tag + * changes alone will not trigger RETRY. + */ + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + return atomic_read(&ffa_partinfo_tag) & GENMASK(15, 0); + else + return 1; +} static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t flags, uint32_t *count, uint32_t *fpi_size) { @@ -140,6 +169,7 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_count, for ( n = 0; n < sp_list_count; n++ ) { void *entry = sp_list + n * sp_list_entry_size; + void *dst_pos; if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) continue; @@ -151,11 +181,20 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_count, * This is a non-compliance to the specification but 1.0 VMs should * handle that on their own to simplify Xen implementation. */ + dst_pos = *dst_buf; ret = ffa_copy_info(dst_buf, end_buf, entry, dst_size, sp_list_entry_size); if ( ret ) return ret; + if ( !ffa_uuid_is_nil(uuid) && + dst_size >= sizeof(struct ffa_partition_info_1_1) ) + { + struct ffa_partition_info_1_1 *fpi = dst_pos; + + memset(fpi->uuid, 0, sizeof(fpi->uuid)); + } + count++; } @@ -167,6 +206,38 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_count, return FFA_RET_OK; } +static uint16_t ffa_get_sp_partinfo_regs(struct ffa_uuid uuid, + uint16_t start_index, + uint64_t *out_regs, + uint16_t max_entries) +{ + uint32_t idx = 0; + uint16_t filled = 0; + uint32_t n; + + for ( n = 0; n < sp_list_count && filled < max_entries; n++ ) + { + void *entry = sp_list + n * sp_list_entry_size; + + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) + continue; + + if ( idx++ < start_index ) + continue; + + memcpy(&out_regs[filled * 3], entry, + sizeof(struct ffa_partition_info_1_1)); + if ( !ffa_uuid_is_nil(uuid) ) + { + out_regs[filled * 3 + 1] = 0; + out_regs[filled * 3 + 2] = 0; + } + filled++; + } + + return filled; +} + static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_index, uint32_t *vm_count, void **dst_buf, void *end_buf, uint32_t dst_size) @@ -383,6 +454,135 @@ out: } } +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs) +{ + struct domain *d = current->domain; + struct ffa_ctx *ctx = d->arch.tee; + struct ffa_uuid uuid; + uint32_t sp_count = 0, vm_count = 0, total_count; + uint16_t start_index, tag; + uint16_t num_entries = 0; + uint64_t x3 = get_user_reg(regs, 3); + int32_t ret = FFA_RET_OK; + uint64_t out_regs[18] = { 0 }; + unsigned int n; + uint16_t tag_out, tag_end; + + if ( ACCESS_ONCE(ctx->guest_vers) < FFA_VERSION_1_2 ) + { + ret = FFA_RET_NOT_SUPPORTED; + goto out; + } + + /* + * Registers a3..a17 (15 regs) carry partition descriptors, 3 regs each. + * For FF-A 1.2, that yields a maximum of 5 entries per GET_REGS call. + * Enforce the assumed layout so window sizing stays correct. + */ + BUILD_BUG_ON(FFA_PARTINFO_REG_MAX_ENTRIES != 5); + + start_index = x3 & GENMASK(15, 0); + tag = (x3 >> 16) & GENMASK(15, 0); + + /* Start index must allow room for up to 5 entries without 16-bit overflow. */ + if ( start_index > (GENMASK(15, 0) - (FFA_PARTINFO_REG_MAX_ENTRIES - 1)) ) + { + ret = FFA_RET_INVALID_PARAMETERS; + goto out; + } + + uuid.val[0] = get_user_reg(regs, 1); + uuid.val[1] = get_user_reg(regs, 2); + + tag_out = ffa_partinfo_get_tag(); + + if ( start_index == 0 ) + { + if ( tag ) + { + ret = FFA_RET_INVALID_PARAMETERS; + goto out; + } + } + else if ( tag != tag_out ) + { + ret = FFA_RET_RETRY; + goto out; + } + + if ( ffa_uuid_is_nil(uuid) ) + { + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) + vm_count = get_ffa_vm_count(); + else + vm_count = 1; /* Caller VM only */ + } + + ret = ffa_get_sp_count(uuid, &sp_count); + if ( ret ) + goto out; + + total_count = sp_count + vm_count; + + if ( total_count == 0 || start_index >= total_count ) + { + ret = FFA_RET_INVALID_PARAMETERS; + goto out; + } + + if ( start_index < sp_count ) + num_entries = ffa_get_sp_partinfo_regs(uuid, start_index, &out_regs[3], + FFA_PARTINFO_REG_MAX_ENTRIES); + + if ( num_entries < FFA_PARTINFO_REG_MAX_ENTRIES ) + { + uint32_t vm_start = start_index > sp_count ? + start_index - sp_count : 0; + uint32_t filled = 0; + void *vm_dst = &out_regs[3 + num_entries * 3]; + void *vm_end = &out_regs[18]; + + ret = ffa_get_vm_partinfo(uuid, vm_start, &filled, &vm_dst, vm_end, + sizeof(struct ffa_partition_info_1_1)); + if ( ret != FFA_RET_OK && ret != FFA_RET_NO_MEMORY ) + goto out; + + num_entries += filled; + } + + if ( num_entries == 0 ) + { + ret = FFA_RET_INVALID_PARAMETERS; + goto out; + } + + /* + * Detect list changes while building the response so the caller can retry + * with a coherent snapshot tag. + */ + tag_end = ffa_partinfo_get_tag(); + if ( tag_end != tag_out ) + { + ret = FFA_RET_RETRY; + goto out; + } + + out_regs[0] = FFA_SUCCESS_64; + out_regs[2] = ((uint64_t)sizeof(struct ffa_partition_info_1_1) << 48) | + ((uint64_t)tag_end << 32) | + ((uint64_t)(start_index + num_entries - 1) << 16) | + ((uint64_t)(total_count - 1) & GENMASK(15, 0)); + + for ( n = 0; n < ARRAY_SIZE(out_regs); n++ ) + set_user_reg(regs, n, out_regs[n]); + + return; + +out: + if ( ret ) + ffa_set_regs_error(regs, ret); +} + static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id, uint8_t msg) { diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_private.h index 1a632983c860..c291f32b56ff 100644 --- a/xen/arch/arm/tee/ffa_private.h +++ b/xen/arch/arm/tee/ffa_private.h @@ -289,7 +289,7 @@ #define FFA_MSG_SEND2 0x84000086U #define FFA_CONSOLE_LOG_32 0x8400008AU #define FFA_CONSOLE_LOG_64 0xC400008AU -#define FFA_PARTITION_INFO_GET_REGS 0x8400008BU +#define FFA_PARTITION_INFO_GET_REGS 0xC400008BU #define FFA_MSG_SEND_DIRECT_REQ2 0xC400008DU #define FFA_MSG_SEND_DIRECT_RESP2 0xC400008EU @@ -452,6 +452,8 @@ bool ffa_partinfo_init(void); int32_t ffa_partinfo_domain_init(struct domain *d); bool ffa_partinfo_domain_destroy(struct domain *d); void ffa_handle_partition_info_get(struct cpu_user_regs *regs); +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs); +void ffa_partinfo_inc_tag(void); int32_t ffa_endpoint_domain_lookup(uint16_t endpoint_id, struct domain **d_out, struct ffa_ctx **ctx_out); -- 2.52.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:47:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:47:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244416.1543860 (Exim 4.92) (envelope-from ) id 1vx5UK-00007b-6o; Mon, 02 Mar 2026 15:47:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244416.1543860; Mon, 02 Mar 2026 15:47:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5UK-00007U-47; Mon, 02 Mar 2026 15:47:16 +0000 Received: by outflank-mailman (input) for mailman id 1244416; Mon, 02 Mar 2026 15:47:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5UI-000072-KU for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:47:14 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1423503b-164f-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:47:13 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA2PR03MB5817.namprd03.prod.outlook.com (2603:10b6:806:11d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Mon, 2 Mar 2026 15:47: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%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 15:47:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1423503b-164f-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Nf38qlXtLyPOEiEubE01tKmOKd0kIKb9Zv8DRjQ6qzVwbs9/dMAIfM5LzH6ypn2t///yRCR+0fcc1rk448WbM6T9piRe1VFLXnMSovqiUHke1fVbGrVKS/XvJCnvJnnVkRQrS3SY7CuL2hsBGr1WgtZzMfTJhsOeiud6P2HkS8bfkNod2WW/FTPIL3sZnpGBlD00L6hYHmczY0JFPkFEWrCt1nPiLW0HtRtpyV5K4Rn36ZjYcuXzP3FRhXttiWi225IYnfFoCCWkQO1d/Q+z64Q3LEo4QmhD4x55DJa4ZLP8oU38rgSxHgkUTn/C5oDicF/LKycBn9ZSYz/8FDm6MQ== 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=0y+S1Kp3BTitawanS0oApxEXRRZN8x8ryHCgv2OtqCM=; b=pR3seyYgfYPkrTtj0xaTP6KeGNhTIKGW83PDnjbV5H7FjFY/LkxjdgtIuHyafAMKPk41fhUkeq02ExbrwYpFj8QrasI0GW8eXTWqpeQH4G4Ihm86t7TuCSvL3QAANHtlUrokgBra7oIJIyMUCKMnbLHJE9Vj1/h8du4k8Kf4IxMt0o9cPAPUNVmaDRgJqrvHSzKD1NbBjAiXDzWm8tOAv6BBlY19nS5Kq5wjN+chxD4Lb0arsx17pA+NIhN5wY2L/vOjGYne9LjkboeXtF2hflrc+ffCkzU3IMszUOlS7OKqYgdYQZrAJfD7dXCDmMaCQiRblCZTx/nSmSfB3M0srg== 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=0y+S1Kp3BTitawanS0oApxEXRRZN8x8ryHCgv2OtqCM=; b=PwHvx90EBzzlAbcnFQ2jwejxtkceZw9p6Jn7u7kccL0qcxPzQEicsXQK5C9axBWSEBvgTJ9JGGcTWac8QNapftqye8ATA6clAs4CP9NK9YZ8t5HzPev5frz8CHNog09wTm1i1lM6m3rmTWC2hn5QzvH59WWWgy2OFufYcnRZ1ss= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <2df919aa-5eac-44d7-a707-4a658b78d1af@citrix.com> Date: Mon, 2 Mar 2026 15:47:04 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 06/14] x86/traps: Don't configure Supervisor Shadow Stack tokens in FRED mode To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-7-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P265CA0003.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:339::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_|SA2PR03MB5817:EE_ X-MS-Office365-Filtering-Correlation-Id: 019f0179-7437-4303-91fe-08de7872f5d3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: KVNE6wzj9kePr4xlARLKst+owzVWjrxICFHHZvwIAr34E7OA6eJBQZmpqeqIgvB5HlECkkzHJYug0KsaFN1b8Z3zKoJRtk1W8C18yaMmX41CW9TvCiFLmEaUTpOi2pm5ACRSY+nyY+e+nA+QhDU3Z5TG+Lq2IhJbsWIw5MCznw7YuAvjjIJ1mUm7YWqwTVB1n23Y04cTLcH3zUTPBTSwjfnApPpy0p7cY7OFn2h96HduJg30BwaECy1U9g/p2hxu2DwYDN5oI53FBCLsD2iwN0f0Ced7ivbsFWdu7QekPmJ3hGdaH19l6W/7v/43chnd6lGoZgLSD3Op6cxrIW+uvTdoNUljaAT/I6AH6G+xnpX83msOPQLu4YIUklI/UHnUYhtV6ulJVfrZGtc/xGjCT43WmvuLz+6/ujMUS6gatnQdDhnPJQgkzCJ2Mrar7YkzzCiSluso5vaAcySahlphXEzFz3+zq1P04r797s8u6SwJ4cgTMKcEmLjp1jKEGFF6FNfRU013FntPhc00klhqIkm+0ptTKnSBj4Upc4Q1Xu5riUsYHdhTgIud2282LgB3h7yctW/uJbbaOPSrRsNaQYq/1xeXQWlDo5+R+xnJTGx06roJr14gptRSpm7eiUDoAE+4ijz/DGXpeCs0DDRTjRCxyxyRvOi1WAV4DGyOtCpnCBpjNyjCGN+jxakavA1VFse7AmoHxvb+iBC9THCb6HgfJEtvYmQulJUG7MFX+Dg= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bzM4QkpVbU5XRWxnUUI1ZWdkSGR5bDlYWkp0ckcxNG1pNndXUVJldnpFeG9y?= =?utf-8?B?Z3lsQnRaVDNkMVBERVdLOExueURRTUJwcHpuUS94Z0JKMFZsOEFVenVJMlFU?= =?utf-8?B?WEE4b2tpcmpJMFNyS05QMWxKNGxMeHE1V1lPY0g5QnpiODhFNktKM1F1VUd3?= =?utf-8?B?L1dyMUdSalZuaXZUWGFod1pUbzNaeDZvVUtRYUFJcFVZSVlYUFJXWEZwVHZt?= =?utf-8?B?dTRzakV0NjFWY1Q5ZnBWWUo0cm1ERVgwYktvTzNMNittTUE5K2d3OC9LYVhn?= =?utf-8?B?L2JnU3ZpYmNLbFE4NXRoRzNSUDQ1QW5CZktqMDg1S2kwTDFoT3lpZ3AweW5a?= =?utf-8?B?M1Z2MGI2SEhTc05qWTd4N294enM2SXFyRHBrUnF0NGxmd1ppd05CTkozZnc2?= =?utf-8?B?RmZXeHQrdVdaTDJ0bmV0MVBqOUdxL0FQdmlpbitILyt1Vnp5cG9aWGpLakxJ?= =?utf-8?B?ZVpkcnp0ZXRPb05JSk9zRyt4RGNEcUY3Q2Q3WSswUmlvUytwSVZYdGJVV2JK?= =?utf-8?B?Ykx3ZFZuYnpJaDNWRGgrbmc3RWNaczVPZWRZcGdicTlNTHZsdlNwSlNQRXFO?= =?utf-8?B?SXZXdW53YWFWWDhkbUlrSERPRzluL0xScHBockd0MlFHeFY1V0dNcFVsa0Iv?= =?utf-8?B?VTBueEJhbkZ1T2FvbmVJaTRGZVBiaU1kWXptOXNoWVR4NGJCS3NnbS92emJl?= =?utf-8?B?M01UQ3VLOXRpcGhlRmEvMmNVTjRFOTFVTjdhRkkxNEMxc1lWclg2WDhJUTNz?= =?utf-8?B?U0tHVXVmWXJsYjZSVlErMFFnazhBSmZnb2I4NG5EWHBxQmpITEs0SGx3VXdx?= =?utf-8?B?dHAraTdsRmZjcWdCNjlybkd0UlFpNHhoaDl2YVhmeW40R0tIVVZRaDhibzc0?= =?utf-8?B?UEloaW5kTCsyQUhTMzFTZXhKSnpoY0xGVzcranpNa1UxZTExcnRWV3pJUEtL?= =?utf-8?B?bGMvcGlvd1NCWFJNM244bXNDR3B2a0pXTFMrYkZISlJaQ0YwdkcyWFU4ekVS?= =?utf-8?B?d2ZaR1ZUeEZCSjVnQk5JZWZnbTNTL1NXWlVRUWZPUTZhbzVNQ0h4cGw2a3N0?= =?utf-8?B?MkpCdnk0WU9XUW9RekhIT2lmQUJpMlFLOThSbE9nSzNsMUF5bFFhT21aNnRN?= =?utf-8?B?UXd1VkNydllNWmlDS2ExZDluZkRFZ3R2K1dRVzFzRU83RkxabFJCVWU4UGUy?= =?utf-8?B?TnRqbWtWMEdsZVB4QXY5TTcyam5scmgyVERielErUXRzVUtFYXh0UUYrYTZ0?= =?utf-8?B?dmFXTkdqN2FtWUU1QXBHSTFRd3ZFbFRqUDZLeWFTT0NNM3I0b3llMzdkMXRs?= =?utf-8?B?M28rRU5KQW9Wc2xESWxnMzZHbTdaQTRFWjIvakZXcWIzbFpjeVVoUzNtT0l6?= =?utf-8?B?eC9pRHplRWFiTzlEbFkwbng0VUJrQnZwVTN0Ukg3YlhvSlZ5WVBUVlNuSW5E?= =?utf-8?B?RExhVUhnUFJ5bk94UGZ2Rk9tdEN5V24vK2RYTURzc3MvUHBpOVptS3lBb2Vq?= =?utf-8?B?aG5FaksvcXh0Ump5Um9Cc1dNR3JMYTJETDROcjlyNTNidlhrL1JpYkgzZkhx?= =?utf-8?B?NFlzWjBYQTdOL2NhYjExZW9iTVJ4Zjd3dWJiT2hrWnFkQnZPSU9vdFRWVm45?= =?utf-8?B?eXAwZ2paV0lwRlZKU1ZjSzFQWVBFNjhXN1Vka24wM3U1Q1JQTnc5VFZvRDVF?= =?utf-8?B?VjljKytWd0s4QnNDbm9mZldMTHNTSzUxRGZ6Ym9aRFo3aFhiWElYU1I0NGtj?= =?utf-8?B?blZYUmg3NUFzV3BPeVdZUTdFbUx2YU4zZnRLeWxnWUpnRUR0VG1LTHIvSVRE?= =?utf-8?B?aW1RZ1lwTzFSZ0FDTDE5ZFliMG50RS9ITmRrUkhDSXl2TnpmLytRa2FwYzZM?= =?utf-8?B?M1F6SWI3aDNaSFJqVlgvUStyQkVYQjA1c2tEUVNwNjJlME95a05tN3NCVDRR?= =?utf-8?B?NU9jVXF1TXJvaU5kMDJ3UHl5OXVmOWJDYTVNOEl1bS9MN0RnWjJkSXE3UUtj?= =?utf-8?B?N00rbkFYd2xtMnZqa3F0c2tib2dzN094aFRXcVU2cE9YKzdBb0xoVVZBS3Yv?= =?utf-8?B?eE1wYVNBODVWYUVJQ0lycFJDYjE0WVVXZ3gyUmJVZkRWQXlwdHBNdVJKY25t?= =?utf-8?B?TjEwbjdFQWVQOWRNMDdhL1RXT0JHR3RUSGFTSXlabkIyZG4xOHF3T0FRcklP?= =?utf-8?B?blBrdmJsaEpuWXR3RldndzNUajlqcTlENHBUMllvZVgrVm5pMVZHWDZwcjRW?= =?utf-8?B?RVV3YnhkT2ZXN2xybC9jWEZkZklMM05vRUl1NDVzK1FURi93c2Z4T0QwVmpj?= =?utf-8?B?a1Frbi9RUVNIZlhsV1Z2OHV0clhjTzFUYlBBZ0cvUnpEWS82UVV0dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 019f0179-7437-4303-91fe-08de7872f5d3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 15:47:08.0594 (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: A51T/NibxaCcuhB5KrMPSc5PXJoguXH/F2Xe8T99zxVAEFWUUbl6bRnv5t/ChyER6jXnoDMiZdFbnBtypUz+Mfe48Odrdob9wQCKbRnwwIo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5817 On 02/03/2026 2:50 pm, Jan Beulich wrote: > On 28.02.2026 00:16, Andrew Cooper wrote: >> FRED doesn't use Supervisor Shadow Stack tokens. This means that: >> >> 1) memguard_guard_stack() should not write Supervisor Shadow Stack Tokens. >> 2) cpu_has_bug_shstk_fracture is no longer relevant when deciding whether or >> not to enable Shadow Stacks in the first place. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. >> The SDM explicitly points out the shstk fracture vs FRED case, yet PTL >> enumerates CET-SSS (immunity to shstk fracture). I can only assume that there >> are other Intel CPUs with FRED but without CET-SSS. > Isn't CET-SSS still relevant to OSes not using FRED (much like you do for > the fred=no case)? Yes, CET-SSS is relevant outside of FRED mode. I just don't see the point of the note if all FRED systems will enumerate CET-SSS. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 15:54:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 15:54:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244430.1543869 (Exim 4.92) (envelope-from ) id 1vx5b3-0001um-VH; Mon, 02 Mar 2026 15:54:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244430.1543869; Mon, 02 Mar 2026 15:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5b3-0001uf-Si; Mon, 02 Mar 2026 15:54:13 +0000 Received: by outflank-mailman (input) for mailman id 1244430; Mon, 02 Mar 2026 15:54:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5b2-0001uW-R0 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 15:54:12 +0000 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0cbe06f4-1650-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 16:54:10 +0100 (CET) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 506227A013F; Mon, 2 Mar 2026 10:54:08 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Mon, 02 Mar 2026 10:54:08 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 2 Mar 2026 10:54:05 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0cbe06f4-1650-11f1-b164-2bf370ae4941 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=1772466848; x=1772553248; bh=o9cpGhld9lKXfSpgy3pgdi3vK+UFWbk2cVYvl3BrPTE=; b= qoujYvowuv0hlW6ILJCddnCZk39UxGyVdesGfyKns062zK89BtQWw13lINoXjF9A oiS5ZgBVGsGxSESKilaajAP2x8WOo9ATJRDKOCe7mtx9mAMrOWY0wTFKoFV3v55e K1tQh5/GyWZ2RaL1TW4oJNmNRao7549DDI2g1RgHAcdZ1M2I7rWLcALLx4ekByhR aoxz3jsBlwvJKgmS9kcnNQlnDb6KX7gyQZPhAJPYN1VflMHvW8S8GvmGWUk5w5G5 rq9jn19ipNvwls5dfNn/NflHVpFA+VYSAVu0ZmpGsO1g+0N0fKiK+ZZGGMOzHWMa Mojhceauqp9e2mXvsVlWCQ== 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=fm1; t= 1772466848; x=1772553248; bh=o9cpGhld9lKXfSpgy3pgdi3vK+UFWbk2cVY vl3BrPTE=; b=f1Ya3sPAczrvg7ue54hXKyb+bNEgut0Gs2BemEz4JipZDHJrES9 9fL/afWtsSU0iLQadwUhoaXkHP3CiH1ny4LWzE6+xJHkjC1VarCuusNjBTGOIbTA Klh5gc647k0928ZDAB67BmcS38zCciBY9+RJCEXXKb/lDelco43+wW7u4DXGHEKw O4LbgF4/Ly8ONwWym8NJzPliDYn8XTd0T6hPH3iq/Rx7aSlkixsHsyLGhEZhzTi1 U5acSQ/jSYy1NnuSN6OoPynEiISOZgxTbvwFOMNZ1pel9BSd3I7S/ORrXYX+QSHc Z4jKHMtakqUAYf3Kbn9JNbacD+SIEr1F9gA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvheektdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepuddtpd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehjrghsohhnrdgrnhgurhihuhhksegr mhgurdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpd hrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdho rhhgpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrd gtohhmpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthho pegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthhtoheprg hnthhhohhnhidrphgvrhgrrhgusehvrghtvghsrdhtvggthhdprhgtphhtthhopehmihgt hhgrlhdrohhriigvlhesrghmugdrtghomhdprhgtphhtthhopehjuhhlihgvnhesgigvnh drohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Mon, 2 Mar 2026 16:54:03 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Cc: Roger Pau Monne , xen-devel@lists.xenproject.org, "Daniel P. Smith" , Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] x86/efi: remove unreachable efi_halt_system() function Message-ID: References: <20260224200708.51120-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r+mswVBtSV8/6BKu" Content-Disposition: inline In-Reply-To: --r+mswVBtSV8/6BKu Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Mar 2026 16:54:03 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Cc: Roger Pau Monne , xen-devel@lists.xenproject.org, "Daniel P. Smith" , Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini Subject: Re: [PATCH] x86/efi: remove unreachable efi_halt_system() function On Tue, Feb 24, 2026 at 02:05:10PM -0500, Jason Andryuk wrote: > On 2026-02-24 15:07, Roger Pau Monne wrote: > > After e4c3755d4dd7 the function efi_halt_system() is unreachable, remov= e it > > from the file. > >=20 > > No functional change expected, as the function is not called. > >=20 > > Fixes: e4c3755d4dd7 ("x86-64/EFI: don't call EfiResetSystem() from mach= ine_halt()") > > Signed-off-by: Roger Pau Monn=C3=A9 >=20 > Reviewed-by: Jason Andryuk Acked-by: Marek Marczykowski-G=C3=B3recki --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --r+mswVBtSV8/6BKu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmlspsACgkQ24/THMrX 1yzhgAf/aH/IgRfFV9MYPW+CFSrrBrHtkIu3i4EqN1ph/3vWl8wGAlImUbcl9Z+C ZPhTxFiUkhFXqfeuTC7H/cn/RvH7NC0rafeuuKmT8KBVDpSnhNjJxe/9giX/B6VV g2mW+eCHnz5UaXfWWrO/wODv+lrCzoIa3Yqr/bezA5wKm8V8P4BPbIsx0mkfybvl GcLpwa7zBjgN4P76MxsliCJ/rpIRdJ3QFA7gJ0vYSwxQCx9r81d8jUeWHGqECrY5 DF4z3nvmNVUnwwVL5ZI/2rwD6HfWmrJb55+y3FTiOsZ7/GZjDM82a1Nal4FnuRk/ 6WSackBOB8xY7C+KB0KH+AEI6kBhbw== =7DhU -----END PGP SIGNATURE----- --r+mswVBtSV8/6BKu-- From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:12:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:12:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244443.1543887 (Exim 4.92) (envelope-from ) id 1vx5ss-0005W8-EX; Mon, 02 Mar 2026 16:12:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244443.1543887; Mon, 02 Mar 2026 16:12:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5ss-0005W1-Bv; Mon, 02 Mar 2026 16:12:38 +0000 Received: by outflank-mailman (input) for mailman id 1244443; Mon, 02 Mar 2026 16:12:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx5sr-0005Vs-Ft for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:12:37 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a031208f-1652-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 17:12:35 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439af00d33cso1529361f8f.1 for ; Mon, 02 Mar 2026 08:12:35 -0800 (PST) Received: from [10.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-439b4d06c27sm9976489f8f.17.2026.03.02.08.12.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:12:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a031208f-1652-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772467955; x=1773072755; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=h5tijJDKgCHJT9kT5kp84WZqHGBvYnXwSlos1jRzp5w=; b=JVeb7wsawovWd2G+YnQEvHJcEovdhMdkvgGXSfOlzw+kEu/n5qvAaxWJpPUUXHmSdY gHqFhV3MC/HMDnPg3bChXgSKG5yUvU5tIDbq5kOIg1NPDWnpn4xKAIPYeXrWem8Oies6 8eIVZMwzI+34HsIteoHI2k7P3Ie7y9+F/Vk2blwmiWpYcWcECgeKMuUcPh7JI3comYGB anAUsuFI9n7BIRlvQSPWyHU8q/qqlcObKnA8eDZO9gp5LTmWHrlZI6dkMuOwtKdkGUFb xWk/X7ua+bWRfz+iuR8RRjA/76atmHj9x+nkujB4Xa2Cn+KyO7wMGlJhSJvNa9MLOTQK 9tdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772467955; x=1773072755; h=content-transfer-encoding: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; bh=h5tijJDKgCHJT9kT5kp84WZqHGBvYnXwSlos1jRzp5w=; b=AL6Q1YtpZvW+5bnPjakzh8r3jInk7cehQnTmZCIxtfLPFqyBb4C8gx/bffC4tGqC2v /avXwKp+gLvbYCS5N/XE5d7WgGpmwpOBx0p+bWLKHDnQce7jAHPg9vBPCpDFy9fPXjdh f8+T9Z35Pdh+x/S9CwAc3vEcX1JhvB9L7713qdzyzkPhvi8Na7tHuX5xlzO/2XvBkrJW CFmPmI8d5Dih3fGhzcTa6Y3/2B8mEyiGD6s7lBocRmZhJHhdGrbV0cZWGAYEj3KKYJni xQqH0404XTWhkqfNFs1jxQHkR1rhrzowWVL2ok4URktX0DrQzjV/7/7pZTODoNZikZ17 Fe9Q== X-Forwarded-Encrypted: i=1; AJvYcCUh+HkGem2wODlUqmBB4kcmaOplhjGyApjYW8C2Ds/j4y4py/AH1DeWuCn9wgmGuCe4cD2t6Axv+M4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzvobG/eXx1pmoRuccSeV0RApDgpsGtPMPaiG8Q4WyNZo64s1m+ 0dtisMPiNkitrmriT23+CdYNlkFywDqK9Gjow95mDuMmYNmxv5piYzxjHQiK1ZI1lQ== X-Gm-Gg: ATEYQzxK6CpgymRLesbw/zV1AFXrY6rGCXt+CWYv2/MXaLztwBF+V8lo5cwGklFbyoX dP69U59MpagOXEf1JUOxy3RR3UP62xnDt+SB/eUKz7UkwWbKvUEfbrrao5wJ95EeqzSwcQgh/9A dYiqy0HnMUPxujcrX0MTeHwhtAE8vUmBqr0eLm+ddaprkb3g2/jTkGmj8p0AfcrnI1fHBX35Nkp 29mZSOTtoWD2/H8dI10+7vBB4rdp2e9aN6OzMLkI8xPy9MLCl3hiS865WCGx46plW07hB9yzY6q +b536CHJMdy1MrwQp8sV8ztWChwBDjdfEyNE5hIPGK7dcm3VJ9GnemnVyIFjnFvnpumwQ6Hbwr7 zengaWIX/dgIJ3BRE9BYJSwLooyFYe4pINhUUCARrVohL4nQG1W+iyFLdYXCswaGEJ7S7XsQ2pU TUO/CVx9IY/xRDB2tW+XXozSmP7Vb6cF/1qB6mVi1X1y1CO7JEuMB47YDyEGhTF5xdzWYlAB73s 4TkPB3LTKgkRlE= X-Received: by 2002:a5d:5850:0:b0:439:ba75:7db7 with SMTP id ffacd0b85a97d-439ba758121mr5007110f8f.7.1772467955072; Mon, 02 Mar 2026 08:12:35 -0800 (PST) Message-ID: <0dbf14bc-1505-4a33-bbf8-53c1ea41c7da@suse.com> Date: Mon, 2 Mar 2026 17:12:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 08/14] x86/traps: Enable FRED when requested To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-9-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-9-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > With the shadow stack and exception handling adjustements in place, we can now > activate FRED when appropriate. Note that opt_fred is still disabled by > default until more infrastructure is in place. > > Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses > MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP > when CET-SS is active. Otherwise, they're all new MSRs. > > Also introduce init_fred_tss(). At this juncture we need a TSS set up, even > if it is mostly unused. Reinsert the BUILD_BUG_ON() checking the size of the > TSS against 0x67, this time with a more precise comment. > > With init_fred() existing, load_system_tables() and legacy_syscall_init() > should only be used when setting up IDT delivery. Insert ASSERT()s to this > effect, and adjust the various init functions to make this property true. > > The FRED initialisation path still needs to write to all system table > registers at least once, even if only to invalidate them. Per the > documentation, percpu_early_traps_init() is responsible for switching off the > boot GDT, which also needs doing even in FRED mode. > > Finally, set CR4.FRED in traps_init()/percpu_early_traps_init(). > > Xen can now boot in FRED mode and run a PVH dom0. PV guests still need more > work before they can be run under FRED. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich > [*] PVH Dom0 on an Intel PantherLake CPU. What other part is this remark connected to? > @@ -353,7 +440,11 @@ void __init traps_init(void) > */ > void __init bsp_traps_reinit(void) > { > - load_system_tables(); > + if ( opt_fred ) > + init_fred(); > + else > + load_system_tables(); > + > percpu_traps_init(); > } I see now what you meant in reply to comments on an earlier patch. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:24:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:24:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244453.1543899 (Exim 4.92) (envelope-from ) id 1vx64D-0007LA-E8; Mon, 02 Mar 2026 16:24:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244453.1543899; Mon, 02 Mar 2026 16:24:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx64D-0007L3-AJ; Mon, 02 Mar 2026 16:24:21 +0000 Received: by outflank-mailman (input) for mailman id 1244453; Mon, 02 Mar 2026 16:24:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx64C-0007Kx-IY for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:24:20 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 433dcbae-1654-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 17:24:18 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-436e87589e8so4492287f8f.3 for ; Mon, 02 Mar 2026 08:24:18 -0800 (PST) Received: from [10.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-439b503424fsm11876479f8f.22.2026.03.02.08.24.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:24:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 433dcbae-1654-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772468658; x=1773073458; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=4sUZCTH/Q1jwHYCtk/g084ctsIEAOJE2quet31258JI=; b=AnoQFyVSuYcKp1u3IlnDWOGwnSO5rDJXG+t21nwauK+B2PfMgYY3g6qcOS0Ecz+Psz Hjmt/2bNQiTLFWFztlJrxuyc3CNIKJtZLIv2mkI3/GI9Aza8/pXZ2zN4BxB0VX69r4gD aLGhJLt/8NjpGOuBCRl8W2cqmryA3fVXfVxuTnlU7t4d4bDoGDvOGKnUxDQLyMGHt57t FonQCHosItpNRN9IUFFwRO+88FPrj8L94/Nx54haC0d96cCVjjHjCq+H+9aEg2Z2xz+V A6uRAF3jYeMzT5nH7Yk1WNuMsCypdoGoBMTNusDRJL7H+/5NvG4aCK8a91F7OykqL/pr IAlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772468658; x=1773073458; h=content-transfer-encoding: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; bh=4sUZCTH/Q1jwHYCtk/g084ctsIEAOJE2quet31258JI=; b=l1QV+Weq47Bd8erp0Zhac6vxCcCKqO+3Uad+P/TWrl2UDYYuf3JdCAsva7nSU9VyTC tks/hIOzCU3AZkroExLQYx0r6EfA0r4MUKbJfQLjkvYaffx7zTLK4b8XI2SXSwGJd7HK KeFyOZGJ3K29iXxw/ynBwYRJgtmx1dYnAxVwth47gAIeeDIqkkaTRSLE58nxe9P7rk4d DhSmMT8Qz+oYTgC4SnK+MJ2Elwoqr3RrTCHaOUVszzd5SY5eQy7WvJc7pME2RWB5pNqC SxCOOmChjuIXug+A/8tQeMYQNp0jd2V/rG0nRLdEV5r8/GYYfDaMkYriVY367Cm5yJMj w1TQ== X-Forwarded-Encrypted: i=1; AJvYcCUZ4kAY9egHb6/gD4qIbUOeBMTICziXvQhXy4o9eZck0X7CY6EriSV3quPh70Ha8UIvDSGAzpfhO+Y=@lists.xenproject.org X-Gm-Message-State: AOJu0YxJ//T+itYhua89WHigos60D7y2y61RWAFtFpPFzDec9EicrWEe cPZepwPXRFM+E8+yLg2O2xPSiOvZJLJeZS0kx3NkWwCdDaixeYbBaV4wefniKUNDUQ== X-Gm-Gg: ATEYQzwSP4LvqfIH79YiBDLIT4JT3150a7d539802N2fWtop5/Bw3FLdmW22+CbCuDz uyJUAUqH8Yc4lfIL2dGEm2npeCqld2wskX1LrrQoPPhk564UtJ7yvyXlO1uhZP2uTBMDEDOSM5f KSUjSSSujSENDOisnSwsS5tgcdk8rIn6w2YZwGXgYEw7u4djUDQRsNiY6N/ilhYHlElIrQHQUSG wkrf3cfF0tIJRNxFIv/07R3lK1MjJUcqa5JDJUPQbgG9jRhGxWnZGda5H7CerZOvPyMxkmkBfbS Wrfso9hyWojBZcpi5l/qZqea6cjcwQeVOWjCyWh4CzjjnD+qO+RW+LgcYpMvhcjkHdDTqVzp/l+ a5GfZjdVG0wZMJ7W1Pl2gqRJ8HxnYX53HTslngQ0Z1gI7bPz+60jqbrg0qgtT964wfYGmhXN7fm H0crGiJr0zEaViW8kOhJO8oiG2ZI1zJquVC2xoWe1EsH9XoHV0Yb4cia8ky1LYkZK4FegPhjEST 4OkzBkQO33Nw3c= X-Received: by 2002:a05:600c:1d89:b0:483:71f9:37ef with SMTP id 5b1f17b1804b1-483c9bc031cmr206487835e9.8.1772468657824; Mon, 02 Mar 2026 08:24:17 -0800 (PST) Message-ID: <8d0a13b7-3387-4766-bdd5-de62c868e365@suse.com> Date: Mon, 2 Mar 2026 17:24:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 09/14] x86/pv: Adjust GS handling for FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-10-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-10-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.02.2026 00:16, Andrew Cooper wrote: > When FRED is active, hardware automatically swaps GS when changing privilege, > and the SWAPGS instruction is disallowed. > > For native OSes using GS as the thread local pointer this is a massive > improvement on the pre-FRED architecture, but under Xen it makes handling PV > guests more complicated. Specifically, it means that GS_BASE and GS_SHADOW > are the opposite way around in FRED mode, as opposed to IDT mode. > > This leads to the following changes: > > * In load_segments(), we have to load both GSes. Account for this in the > SWAP() condition and avoid the path with SWAGS. > > * In save_segments(), we need to read GS_SHADOW rather than GS_BASE. > > * In toggle_guest_mode(), we need to emulate SWAPGS. > > * In {read,write}_msr() which access the live registers, GS_SHADOW and > GS_BASE need swapping. > > * In do_set_segment_base(), merge the SEGBASE_GS_{USER,KERNEL} cases and > take FRED into account when choosing which base to update. > > SEGBASE_GS_USER_SEL was already an LKGS invocation (decades before FRED) > so under FRED needs to be just a MOV %gs. Simply skip the SWAPGSes. > > Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v4: > * Adjust GS accesses for emulated {RD,WR}MSR too. I think this ... > @@ -926,7 +927,7 @@ static int cf_check read_msr( > case MSR_GS_BASE: > if ( !cp->extd.lm ) > break; > - *val = read_gs_base(); > + *val = opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : read_gs_base(); > return X86EMUL_OKAY; ... calls for a comment both here and ... > @@ -1066,17 +1067,22 @@ static int cf_check write_msr( > if ( !cp->extd.lm || !is_canonical_address(val) ) > break; > > - if ( reg == MSR_FS_BASE ) > - write_fs_base(val); > - else if ( reg == MSR_GS_BASE ) > - write_gs_base(val); > - else if ( reg == MSR_SHADOW_GS_BASE ) > + switch ( reg ) > { > - write_gs_shadow(val); > + case MSR_FS_BASE: > + write_fs_base(val); > + break; > + > + case MSR_SHADOW_GS_BASE: > curr->arch.pv.gs_base_user = val; > + fallthrough; > + case MSR_GS_BASE: > + if ( (reg == MSR_GS_BASE) ^ opt_fred ) > + write_gs_base(val); > + else > + write_gs_shadow(val); > + break; ... here, much like you do about everywhere else. > @@ -192,11 +193,12 @@ long do_set_segment_base(unsigned int which, unsigned long base) > > case SEGBASE_GS_USER: > v->arch.pv.gs_base_user = base; > - write_gs_shadow(base); > - break; > - > + fallthrough; > case SEGBASE_GS_KERNEL: > - write_gs_base(base); > + if ( (which == SEGBASE_GS_KERNEL) ^ opt_fred ) > + write_gs_base(base); > + else > + write_gs_shadow(base); > break; > } > break; Same perhaps here, and ... > @@ -209,7 +211,8 @@ long do_set_segment_base(unsigned int which, unsigned long base) > * We wish to update the user %gs from the GDT/LDT. Currently, the > * guest kernel's GS_BASE is in context. > */ > - asm volatile ( "swapgs" ); > + if ( !opt_fred ) > + asm volatile ( "swapgs" ); ... the comment in context could also do with inserting "unless using FRED" or some such. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:35:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:35:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244465.1543919 (Exim 4.92) (envelope-from ) id 1vx6FE-0000nn-EM; Mon, 02 Mar 2026 16:35:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244465.1543919; Mon, 02 Mar 2026 16:35:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6FE-0000ng-BY; Mon, 02 Mar 2026 16:35:44 +0000 Received: by outflank-mailman (input) for mailman id 1244465; Mon, 02 Mar 2026 16:35:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6FC-0000na-Hl for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:35:42 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d93184c1-1655-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 17:35:39 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4807068eacbso38784935e9.2 for ; Mon, 02 Mar 2026 08:35:39 -0800 (PST) Received: from [10.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-483bfabb84esm424881895e9.0.2026.03.02.08.35.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:35:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d93184c1-1655-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772469339; x=1773074139; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=SkiveMPDqUa4iYvNv23soiX7FoIfSEYshF9oriBv7Kg=; b=EPZgkmSsvG00sSwtRjH83EYcr1ujRoPTBASm4B0BZPsZIsQpnJKUPgvkr7RXvxF2BO ptSB9GW+zOZ7eNSPg5ZuYUye83AC2uOsFqa3db4c0I9rZNlODjGz8TFd6BPssZgCdOtm LBqSOoO3uks3wJtZZkUyoSIDCR2ATkvl+79iLe+rZs+fdsUDJhv2g9N8FwNc6ePr2Tnm l6AOMyprc1HssVaOjocY6HLHDXgtWTCYhCn6sGh9lVLFkpe/yr+W+c/sR2QDVRO21dfU PqofYrw5fIVlet/5OM6dVuRhZhYCH5ofaE9hwGidbEx3czUZWY23KqOvE/Tee4EoO1Mo jHlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772469339; x=1773074139; h=content-transfer-encoding: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; bh=SkiveMPDqUa4iYvNv23soiX7FoIfSEYshF9oriBv7Kg=; b=O9eU+souIu12us1761k4cUNtVL4HZM4gM1x5MzRR9olCD1+H+Yi0J50AFSFLB9D3tJ ljyTHPA9UYs5jbRBwsn0TltshNuGhA8I5Bda6nJLKxBLxsgTY/HltAzwpqLZ65FI1wZn iBYPpQmBohOHOymaR/ddUN+8MDuHud93zE4R+fdbZYrOQImiCbMwL8blhXuXxKmeiCTZ C918SanbIew8gog7U0PqUnejCYYIzsiRE5ENyd0iAmyUnSNBfivWRzXJF2IcmctiCQfR rd5EpuZwPYDRWcvPj0Ep4ZNLgHWuWl7vmWXAMywB5Gqza1X/JYejsH2uMPbezguwYxZH uiHQ== X-Forwarded-Encrypted: i=1; AJvYcCVzCSp9BAiboPc2aL1uX+AWo/tZee6FyW798mMbrE1megn0sx28/uP1BPPvxp02rMgg4d3chQAwSTQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxDr08QLaUfa12P71Fmm3BCxYbLV72pzUvtkozPNw/bIebRP1QG hLUCUaA8QFNQMZsJvPdjOhb8EZ8xmgzHS5o29E5usTqUsaHk9TZBZox7IY/iMMrPbA== X-Gm-Gg: ATEYQzxogkqTK+TYhMYzE+J4S5Kj/MzH0ztg/lGPXVcDnMTem86uK/4r4nI0CWGH6Kl pj1uaY6coEjpHJEgKpFAtpTRo1o1OUu7JYYo6IwJm6pDIEVMakGyv2p2nDoY4WH3TsWwJGz/Ad6 a8e9FXUO6KdLNV1BAH4d2rqynGqAn8y4XAvjxG8+rlTUppPoILJkt4AWT/fr/flgb+WjGchs3c3 n40VNUh6FbR5GzIoUgvOv6W2XMU8PsO/puyLvalGwMuchYTLcrciIib9dTFyTZhzvLnSP6703v9 Z++XWx81ZUCx86AAiiaP1ob/loetULEASJUpsWxedB9ApicjI4MkOEORUufqV79ar+8K+A3mJLz w1sFdM3l2geob+R0CHjBBYjue7aS3+SkiXHlNAvbkwHlmUkKhh5fxHyHAfaLYJlgCKNn4sElAW3 KwKiejxRNJrw4ira5LyJF8yEmmV4+1m+S0gTgS5GiNhNTAUny+bvFqDMKjylcroJzZ/STINGb96 x1cHzu2h5qM7p4= X-Received: by 2002:a05:600c:a16:b0:483:64b4:79da with SMTP id 5b1f17b1804b1-483c9bf45fcmr212700185e9.26.1772469339136; Mon, 02 Mar 2026 08:35:39 -0800 (PST) Message-ID: <9d5526e7-2f82-4a9b-b622-4dc1051bb272@suse.com> Date: Mon, 2 Mar 2026 17:35:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 13/14] x86: Clamp reserved bits in eflags more aggressively To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-14-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-14-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28.02.2026 00:16, Andrew Cooper wrote: > ERETU, unlike IRET, requires the sticky-1 bit (bit 2) be set, and reserved > bits to be clear. Notably this means that dom0_construct() must set > X86_EFLAGS_MBS in order for a PV dom0 to start. > > Xen has been overly lax with reserved bit handling. Adjust > arch_set_info_guest*() and hypercall_iret() which consume flags to clamp the > reserved bits for all guest types. > > This is a minor ABI change, but by the same argument as commit > 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"); the reserved > bits would get clamped like this naturally by hardware when the vCPU is run. > > This allows PV guests to start when Xen is using FRED mode. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Roger Pau Monné > > Still slightly RFC. Testing still in progress. > > v3: > * Rewrite the commit message. > v2: > * New > > The handling of VM is complicated. > > It turns out that it's simply ignored by IRET in Long Mode (i.e. clearing it > commit 0e47f92b0725 ("x86: force EFLAGS.IF on when exiting to PV guests") > wasn't actually necessary) but ERETU does care. > > But, it's unclear how to handle this in in arch_set_info(). We must preserve > it for HVM guests (which can use vm86 mode). PV32 has special handling but > only in hypercall_iret(), not in arch_set_info(). Any reason you don't ... > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1244,7 +1244,7 @@ int arch_set_info_guest( > v->arch.user_regs.rax = c.nat->user_regs.rax; > v->arch.user_regs.rip = c.nat->user_regs.rip; > v->arch.user_regs.cs = c.nat->user_regs.cs; > - v->arch.user_regs.rflags = c.nat->user_regs.rflags; > + v->arch.user_regs.rflags = (c.nat->user_regs.rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; > v->arch.user_regs.rsp = c.nat->user_regs.rsp; > v->arch.user_regs.ss = c.nat->user_regs.ss; > v->arch.pv.es = c.nat->user_regs.es; > @@ -1268,7 +1268,7 @@ int arch_set_info_guest( > v->arch.user_regs.eax = c.cmp->user_regs.eax; > v->arch.user_regs.eip = c.cmp->user_regs.eip; > v->arch.user_regs.cs = c.cmp->user_regs.cs; > - v->arch.user_regs.eflags = c.cmp->user_regs.eflags; > + v->arch.user_regs.eflags = (c.cmp->user_regs.eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; > v->arch.user_regs.esp = c.cmp->user_regs.esp; > v->arch.user_regs.ss = c.cmp->user_regs.ss; > v->arch.pv.es = c.cmp->user_regs.es; ... filter it out here conditionally upon domain type? Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:39:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:39:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244477.1543930 (Exim 4.92) (envelope-from ) id 1vx6Iu-0001ac-VR; Mon, 02 Mar 2026 16:39:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244477.1543930; Mon, 02 Mar 2026 16: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 ) id 1vx6Iu-0001aV-Sr; Mon, 02 Mar 2026 16:39:32 +0000 Received: by outflank-mailman (input) for mailman id 1244477; Mon, 02 Mar 2026 16:39:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6It-0001aN-Ac for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:39:31 +0000 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azlp170120002.outbound.protection.outlook.com [2a01:111:f403:c007::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5f070e6a-1656-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 17:39:25 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA5PR03MB989110.namprd03.prod.outlook.com (2603:10b6:806:4d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.14; Mon, 2 Mar 2026 16:39: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%6]) with mapi id 15.20.9654.020; Mon, 2 Mar 2026 16:39:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f070e6a-1656-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aDfFntt/dFAH6wPBjAwQGqlecmvaJvIrGm/Ncgm6du8yNL4SSBWA9ASmhU7jUmOouZELxd1qVIbvaAk9sTsS8YH6czhKTPpTVomYV8KR9iipOLsY2ZkNQWNGcPs0VIdhU8rawlNGc9SbUD917g1tWb6rXuUffVfmDQTyAwiXiFnFkIJupBOfAlZ+2smwtxaV/lgUK1Iok5twHITtNiQJdNNkCwG7+6UuuOq8oqde5jnMcV9RX5ap1OLnHwCD6lzZb/ZjPMh1cKrlKBai53bYVNyNSSbY0J6DEufO0kRzDiWnw+0hmV1SsCq8LWEwMBQDq9VvHZrIcQLskKWWx53j+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=9ZAGbleNAGsLGpujOu2E+DZhVBBMKqRjOv3fR+dtsqo=; b=Rvef9ZITNx8HSH+ydxbm8crZi54ClOJIILXNs/eAVySMCWDJ1rthEnXajTxBlirHXM5jBOQ/7iOeVpWXtL5kB1aC6Q+w5hMb/nw27VlXbZpp7ICvror1iKp7GgL+G5bpWkWLQNXDdN1GxM5G5FvWlH4SK+2tU9TmG4AyvhExGGUFkwxu1gX/hgOqekO1eEDGx/FTUar6x39QefTPO5Ogd36OFzY3JCWkR9XXOfbu33/i3i8tDwrq3ReE3rF7p4hD6JMfnkkHXUuIHeADalwzIx4euEMkRswlCkkJ1kDeEcywJOK3S9J3bjmZmywsL+/V4wcMGHpkPbhD7BWKDVuatw== 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=9ZAGbleNAGsLGpujOu2E+DZhVBBMKqRjOv3fR+dtsqo=; b=T4152G9dOEr8SJGg5wFp6d1ssrVyP9cWAsf/PdcIY5EE3M9mre4yvDqVfHjmo45e7aG9VNyCJsosu6FACEm7GNFt0E40tg68Js3nX4ZyJGDNOTdjO5JkgfbXU6FMK1dmzTYLt4TL0+dZyARO22S0uiTwr7BWHS5bQzbJNrBAm/M= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Mon, 2 Mar 2026 16:39:12 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 01/14] x86/pv: Don't assume that INT $imm8 instructions are two bytes long To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-2-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0534.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:2c5::19) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA5PR03MB989110:EE_ X-MS-Office365-Filtering-Correlation-Id: b9bf0bdc-085f-4a65-edaf-08de787a3df3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: SYmyP750UB3I4uV/tt0FmMirshYbKZgX/0IV+h4cbiyOdRi3ci2RJv3Y2H9cxLsjVGFwzE50uzttEUlTCgNAD7XO/C2Phi+q1Kq5DG0wby8XyNlLDCHz0T6qMg+Zc+Wr0K6Vmj7v5XQo1p+lTGrKqLuRrXE7i+pUoGCexG8J8ZE1hZO+dssAQX2zctITY3lJZn4X6RZoi5l2z/uV90BtHvbs68ndHnPU1U1CasOkiNEGxQgEDiUdiJIY7Dz73vCBEen2uM4HG5brMg8ZIn2DO/jlxW4BbVh3z3gtd1sH9Ctllu5UTlVNUn5hiQVsZ6f7LCrahHUERHWenJx0Iv0s7K1Xv5hokhjljzLJ6+pxih10MHOQCqZ8ndsPoaEg3Wy+5hbjtup0+qVaJXF68gVn3SkRSivsmeSwWLhZRztMF04VpQwK/QbCdAhhbmMn6reyyGk7gzEHeC5HlFFNpDf/5pGGs8QMugc6n+hNONQucbOm4sAo+/TeUUh3r/PR4fI7qNbCXaZbxzOm73hnmJo8+wk+6cCR11pRDH9l1HZcqMm1pyHatg9qW+HFJEQZYV3ERi/OaaOC7WOmiwOqRnWEIBlH54mFWy2TNICDlwpgdi1Fmr5adAA9RNrwESC86KCoobN89GuLZMSLnVnue4MvdWuPRk+0Kz015HcyPdM/qesPkCmOt9WAdEBKH0crZ9XxundfXVtH8tJjKNjkuoQ5llBXyaP8qOU0U0ixCPIq1dQ= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MkZHeHh0dCtVc2ZITVVpZ3VtaDN4eGNyVUZNbXVaQWh3Vm9SQThMUmZvZkV0?= =?utf-8?B?OTJOVWpYWEhVSlFIRkl6b2wyaktoKzNnUE5wVlQrOGUwemkvVDZoK3JTdElQ?= =?utf-8?B?aTU0enZ6QWNCUmRRb25ndkFvZDJRdkhkYitjeHpacTZMN0NGTkhCSVk5Q05Z?= =?utf-8?B?MUV6K2x0akpzdmx3bzVoU3FQUWtxT2gzWWh0bjc0bmRzQlhhYzRKaXpsNzNY?= =?utf-8?B?bFgwRDFDeTJZNnNEVDUxYXRNdzRSL1JPRUVnU3Y5SVdna3QzU2ZwMDBZWGlS?= =?utf-8?B?eSs5VXdCRGtWRFI0dksreTZYRURCNkg1K1IvRjV1cHpCdnBjUTVFL1RsTk9v?= =?utf-8?B?SWo0VEkyQTdDaUd6U0UvZ0JRK2FnWFljYVEvQ011THE4cjFlTUVabHpiN1hm?= =?utf-8?B?Z09rTXFXWkwvYVFvVkpEL09weHN1eWFCNHBkWGp1TlY1STc5dmgwRFhyRk4w?= =?utf-8?B?Rm8yd3NHczFBZnFXajYzbzNCM2JRK1BzT0dBNkk1UTlPWTVSeVIvaGg3Q3c1?= =?utf-8?B?K2F0VjcvN29OaWFtQ2ZqcmNSUkNiUlZseWlzVTBteDFCY21yMjMrVHpFb1dq?= =?utf-8?B?RGpNekNpSTZQU1Q2cU1PVU4yQk1lb3NUV2lwZVNXR2k4V3lDZkE4T1ZzUUZI?= =?utf-8?B?akRPZkttcW1SYWFpUGFINUo3OXZ2Z0pwcHFRT1JsNEhjMkcxS2VuakFGb056?= =?utf-8?B?Z3ZEVDhaRUNpZzhNTnhuRWN3OUFuV0E3Y09xR0d3R09qQmYvWnVESkdlYkVI?= =?utf-8?B?YVZ2WG9aYURYZzduZEszdmdKUkdQRFhVeldBVCtTVWUrVHNNOGY2Wk5sajMz?= =?utf-8?B?TitManFwcm04b2NRc2h6dVFxQ0R2dXZBOFY2WGg2Yk1XTkt4UGpnemJZUTR0?= =?utf-8?B?MTVIWjFINHlRbDlEU25GM3gvZnB2TVl6aVhMVHhicThqdVMwd2grT2RQc2Mz?= =?utf-8?B?NGFOODk5aVJiSTV3MVp0c0FWTjJZWVdZcEFkQXJPQ3pOaXRkK0ZIcUNqOXVR?= =?utf-8?B?M2c1NzJZTGpRbEpVeVVKNWtXNDAxcWZLczlHc1VkZmVqbTRsS0ZKTHJtdDA1?= =?utf-8?B?aHRaN2wzR1ljMWQ0Y2Qrb0pRbExBNmFzaDVzaTh3VlQ5VkhJUGVzMWJFR3JB?= =?utf-8?B?RGlMVFJVd2Y0K2gwUExFbTNKcFBNMXkzOFNBbC96T3ArYXR6OElWeTREM2xI?= =?utf-8?B?cDNycWEvVE8wMXltSlptaStwWDdxTFp4NnpXNjNCU0FicXc2MEQ3a1ZsclQ5?= =?utf-8?B?YmJlejFxTjhFcmNzbXZwQ2hrcHlsTnhlNUxDL09FZS9KTnFrakI0K1FjNTdX?= =?utf-8?B?NGtveDd5a0xKKzE3UFduemhaV2ltT2g2MkMxS2k3K0pwcTdhOGRzcnZwNnNP?= =?utf-8?B?a2JCck9mQWFxTC92L0FaY3pHNUs2a1A3ei94aUZvc25YV3V1L3Bma3UyVWVN?= =?utf-8?B?KzYwNi90d2gvOHVtNk1jL3paUlNRdjF1SXJnWXdEQlRmRXRmWXdlN2w1dUta?= =?utf-8?B?T3R3T2UwSzRzRlRvenQxVi9lRDRPZk1IRFc3OTJ2eW1aN1M1K3VlRGt5em1u?= =?utf-8?B?bTlGajNHQ1F1d0E2WVlnc2o0QlRxMVdPbktVOG0wRjdNN0FiVnlvSm1IaVNQ?= =?utf-8?B?TGwwT3ZWdWpPbXFOVWtTUDJNV3Q2alBiSktqN0d2bk1qM05kVXVVQUxoUXRs?= =?utf-8?B?eHMzUmJ3WjF1bEpEdXFIQXV0RStmeE5kU0ZQTG9qVGpjVGw1SDhPSzVDcy9M?= =?utf-8?B?aGVNd0pGV3F4K3NhSkVnQ3pFeEZocGZSemNCdGZNdUxOTUpUL1NndFZzdklB?= =?utf-8?B?OWxPWTBpaTYwcHFjS2dwZnQrSnA2dE5UZXhpQVNQTWpSV00xTXlGdVJKTTRR?= =?utf-8?B?OXNaNTFhbUQyWCt0eHdoYysvOFlWQ3NQU0xaRlFXK04wNE5COTRoRDBhZW1i?= =?utf-8?B?YXlZQnludjBwd0Z0VnlJdU1SMjRZVnYxTW03bUhkNEtTalY4bWJPaTcyazBn?= =?utf-8?B?VmlDTCtMMzdJVC9SWDFHaloveFdOdWNmMFRISlNUbnJ0Wkw2YzVhbmN3dk9V?= =?utf-8?B?VU84bUhhM0dxdkNndmw1TmpRRkhIUndtYzFHbEYxcThBQjVHa2l3eDlKeVdF?= =?utf-8?B?aDQ4Y214cEg0Yk94NENJSWNBeEZLTUd6Y2UvV2Z0bXR3ZG9RWHZUQ2JXWHdO?= =?utf-8?B?SGM5NGE0VnJZRGhLaHFTTnQ5REQ4QXk3UlZ0TCsxS041NHZjTGM3eDBuaHIv?= =?utf-8?B?QW9TZjlVc0RISjQzR2pUVnBtbGd6aWhoaklHczJIajlTd202UjVxUmZrQlBR?= =?utf-8?B?UjNBTGhaRDJrZ29PQnVvMVlheFpyRHI5OFpzemFjZUxWRDNQVzBGdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9bf0bdc-085f-4a65-edaf-08de787a3df3 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 16:39:15.4800 (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: eMUzYn7lELLhxYwqwNsLnwqiyhSIhd1zlNzUAt2PacSfzrOJyIPhdJYeLzS3q71HLXfIG3YCN6BbLjMhS3CTImVwnvAqJdpXfW5zzKLD8Lg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PR03MB989110 On 02/03/2026 12:57 pm, Jan Beulich wrote: > On 02.03.2026 12:43, Andrew Cooper wrote: >> On 02/03/2026 11:03 am, Jan Beulich wrote: >>> On 28.02.2026 00:16, Andrew Cooper wrote: >>>> @@ -1401,6 +1402,53 @@ int pv_emulate_privileged_op(struct cpu_user_regs *regs) >>>> return 0; >>>> } >>>> >>>> +/* >>>> + * Hardware already decoded the INT $N instruction and determinted that there >>>> + * was a DPL issue, hence the #GP. Xen has already determined that the guest >>>> + * kernel has permitted this software interrupt. >>>> + * >>>> + * All that is needed is the instruction length, to turn the fault into a >>>> + * trap. All errors are turned back into the original #GP, as that's the >>>> + * action that really happened. >>>> + */ >>>> +void pv_emulate_sw_interrupt(struct cpu_user_regs *regs) >>>> +{ >>>> + struct vcpu *curr = current; >>>> + struct domain *currd = curr->domain; >>>> + struct priv_op_ctxt ctxt = { >>>> + .ctxt.regs = regs, >>>> + .ctxt.lma = !is_pv_32bit_domain(currd), >>> The difference may not be overly significant here, but 64-bit guests can run >>> 32-bit code, so setting .lma seems wrong in that case. As it ought to be >>> largely benign, perhaps to code could even be left as is, just with a comment >>> to clarify things? >> LMA must be set for a 64bit guest.  Are you confusing it with %cs.l ? > Indeed I am, sorry. > >>>> + struct x86_emulate_state *state; >>>> + uint8_t vector = regs->error_code >> 3; >>>> + unsigned int len, ar; >>>> + >>>> + if ( !pv_emul_read_descriptor(regs->cs, curr, &ctxt.cs.base, >>>> + &ctxt.cs.limit, &ar, 1) || >>>> + !(ar & _SEGMENT_S) || >>>> + !(ar & _SEGMENT_P) || >>>> + !(ar & _SEGMENT_CODE) ) >>>> + goto error; >>>> + >>>> + state = x86_decode_insn(&ctxt.ctxt, insn_fetch); >>>> + if ( IS_ERR_OR_NULL(state) ) >>>> + goto error; >>>> + >>>> + len = x86_insn_length(state, &ctxt.ctxt); >>>> + x86_emulate_free_state(state); >>>> + >>>> + /* Note: Checked slightly late to simplify 'state' handling. */ >>>> + if ( ctxt.ctxt.opcode != 0xcd /* INT $imm8 */ ) >>>> + goto error; >>>> + >>>> + regs->rip += len; >>>> + pv_inject_sw_interrupt(vector); >>>> + return; >>>> + >>>> + error: >>>> + pv_inject_hw_exception(X86_EXC_GP, regs->entry_vector); >>> DYM regs->error_code here? >> Oh.  I'm sure I fixed this bug already.  I wonder where the fix got lost. >> >> Yes, it should be regs->error_code. > Then (plus with my confusion above sorted) > Reviewed-by: Jan Beulich Thanks. > >>> Might it alternatively make sense to return a >>> boolean here, for ... >>> >>>> --- a/xen/arch/x86/traps.c >>>> +++ b/xen/arch/x86/traps.c >>>> @@ -1379,8 +1379,7 @@ void do_general_protection(struct cpu_user_regs *regs) >>>> >>>> if ( permit_softint(TI_GET_DPL(ti), v, regs) ) >>>> { >>>> - regs->rip += 2; >>>> - pv_inject_sw_interrupt(vector); >>>> + pv_emulate_sw_interrupt(regs); >>>> return; >>> ... the return here to become conditional, leveraging the #GP injection at >>> the bottom of this function? >> To make this bool, I need to insert a new label into the function. > Why would that be? Simply skipping the return and falling through will do, > afaics. > >>   I >> considered that, but delayed it.  do_general_protection() wants a lot >> more cleaning up than just this, and proportionability is a concern. > Whatever you exactly mean with this. Hmm.  That was supposed to say backportability, but I have no idea how ended up like that. The other advantage of being void functions is that they can be tailcalled. Anyway, I have a plan for cleanup once FRED is settled, which looks a little like this: handle_GP_IDT()     if ( guest_regs() )         return handle_GP_guest()     else         return handle_GP_xen() handle_GP_guest()     ... handle_GP_xen()     ... where the two FRED entrypoints can now call the context-specific function rather than the generic one. This does involve duplicating the X86_XEC_EXT check which is the only common aspect in the #GP handler.  Next I need to figure out whether the other handlers can be rearranged similarly. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:40:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:40:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244484.1543939 (Exim 4.92) (envelope-from ) id 1vx6Jl-00030X-81; Mon, 02 Mar 2026 16:40:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244484.1543939; Mon, 02 Mar 2026 16: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 ) id 1vx6Jl-00030Q-5G; Mon, 02 Mar 2026 16:40:25 +0000 Received: by outflank-mailman (input) for mailman id 1244484; Mon, 02 Mar 2026 16:40:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6Jk-00030E-Et for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:40:24 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8175717a-1656-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 17:40:22 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-439baf33150so706698f8f.0 for ; Mon, 02 Mar 2026 08:40:22 -0800 (PST) Received: from [10.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-439b55d15besm11972879f8f.30.2026.03.02.08.39.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:39:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8175717a-1656-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772469621; x=1773074421; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=AKyX3ptxeTzIuEOXF3s2i/pde3r0AGZiyoKUzK+X92c=; b=VQrl278QYS5d+UzW4JFpCKSa98vKq3yxKasCNwT0dMMe1+2SZSEfrP7UdcXRSjVD+6 PQpb9K74+ZuVOrJ43d2V2TvV2qcW+jGRGAPwap3u6UiPa5Japgb0nZkULRJTCFYTjlQO vFkkgipyHinYIphoYuTNNJCAKgQI3S3qpVfftFQm1LD+Rkzg1PY013f/uQFfijz/VnUU V3FhcxBod16Czim5NV+eiJdCbKankb4h/tWvGaMPMtoXihLna3FrPtPjOvMjgYEzBYY4 awLZwI9HEhH3wmUdrEVHw6/jkW1jwB5SDrAWMVAN7Zx0XqQH6KXgNxH4AofrS7Ep4MWI Se4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772469621; x=1773074421; h=content-transfer-encoding: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; bh=AKyX3ptxeTzIuEOXF3s2i/pde3r0AGZiyoKUzK+X92c=; b=Af6NUq8530ljyhtRPn4vttp18VZ1HtdAjxfFswVWyCPo/6Ojs00vSGjrCb3g5HABzD DTiwkciXwWoTFurwyykPAJ+PdgR9brlKcggWlyhfYaJx6hQwPPS25TOv9vYcod3l0xYI 8wBRJnd88FQyLIkmGzmyHYyqtjkeWvthEB/Wc1a8YemdxeXnl9+NknBTEDLF1SKgckq4 gT7bRZKVrNBDYyy6WMjceM3kv3xakjtyBR0Ev9/1E4Is+My/5RHpf0g3AibedbbuyZnK 3lOzUWjMlKwMh5gK6VO1P5C6sAevzXoOM2iwnvP7t8gXQiW1/NxMwIJ+rQ3Fe/Rtq+Va xpEA== X-Forwarded-Encrypted: i=1; AJvYcCU6nsXNpkRApV+66NqA1RzNI9j8SduKTJJ30l84Pn4YQruLUwqka/uq0JFUa6yZpU0gEMO+kaBtwZ4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzbpHjvpZf2I9i70GtoOwIYtBu5Fy9ozxJYetULG0clYlzTxrD1 KKdwNx9eJcuum9PUehHqpF5wbJJIKUwWNo+lB5P2nCHEKlVJvRataGCXKbF7T7ToSQ== X-Gm-Gg: ATEYQzx5O93aBmWyP4TXSTv0nOXxzkHowsQXatYFJzuvmMbmrRoud3V3r8Q67lVkuPj UZTqPSIlXxqT4TlJXPXHta8IMnOuX6DIFjMAqC4fqL07VHCvXRiB8S9Uiw2Dm3FFjn4iVu/QVYS NrCbSNusSsnUBXtEw8sQ2hu+qaAdsesRsVnp0g3xpu1jB+c/9KdEqlyrQjPlWusGAHirMnYVdGU mR+qsOwdGuPYbiPCx+OdLzq7CFGGyDZQ9Cb1mCCkBHjkzDhYBLmCnYkcQTZn2a2DxenG/uXBCQ/ uNd+nywwdISfe9egqfA6IkCYNhQIUDKDntsgNBCN7jyY0CIQ3nH+Jj+4SXUVEcmJcUlBHanpzuv P+WShrSab+XaAJ3HTJLr/I5/FGeMSsQwuHrPGtG+bFsUrwg/A6HaqFK7ZRqn7x4yNu1i65oZQpr Xx9ebhnRSC/5+iOWuV/1bGccz2tBlEQvVCnfdjIrEDiXknt3V1Z608gFNhdfTfE6oC+J8Yp+16I rePa5oEmCjPL7U= X-Received: by 2002:a05:6000:420b:b0:437:71b2:6f23 with SMTP id ffacd0b85a97d-439971a6119mr29855780f8f.5.1772469621389; Mon, 02 Mar 2026 08:40:21 -0800 (PST) Message-ID: <3d7f0bfc-66f9-47f4-9a53-099c5a35df98@suse.com> Date: Mon, 2 Mar 2026 17:39:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 14/14] x86/traps: Use fatal_trap() for #UD and #GP To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-15-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-15-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > This renders the diagnostics in a more uniform way. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:40:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:40:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244492.1543949 (Exim 4.92) (envelope-from ) id 1vx6K8-0003Rg-Fy; Mon, 02 Mar 2026 16:40:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244492.1543949; Mon, 02 Mar 2026 16: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 ) id 1vx6K8-0003RZ-DN; Mon, 02 Mar 2026 16:40:48 +0000 Received: by outflank-mailman (input) for mailman id 1244492; Mon, 02 Mar 2026 16:40:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6K7-0003Hu-7a for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:40:47 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8fdf2a6b-1656-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 17:40:46 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-439b78b638eso1199588f8f.2 for ; Mon, 02 Mar 2026 08:40:46 -0800 (PST) Received: from [10.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-439b55d15besm11972879f8f.30.2026.03.02.08.40.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:40:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8fdf2a6b-1656-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772469646; x=1773074446; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=AKyX3ptxeTzIuEOXF3s2i/pde3r0AGZiyoKUzK+X92c=; b=dqZ4RurYV2DF5tGl04rSp4W2yDKjYtcvbZhcGX9CO0kIxrEQKFVVIKVSAIVPhpwvx5 94UOgnaBSVzCYaO1bIKXDIFVMmI47d+00vAylXXAPjZwsrVwI3+k0DKacCR7JPFxaEcx 0Z5eKzV1YO1T0ER0ic24eq1IGdgIkmr2mzmvgCzi/k9FMSo1GcStDEmo3L2xy2jK1Th2 aXf+HM0E+K89Ack3ZTkCCkh8OnStPiJTDEkR/CWVcON2qKdA3kKk8MqMCm6eeHTwKsuN 5DP7GRA2P72N4h8H2bki80YHXVeBRfDJ87crlw7oLuze/Dr/asZ/R5UE8FYRGzaCU2T0 AJfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772469646; x=1773074446; h=content-transfer-encoding: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; bh=AKyX3ptxeTzIuEOXF3s2i/pde3r0AGZiyoKUzK+X92c=; b=Ivm5mJyjijrfOg6wG3dVkibUOQ1b19QJM5gf2Q66hBoI/yi1f8M0flarL3BkzQ9q9r /drAmy3hHk9+npirR/b+gQGSxp/d3IaEPbJWPcju/ZSojLgLgxrkleBdIXE9uhCpCW9w JgQwRPH69ru02ynCIMwMP5VHWSbk+qGwqVHAaPG5BTC4hIwc6oB1+P6E81lQ948qJA+Q Y98cE7hR2CCoDYpicg3DmryBfwDmKR4blHTs18C1c6UBjokOY0F6I9Cid6VhhoMlncye 4ZagvAxVyvlK6TBz8n9IgoWhXuvtGYpSxgxdw/vXTJZc29QQdxoXxFvj+gvtY6YKrZUy NTJQ== X-Forwarded-Encrypted: i=1; AJvYcCVNgNP33LHPGg1nyAy5IXPHbym7x2sPX36AMqzW7aZk0sHiVNGbvEawq9qapUotC1bCV/hGY95qpWA=@lists.xenproject.org X-Gm-Message-State: AOJu0YwEWLm8eu07p2fY6HHjtNOy/pZcIdvFcP9NEDQF5v6l/bgGBRr3 ULamb6/3sB8otJJSMwJEeIuLeEke39Ga5FSLOQQDGpvI/3UYkRBYrhHqFKfMXjlxU4ODgD5WcCH vm6M= X-Gm-Gg: ATEYQzyfYY9wGvqRheYINlj/msOibsyz2KmKWMMJoNv1cYvdxYlkU1k/BeCHq0Yep+T dpO28OP9BCKfJMYLy2ajwW8JYMDTo+yt8yPAxGsHcccepYTG7blEzws2MC+kNwdUgna1t4DKo5V k5keePe5HskjeonpDZrLrORnShRxDp5AQ8LZziyyzz9HQGTxGT3gGT1wdTqILEdjHCUrZ7j2jcb lGRAQcIKHibP/DZS0UhpKBLO5LKSIyPXyhjb512qVE+l9Tqlb2FVddTgztGl96glBpouKg3jE1T Q4LPeYBmTYBKF1W8KXFNNM4L7VJqRrz8yV7u68GUe348NTDAMgx7Xn/zdNOi7yB21zAHKFVT19b ziXkWlKpErxC2Sns04nZT1CgS+uc2f+PQfkXZqnniomqfeL0YmeWcViYLpYPMEhD5veWOncYbda iM8tusy0690DG13qi7TnZ7hY0ULYOQA4MYsnwzZLvCmoiNzhXh3AhF9wyPeg1GXdU8OOiqi2fnI q+rrh9kYb/Dsnw= X-Received: by 2002:a5d:5c89:0:b0:439:bc31:a056 with SMTP id ffacd0b85a97d-439bc31a2f8mr3682030f8f.51.1772469645681; Mon, 02 Mar 2026 08:40:45 -0800 (PST) Message-ID: Date: Mon, 2 Mar 2026 17:40:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 14/14] x86/traps: Use fatal_trap() for #UD and #GP To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-15-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260227231636.3955109-15-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 28.02.2026 00:16, Andrew Cooper wrote: > This renders the diagnostics in a more uniform way. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Mar 02 16:50:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 16:50:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244504.1543959 (Exim 4.92) (envelope-from ) id 1vx6Td-0005Ku-CU; Mon, 02 Mar 2026 16:50:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244504.1543959; Mon, 02 Mar 2026 16: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 ) id 1vx6Td-0005Kn-9u; Mon, 02 Mar 2026 16:50:37 +0000 Received: by outflank-mailman (input) for mailman id 1244504; Mon, 02 Mar 2026 16:50:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx6Tc-0005Kh-51 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 16:50:36 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id edf21837-1657-11f1-9ccf-f158ae23cfc8; Mon, 02 Mar 2026 17:50:33 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-483a233819aso45432605e9.3 for ; Mon, 02 Mar 2026 08:50:33 -0800 (PST) Received: from [10.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-483c35910f1sm249159025e9.2.2026.03.02.08.50.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2026 08:50:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: edf21837-1657-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772470233; x=1773075033; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=+Y8ZBfCQicOjA/MPxg4ajXuc0vJMzWClaVTSx+x8DqU=; b=Q+ZZcFHfJJQPvGcnOaGxW28XCyGol9KVdpOQPaBcGUDOW72ENRzQ2iO9BsyIzXyxCt rkF241tEIiQ0PlF+jMRw+uZzpknvT3M5VVC1fTQSINIAiqSs+WIh+t6k+ts3WmAAj9iu aa9v+JtfUWrNhfiH92mLGOJjYKgMRPdqMD4iOE/CwVlorPIF3odTBKv9iiY1aRGGXThG 7Vdsd1fx8sMqyQBu3LdBSmI8KIT8jZgGlmxxI8l1PF7xxx0cxu0RuONTLoN7o+BGFZzq n4kkMhyoNY3WsqpsOufGUXBU1ZeNqe+/rQ1L5ulPpHC3K93WgYB2D03rtN8edKGtj87F BuiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772470233; x=1773075033; h=content-transfer-encoding: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; bh=+Y8ZBfCQicOjA/MPxg4ajXuc0vJMzWClaVTSx+x8DqU=; b=CJKh9d6OvJ9i81yzt2Bx5QPQK8RoIMe0rMSdH2+CcXlpFY5Nx2r56paGiWrz9JLgJ/ QCpdq/wzIw8ULURsule8YYrP/uPxaZhXUm2AJDuXvuBB3IOdkW89eoB8i6kimzd+pBQg U0CMAkI/Zl4gXsbJtudsM6Xj7qiBS64Fjtjz9nVgV1saUk8GEWP62PbT0n2ZHeQ7PU2z ET9FCckomxXei3AwjuQABnDrPk0qEsWSzr4VfCMALUqKh1Qbl+JvGBvWaexbOaWJsOG6 RuutuuGFOHCD00LZTw5l/kyInGBe7Gs/OFmLUx8TrG8CyDyA05/EiuyWJEJm0+qGeOYU /mvQ== X-Forwarded-Encrypted: i=1; AJvYcCVzpojJpMY/jRidFSLfZ3UwNdGqSKsiayQb/pOGy1LtFpsxuD6uhEJvJtBE8GB0q1WEemzcH8+K/78=@lists.xenproject.org X-Gm-Message-State: AOJu0YwCc0cLwLPACFdhqhoLAyJNG3dmAo2arKA0WLSOcBd7fub222tK SO/PrzdiIWSYutWAi1y/8DqgKiHhj0EKCXDatYTzpMDU2KyYkXMEZZc1nVwgtUh4J184rxEa0N3 2tso= X-Gm-Gg: ATEYQzziX/X9JDIvnbcXbiktL7TLQCOblMMp+8ZOL8+aKM3u3v1vj0Pb/9b97a8mY+f VoQ+TN/mb7f7UA8RxJX3a+LTM2P31eyXhr5+CPRyFx3fTAWeO6O/ke8H8OhzKrL5Eb+MF3PNDs+ nNAvd921SbudfFZUxJ6n/qmQOnLefRgmZOH0F0NFyy47BFZethtnoHNvHkRqFiVhM9Cv0z/lgiF JBpuDqsdkQ68xHtpHpwwgzv7+OfNRfJEsQGZIfjQW9aWwcIx0IQGxTT5mLLhoiUiA6zH7muZQpf RwZhVIexo7Lb4tSgEksNibT2ITgpwV1emYlOgL801p4OLqxtNO8vfizLSq+t5JCk3AHKrCh3hOn z3/gq1QFxtMqA+qwPgQWYmJ9JiODDNqhSxOX3ZjGE8724MG9FiMqhtE+NUiInsfwRQr6AVKWFVF Vxh0I71FFQrAkWceU3RLLGQkAyLG9AxSYzKZKnpzaoeNDl9Wgy1PJny820uV/R26RcD29IURzH2 Ft/gaSPy0uo458= X-Received: by 2002:a05:600c:8b53:b0:47e:e91d:73c0 with SMTP id 5b1f17b1804b1-483c9c0bce5mr231103595e9.19.1772470232978; Mon, 02 Mar 2026 08:50:32 -0800 (PST) Message-ID: <7380cf63-e9ac-4df9-9633-c26f9de0027a@suse.com> Date: Mon, 2 Mar 2026 17:50:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 2/2] xenpm: Add get-core-temp subcommand To: Teddy Astie Cc: Oleksii Kurochko , Community Manager , Anthony PERARD , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 18:00, Teddy Astie wrote: > @@ -1354,6 +1358,127 @@ void enable_turbo_mode(int argc, char *argv[]) > errno, strerror(errno)); > } > > +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *temp) > +{ > + xc_resource_entry_t entries[] = { > + { .idx = package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STATUS }, > + { .idx = MSR_TEMPERATURE_TARGET }, > + }; > + struct xc_resource_op ops = { > + .cpu = cpu, > + .entries = entries, > + .nr_entries = ARRAY_SIZE(entries), > + }; > + int tjmax; > + > + int ret = xc_resource_op(xch, 1, &ops); > + > + switch ( ret ) > + { > + case 0: > + /* This CPU isn't online or can't query this MSR */ > + return -1; Further down at the callers of this function you assume errno is set whenever an error indication is returned. As xc_resource_op() didn't fail, you will need to synthesize an errno value here. > +static void get_core_temp(int argc, char *argv[]) > +{ > + int temp = -1, cpu = -1; > + unsigned int socket; > + bool has_data = false; > + > + if ( argc > 0 ) > + parse_cpuid(argv[0], &cpu); > + > + if ( cpu != -1 ) > + { > + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) > + printf("CPU%d: %d°C\n", cpu, temp); > + else > + { > + fprintf(stderr, "Unable to fetch temperature (%d - %s)\n", > + errno, strerror(errno)); > + printf("No data\n"); > + exit(ENODATA); In how far is using errno values as arguments to exit() a useful thing? (I think you had it like this before, and I merely forgot to ask.) Yes, I can see the tool using a number of exit(EINVAL), but I don't understand those either. This way you can't even document easily what particular exit codes mean, as the errno values may vary across OSes. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 02 19:18:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 02 Mar 2026 19:18:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244524.1543970 (Exim 4.92) (envelope-from ) id 1vx8mr-0005H0-7v; Mon, 02 Mar 2026 19:18:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244524.1543970; Mon, 02 Mar 2026 19: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 ) id 1vx8mr-0005Gs-39; Mon, 02 Mar 2026 19:18:37 +0000 Received: by outflank-mailman (input) for mailman id 1244524; Mon, 02 Mar 2026 19:18:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vx8mp-0005Gm-U5 for xen-devel@lists.xenproject.org; Mon, 02 Mar 2026 19:18:36 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9b128558-166c-11f1-b164-2bf370ae4941; Mon, 02 Mar 2026 20:18:34 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by SA1PR03MB7032.namprd03.prod.outlook.com (2603:10b6:806:331::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9632.16; Mon, 2 Mar 2026 19:18:29 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9654.015; Mon, 2 Mar 2026 19:18:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b128558-166c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eRxj3OWcVp167CrvWLrOkbh1urCYOkHtCGMT7NL6SmsYPvGeKsbHe6skXXdFYgtvZBO50/lgjN03hbbjy0WpQ2Y7enitoctnxu7veTvXoK8DRfuERuSNMpWvx7uKwjuiTsQCTK9F+/QRxzlBsod5cXrULv8YlTygsMkDOW3p6uSM0Ila9pO7fog7cZuDjD6WOZK4FDQWIxpYBiwc9YKyUmCUelfjOi5GELjLqO3FW3w3fshYSAh7yuSNfxgB2X3+d98ZvgqcnbuF2RdrlxPPCjYexfxkbxMzCuXLRUy5vTohs/8rdROZxR/yqaHUibD4B3BSyLg99gRCaypHSzW9Zw== 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=LCPhyc8uZGTS+6RkMDRkq18hqcIIjgjPFEAxZTbMplM=; b=StCtAzpLnMibWQmsrnr6WCAQDpzGcE95jJH4gc3Ti+7AEBZlgLBDy87mEfqJuUPs1fn38L15z7ERp1QDBObLue4kqjLWCZFO7yKms2eX3KYp35I6Yp6zpmGWRYwAe1Bki4EzLqta2cG/swPCUyIc+QdNOk22yAgF4Zq7tZ1pcP6Hw1dOnr2Z+EY9N3pD7efFgNWJe6/kRJosxOXWQrBFRXgz/a1x0fTd3zHcWlNSY3VYRT5q7kMvVh/unCIHLyHiuBcAxb1m4Wrd1sxL8wrmVGoloUR8RTJyATW/NyjdFKJve3CJuWXVL+FJ2BVVqrgj6Lrko7IUcDV5r2df69Bzgg== 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=LCPhyc8uZGTS+6RkMDRkq18hqcIIjgjPFEAxZTbMplM=; b=OFb6wRkLyEgJX0VM+WAwqv3FU610h6z8T1QONpBZiDZPFNPLvxRQUp9w1aMM4RQj9LUYBAnWTu+IAHJdVR5ol77MukD4ijr8RrpnZJjpL/dCXisj4M+Kj9zFMhthOVLRmGMF7yfcf5zyj2xYRbmi14u4jRd81tk7J4X/rC4FHrE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH] x86: Remove x86 prefixed names from mcheck code Date: Mon, 2 Mar 2026 19:19:00 +0000 Message-ID: <20260302191900.672460-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0134.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:193::13) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|SA1PR03MB7032:EE_ X-MS-Office365-Filtering-Correlation-Id: 2115c1ea-82ac-49f9-7993-08de78907c2c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: Ys7qrlY8M5N4bR9ZlicQWui/CePe3dyMM1BquGicMBT4Ixws7mGIH+jJQBOCcP82u94GGpCwf+ETNysZNmSbkH27VmM77ybnXoMSgpqs6qc219/ZcLeW0V7PMlH+nfGtDkrAN5e/ysfDg2SjOgRoI3uu6mykFKgBz14g8otOqpCMlGDVHaVdhJJqcsbuMisGkSMdsOH/S9bxbsLYtj7WAbjflhHB0O0dCP01bdHw3v69/aQrF9OoL8kPB/HevGbRX7PZGJeG/+LrVuC7vkbgBqqMjOnxqfzuyAIA+Vp+5YpmWDuXaswLFboIotiSt7eXKwEbUtM6PRfDZLgnXXSZ6qbTd1PreoiZTqXp9OGyIZ20Y86YX8bFFRVqE8BJrs7fHV5d7ipbZG7gvCZG4Buh5NCeyYxr89Z5XlcPM0nyffMtBwXY8FCBPL4Ol2d6t1mIpeHTCh6QBjFzCldWGVRlNmemfn7zcWHNT2CuBgbv+fQdNjYFjzb9XSgjtnLO23pajpDTK0MjRQGfuNiWjqFO8oMrJQpB9t9Wnjdavc/b4Xn1BtexazLJ0yDhudP8s9kjUIPadvXFijGTdUbXpaxptQYHzDrQZfiSrK3cUDMU3PWyJG+BgVKh7KYxa/ABPEv1FHM1fc4PlRSL5tOpul6eb8CEtNeyMOEeVRnhOKC71CglqjxKJ6QPxxDavLtKnZPNAEO4pvJD0LcZT5q1jVOWKuMCt3zM4ad7687Q+j3M+DY= 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)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?rtBIzNxURKjXDzw3zt0fKebM+RSVmVUYQuH/pYaro5Ka5XRKAdFwVEvp0RHS?= =?us-ascii?Q?ebQc4U/cVDAOGMvZSDcc4zJD6n9x2ZrRC0+h1PZVn1MQxG2f7IejjqX+iTMf?= =?us-ascii?Q?lEwzaDXUan5cmXsPjB8Hzy9dTiyVRM6kaCeknqEF0ezMbWMfO17PyXG87qS5?= =?us-ascii?Q?ARweUkzRgG9liHHqwUvlOSd4LqRdOqJlfQZ5QvOeSmROCHLeX/tUTzuVBt5u?= =?us-ascii?Q?AwvUO9RqGI4NUWaZXt6GeCEr/a4B9Dm5sAcHKshM9d0SD79Ab18tzy9h9ATI?= =?us-ascii?Q?jAtAtutS7DLcctGaO1NtAbRPCWIqxKuOLgW5PqB3KFMSPFDxRcRB9cMSKyfv?= =?us-ascii?Q?mOWfdN2UKfyBWJ3zkA4i5PRu5cBwgJILl8zxwOeCT+G82ChYywDkidf/5elC?= =?us-ascii?Q?AGk5jrlbA8ykfYjJEWPB2cOmmY3eQU+KB1TvxwuwNpf4ubfARyjazNlp9Hs7?= =?us-ascii?Q?2w8I5HuBcf33jTc8GjMiB0lobJzWDXD6jsTnVHnauwXyE2edLm4exZrANXsK?= =?us-ascii?Q?LJ/XBhbLwjm7DZojWDQ4Xn7pa3hMcuVTA4TxWoW5DkdeC5kiKKzVktDGu108?= =?us-ascii?Q?2loxVsbzdTAHaW0jBmvKp4SYQcRVCUtQt6RXzCLKU82b/7JA/kNzeQKkma/N?= =?us-ascii?Q?q99WczZcHFWjUUUuDt5xGU14DEGauyphzDfVCRnboU0iyH50GOqR1LZnc2hi?= =?us-ascii?Q?YwkGGjw4/fHVKPDivvf8x5qg05o6atf7LKILvNGuvB+UJ2U2y9noTy07fuoz?= =?us-ascii?Q?fmL7BH+myLdxofTz2fXUr0S+2lAPPWMe/8t7w9R8TIa0AzqjqK3I+VKxdLfN?= =?us-ascii?Q?8l1jfDhmbzaNwk4FJNdrLa1H4CX7CUN2WJX8q4AhB8xrQeqh/aGqO13gpIIw?= =?us-ascii?Q?No6CTJweivyNF9L+8oTCWkJDLhERsZcvY3pksXIwtTrrbmGBxCuYeJuA0Qyl?= =?us-ascii?Q?9Csnb21DzreqUJuBv7VENKCAaB0HUyalGxhbC23KfCLx0lh74q7M7Uv+DvYs?= =?us-ascii?Q?qJKTsQ9MARsWFhn8wc7ukcOV5MjFeinA2NdUm+lf8UZe1hj+iK0JAbClM+Eb?= =?us-ascii?Q?O2EyEgjiJd9pIgucl1a2LOCYDFpjDJWYVGXMWpK4ZH9Aj/N+WB+H7EHAZ2fp?= =?us-ascii?Q?1zBbsdoqYr4hBmXAedc6NWWRVVhPtrcImdFylaB+lBHfUDTmxyNeIH+bjqGW?= =?us-ascii?Q?Ga7PuQ5OJXdS7JVTbhYwfWCU5bdn5rm5S8dD0S2B5zgWdm6aAjjyPoN+bd5q?= =?us-ascii?Q?M0mNnWVdr8FbMF8uuruAHBP1j9BN5+s9/xPdZPO5M3vmGEWHz/wv4+GQHK1g?= =?us-ascii?Q?+Xa4+4zR1fU6tCCPlnBKt8xcr5SjQFnbeSpm+g+1sbLfMWPoZBt3SU8OYzp6?= =?us-ascii?Q?Lzy0fw/E1+pBy21jb27LvSeQOucriCkW2b5bHiycrLryb5FlhfP9RCbkU7eA?= =?us-ascii?Q?hMYghYyNNuYVKjNMOgGdWh/djH1wt8pAuqTSisYcOaPd40YZE4HgYyE2Iw+U?= =?us-ascii?Q?/fBaPwOkBfBRlfT7vsbRtCJrblcZlGUiE/ViTRalLjgSLr+b9GbXhlfj72XQ?= =?us-ascii?Q?RKFecXkKL6mDo9r3yAunZpp4A5xkLRSJ+90urs2x2XQfrkFC0Q99l13BTnyJ?= =?us-ascii?Q?GWhD9Bkg5EG8wKBK1B/4UqToIY6khLfrhejaBVEESObfiNiS8P22CxnLal9c?= =?us-ascii?Q?/HcjMTnC2VdZp16f3H9ylHgTC3gozfVFDEwB9iiuWGFKXmtXJ6JdvMPwQnGa?= =?us-ascii?Q?z6jQ+tkywQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2115c1ea-82ac-49f9-7993-08de78907c2c X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2026 19:18:28.8354 (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: FlE2/SiN/RbdBKTniI7igoQVQ2ofys0i56xNKchH2BhCL9odwNZt4AdWhMoaaMdjt08Yofx3b+0F/4lAgUspXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB7032 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- In xen/arch/x86/cpu/mcheck/mce.c: mcheck_init(...) Xen only calls `intel_mcheck_init(...)` if family is 6 or 15. Linux only calls `mce_intel_feature_init(...)` if family != 5. Do we need to do something like extend this switch statement in `mcheck_init(...)` to include family 18 and 19? In xen/arch/x86/cpu/mcheck/mce.c: mce_firstbank(...) The check c->family == 6 && c->vendor == X86_VENDOR_INTEL && c->model < 0x1a could be re-written as c->vfm >= INTEL_PENTIUM_PRO && c->vfm < INTEL_NEHALEM_EP I don't know if that would be better. --- xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 2 +- xen/arch/x86/cpu/mcheck/mcaction.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 30 +++++++++++++------------- xen/arch/x86/cpu/mcheck/mce.h | 2 +- xen/arch/x86/cpu/mcheck/mce_amd.c | 16 +++++++------- xen/arch/x86/cpu/mcheck/mce_intel.c | 5 +---- xen/arch/x86/cpu/mcheck/non-fatal.c | 2 +- xen/arch/x86/cpu/mcheck/vmce.c | 8 +++---- 8 files changed, 32 insertions(+), 35 deletions(-) diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c index 7d48c9ab5f..fb52639e13 100644 --- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c +++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c @@ -191,7 +191,7 @@ static void cf_check mce_amd_work_fn(void *data) void __init amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c) { - if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) + if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) return; /* Assume we are on K8 or newer AMD or Hygon CPU here */ diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c b/xen/arch/x86/cpu/mcheck/mcaction.c index bf7a0de965..236424569a 100644 --- a/xen/arch/x86/cpu/mcheck/mcaction.c +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -101,7 +101,7 @@ mc_memerr_dhandler(struct mca_binfo *binfo, * not always precise. In that case, fallback to broadcast. */ global->mc_domid != bank->mc_domid || - (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + (boot_cpu_data.vendor == X86_VENDOR_INTEL && (!(global->mc_gstatus & MCG_STATUS_LMCE) || !(d->vcpu[mc_vcpuid]->arch.vmce.mcg_ext_ctl & MCG_EXT_CTL_LMCE_EN))) ) diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 9a91807cfb..10e826e3a6 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -334,7 +334,7 @@ mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask, mca_init_global(mc_flags, mig); /* A hook here to get global extended msrs */ if ( IS_ENABLED(CONFIG_INTEL) && - boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + boot_cpu_data.vendor == X86_VENDOR_INTEL ) intel_get_extended_msrs(mig, mci); } } @@ -564,8 +564,8 @@ bool mce_available(const struct cpuinfo_x86 *c) */ unsigned int mce_firstbank(struct cpuinfo_x86 *c) { - return c->x86 == 6 && - c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a; + return c->family == 6 && + c->vendor == X86_VENDOR_INTEL && c->model < 0x1a; } static int show_mca_info(int inited, struct cpuinfo_x86 *c) @@ -596,7 +596,7 @@ static int show_mca_info(int inited, struct cpuinfo_x86 *c) case mcheck_amd_famXX: case mcheck_hygon: printk("%s%s Fam%xh machine check reporting enabled\n", - prefix, type_str[inited], c->x86); + prefix, type_str[inited], c->family); break; case mcheck_none: @@ -766,7 +766,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp) else if ( cpu_bank_alloc(cpu) ) panic("Insufficient memory for MCE bank allocations\n"); - switch ( c->x86_vendor ) + switch ( c->vendor ) { #ifdef CONFIG_AMD case X86_VENDOR_AMD: @@ -777,7 +777,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp) #ifdef CONFIG_INTEL case X86_VENDOR_INTEL: - switch ( c->x86 ) + switch ( c->family ) { case 6: case 15: @@ -882,7 +882,7 @@ static void x86_mcinfo_apei_save( memset(&m, 0, sizeof(struct mce)); m.cpu = mc_global->mc_coreid; - m.cpuvendor = xen2linux_vendor(boot_cpu_data.x86_vendor); + m.cpuvendor = xen2linux_vendor(boot_cpu_data.vendor); m.cpuid = cpuid_eax(1); m.socketid = mc_global->mc_socketid; m.apicid = mc_global->mc_apicid; @@ -983,10 +983,10 @@ static void cf_check __maybe_unused do_mc_get_cpu_info(void *v) &xcp->mc_apicid, &xcp->mc_ncores, &xcp->mc_ncores_active, &xcp->mc_nthreads); xcp->mc_cpuid_level = c->cpuid_level; - xcp->mc_family = c->x86; - xcp->mc_vendor = xen2linux_vendor(c->x86_vendor); - xcp->mc_model = c->x86_model; - xcp->mc_step = c->x86_mask; + xcp->mc_family = c->family; + xcp->mc_vendor = xen2linux_vendor(c->vendor); + xcp->mc_model = c->model; + xcp->mc_step = c->stepping; xcp->mc_cache_size = c->x86_cache_size; xcp->mc_cache_alignment = c->x86_cache_alignment; memcpy(xcp->mc_vendorid, c->x86_vendor_id, sizeof xcp->mc_vendorid); @@ -1142,7 +1142,7 @@ static bool __maybe_unused x86_mc_msrinject_verify(struct xen_mc_msrinject *mci) if ( IS_MCA_BANKREG(reg, mci->mcinj_cpunr) ) { - if ( c->x86_vendor == X86_VENDOR_AMD ) + if ( c->vendor == X86_VENDOR_AMD ) { /* * On AMD we can set MCi_STATUS_WREN in the @@ -1177,15 +1177,15 @@ static bool __maybe_unused x86_mc_msrinject_verify(struct xen_mc_msrinject *mci) case MSR_F10_MC4_MISC1: case MSR_F10_MC4_MISC2: case MSR_F10_MC4_MISC3: - if ( c->x86_vendor != X86_VENDOR_AMD ) + if ( c->vendor != X86_VENDOR_AMD ) reason = "only supported on AMD"; - else if ( c->x86 < 0x10 ) + else if ( c->family < 0x10 ) reason = "only supported on AMD Fam10h+"; break; /* MSRs that the HV will take care of */ case MSR_K8_HWCR: - if ( c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) + if ( c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) reason = "HV will operate HWCR"; else reason = "only supported on AMD or Hygon"; diff --git a/xen/arch/x86/cpu/mcheck/mce.h b/xen/arch/x86/cpu/mcheck/mce.h index 920b075355..3b61b12487 100644 --- a/xen/arch/x86/cpu/mcheck/mce.h +++ b/xen/arch/x86/cpu/mcheck/mce.h @@ -137,7 +137,7 @@ void x86_mcinfo_dump(struct mc_info *mi); static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr) { - switch (boot_cpu_data.x86_vendor) { + switch (boot_cpu_data.vendor) { case X86_VENDOR_INTEL: if (msr >= MSR_IA32_MC0_CTL2 && msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) ) diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c b/xen/arch/x86/cpu/mcheck/mce_amd.c index 25c29eb3d2..2d17832d9c 100644 --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -160,17 +160,17 @@ mcequirk_lookup_amd_quirkdata(const struct cpuinfo_x86 *c) { unsigned int i; - BUG_ON(c->x86_vendor != X86_VENDOR_AMD); + BUG_ON(c->vendor != X86_VENDOR_AMD); for ( i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++ ) { - if ( c->x86 != mce_amd_quirks[i].cpu_family ) + if ( c->family != mce_amd_quirks[i].cpu_family ) continue; if ( (mce_amd_quirks[i].cpu_model != ANY) && - (mce_amd_quirks[i].cpu_model != c->x86_model) ) + (mce_amd_quirks[i].cpu_model != c->model) ) continue; if ( (mce_amd_quirks[i].cpu_stepping != ANY) && - (mce_amd_quirks[i].cpu_stepping != c->x86_mask) ) + (mce_amd_quirks[i].cpu_stepping != c->stepping) ) continue; return mce_amd_quirks[i].quirk; } @@ -291,13 +291,13 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) uint32_t i; enum mcequirk_amd_flags quirkflag = 0; - if ( c->x86_vendor != X86_VENDOR_HYGON ) + if ( c->vendor != X86_VENDOR_HYGON ) quirkflag = mcequirk_lookup_amd_quirkdata(c); /* Assume that machine check support is available. * The minimum provided support is at least the K8. */ if ( bsp ) - mce_handler_init(c->x86 == 0xf ? &k8_callbacks : &k10_callbacks); + mce_handler_init(c->family == 0xf ? &k8_callbacks : &k10_callbacks); for ( i = 0; i < this_cpu(nr_mce_banks); i++ ) { @@ -311,7 +311,7 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) } } - if ( c->x86 == 0xf ) + if ( c->family == 0xf ) return mcheck_amd_k8; if ( quirkflag == MCEQUIRK_F10_GART ) @@ -337,6 +337,6 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) ppin_msr = MSR_AMD_PPIN; } - return c->x86_vendor == X86_VENDOR_HYGON ? + return c->vendor == X86_VENDOR_HYGON ? mcheck_hygon : mcheck_amd_famXX; } diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c index 839a0e5ba9..9100ce0f6c 100644 --- a/xen/arch/x86/cpu/mcheck/mce_intel.c +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c @@ -711,10 +711,7 @@ static bool mce_is_broadcast(struct cpuinfo_x86 *c) * DisplayFamily_DisplayModel encoding of 06H_EH and above, * a MCA signal is broadcast to all logical processors in the system */ - if ( c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && - c->x86_model >= 0xe ) - return true; - return false; + return c->vfm >= INTEL_CORE_YONAH; } static bool intel_enable_lmce(void) diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c index a9ee9bb94f..4e7c64abef 100644 --- a/xen/arch/x86/cpu/mcheck/non-fatal.c +++ b/xen/arch/x86/cpu/mcheck/non-fatal.c @@ -23,7 +23,7 @@ static int __init cf_check init_nonfatal_mce_checker(void) /* * Check for non-fatal errors every MCE_RATE s */ - switch (c->x86_vendor) { + switch (c->vendor) { #ifdef CONFIG_AMD case X86_VENDOR_AMD: case X86_VENDOR_HYGON: diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c index 1a7e92506a..84776aeec8 100644 --- a/xen/arch/x86/cpu/mcheck/vmce.c +++ b/xen/arch/x86/cpu/mcheck/vmce.c @@ -45,7 +45,7 @@ void vmce_init_vcpu(struct vcpu *v) int i; /* global MCA MSRs init */ - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) v->arch.vmce.mcg_cap = INTEL_GUEST_MCG_CAP; else v->arch.vmce.mcg_cap = AMD_GUEST_MCG_CAP; @@ -63,7 +63,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct hvm_vmce_vcpu *ctxt) { unsigned long guest_mcg_cap; - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) guest_mcg_cap = INTEL_GUEST_MCG_CAP | MCG_LMCE_P; else guest_mcg_cap = AMD_GUEST_MCG_CAP; @@ -136,7 +136,7 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val) break; default: - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { #ifdef CONFIG_INTEL case X86_VENDOR_CENTAUR: @@ -273,7 +273,7 @@ static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val) break; default: - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { #ifdef CONFIG_INTEL case X86_VENDOR_INTEL: -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 03 06:23:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 06:23:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244558.1544006 (Exim 4.92) (envelope-from ) id 1vxJAS-0005Ks-8R; Tue, 03 Mar 2026 06:23:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244558.1544006; Tue, 03 Mar 2026 06:23:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxJAS-0005Kk-3Q; Tue, 03 Mar 2026 06:23:40 +0000 Received: by outflank-mailman (input) for mailman id 1244558; Tue, 03 Mar 2026 06:23:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxJAQ-0005Ke-DN for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 06:23:39 +0000 Received: from mx0b-00498f03.pphosted.com (mx0b-00498f03.pphosted.com [148.163.143.241]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 804bfee5-16c9-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 07:23:33 +0100 (CET) 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 6234U97U3271727 for ; Tue, 3 Mar 2026 06:23:31 GMT Received: from ph7pr06cu001.outbound.protection.outlook.com (mail-westus3azon11010029.outbound.protection.outlook.com [52.101.201.29]) by mx0b-00498f03.pphosted.com (PPS) with ESMTPS id 4cnrp1gjg9-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Tue, 03 Mar 2026 06:23:31 +0000 (GMT) Received: from BN0PR04CA0129.namprd04.prod.outlook.com (2603:10b6:408:ed::14) by SJ2PR16MB6249.namprd16.prod.outlook.com (2603:10b6:a03:584::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.15; Tue, 3 Mar 2026 06:23:27 +0000 Received: from BN1PEPF00004685.namprd03.prod.outlook.com (2603:10b6:408:ed:cafe::9) by BN0PR04CA0129.outlook.office365.com (2603:10b6:408:ed::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.22 via Frontend Transport; Tue, 3 Mar 2026 06:23:11 +0000 Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by BN1PEPF00004685.mail.protection.outlook.com (10.167.243.86) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Tue, 3 Mar 2026 06:23:26 +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 6234Rh771461801 for ; Tue, 3 Mar 2026 01:23:24 -0500 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 4cmk4uakj9-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 03 Mar 2026 01:23:24 -0500 (EST) Received: from localhost ([19.12.76.221]) by cmsmtp with ESMTPSA id xJA9vVhMbkQ6qxJAAvRcZW; Tue, 03 Mar 2026 06:23:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 804bfee5-16c9-11f1-9ccf-f158ae23cfc8 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=1LRWpccveiPINMTJncKdme8CBh1 yL3XssSG6j2s783Q=; b=SEdZQOQsyKUVNdcPJiOONvdqqUSlSrnclbM0oJoX2VA 6524D7+/Z0KrVLSki9XMas0TNigFwPlNygO5cHgkwa5hwGY3PFGs6Ce1EjbxNJ44 kWmT+SZMoVzO2X3BC6DoPBqqoVPrUGw0t0zQdszozt7/UKkhyUcF9IODRvnNhQoH A4/dkI0NEzsS2AtfFkTEMfLnG/AAKqSTIu0/bXwBGWPfuvsZC6H85rJlhXlJPw9S 3poE1BtCf2o1d6d/g2W48NYHsvp5xJ27c3W0sviorxrotT86T02afK35LT7/h21m S3/gfJ5PXTs367DLOBrg7b4FO073msfX4I4bHN2uABA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Q9r/3UZNnrjNbK1vbIhL2jOKK8ObjdWn0Y4IXI9ZbxPZygCEmo+6A4wt99JNUmf+JYTSwmBUuokSjhgz0mhWprV+i8uHbmPhQTHXF3wX0tbQ/8vsrZEyIxbrO0sMpESdZBWU8I+Z+QyJhNZoU8yRd3U0V4EjjchNvIHhRJxCw+hzApJxr3IFDMf4R5RkWtCqUyFWsOq5jT2gjWvAN+AX1e+Dv3ocgPYF0pGX/s/JlWmIwh8YnGqz4iGQyvlz3yHlN0lc4CojyLokMO9YlSD/yd8YRyDvs51jSJWNIG9TP4XsXDN+vXbWj+e0Ph8NKmwdMh67aXm26mPt+erZTPYzig== 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=1LRWpccveiPINMTJncKdme8CBh1yL3XssSG6j2s783Q=; b=MHZ2rHg1I4GxHocSGd/Fa7sGxGM/u6WUicJ3D+L3g03PgJXAwtS+/OA/kREQNLv577bW/NjmrDAuv7B93MgjXdDyZAo8n8YXLdtOPybFyKMkie7BVJVwFMna6xebsyUnL2T2Hpa9wPPORAWj1PwLKKJXT3ktP0u69InZ9QTxCuQfjJX/fplXkjgqNoBeo5CG0iaFbvUWEBeQd9Cf10RkP/buTDadpyi2Ypa73nB9XMwjs/Q8aRSEa0dc8PRoq0DR7ee914dK9uVZYgwXBvyUn7EvHP+JOPg6reHIjVpeSP14Q6xuk6eCd4/8Zvc9tplHgEiym/hLw28fYOy0mtDrDQ== 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=1LRWpccveiPINMTJncKdme8CBh1yL3XssSG6j2s783Q=; b=A1jAwvscdRgWqQRM7ycE4/sxAo9iDOTD0Z450YaVvi30hM4XRNUbePHS+r1O36ggAXbRwlDvrhIMeIbC7k0T6/BnUPBYBs6ujtjaFoe/vY7QivbJ82UUumRFu3v++udPKiDT94hMciiydvJl445JG2WL5o9KAfY/FfdJLDsyC/o= 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=1LRWpccveiPINMTJncKdme8CBh1yL3XssSG6j2s783Q=; b=ozIEP8gCBNRS vSKtE878JtQM7SmOSoNzECeCSeAFlgC+Gb0BBTVBeuCjYgC23T4FxGqipzg2ail5 v3ykUKZEfl5xxSudf4252d+RkPFRnsDSsPmbt2AQZjO//irb7VX1G2fJO7qYXxsy afk6jfe89TUeI5S9xPFKz3Fed1vuVv+Y/p59zW3VKc33FxIg2dJFyzn0zeZKbizD zY2h0IVWqZ8m9I4LK4QAikFL+vaAzJRtXfhoPU2B1J6y3t2wapkeECPrTuJl8Bu9 JJkHwhXVgMGQJ+NYFrn6Inj8M9A1Aa2BmMoqYrhE07UOWLcrG9txVw8/IiYa1Swm LWn4Xw5PGQ== 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=1LRWpccveiPINMTJncKd me8CBh1yL3XssSG6j2s783Q=; b=Ifq0aaI0q3R4qrB9y5l32amdMI7GeftkzkBg In92+tXXd0okEc4RyTa6tMePQxAOvOY7oLAje8utCiO4EfBXRVpQyKbCU0bsD234 UPbWY1dpASS3y3KTfs8IaDoLPnRXZ6n8oudGJaFtS37VxoQsWsUA7XrWWNNn2R8e +F1DWkZX4tLtTa9VbEcE34IE6UaYKySV2hFEnJ8WqitspeBITCP1bxzetuHYNO0k k8uSssMSseDWuwOrAv8DwgfJxIB+69LYiOYD8WMgFuj35Zv5T0RhfjFZ2J0dReSo tzg3IdcYFg4B7ezVJQhg7ibBFhtSR2sTrSc8NZw8W+uoooHeJw== X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7 X-Cloudmark-MID: xJA9vVhMbkQ6qxJAAvRcZW X-Proofpoint-CID: eb09f7eb-2dc2-34ab-a188-7b293c1db1fe From: dmukhin@ford.com Date: Mon, 2 Mar 2026 22:23:21 -0800 To: Anthony PERARD Cc: dmukhin@ford.com, xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org Subject: Re: [PATCH v5] xen/domain: introduce DOMID_ANY Message-ID: References: <20260205235126.3764953-1-dmukhin@ford.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: PSER-M365-App: SER-APP X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-02_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0 malwarescore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603030041 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN1PEPF00004685:EE_|SJ2PR16MB6249:EE_ X-MS-Office365-Filtering-Correlation-Id: 9447569c-685f-40b8-57af-08de78ed60fb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700013|82310400026; X-Microsoft-Antispam-Message-Info: X4l1qC6068PLzAYQIZCFaJqZrHrNE3pj/ACiUyJmHFqFWxCIBW/4l+H75TeStepUTOhe5vZBgtfXw77lyePEqLlr8t/li5N13T0YiflE28ZKuxSX35dvTxt8dL6Umy7GOaFZPi8bWwlgxPKpDVn3CvkRpGOpJKEbOU1vMjaZ+8HOrCV1MbWtS2kvYr1goM4/Oj+qWlOXnm68UemFGa45ZooUc0oc69ceFitc0rM51LtC+uzBSrrcoPR1lvhi0+LEAkWvkyh7nZzx0u9N6QBBPm843dEvQLdd5mcIo0tneDRmCOUssiW2alejcgY6CpQ3pM8A0ISxWJEusQtDtkl2LZ8Q5Pm1VUfAjCxa+H7C1rKlqUzA+2sZv08PZiR5hG6G3A/8YXHUrxxMqG1oS+5meEOcp9OzOgYytZ31iiXxyM2Ijoa8YEEsb26G2z8BPwC6EeimViOsKzfm26MBXUCH37LQK/6G5cvx1DBQC98m2r8BtjfCQ5MImmnoUBlxAzFaZZT12dqx4k7VgRiyAahIeiDt9qhEUOBpNF+Pdclqt5KN8VU3rkxW7w0WycgwffzQh6VSk6StLZGlhbYoY0HGTJiCoCusTrqZ4X18HlCi3Y44Uoue/dzn/j3KSeY8xhb8lroZD7POuown/5UausC/RevS+d5zbtMsspFKMQ8gettbfKtoNPJHK5nWvjbQn2JsiznKCkJZ/zlmSibQ18yuL4v8GSn0jrx56rl/ELtHAxsIcoWQlHBa44aGoVfcot9Dt+1mZsYfv4T9syLwWz7D6AeG4J/ntXEaNf5h/H5jNC+oD1WVWyL6Rk49vNin0VmKCfPq+wnjyxkbYUKASL/VWQ== 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)(1800799024)(36860700013)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ZVQNJxwZXIuu84crdOq/KWVJns9hJtH63bi42/87rysQCF9HKg985Bv7E2+3n8ap8/lvC15dEtJjPhuHxH9munT8Tl7GNh0rpHGSqavnLJFJ047PoAK8a7j86HIMniOHi6dsuUlBOV1yi6IkX4F7x7z7xYruWPekOMdXYV7T8AJk0mfRRUXt58UeEbxDFfj/J1trg/JWRVOD+8ejMmJ8jF62BrW39yst6fIzcgsHyGCCQQ2ukjB1PVrCaiF5VurOcdgfAoT9tD5TQty+ycrerzr6a6kudMbcSrmcW7RB9/52+APEegDRa+/nY6FHZqkl9E7HBOfIBE94BwyPWB+e99SJ6Q6xbsHWoY23hDY7caesN7CmyYyzLiEQnqQsZ4zAtlol8vGZl/vrIYTZfZRYs6x24G8l6w26eW/0eYPjv5Jog0FuHlOBRcWLp72p3JQW X-Exchange-RoutingPolicyChecked: sZnk/ysg/8r1+1QgTSr9nZSYPLgFJLhKAWiBFHtNTeMWnWhXvxuurWFUVC4JcynwpjFlRh86pWFGFF7vZ3+A5sFgR3RwxD74NjYONhcA2fGspGHqBXg6/RSqUKWRoTRHrkFDMcahOSmlZOEC7KovcHsIOXnRu0HP+KBnQwB9LMF5nUTQIh2UTc7vX8BD0/vcAdyAciJlT72SAzCN9F+R290xiOvxQ1M1eU7jtUNazsXixAgcAB82NOCeFtDsPLqlgfowwHkeIvcWi9/8GQTJE2bg0Z91SbmFMhdf2USmJkpckQs/RsbgF0yxVKyoJz5+RI1qwqjRlV/IvwpMOFUVpg== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Jvajp++cMlKGw2ATDwk35zlrXl3ZKePFXiukraSevjhej6uHfvOsMq4RJ6+IZvjUpip/H2tK/yzsCvbWSyLvVvGRqJt5Yd/4YF1sBFGeGcRSyORaoEnN8vs/6EwiRLTxFuMPCTQGYJX6k+nMcy4epLny/R+QjbTvRlEqJFt5I1LTZIHSbLNjo+n2KtiWHf3KkI1qO0q4p5DxVfuLbknb9hdHfP1DO+wi2jsn7mXnJJEIknBCSPGHvBWdb6emBCxSIuEvnMKLOAalZ7WVKPXif/Aq18SxtvVnWzqJ+tLE83rWHUellDsv42TUYo8eJreSufbX69K40zu4RBQ5sklDBGattD1iF+1CheX76m5dGcbjEWJnAv5obSyp3/o6Icx9+RK3JOzTpeAz8zYeTl9AC3hnBXVJez38R02lhbSd5of04vP1s7tn1ZCiMq4TOxWPP8LV9ECOYsSRvKwVuRoPaJtKBEEnAsejfiL63in+GVibDqJ39YgLkoEhGKE8UMBVHFNxQBkzmTEAZSnEJwXNMKhd14WnEUnzto2RO6VtHIIiu0yT/iAZ9UclHxbebIxhRgzz3FlVUbZg0IqC9nvvzRK5WPRhIKuvm104PCLHy8JcossCtDCyyEWBOR/OeOxL X-OriginatorOrg: ford.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 06:23:26.1824 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9447569c-685f-40b8-57af-08de78ed60fb 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: BN1PEPF00004685.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR16MB6249 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzAzMDA0MiBTYWx0ZWRfX76OeBdO3cmm6 NjsZAAkryQm9VdaA4KF3ALVd1wERrxGd241i76cmuwIZNjknlMxu//ihShWqrRirhPRR4837sQs RqVe9XoNopU+GmsOwGtF7q3/w8NQRB6g/ZVMnKeZQRJLPfKZVWwp8IAiGrkJorZ2mxftE/OkC/J 6G7jiudAhaN8O0xk5bVDjfWa/GjzWzHwX1q3u6xCblm1XaVCapCOA0aEi/thY1wBQT67dsvcYPK vNRkrLgZNMrRtCT+NUrNOnPhhuGcbAEjm0XpdjTe7JTwwkcEqmCY5g4Qr8ALFbxI3cA+BwFn1A9 6vKpBLD2hJoX0u2Y+3gBBkZFYi6Ob00Njdnivgt3GO8sy8yDGye6ikBWinskcgDlfemntd5spf9 od4YbKgaHt+ZZdzWKAQHsyjtS84qA68WwuWOKlmYTsuN/cpmOHPEv4u85ZhsS46Nu2gGHhjalA0 tlr0DX5VH9FfvnOhGWg== X-Authority-Analysis: v=2.4 cv=abdsXBot c=1 sm=1 tr=0 ts=69a67e63 cx=c_pps a=FnNH6Hr+id3EzXqhVuY+iw==:117 a=b7IhknPlfT0FN1EembXvig==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=AHe91QgOk3R4nFVtG5At:22 a=cbNQJ9GKAAAA:8 a=CEWtYdiJhwX6ivxE-jwA:9 a=CjuIK1q_8ugA:10 a=DqJYxgmhk6moR-_7_KoZ:22 X-Proofpoint-GUID: BRqJ5tKpvk3Aeva-YQOv7dGD4uoi9XEu X-Proofpoint-ORIG-GUID: BRqJ5tKpvk3Aeva-YQOv7dGD4uoi9XEu X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-02_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 lowpriorityscore=0 spamscore=0 bulkscore=0 suspectscore=0 impostorscore=0 malwarescore=0 adultscore=0 phishscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603030042 On Mon, Mar 02, 2026 at 02:25:33PM +0000, Anthony PERARD wrote: > On Thu, Feb 05, 2026 at 03:51:26PM -0800, dmukhin@ford.com wrote: > > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c > > index bfc9149096a3..714e71441498 100644 > > --- a/tools/libs/light/libxl_create.c > > +++ b/tools/libs/light/libxl_create.c > > @@ -676,15 +676,14 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, > > if (ret < 0) > > break; > > > > - v &= DOMID_MASK; > > - if (!libxl_domid_valid_guest(v)) > > - continue; > > - > > - local_domid = v; > > + local_domid = v & DOMID_MASK; > > } else { > > local_domid = info->domid; /* May not be valid */ > > } > > > > + if (!libxl_domid_valid_guest(local_domid)) > > + local_domid = DOMID_ANY; > > Well, that make it possible to have DOMID_ANY selected when a "random" > domid was asked for, and this value is more likely than any other domid. > I don't think it's wise to change that. The domid generated in the > random case was already valid, no need to check again. > > Coud you move the new validity check into the case where domid isn't > "random" or introduce a new case in the if/else chain ? > (something like that for the second option: if (domid==random) elif > (domid.is_valid) else (use domid)) Will do, thanks. -- Denis From xen-devel-bounces@lists.xenproject.org Tue Mar 03 10:19:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 10:19:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244622.1544032 (Exim 4.92) (envelope-from ) id 1vxMqF-0006tg-F8; Tue, 03 Mar 2026 10:19:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244622.1544032; Tue, 03 Mar 2026 10: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 ) id 1vxMqF-0006tY-BF; Tue, 03 Mar 2026 10:19:03 +0000 Received: by outflank-mailman (input) for mailman id 1244622; Tue, 03 Mar 2026 10:19:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxMqE-0006tS-FP for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 10:19:02 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6428ef9a-16ea-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 11:18:59 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fQBbj5zSXz35hTcb for ; Tue, 3 Mar 2026 10:18:57 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id df24cb92e8e74cd2b1688990cf33efc8; Tue, 03 Mar 2026 10:18:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6428ef9a-16ea-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772533137; x=1772803137; bh=gY7bo8n2Ji8RCSj9PuRMRRI6asnxRBgmrksWWb7Qm5M=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=bLUGhutOM0yp3gtdBy0F2pyGsNrguMuxltwwlZVuRv0RJUyxjDdswWkk/44XuPaGX axIPAbYtq2uQEQPNdYuCKk091q6cQ20Q6LGyYwBFxtnJRkamcXZX+ZN0ISdM/4viYS ACMg859JKCpegVVewF1CC2fHb4uhGVnWhNkzpxkr2UemRmJ+PkijJt9fMxzsM9uQF4 nvkZINBJ3JLoWkq3ZGbUwyaNgIYAAcrt+UDuLdOK1UV6F15u3QENGEjL9II6EYEMac YCZ3I5+xrVsuwnZlw6+7kj1IqzBD1bRBzsWSVEH4pt/RYNwM7qXRv5bdXqe+NvM8dk eaeCVqsy0OgzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772533137; x=1772793637; i=teddy.astie@vates.tech; bh=gY7bo8n2Ji8RCSj9PuRMRRI6asnxRBgmrksWWb7Qm5M=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=BqNGpWNYyPJAtaQK2hFF+Bn3Xl863tFHM8xe8jMqq1SjcHLtZmBfekDm2XF9I+E+H AGuEoR6W2QElwrpKoErkbh/LQKxzHs1fJVb7JebsYeznQTkh5YmiPqUbrSU/9gD7UI l/yGcxCj+dgWuDeyRL5Es4gQiHgDAMIbGq7lz049hAJHA/1O3d8GoVLTTHibyEayjr +KAqXS3PI+OQDT1bVRoFBw6h+Y2SKeOEbDflAwBSIGvHklxvczTjqcfd5qOx47AZp0 cM2r23ZhDKBRKjX9BWKp6WUASZXWu3xAa4YBvjdJ5of/oY1iPh9kCha3syePPaAHvY pUwH/gfxNg8Nw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH]=20x86/ucode:=20Support=20discrete=20modules=20being=20CPIO=20archives?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772533136794 Message-Id: To: "Andrew Cooper" , Xen-devel Cc: "Jan Beulich" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" References: <20260223185054.3598305-1-andrew.cooper3@citrix.com> In-Reply-To: <20260223185054.3598305-1-andrew.cooper3@citrix.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.df24cb92e8e74cd2b1688990cf33efc8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260303:md Date: Tue, 03 Mar 2026 10:18:57 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 23/02/2026 =C3=A0 19:52, Andrew Cooper a =C3=A9crit=C2=A0: > Multiple downstream distros have tried passing discrete CPIO archives and > tripped over this not working. It turns out to be easy to support, so do= so. > > Signed-off-by: Andrew Cooper Tested-by: Teddy Astie > --- > CC: Jan Beulich > CC: Roger Pau Monn=C3=A9 > CC: Teddy Astie > > v2: > * Docs update too. > * Set opt_scan in early_microcode_load() so microcode_init_cache() oper= ates > properly > --- > CHANGELOG.md | 1 + > docs/misc/xen-command-line.pandoc | 19 ++++++++----------- > xen/arch/x86/cpu/microcode/core.c | 20 +++++++++++++++++++- > 3 files changed, 28 insertions(+), 12 deletions(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 18f3d10f20d2..c191e504aba9 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -13,6 +13,7 @@ The format is based on [Keep a Changelog](https://keepa= changelog.com/en/1.0.0/) > - Support for Bus Lock Threshold on AMD Zen5 and later CPUs, used by= Xen to > mitigate (by rate-limiting) the system wide impact of an HVM guest > misusing atomic instructions. > + - Support for CPIO microcode in discrete multiboot modules. > > ### Removed > - On x86: > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-li= ne.pandoc > index c1f2def9f99c..ebdca007d26b 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -2764,23 +2764,20 @@ Controls for CPU microcode loading, available whe= n `CONFIG_MICROCODE_LOADING` > is enabled. > > In order to load microcode at boot, Xen needs to find a suitable update > -amongst the modules provided by the bootloader. Two kinds of microcode = update > -are supported: > +amongst the modules provided by the bootloader. Two formats are support= ed: > > 1. Raw microcode containers. The format of the container is CPU vendo= r > specific. > > - 2. CPIO archive. This is Linux's preferred mechanism, and involves hav= ing > - the raw containers expressed as files > + 2. CPIO archive, which involves having the raw containers expressed as = files > (e.g. `kernel/x86/microcode/{GenuineIntel,AuthenticAMD}.bin`) in a = CPIO > - archive, typically prepended to the initrd. > + archive. Linux commonly prepends this to the initrd. > > -The `` and `scan=3D` options are mutually exclusive and s= elect > -between these two options. Further restrictions exist for booting xen.e= fi > -(see below). > +The `` and `scan=3D` options are mutually exclusive and w= ork as > +follows. Further restrictions exist for booting xen.efi (see below). > > - * The `` option nominates a specific multiboot module as a ra= w > - container (option 1 above). Valid options start from 1 (module 0 is > + * The `` option nominates a specific multiboot module as cont= aining > + microcode in either format. Valid options start from 1 (module 0 is > always the dom0 kernel). A negative number may be used, and will > back-reference from the end of the module list. i.e. `ucode=3D-1` = will > nominate the final multiboot module. > @@ -2794,7 +2791,7 @@ When booting xen.efi natively, the concept of multi= boot modules doesn't exist. > Instead: > > * In the [EFI configuration file](efi.html), `ucode=3D` can= be used > - to identify a file as a raw container (option 1 above). Use of this > + to identify a file as containing microcode in either format. Use of= this > mechanism will disable both `` and `scan=3D`. > > * If `ucode=3D` in the EFI configuration file is not used, = it is > diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microco= de/core.c > index ea0b35c4991d..9b8d1e09cb98 100644 > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -767,6 +767,7 @@ static int __init early_microcode_load(struct boot_in= fo *bi) > void *data =3D NULL; > size_t size; > const struct microcode_patch *patch; > + struct cpio_data cd; > int idx =3D opt_mod_idx; > int rc; > > @@ -783,7 +784,6 @@ static int __init early_microcode_load(struct boot_in= fo *bi) > for ( idx =3D 0; idx < bi->nr_modules; ++idx ) > { > const struct boot_module *bm =3D &bi->mods[idx]; > - struct cpio_data cd; > > /* Search anything unclaimed or likely to be a CPIO archive= . */ > if ( bm->kind !=3D BOOTMOD_UNKNOWN && bm->kind !=3D BOOTMOD= _RAMDISK ) > @@ -851,6 +851,24 @@ static int __init early_microcode_load(struct boot_i= nfo *bi) > idx, size); > return -ENODEV; > } > + > + /* > + * If this blob appears to be a CPIO archive, try interpreting i= t as > + * one. Otherwise treat it as a raw vendor blob. > + */ > + cd =3D find_cpio_data(ucode_ops.cpio_path, data, size); > + if ( cd.data ) > + { > + data =3D cd.data; > + size =3D cd.size; > + > + /* > + * (Ab)use opt_scan to inform microcode_init_cache() that > + * early_mod_idx refers to a CPIO archive. > + */ > + opt_scan =3D true; > + } > + > goto found; > } > > > base-commit: 5eb84d6c992cf4e81936872c441b649057947442 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 03 10:36:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 10:36:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244636.1544042 (Exim 4.92) (envelope-from ) id 1vxN75-0001A5-Pf; Tue, 03 Mar 2026 10:36:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244636.1544042; Tue, 03 Mar 2026 10:36:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxN75-00019y-Mn; Tue, 03 Mar 2026 10:36:27 +0000 Received: by outflank-mailman (input) for mailman id 1244636; Tue, 03 Mar 2026 10:36:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxN74-00019c-PO for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 10:36:26 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d3a96872-16ec-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 11:36:25 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fQBzq5d3Vz35hTbg for ; Tue, 3 Mar 2026 10:36:23 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 8d3d45f8eee04d98930e521723555683; Tue, 03 Mar 2026 10:36:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d3a96872-16ec-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772534183; x=1772804183; bh=d+Gf5ULgHW5IJhmRmxNvkZtOOex1lueb4vEqeJbOAEo=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=0LnmLmxtqNLtQU25CztmGHzOy1A6Yvbs7ImxTsfJ3C360s/mp5hb3EpC4QHjlwwnO lE0vVXOj+olkoAoM2oGjMe1qjxk793Uu1JHKvjj4UIkAEd6ZD5gc8oM9VcSDS5BWlk ctTMFney1cXd5rcFr25GXHXL2y9kZN9VEeh0SFbo0dNePFRw4eKmzkNvrl9xBeThs/ 36N4kVCIGZNeA3Am57hAUd5JcIHM7BXJ1Yg2A8E609hpctjzs7rxIwYnDHEmmyEs47 j+Avq3b8k+morkbr4oYoCp3IJSqrg3V9wn53kYQUY+IRPjZknitrcF8t7A3RAh8Vvk EURZcwfKEB8fA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772534183; x=1772794683; i=teddy.astie@vates.tech; bh=d+Gf5ULgHW5IJhmRmxNvkZtOOex1lueb4vEqeJbOAEo=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=w8FX3NsIaVATAV2a/zLFRwUN5ztoAG/aLW6RxscDgWf+SFl/oBu4J/C7kfFIUD3mJ UCtRKybt08TojYaEFUwb0+hFofMjB/Q98zJMlIettxtnschstLZXyAbKvv+G2UPf/n NY8h+iKKMmEd6eomkxaYlceUynLYmwyxmlnplevoHEWMMBlvDbSvn06bB85l4VjXuW tP5OWOjyZNmBs2/YjnpeS3ybwX0bRWpez+CBqM9+/SHQuGEHdXgx5A7py80HswL1aR 0cPdlSUJYx2lNA0TrXgcQ4StDKgRl2hbhmCwEDGzs2WP5F+YXnaESHlefr/2lpVp+U p0FNd5jngJahw== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v8=201/2]=20libxc:=20Report=20consistent=20errors=20in=20xc=5Fresource=5Fop?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772534183074 Message-Id: To: "Anthony PERARD" Cc: xen-devel@lists.xenproject.org, "Juergen Gross" References: In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.8d3d45f8eee04d98930e521723555683?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260303:md Date: Tue, 03 Mar 2026 10:36:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 02/03/2026 =C3=A0 16:14, Anthony PERARD a =C3=A9crit=C2=A0: > On Fri, Feb 27, 2026 at 05:00:05PM +0000, Teddy Astie wrote: >> xc_report_op doesn't update errno in some error conditions. >> Make sure it reports -ENOMEM in out of memory errors and -EINVAL >> in invalid usages errors. >> >> Signed-off-by: Teddy Astie >> --- >> v7: Introduced >> v8: Use errno to report errors >> >> tools/libs/ctrl/xc_resource.c | 11 +++++++++++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/tools/libs/ctrl/xc_resource.c b/tools/libs/ctrl/xc_resource= .c >> index cb6a97202b..ac1524d1bd 100644 >> --- a/tools/libs/ctrl/xc_resource.c >> +++ b/tools/libs/ctrl/xc_resource.c >> @@ -28,7 +28,10 @@ static int xc_resource_op_one(xc_interface *xch, xc_r= esource_op_t *op) >> XC_HYPERCALL_BUFFER_BOUNCE_BOTH); >> >> if ( xc_hypercall_bounce_pre(xch, entries) ) >> + { >> + errno =3D ENOMEM; > > Looking at xc_hypercall_bounce_pre(), it's looks like `errno` should > already be set. On Linux, that would be `mmap()` or `madvise()` updating > it. > >> return -1; >> + } >> >> platform_op.cmd =3D XENPF_resource_op; >> platform_op.u.resource_op.nr_entries =3D op->nr_entries; >> @@ -54,11 +57,15 @@ static int xc_resource_op_multi(xc_interface *xch, u= int32_t nr_ops, xc_resource_ >> call_list =3D xc_hypercall_buffer_alloc(xch, call_list, >> sizeof(*call_list) * nr_ops)= ; >> if ( !call_list ) >> + { >> + errno =3D ENOMEM; > > Here, xc_hypercall_buffer_alloc() should already have updated `errno`. > (It's a function called by xc_hypercall_bounce_pre(), so we've got the > same culprit updating `errno`.) > >> return -1; >> + } >> >> platform_ops =3D xc_hypercall_buffer_array_create(xch, nr_ops); >> if ( !platform_ops ) >> { >> + errno =3D ENOMEM; > > Here, xc_hypercall_buffer_array_create() calls `calloc()` and `malloc()` > which will update `errno`. > >> rc =3D -1; >> goto out; >> } >> @@ -66,6 +73,7 @@ static int xc_resource_op_multi(xc_interface *xch, uin= t32_t nr_ops, xc_resource_ >> entries_list =3D xc_hypercall_buffer_array_create(xch, nr_ops); >> if ( !entries_list ) >> { >> + errno =3D ENOMEM; > > Same as above. > >> rc =3D -1; >> goto out; >> } >> @@ -81,6 +89,7 @@ static int xc_resource_op_multi(xc_interface *xch, uin= t32_t nr_ops, xc_resource_ >> platform_op, sizeof(xen_platform_op_t)); >> if ( !platform_op ) >> { >> + errno =3D ENOMEM; > > With xc_hypercall_buffer_array_alloc(), `errno` is updated by `mmap` or > `madvise`, like the first case. > >> rc =3D -1; >> goto out; >> } >> @@ -90,6 +99,7 @@ static int xc_resource_op_multi(xc_interface *xch, uin= t32_t nr_ops, xc_resource_ >> entries, entries_size); >> if ( !entries) >> { >> + errno =3D ENOMEM; > > Same as above. > Ok for all, though good to note that malloc ones are documented as platform specific behaviors (at least in malloc(3)). But in our case (POSIX platforms), it's supposed to be the case. >> rc =3D -1; >> goto out; >> } >> @@ -137,6 +147,7 @@ int xc_resource_op(xc_interface *xch, uint32_t nr_op= s, xc_resource_op_t *ops) >> if ( nr_ops > 1 ) >> return xc_resource_op_multi(xch, nr_ops, ops); >> >> + errno =3D EINVAL; > > Ha! This one was missing indeed. > > The patch description will need to be updated with all the chunk be one > been dropped. > Overall, it's libxc: Report EINVAL on incorrect xc_resource_op usage When passing 0 operations to xc_resource_op, a error is reported without setting errno appropriately. > Thanks, > > > -- > Anthony Perard | Vates XCP-ng Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech > > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 03 10:51:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 10:51:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244645.1544052 (Exim 4.92) (envelope-from ) id 1vxNLE-0003rw-0R; Tue, 03 Mar 2026 10:51:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244645.1544052; Tue, 03 Mar 2026 10:51:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxNLD-0003rp-TV; Tue, 03 Mar 2026 10:51:03 +0000 Received: by outflank-mailman (input) for mailman id 1244645; Tue, 03 Mar 2026 10:51:02 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxNLC-0003rj-Mg for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 10:51:02 +0000 Received: from mail178-23.suw51.mandrillapp.com (mail178-23.suw51.mandrillapp.com [198.2.178.23]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dd9c5c03-16ee-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 11:51:01 +0100 (CET) Received: from pmta13.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail178-23.suw51.mandrillapp.com (Mailchimp) with ESMTP id 4fQCJg2r81z35hTPt for ; Tue, 3 Mar 2026 10:50:59 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ea06e0878b7b46b086ed0fd05c3267ec; Tue, 03 Mar 2026 10:50:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dd9c5c03-16ee-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772535059; x=1772805059; bh=do0k8s2/i826y+Ow/hLp7T1yQxJuUBshAis7wonRKd4=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=cTVP2bAnarTtOKyVMrsywXgynHkNhqbofs3Xa1jDXr4pefIs0y1T2yYT6N0wl0MxZ 6AjEfweHLtXDPlKK/drjBc7JpYltpctWvM6Mc5AtpGoS0LM69D/xnc/HWOSBrLdaaj I5ioaEEYzcSu1h3KpH2zW66nJBTJ9W7QMgQ5soougpWz6A9ygsKLtqzg/q3vq/3Obo yyROVdLbSO6P0kI1Z8B6ni761uCvj8FCsUwPMtF2bKJwcJgn4OfjJBj9UZGcIDA3Kq UM/nU5dV3x8J6HAHoF6NLSR7Ul85xFeePWnDH9KUyvkfXyVbQTM1auvA2M3VHlLedk Sg7M+SFxyzhMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772535059; x=1772795559; i=teddy.astie@vates.tech; bh=do0k8s2/i826y+Ow/hLp7T1yQxJuUBshAis7wonRKd4=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=f9HmVMI56qfEH8anX9Gs8JrLjAkmkrabnl1tC01djOJrTZhbReeruAuo40AFe0wqf Ja4gIIPrbzuPq4YAFOPT9bsoWr4hPDhFuennQQfoMl4wPdI4k7CVj1XC8RmiO5ESH1 2UjLfeo9s7k2wtPhq4UYS4sPmJA+48rgXKDMAGdPiUNAX0C0dej3s4WFRFH3ovogjE 5kn2OOIVSfHd9UZoNpoZHKqrXYQApi2GHgiqmMJxcuOIFC1AEQVyjLQYETex+gHNXt VVsALa9mMhkp4YDbG4pdV39d+D/nNFjkaYb4ZgdybL/rpg0ug7tu17fwGRqoout0c8 TKtgntzKffBXQ== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20[PATCH=20v8=202/2]=20xenpm:=20Add=20get-core-temp=20subcommand?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772535058591 Message-Id: <4c18413b-6296-4a30-bbec-561f7b802cbc@vates.tech> To: "Jan Beulich" Cc: "Oleksii Kurochko" , "Community Manager" , "Anthony PERARD" , xen-devel@lists.xenproject.org References: <7380cf63-e9ac-4df9-9633-c26f9de0027a@suse.com> In-Reply-To: <7380cf63-e9ac-4df9-9633-c26f9de0027a@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ea06e0878b7b46b086ed0fd05c3267ec?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260303:md Date: Tue, 03 Mar 2026 10:50:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le 02/03/2026 =C3=A0 17:52, Jan Beulich a =C3=A9crit=C2=A0: > On 27.02.2026 18:00, Teddy Astie wrote: >> @@ -1354,6 +1358,127 @@ void enable_turbo_mode(int argc, char *argv[]) >> errno, strerror(errno)); >> } >> >> +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package= , int *temp) >> +{ >> + xc_resource_entry_t entries[] =3D { >> + { .idx =3D package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_= STATUS }, >> + { .idx =3D MSR_TEMPERATURE_TARGET }, >> + }; >> + struct xc_resource_op ops =3D { >> + .cpu =3D cpu, >> + .entries =3D entries, >> + .nr_entries =3D ARRAY_SIZE(entries), >> + }; >> + int tjmax; >> + >> + int ret =3D xc_resource_op(xch, 1, &ops); >> + >> + switch ( ret ) >> + { >> + case 0: >> + /* This CPU isn't online or can't query this MSR */ >> + return -1; > > Further down at the callers of this function you assume errno is set when= ever > an error indication is returned. As xc_resource_op() didn't fail, you wil= l > need to synthesize an errno value here. > ah yes indeed >> +static void get_core_temp(int argc, char *argv[]) >> +{ >> + int temp =3D -1, cpu =3D -1; >> + unsigned int socket; >> + bool has_data =3D false; >> + >> + if ( argc > 0 ) >> + parse_cpuid(argv[0], &cpu); >> + >> + if ( cpu !=3D -1 ) >> + { >> + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) >> + printf("CPU%d: %d=C2=B0C\n", cpu, temp); >> + else >> + { >> + fprintf(stderr, "Unable to fetch temperature (%d - %s)\n", >> + errno, strerror(errno)); >> + printf("No data\n"); >> + exit(ENODATA); > > In how far is using errno values as arguments to exit() a useful thing? (= I > think you had it like this before, and I merely forgot to ask.) Yes, I ca= n > see the tool using a number of exit(EINVAL), but I don't understand those > either. This way you can't even document easily what particular exit code= s > mean, as the errno values may vary across OSes. > I reused the exit(...) pattern used in xenpm, but I'm also fine by returning simpler errors (like exit(1) or exit(EXIT_FAILURE)). diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c index 981d3ec519..7d186c4837 100644 --- a/tools/misc/xenpm.c +++ b/tools/misc/xenpm.c @@ -1377,6 +1377,7 @@ static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *te { case 0: /* This CPU isn't online or can't query this MSR */ + errno =3D ENODATA; return -1; case 1: @@ -1434,7 +1435,7 @@ static void get_core_temp(int argc, char *argv[]) fprintf(stderr, "Unable to fetch temperature (%d - %s)\n", errno, strerror(errno)); printf("No data\n"); - exit(ENODATA); + exit(EXIT_FAILURE); } return; } @@ -1475,7 +1476,7 @@ static void get_core_temp(int argc, char *argv[]) if ( !has_data ) { printf("No data\n"); - exit(ENODATA); + exit(EXIT_FAILURE); } } > Jan > Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 03 11:55:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 11:55:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244670.1544061 (Exim 4.92) (envelope-from ) id 1vxOKs-0002rY-DG; Tue, 03 Mar 2026 11:54:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244670.1544061; Tue, 03 Mar 2026 11: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 ) id 1vxOKs-0002rR-AJ; Tue, 03 Mar 2026 11:54:46 +0000 Received: by outflank-mailman (input) for mailman id 1244670; Tue, 03 Mar 2026 11:54:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxOKq-0002rG-SC for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 11:54:44 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bcb1983b-16f7-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 12:54:30 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4837907f535so48750925e9.3 for ; Tue, 03 Mar 2026 03:54:30 -0800 (PST) Received: from [10.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-483bd750607sm471415035e9.10.2026.03.03.03.54.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 03:54:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bcb1983b-16f7-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772538870; x=1773143670; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=AVFhxFutpF3studja/ZLtYGSJGAcd6yQ/oiyg+/5vvY=; b=Y8AYmANMcKsf3BCJSnpMhehi+UvSU9lfS0smZHkQRXteO5bzmft0OXMOvwdVLsCnmh sUJkTY5QKzqbRsDkkcvkp+bEywwHx+64jg0tWMbO8Pw5Mkxo1QSgknryCPPIyPbT4cOT vRd/a1D6Lvs26FxqCqjaId+knPnzseFPwgiLcCVfug1J3PUgM67b3n3JnYSdeEWGJWET 4D0DTT3QLwQOtrc23jtRcfKNdclkx8UpI3IdZsHTQ+V1nDOxmog5adOhxY6/dszWrzt/ ijEdtA9jDTn7acHsIrZ4QR3Sd3bsyp4ZBV6Sg2tuenqsF8rBOlr4XkmdI0mPG/puJQGf 5zyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772538870; x=1773143670; h=content-transfer-encoding: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; bh=AVFhxFutpF3studja/ZLtYGSJGAcd6yQ/oiyg+/5vvY=; b=H8zkMKdXqsGs8T4kfMKevdFojHKW9EUBi2lgD0Jf5lYUl1asmLnr1TTcVwq/K5FMUK Qlbtjp6Pjvron7ScmC/JRl9fIH0W1EZImD+L4l9vH7J92cVkHH8NBRMO6WHIfm7bVmZK 4IbenqXJlDZVBszwN6UnXCAVfmCJsrpErJWN8cC9NETfi2VocBulpa3bgp/or6VOd9sT 1ynXoKvaC23sWkN+y6nzZVxzvltgKIyJWHlrWEelMcTVEDiDDXDoNivkdz7xUDaav1fz Ha92v1K2ORj3ICpa2p8F3B/4mR16QEihxa5g06Sugrn181Mhxynu+cTkNjmPdC7xurK2 b9DQ== X-Forwarded-Encrypted: i=1; AJvYcCXdI6SKpNxMaUYPTT/BA1r9K6t1V+L5Daz8lhxAMj2MhjEjEzdqXhiN7+re1At4uqFNOVd4NrVxdOg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzZDWTiL1XvDFV++WN9G5JysEyuRvnrYL/mLYVG1MUSsPIsPl8T nxafZtXcjsPxwKf1uMBUg50t9rWHRuocam0Y84ImAlADr3HWC+bHJ9fHPB//v7AvlQ== X-Gm-Gg: ATEYQzyyvetK1Y7ixcIptNjKiEgQrA4KMSnTR40Daq2aqZsluI9UK6UgD/ueBFrmjbz mZAKvHqDb3/ri8P9gzPTh4Md55Q7aqzo0NbHGsXkStRZnSobMv7Us69f4IiNhJhSeWp39ma6dVy Izjh04pDQiLzltAs+a4kGnvEoHBmMm0a4mFfWTzDG4OYKViPerIoLjzt6Qtpig+5rxq56UQf7U3 bzOtOvrmjtwMdZTvf03ZxlCDpYY9m9PiRuuRBDTAgppPzdpkoDxCXzYuyk+78aYmBGZ4ueVQflE f0W9S+EL3XlwsXpHvmczteSeGEzQ2/JvI4muoqibk9k41tRP0nTmboPVWznG3jHskfacQ3oR7vf 6GLxu3lXnvQnmw5rr4BHmmBNOTMbxpw0kDmlBkYc4DPKf+kGl5JR0BBgc/WZxenSNIfiHUQ2PTh uj9XdPxCV66pNE0oD1x6nHJKK25X5wb7Xcyr3YEvYcAIFeiIDq2gZIMbDJJR8PsStLjAWrR47VB QYxZk+x48B3FV8= X-Received: by 2002:a05:600c:818e:b0:480:1b65:b741 with SMTP id 5b1f17b1804b1-483c9ba3aadmr290397015e9.15.1772538869902; Tue, 03 Mar 2026 03:54:29 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 12:54:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 2/2] xenpm: Add get-core-temp subcommand To: Teddy Astie , Anthony PERARD Cc: Oleksii Kurochko , Community Manager , xen-devel@lists.xenproject.org References: <7380cf63-e9ac-4df9-9633-c26f9de0027a@suse.com> <4c18413b-6296-4a30-bbec-561f7b802cbc@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4c18413b-6296-4a30-bbec-561f7b802cbc@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.03.2026 11:50, Teddy Astie wrote: > Le 02/03/2026 à 17:52, Jan Beulich a écrit : >> On 27.02.2026 18:00, Teddy Astie wrote: >>> @@ -1354,6 +1358,127 @@ void enable_turbo_mode(int argc, char *argv[]) >>> errno, strerror(errno)); >>> } >>> >>> +static int fetch_dts_temp(xc_interface *xch, uint32_t cpu, bool package, int *temp) >>> +{ >>> + xc_resource_entry_t entries[] = { >>> + { .idx = package ? MSR_PACKAGE_THERM_STATUS : MSR_IA32_THERM_STATUS }, >>> + { .idx = MSR_TEMPERATURE_TARGET }, >>> + }; >>> + struct xc_resource_op ops = { >>> + .cpu = cpu, >>> + .entries = entries, >>> + .nr_entries = ARRAY_SIZE(entries), >>> + }; >>> + int tjmax; >>> + >>> + int ret = xc_resource_op(xch, 1, &ops); >>> + >>> + switch ( ret ) >>> + { >>> + case 0: >>> + /* This CPU isn't online or can't query this MSR */ >>> + return -1; >> >> Further down at the callers of this function you assume errno is set whenever >> an error indication is returned. As xc_resource_op() didn't fail, you will >> need to synthesize an errno value here. >> > > ah yes indeed > >>> +static void get_core_temp(int argc, char *argv[]) >>> +{ >>> + int temp = -1, cpu = -1; >>> + unsigned int socket; >>> + bool has_data = false; >>> + >>> + if ( argc > 0 ) >>> + parse_cpuid(argv[0], &cpu); >>> + >>> + if ( cpu != -1 ) >>> + { >>> + if ( !fetch_dts_temp(xc_handle, cpu, false, &temp) ) >>> + printf("CPU%d: %d°C\n", cpu, temp); >>> + else >>> + { >>> + fprintf(stderr, "Unable to fetch temperature (%d - %s)\n", >>> + errno, strerror(errno)); >>> + printf("No data\n"); >>> + exit(ENODATA); >> >> In how far is using errno values as arguments to exit() a useful thing? (I >> think you had it like this before, and I merely forgot to ask.) Yes, I can >> see the tool using a number of exit(EINVAL), but I don't understand those >> either. This way you can't even document easily what particular exit codes >> mean, as the errno values may vary across OSes. >> > > I reused the exit(...) pattern used in xenpm, but I'm also fine by > returning simpler errors (like exit(1) or exit(EXIT_FAILURE)). Anthony, can you please suggest which one better fits the toolstack as a whole? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 12:23:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 12:23:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244686.1544072 (Exim 4.92) (envelope-from ) id 1vxOn1-0006rR-Os; Tue, 03 Mar 2026 12:23:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244686.1544072; Tue, 03 Mar 2026 12:23:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxOn1-0006rK-Lm; Tue, 03 Mar 2026 12:23:51 +0000 Received: by outflank-mailman (input) for mailman id 1244686; Tue, 03 Mar 2026 12:23:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxOn0-0006rE-FV for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 12:23:50 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d0b6dbf6-16fb-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 13:23:42 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4833115090dso57890925e9.3 for ; Tue, 03 Mar 2026 04:23:42 -0800 (PST) Received: from [10.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-485135d4228sm18463455e9.30.2026.03.03.04.23.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 04:23:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0b6dbf6-16fb-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772540621; x=1773145421; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=wrtzYQRA1AG3GXiJ2C5lpnR+bDdEvX3UQGRRP/xfbFE=; b=cve/GfX2nKmwCQmwjPD0xT6E4rzR2kK48Cd1uOAMwPcDhkNa7rueZ7Sj6nqVTJ0Vkd wgw/aCSCz3au9CXasx2D630mWxzV7NTHNv+APgIM/dNTthkMC/CbOqpHww744y9FUMFL qyR3R5BrcznIQ5YqUKXPCkRw9iDvMPBMbplh9N+vfxw0H+LqWBYhIcf5pa15u+WdeSWh lp5K6yZ2ymAuHQmVazEHKXR8Ep1mi0dHMJSFJeaRfgufJL/sJoJ850ZM7W8QvVc4aMFP he2Tcy++H8Y4bexWRleWIJ0fYyCUAw9dN23FXMF8vl8f910GmXMuKdbzObCat67+AJBt 7s9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772540621; x=1773145421; h=content-transfer-encoding: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; bh=wrtzYQRA1AG3GXiJ2C5lpnR+bDdEvX3UQGRRP/xfbFE=; b=OAl9Xc0NRo/ZT7XFEibMIlYZslepKFwUXl2/Mu8NERIJKyHcGJA8tl3+AKrUQmXlXi Lr672TPmgvIREdqinIkkVJz11U+ksnNIvWyu8M/KXF6bcu3M//lM06ZBK8imoOfDxl2M dfQ5S30PeYZzvGKuXonGTbTj81NTOMl2ublEfV29q3qUFCRvT75uvcBRb+hrZPfpB+Zp tapcuZ2V5vQvvTzosg4EIktPJjTSRGeOSB6ltSNTfEdTTpYEX/6dFzRhDGrMjVXM8YzD 11h8q3WL8SRRKCK23cqaOwtefGW/mr+IpreA0RsR2ATi1x7k0t4mo2VESv65J4ga5tla NXWw== X-Forwarded-Encrypted: i=1; AJvYcCWxxl0z6+F1OU0KMEPWJUZekLK1g7ZE0hcgVZ4KBr9zNHxqdymAcvt9Yq6vtc+Nco9Ck2nl5my/qjU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxasKUhldeKE5TPw+PcfRH77Muct1tYVaeuhLz4mhO84yDlKJo1 trTls6w0PujCpT+fuVX75tXaq8F/rf5bVbPPFloaC1JvIdyIESVmUZY0OH0oTDH4fg== X-Gm-Gg: ATEYQzxSKP1Vs6yHx5ZZ40L2Fq6NZhNCN0JSkQYCn7liYPrEz2Ud7/wmUwX+BW0Bpwg iO7PU7LCdcok8qmgu9j1eha3U/rpDBOcGzZsToZE4p1YFQG+y2b/g71Ssh9dblGXk5iHWW7OieK OEyS0nQA+N2rQLu8zmUi7Fg5VqFM67vxmwazv0MD/TOM2QD3SOYUDr8h4gW7We5Xh3NQ0cb/A+X I3kktbW4Ct2gGlK8Ex99HLmo43LansirgOMAr0OuqRJgCyK5xTOMMURekulGxeXhKv7kCho/h3a MjfnoRDju8/qCB9+MKASOLn7Fd3kqb+23IHEiycxCm2kBNYSmTjikBVZutub17E3v1h2qIDfj9v ZyM39pcjUbdzJEN5mX+VTlHSEOUpYs6X84EFHlH5EeSfj88qjNHTUk4VRNmw3sGAslfx750rn9S 50eNc/HP/Tb0f0fkunat1l29q9i3s/3H8VE+ATnXvI42+jki0Wr0ukFTTMCT6rPBUmp48F18DIV rysJi1vmJNJsUE= X-Received: by 2002:a05:600c:3486:b0:480:3a72:524a with SMTP id 5b1f17b1804b1-483c9bed89emr316225055e9.19.1772540621422; Tue, 03 Mar 2026 04:23:41 -0800 (PST) Message-ID: <4b67f8cb-43d4-4f18-b2b6-156e21330887@suse.com> Date: Tue, 3 Mar 2026 13:23:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 12:51, Oleksii Kurochko wrote: > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -2,9 +2,56 @@ > > #include > #include > +#include > #include > #include > > +#include > +#include > + > +struct csr_masks { > + register_t hedeleg; > + register_t henvcfg; > + register_t hideleg; > + register_t hstateen0; > + > + struct { > + register_t hstateen0; > + } ro_one; > +}; > + > +static struct csr_masks __ro_after_init csr_masks; > + > +void __init init_csr_masks(void) > +{ > + /* > + * The mask specifies the bits that may be safely modified without > + * causing side effects. > + * > + * For example, registers such as henvcfg or hstateen0 contain WPRI > + * fields that must be preserved. Any write to the full register must > + * therefore retain the original values of those fields. > + */ > +#define INIT_CSR_MASK(csr, field, mask) do { \ > + old = csr_read(CSR_##csr); \ > + csr_write(CSR_##csr, (old & ~(mask)) | (mask)); \ I (now) agree csr_swap() can't be used here, but isn't the above old = csr_read_set(CSR_##csr, mask); ? > + csr_masks.field = csr_swap(CSR_##csr, old); \ > + } while (0) > + > + register_t old; Since the macro uses the variable, this decl may better move up. > + INIT_CSR_MASK(HEDELEG, hedeleg, ULONG_MAX); > + INIT_CSR_MASK(HIDELEG, hideleg, ULONG_MAX); > + > + INIT_CSR_MASK(HENVCFG, henvcfg, _UL(0xE0000003000000FF)); This raw hex number (also the other one below) isn't quite nice. Can we have a #define for this, please? It doesn't need to live in a header file if it's not going to be used anywhere else. > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + { > + INIT_CSR_MASK(HSTATEEN0, hstateen0, _UL(0xDE00000000000007)); > + csr_masks.ro_one.hstateen0 = old; What guarantees that only r/o-one bits are set in the incoming hstateen0? I can't help thinking that to determine those bits you want to use csr_read_clear() (or csr_clear()). > + } #undef INIT_CSR_MASK Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 12:25:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 12:25:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244694.1544081 (Exim 4.92) (envelope-from ) id 1vxOob-0007NW-1w; Tue, 03 Mar 2026 12:25:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244694.1544081; Tue, 03 Mar 2026 12:25:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxOoa-0007NP-Va; Tue, 03 Mar 2026 12:25:28 +0000 Received: by outflank-mailman (input) for mailman id 1244694; Tue, 03 Mar 2026 12:25:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxOoZ-0007N0-SX for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 12:25:27 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0e521b5b-16fc-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 13:25:25 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439b611274bso1447805f8f.3 for ; Tue, 03 Mar 2026 04:25:25 -0800 (PST) Received: from [10.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-439b59723fesm15659360f8f.38.2026.03.03.04.25.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 04:25:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0e521b5b-16fc-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772540725; x=1773145525; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=glQI9NyYmvZoatxQQXBPml8NKmzywG1lmIdrGzxSNlo=; b=AXF1LHHHyKrQQ93+vKbG5+9WJNVaHl8IyGXKPKCapPpalU5mF6v09wtShr3YIMQwIA Kyu8r9EUhQVDKDTZ3X4Vg97QFvwa2e2hvA/whFog9mXfebg5MNt7scQvaeS+xJMhB4uN 8F3DV8iqPLwJwldrNHzOCUyKnmc7tj5EU3aTiJSKtvBoYDwFjzFprNb5auDGmqIGyd+Z DnqyoQZ0fBGsCHM55g2SXNkPczabfCLiAF5WQ6IZBr0DbRRDRDk3IuUMSMFdPsWdZrt+ 0wJgnJQDA58A+X1Je07C+XsBrvrwS9rJ6i9S/hN8N3ZQaubk53Y70kwYP/nNFsOUw5qi UptQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772540725; x=1773145525; h=content-transfer-encoding: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; bh=glQI9NyYmvZoatxQQXBPml8NKmzywG1lmIdrGzxSNlo=; b=LfCbCVamSfxc6YRXvBwpDKfxjXKtDGuii6024srlPLMuaatp1cdZ4dyzwKo0L0Seny YTMwmU77UYV+TIVJCOuSHwDrZdmOL1RX8kFtUIV37co7izeyzy7FOdM1pmDjbCfmCadu dRVkEWhAAUjy19iBF0KB97Shjj7LKSmaRYAAmkOepgd+XT9RqtahAhCXLhM3sltL6s6v STsah4p4bFtrQBhpqhFbLN1pD3LnNOeIZtqVx6ehf/EjqHpOtG/fjzsE2w5z72vJkJIM 8P0RqPn6mvqk0d7C39UEocn9HIghUUKnQH+/WX9ZWYzgKkMroGBh7Po7PtEd4OlIYDFi WYAg== X-Forwarded-Encrypted: i=1; AJvYcCUTaxPwKPiythX5wB9XViJxWRmVkPU/ONBIMyrhkcsfSFWFJHQrYdxyKJGNAiGuiiW0kQk1q9BdXzk=@lists.xenproject.org X-Gm-Message-State: AOJu0YwcgB9APoC9hYYbKfQVHSWUiMGMD05iPhym/ynvZRnQkSFNx0NV BJGQllOVYvALfc9w2zyDljV6RI0M1ba8Cfavc7ty0GPB111UqCYio/wk+knrKAZDLw== X-Gm-Gg: ATEYQzxGS1Novu3vD0kxa1Up/qGqqXUPDjqu8r5ZsJKS1kmEO5Y8hsZEkDsIco6QiBT zSKv4vzKOJq4n0px49Dktw5Zd2ZI2Au/CFxGkxqnRb0qpK0Lho+rMbT2EOuLmPdWkAzWKEpR/gZ xaMb4K46Ke1ubMjSVvzKJC5/kBtxnOsiNNm+b1eNwsxQLqrbVp6ZpqF6wIGlkl7kWhN3JTfs0nV 5GOxbiHCYovaZR4zWVmDejB4FCXR5NayeK0vP7Kbaf7x47/r3duVpWaQxxR6r1lWQT5Z3tyzROs e6ABiJbEp/w1FrgYefFcJa95SwA0EhqkuSHyLUDICdkS/1y/pl/VIiP6GzUU6kJHhE7XUUhmczK OIwzrL9SPVeH49Z/62urp/AZATQbUOcr0VMjidwYHPgmDpZqIFINaAMd3KC16i6ZVlobadVZjbA pg4KTELal18i8OnnPBRm5kzgw2X9RF4LNkxYL0T0S99QhMvutQfW5GG05cQ7fetQ4R+8uFI1v38 bVQN8z2yZev+8Q= X-Received: by 2002:a05:600c:8106:b0:47e:e8de:7420 with SMTP id 5b1f17b1804b1-483c9c1d4bamr255211005e9.22.1772540724801; Tue, 03 Mar 2026 04:25:24 -0800 (PST) Message-ID: <1607bd00-99a3-4601-a995-e038b4e02d4a@suse.com> Date: Tue, 3 Mar 2026 13:25:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 02/14] xen/riscv: implement vcpu_csr_init() To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <9694ff5787d5f162581a16f0974ac9a55c538019.1772016457.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <9694ff5787d5f162581a16f0974ac9a55c538019.1772016457.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 12:51, Oleksii Kurochko wrote: > Introduce vcpu_csr_init() to initialise hypervisor CSRs that control > vCPU execution and virtualization behaviour before the vCPU is first > scheduled. > The function configures trap and interrupt delegation to VS-mode by > setting the appropriate bits in the hedeleg and hideleg registers, > initializes hstatus so that execution enters VS-mode when control is > passed to the guest, and restricts guest access to hardware performance > counters by initializing hcounteren, as unrestricted access would > require additional handling in Xen. > When the Smstateen and SSAIA extensions are available, access to AIA > CSRs and IMSIC guest interrupt files is enabled by setting the > corresponding bits in hstateen0, avoiding unnecessary traps into Xen > (note that SVSLCT(Supervisor Virtual Select) name is used intead of > CSRIND as OpenSBI uses such name and riscv_encoding.h is mostly based > on it). > If the Svpbmt extension is supported, the PBMTE bit is set in > henvcfg to allow its use for VS-stage address translation. Guest > access to the ENVCFG CSR is also enabled by setting ENVCFG bit in > hstateen0, as a guest may need to control certain characteristics of > the U-mode (VU-mode when V=1) execution environment. > > For CSRs that may contain read-only bits (e.g. hedeleg, hideleg, > hstateen0), to the written value a correspondent mask is applied to > avoid divergence between the software state and the actual CSR > contents. > > As hstatus is not part of struct arch_vcpu (it already resides in > struct cpu_user_regs), introduce vcpu_guest_cpu_user_regs() to provide > a uniform way to access hstatus and other guest CPU user registers. > > This establishes a consistent and well-defined initial CSR state for > vCPUs prior to their first context switch. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Mar 03 12:48:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 12:48:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244709.1544091 (Exim 4.92) (envelope-from ) id 1vxPB7-0002Cz-P4; Tue, 03 Mar 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 1244709.1544091; Tue, 03 Mar 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 ) id 1vxPB7-0002Cs-MY; Tue, 03 Mar 2026 12:48:45 +0000 Received: by outflank-mailman (input) for mailman id 1244709; Tue, 03 Mar 2026 12:48:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPB6-0002Ck-0z for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 12:48:44 +0000 Received: from sender4-of-o51.zoho.com (sender4-of-o51.zoho.com [136.143.188.51]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4d6b52c3-16ff-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 13:48:41 +0100 (CET) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1772542104120512.1902581757903; Tue, 3 Mar 2026 04:48:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4d6b52c3-16ff-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1772542111; cv=none; d=zohomail.com; s=zohoarc; b=kSootYNw6kLlF3qln49RAi0hJOcu5bDganrft/zuENJwNNugvywqjtfRLt6Ux44VSnt85UAMVlKNytgGax+AfNut9/7QZiFTyry/8RTeMjmIKjPMAUUZj2Us2wVGQtrGqTSZFVhqGYuzYFZEwwP3du8H/ZanbvEanJ0+hB+UC1I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772542111; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=gzfEYy7bTKSUp73SM9YS+gSsfJ+9m4GvrnOgrRT6tQU=; b=MjcdfKVw1PYICKdwW2GlcC5bKoy114/M/D+efHAIwIFD7tnIlNasY9uES9igeqiOgem4QMHBWBhiDZPJTYb9VGtt+Hdaq79qOEzhJtufbKk4eirkkmvoPE9Ira5TGn4PzIMU7qCpp/OcTm3e3+MCyYWmesUWboctjTGHI8Di/Ik= 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= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1772542111; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=gzfEYy7bTKSUp73SM9YS+gSsfJ+9m4GvrnOgrRT6tQU=; b=fiVA6q5eTqjiuj9ZP/aXxooQkAhzFECrenBzXXO5OL1OdlOMdE19JEHBVMhPFwam EfTOXEAUQhoYBaNAThZJ5KXOwdES9DQVwB3fs/0I6BLsWs0fu4L67S4bvwLx4VJFNbS lnrSVbf+1ZNL/Wz0pdC+5at58RwImOW8b/ipjlu8= Date: Tue, 03 Mar 2026 07:48:23 -0500 From: Daniel Smith To: "Jan Beulich" Cc: "Andrew Cooper" , =?UTF-8?Q?=22Roger_Pau_Monn=C3=A9=22?= , "Stefano Stabellini" , "Julien Grall" , "Volodymyr Babchuk" , "Bertrand Marquis" , "Michal Orzel" , "consulting @ bugseng . com" , "Nicola Vetrini" , "Xen-devel" , "Christopher Clark" Message-ID: <19cb3be119e.107e51fe338081.8287475850457408935@apertussolutions.com> In-Reply-To: References: <20260220214653.3497384-1-andrew.cooper3@citrix.com> <20260220214653.3497384-4-andrew.cooper3@citrix.com> Subject: Re: [PATCH 03/12] xen/argo: Fix MISRA violations around function parameters MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail From: Jan Beulich To: "Andrew Cooper" Cc: "Roger Pau Monn=C3=A9", "Stefano Stabellini", "Julien Grall", "Volodymyr Babchuk", "Bertrand Marquis", "M= ichal Orzel", "consulting @ bugseng . com", "Nicola Vetrini", "Xen-devel", "Christopher Clark", "Daniel P. Smith" Date: Mon, 23 Feb 2026 04:15:55 -0500 Subject: Re: [PATCH 03/12] xen/argo: Fix MISRA violations around function p= arameters > On 20.02.2026 22:46, Andrew Cooper wrote:=20 > > For the ARM build only, Eclair reports a R8.4 violation because do_arg= o_op()=20 > > cannot see its declaration. This means that x86 is picking hypercall-= defs.h=20 > > up transitively while ARM is not. Include xen/hypercall.h explicitly.= =20 > >=20 > > Eclair also reports a R8.3 violation because of arg3 and arg4 differin= g in=20 > > name with a raw_ prefix. Because hypercall-defs.h generates both do_a= rgo_op()=20 > > and compat_argo_op() from a single description, it's not possible to s= imply=20 > > rename to raw_ in the declaration, as that would force doing the same = rename=20 > > in compat_argo_op().=20 > >=20 > > In do_argo_op(), drop the split parameter handling, and perform the 32= bit=20 > > range check via an explicit cast. While adjusting the surrounding log= ic, drop=20 > > unnecessary casts to void * for already pointer arguments in argo_prin= tk().=20 > >=20 > > No functional change.=20 > >=20 > > Signed-off-by: Andrew Cooper =20 > =20 > Reviewed-by: Jan Beulich =20 > =20 Reviewed-by: Daniel P. Smith From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:20:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:20:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244729.1544101 (Exim 4.92) (envelope-from ) id 1vxPfx-0007Gf-5d; Tue, 03 Mar 2026 13:20:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244729.1544101; Tue, 03 Mar 2026 13:20:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPfx-0007GY-2S; Tue, 03 Mar 2026 13:20:37 +0000 Received: by outflank-mailman (input) for mailman id 1244729; Tue, 03 Mar 2026 13:20:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPfv-0007GS-QU for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:20:35 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c21ca7d7-1703-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 14:20:33 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-65f812e0d93so8807671a12.2 for ; Tue, 03 Mar 2026 05:20:33 -0800 (PST) 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-65fac06e3fasm4361347a12.25.2026.03.03.05.20.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 05:20:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c21ca7d7-1703-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772544033; x=1773148833; darn=lists.xenproject.org; h=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; bh=IyHTfy4ChAtQUQKNdGEJw0gkZCQ6Cw6CCEdl2hNEQNA=; b=AkE0enH2jpCGAiIezcAWlmjP1muo09Fj1gwoPaIw1o7OOGeWvbhkFFZuv7aiZGGS+H pRTkgz6ISQeGgc9VTH0Try/SZc1yo5BQZNYDIcdlgsstCGd1KA++mCox2Nar3Xe0u+px YrRk1HA31l3b0MO5ggFEBDPixO+9QUe637eAAAxAQk17c86PA5HGvFZWYFv7f+ORTked SDLzFKjuMVQx9vjQ8PphioWq3sOWGw+HRntnSIOPwUm73JuM4pI46KuObqVY6MZW/aiy CEeAN3kGrvugOs2uYCD0hZzyiJWlBT96fE6UFQ54wU51QhTJCEbp1+0bxod9s7ntbygo Wcug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772544033; x=1773148833; h=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; bh=IyHTfy4ChAtQUQKNdGEJw0gkZCQ6Cw6CCEdl2hNEQNA=; b=pXJxAGzPiDNFGj3xpZ4SM1DmtC1xTQlHfDrSzlBdaQZTiwEpGuYoU+RKZVySN+onfb fspYbfhhotsPjDVIMjNjb1LUYYsm5+hdMBb71vGBcmS7hxNov7bY01e//6kDv1PFQSyb Q5PF3Loh6jgGVVwaZUn8budU+QXDzoioD7r7tqOWonBE6xU8LWHaOC/0zu3JyJLAKlCE Y847QqChPcdKrNqg4RqGZnghVznMrm1yg1Vzn5my3zG4YWD/dW2OSvRjqyjEVUsix1j3 M5klPzoVvwQdfuLHQ4qT5HO1YD8d4OmAnVCB4UvwHZ2hTnsUGWwi8pS8/01bTN7SisUN /A/A== X-Forwarded-Encrypted: i=1; AJvYcCUTi1/D0+4HXDuLn9qDIeWKq1lRUTWzj+xCZI8dHvbRqpRYaNjfcTetnbxwYZx8SrR+4QXzV+dNiho=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx5xl3+gEe4GcZHy91FZmQidDPGhCeqpLj0ON20ei+kznrVsrSR GBLAmUX7qhyMnvPRKsDp4bY1L7hujWF6VYrWs1v38HoyTzgtH8D8+h0iueWBlCg11KI= X-Gm-Gg: ATEYQzzsCjaIPMLBcBUuq1rge5L5HdLGpmHMX/FutALzRvpRnyZjYiXd4GRGRExBirO 3mZXa3qpbsSSZP+mf+GMgN8Qc7j79GNx7lhKfiSoZE38uE65rj245GOmmonNOKHZQ62l6ckyUt1 r0jT2d+9+5ReBJstje9g06ySgTrN1YDpieQz84JH4pEF1PqcVXvaRmmwAytI/ofE9hvlNVknYM7 UioPlRaNCHreFUhq2QlWlO5DagNcEvHQoz8hY57/d9437Sb+sksA9wBeIcRwb0AYIt1tf1uh5fC BlJI7Ovlsy/BA1cLhh8PEVndcEugpWoN4JOONunhSbaGtMC94UQSg7I6m3RswOCH6L6gxpCmval GnrNEwq1T6yY2mify31W4Gwo0yIl+hsi3/Sx6YzPJlNUPtwLSY06tPdCFZ+qiLNOKRuDP32GgO0 usLuAouCSGC12iZv95xVPU/NtXhq8yNrpstG96Qt69knl852i8iUETSs1rTQHZtaqdiYRCOvAmD 7w34U1AAFIh2VCTRaee7GPgM7+WDcSi+lnxpjtJu5GVxieV3SH/VdWcfwwthuRx X-Received: by 2002:a05:6402:1441:b0:65b:93ec:597a with SMTP id 4fb4d7f45d1cf-65fddaf6c63mr10019002a12.19.1772544032837; Tue, 03 Mar 2026 05:20:32 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 14:20:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/xen: Build identity mapping page tables dynamically for XENPV To: Hou Wenlong , linux-kernel@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Boris Ostrovsky , Ard Biesheuvel , Thomas Huth , Kiryl Shutsemau , Uros Bizjak , Brian Gerst , xen-devel@lists.xenproject.org References: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> Content-Language: en-US From: Juergen Gross 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: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------dFm50epvwnn00HLquSsmw60X" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------dFm50epvwnn00HLquSsmw60X Content-Type: multipart/mixed; boundary="------------SGsrkd5BzX8g0Fguu5dFgezN"; protected-headers="v1" From: Juergen Gross To: Hou Wenlong , linux-kernel@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Boris Ostrovsky , Ard Biesheuvel , Thomas Huth , Kiryl Shutsemau , Uros Bizjak , Brian Gerst , xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH] x86/xen: Build identity mapping page tables dynamically for XENPV References: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> In-Reply-To: <453981eae7e8158307f971d1632d5023adbe03c3.1769074722.git.houwenlong.hwl@antgroup.com> --------------SGsrkd5BzX8g0Fguu5dFgezN Content-Type: multipart/mixed; boundary="------------iStjZp5Q40kns7twP9sTAhHN" --------------iStjZp5Q40kns7twP9sTAhHN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjIuMDEuMjYgMTE6MDYsIEhvdSBXZW5sb25nIHdyb3RlOg0KPiBBZnRlciBjb21taXQg NDdmZmUwNTc4YWVlICgieDg2L3B2aDogQWRkIDY0Yml0IHJlbG9jYXRpb24gcGFnZSB0YWJs ZXMiKSwNCj4gdGhlIFBWSCBlbnRyeSB1c2VzIGEgbmV3IHNldCBvZiBwYWdlIHRhYmxlcyBp bnN0ZWFkIG9mIHRoZQ0KPiBwcmVjb25zdHJ1Y3RlZCBwYWdlIHRhYmxlcyBpbiBoZWFkNjQu Uy4gU2luY2UgdGhvc2UgcHJlY29uc3RydWN0ZWQgcGFnZQ0KPiB0YWJsZXMgYXJlIG9ubHkg dXNlZCBpbiBYRU5QViBub3cgYW5kIFhFTlBWIGRvZXMgbm90IGFjdHVhbGx5IG5lZWQgdGhl DQo+IHByZWNvbnN0cnVjdGVkIGlkZW50aXR5IHBhZ2UgdGFibGVzIGRpcmVjdGx5LCB0aGV5 IGNhbiBiZSBmaWxsZWQgaW4NCj4geGVuX3NldHVwX2tlcm5lbF9wYWdldGFibGUoKS4gVGhl cmVmb3JlLCBidWlsZCB0aGUgaWRlbnRpdHkgbWFwcGluZyBwYWdlDQo+IHRhYmxlIGR5bmFt aWNhbGx5IHRvIHJlbW92ZSB0aGUgcHJlY29uc3RydWN0ZWQgcGFnZSB0YWJsZXMgYW5kIG1h a2UgdGhlDQo+IGNvZGUgY2xlYW5lci4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IEhvdSBXZW5s b25nIDxob3V3ZW5sb25nLmh3bEBhbnRncm91cC5jb20+DQoNClJldmlld2VkLWJ5OiBKdWVy Z2VuIEdyb3NzIDxqZ3Jvc3NAc3VzZS5jb20+DQoNCkknbGwgdGFrZSB0aGlzIG9uZSB2aWEg dGhlIFhlbiB0cmVlLg0KDQoNCkp1ZXJnZW4NCg== --------------iStjZp5Q40kns7twP9sTAhHN 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----- --------------iStjZp5Q40kns7twP9sTAhHN-- --------------SGsrkd5BzX8g0Fguu5dFgezN-- --------------dFm50epvwnn00HLquSsmw60X 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/Ey8FAmmm4B8FAwAAAAAACgkQsN6d1ii/Ey9u Fgf/Yiro9lkd7nF1IFHHgUphBmzAbgER5ArgkRnzF55OSXKc+z0T/Su7v1wlNDF3GGyMCti0FXl9 7UmNTXtUi7SBEfvtGDHVpzblInfXbTs4iluL2azKmMEwq3OlBhEGLvH3bX7+sEtDfgb700BfeWYQ 1bBcTs4r2+pDtWJnkQOZtUMQ2w8ennd3NPUjeBZb3qaUgBdCXRgt96J1XosvzhAgvhlw249RmbdN dGJ49ebpe1YgOD8oJwnTe7v1IS+Q+V6yBEcsJxGwW9fTo4xYgf6nJSGy1kNtnZ7rSqUq50i1ahpC twMnMLZpymY4PVZSRJ9Q5+MCR4nxzm8jAo0rfFJLRg== =r39c -----END PGP SIGNATURE----- --------------dFm50epvwnn00HLquSsmw60X-- From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:23:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:23:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244739.1544112 (Exim 4.92) (envelope-from ) id 1vxPjA-0007qS-OB; Tue, 03 Mar 2026 13:23:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244739.1544112; Tue, 03 Mar 2026 13:23:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPjA-0007qL-LY; Tue, 03 Mar 2026 13:23:56 +0000 Received: by outflank-mailman (input) for mailman id 1244739; Tue, 03 Mar 2026 13:23:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPj9-0007qF-L3 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:23:55 +0000 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [2a00:1450:4864:20::62d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 398370cd-1704-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 14:23:53 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-b8fb3c4bbc4so846592266b.2 for ; Tue, 03 Mar 2026 05:23:54 -0800 (PST) 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-b935ae612f7sm611611366b.36.2026.03.03.05.23.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 05:23:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 398370cd-1704-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772544233; x=1773149033; darn=lists.xenproject.org; h=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; bh=D4jVGREkfXDvFUc3S6Y3ejso4Gwgqlhk3ArmnBljpb8=; b=LO0zqKw8uIZJk0tDJwxFUZLFhkyJ6PhDuUcWQtHiJsODBGQpYxH8CraiJUbfVl4ysW W4uxBXMIBlgM0yN/ccG1GjMdcyKwEVfrDhID4H40pXAgip6pN2hBhHh5LBeyfkMmVWfK vGYPyG+Jqa/APcLsa5wKTikaKSb2nukQ31IZbqGp3THZOfy0Agi4Ce65p8FPS3203bv5 XDuYMyVctOBIKwJm03zwaSGjWLBPyI4B2TJGtdV3wA68T3MTOIXKxEQJC8/35x6b24i8 nZwIOF5nvU4tTmDCrppAaQqyZx6oYOmSif9K9CHu0Lzw8NyWk2DFyCUWp0B/5WCI4vw8 8qhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772544233; x=1773149033; h=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; bh=D4jVGREkfXDvFUc3S6Y3ejso4Gwgqlhk3ArmnBljpb8=; b=W3sVjtwlUXlhBCw3eSXAhDOunv+BlEDPximt9luk/vAlaKGj1UeRYREGBzsmrVpgGw YH5xES9bBLuqrqe6mzIIsnjyE7GaAptNg+DpyH2Whd/b5UquTAu9d6leq4j0aSr8kV39 FelTPJRDZ2F06LtuOOMAP7cnoJtRazi/3I6Cpv5nCRDRixgfkUPhmTKMYMBlvs3djFXs CZW4Qa2x+5QnrOJMz9PKOXGfzf/tIgbzOJW3Ewd3kkPlRViddf9QULCP4sq3VV+SqoFF HimxRK+qLNJBaOLfK7jEsyuav/wrWzncADUNO0d4Mh3ZFHRhFwIhDol8FnIU/Vb0MPrQ 9OcA== X-Forwarded-Encrypted: i=1; AJvYcCWWXugF6iNi8yQvOIlJU6l+fAZDmHa48ST6KU/oorIYYoR7ToO44fXPsuYbQTFpqUw39LyOlB0yM4E=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz7KMW45cBCj8be5V6fhp5wQQBakPh1Ce/TVnGRF1bCB1vk1a3c Nitm/ic0LlcVLmeSESI/J1FbElrQpvtVos/ffvYxQkkXg8t83fhO8jRouLdzwcRUigE= X-Gm-Gg: ATEYQzxizlXi2wSAy6qXamBvQzqGREcoRkXMvTRvAjeelN0JyERKmFR9cODABy4U/Nt 1IQUf/7JbJglqpe9L03piWmN4Im9z0yugsn6bVr+A3odPVPWsQOL898sSlatk1Y3eR9GBrGTCq5 svKM7HSSGig/u69xVsEq6v1X79Y8mepKitwv5G8cxkmnbzb0J8z6LRUw5lTQksAGAR2bPpp2OZ4 ETuWJMW8rwO/zSLJ7Xj3RTOcMiEdJOJ1A1XbNh8/eeOSYCqYn3vgykr8QYdrXDZw+nCkQGf6D8q OT4cjXBFCmxOAYxTLMtjP/M4AsKsr35lBP5S3rj7NCh8vaFfu3eOLXx9E3HbUTbq9OgDW6vyU/c KYzJrYooO7HJgI2WOPWs7TMsIeWdxDUeN7w6LDyNqzqbEKja3SXKbctFM4qYxqpD8zLQNkA5ahO /qKFLTF6LVlFjyVMoCOPIeiuVv/yUS3dsJb4yatqaKEywJK2cn06qqQoZrDycVDIjid+EYrKGJ/ XfHnjnXWYHf6fnYzzYG1DjaXqDmtgHGjkIdUr4aYc6X81hq0sKkhOeVzTWw2w8c X-Received: by 2002:a17:906:6a14:b0:b88:6542:86a0 with SMTP id a640c23a62f3a-b9376594b7emr1067333866b.54.1772544233283; Tue, 03 Mar 2026 05:23:53 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 14:23:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/xen: update outdated comment To: kexinsun Cc: boris.ostrovsky@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, julia.lawall@inria.fr, xutong.ma@inria.fr, yunbolyu@smu.edu.sg, ratnadiraw@smu.edu.sg References: <20260224022424.1718-1-kexinsun@smail.nju.edu.cn> Content-Language: en-US From: Juergen Gross 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: <20260224022424.1718-1-kexinsun@smail.nju.edu.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------PbxofBzZ6nVHpzmTLSw0E58S" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------PbxofBzZ6nVHpzmTLSw0E58S Content-Type: multipart/mixed; boundary="------------jRByJlNJhbPitDNg6CPM8PKG"; protected-headers="v1" From: Juergen Gross To: kexinsun Cc: boris.ostrovsky@oracle.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, julia.lawall@inria.fr, xutong.ma@inria.fr, yunbolyu@smu.edu.sg, ratnadiraw@smu.edu.sg Message-ID: Subject: Re: [PATCH] x86/xen: update outdated comment References: <20260224022424.1718-1-kexinsun@smail.nju.edu.cn> In-Reply-To: <20260224022424.1718-1-kexinsun@smail.nju.edu.cn> --------------jRByJlNJhbPitDNg6CPM8PKG Content-Type: multipart/mixed; boundary="------------xV60sHF8B10z2V0QneIrwen0" --------------xV60sHF8B10z2V0QneIrwen0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjQuMDIuMjYgMDM6MjQsIGtleGluc3VuIHdyb3RlOg0KPiBUaGUgZnVuY3Rpb24geGVu X2ZsdXNoX3RsYl9vdGhlcnMoKSB3YXMgcmVuYW1lZCB4ZW5fZmx1c2hfdGxiX211bHRpKCkN Cj4gYnkgY29tbWl0IDRjZTk0ZWFiYWMxNiAoIng4Ni9tbS90bGI6IEZsdXNoIHJlbW90ZSBh bmQgbG9jYWwgVExCcw0KPiBjb25jdXJyZW50bHkiKS4gIFVwZGF0ZSB0aGUgY29tbWVudCBh Y2NvcmRpbmdseS4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IGtleGluc3VuIDxrZXhpbnN1bkBz bWFpbC5uanUuZWR1LmNuPg0KDQpSZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3Nz QHN1c2UuY29tPg0KDQoNCkp1ZXJnZW4NCg== --------------xV60sHF8B10z2V0QneIrwen0 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----- --------------xV60sHF8B10z2V0QneIrwen0-- --------------jRByJlNJhbPitDNg6CPM8PKG-- --------------PbxofBzZ6nVHpzmTLSw0E58S 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/Ey8FAmmm4OgFAwAAAAAACgkQsN6d1ii/Ey/c RAf+PlfQCnYZcOW1+JZipL6agNuExGtzLEhA3WiWB7N2ft+O7M+y6ztNvsDm0ZRa0+9CdfrombrW AN7P90jD4hHFcvOFVS4o9gWh4epqZ+01ybJgFCIF9MMClHYOv/idq3JhObzhhXISdehAUkJp+NZt UwecYAUg2lDf8BEhNfenLUwyc8y3O866I/JFab0lLAI195VasPmDUPLzha5bIEZogVI4se961L3Y S/aEUe/rSGXi+pU7ICkfqCjsgFEQ9f9DzVUb6p/t+liNYPBBlWMRtfWCyHeOLLH2X1UlPfn8ILz7 f+vTFSVZ3GcudXGZdDDilj5QNI8mzrzad/G22GhIhw== =txub -----END PGP SIGNATURE----- --------------PbxofBzZ6nVHpzmTLSw0E58S-- From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:31:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:31:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244752.1544122 (Exim 4.92) (envelope-from ) id 1vxPq5-00017p-E8; Tue, 03 Mar 2026 13:31:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244752.1544122; Tue, 03 Mar 2026 13: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 ) id 1vxPq5-00017i-Ay; Tue, 03 Mar 2026 13:31:05 +0000 Received: by outflank-mailman (input) for mailman id 1244752; Tue, 03 Mar 2026 13:31:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPq4-00017a-1k for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:31:04 +0000 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [2a00:1450:4864:20::636]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3886b18c-1705-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 14:31:01 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b9358dd7f79so864041366b.1 for ; Tue, 03 Mar 2026 05:31:01 -0800 (PST) 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-b935ab146bdsm591186066b.6.2026.03.03.05.31.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 05:31:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3886b18c-1705-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772544661; x=1773149461; darn=lists.xenproject.org; h=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; bh=YDqxSfaFOqi6+CSHyuKH19eODmP7e7ddf6Er21nJG6M=; b=B2KlLuxvwCiox0zi8uSEL7IHE8X4lKAw1dvxcET6ogp0bvdwYN3Q9jDz/DMKYuiL8u 3ajeCR53z1VSsY8lRr8eHmXt+KlA5LFs9fKfenfQawKfhjyEfv4qMTN1+JG5YvvL81nq ON630Bq4X4Yu+kC7RbrNfJ9JUas+UNQjx8eSZV9XV/qZWMnCOFdWHlud4sO29r1q0lRU EQpXrRz5+aoXtLRbEgMDXYVGzsfWBtr0K55LYir/3JffwBqXyL0i9L14mdH4vLYeP+nq xXK9HVc/OFFR0O4U2fdf9Uyffnh1y6lgcYKMiMQes/JrpPEApBpgXX9fX7JmmcTXiaqJ X3qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772544661; x=1773149461; h=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; bh=YDqxSfaFOqi6+CSHyuKH19eODmP7e7ddf6Er21nJG6M=; b=hKcLKyapaFukvpGOo1FpA/q0uq32cegnASA9y4zIDQFf0YFeso6qAzW3vFZ4lVAhgc 9i/LoaYb/doYvROoV+6We4L6SZcZMiDgeqkqop67QA+msgipdsSHey/dPcwcdL2Fr0Rj P/h6VLLe+sc6GRjNuaM8MRELZMjvumkhFg079BYCFtyvUes4lJXEODzgmB/pmgh93iLW RZTdPKbJlZTOxcDg9FudV4LIhS/Q3UuwHP1MEdtMh/8vGYidKnGXc3bKvchcDwpGG8sJ WpmO8u8nF5Hjn/PdFE5BQQOTUmq9xQRfXvYFIavMXq7RdeMbMQjLcOLdFnqZ8H9d6/mj tGYw== X-Forwarded-Encrypted: i=1; AJvYcCWxkS1PVEIoH0PwI+NjH18n/PQepp4xC030nVqto6HAbhTKgS0nkfYyZeZvAKpZfN4LGOtHBDaJn4U=@lists.xenproject.org X-Gm-Message-State: AOJu0YyZ9Xmx/uACCKjyAxWffLM34ztfdJYKszPvpypY3weL1k2YE8wg 8EaBtcAxo+VTWc3Ciih1/RJyqjeN8eKo45cNjMrZlzgLRITI/cfGY4CnA3FR1hdcqT0= X-Gm-Gg: ATEYQzzSXXbzqNJ8EFh9RkbU65xIiI5xFALXhRTIgs6L22Ewz8xN8MsMhe642vJEVPp oZ5u/shwgEdVaGAyiY5/T3jb+QOTOD3youg6Yp28jZlMKiFwAC18ADK0xTfabQgJ3hVOSorKUDR /ow9PLKTmEq32lXUW1k0n5qIX8JWMp6lXspey8AVs9MwAXOoFyYnWzK2+avZslrjJQB3ycKalzq vOLgyr0NXRIaVnmzjqPbZXiHpKK1DkB8l7uDD+EM4n0zcpZHws3MqnTskNbvwzk27p4r5QaWVnp Gk90j3StSi6aVF9OFf1qfVNO50FeErHubkJm7gNOijyDDo2EMl3lI7q/lpEelJcS+rkB1Va8sxo nQlLHvwZWZdIUbKkQB20M2tug1tyHFokCXfniVvP+5RKMMOSAu1TaeJCweWk5La/bFl+Ltuhg2c 5QaBVfYvY6G3Y84qersr43hskGer69faiQ8piK7zJxl3y/sGaLFFINrsXiw+xlOIWGztfuy3UVJ yPK5FcF+p91iW4L/nuCkzW/P0oGWMnSW1kojOmNjN7upFBAkeUmgQ== X-Received: by 2002:a17:907:d1d:b0:b93:5297:b3a2 with SMTP id a640c23a62f3a-b93765c5b04mr1083941466b.59.1772544660983; Tue, 03 Mar 2026 05:31:00 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 14:31:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] x86/PVH: Use boot params to pass RSDP address in start_info page To: Hou Wenlong , linux-kernel@vger.kernel.org Cc: Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , xen-devel@lists.xenproject.org References: <76675c4d49d3a8f72252076812ef8f22276230c2.1772282441.git.houwenlong.hwl@antgroup.com> Content-Language: en-US From: Juergen Gross 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: <76675c4d49d3a8f72252076812ef8f22276230c2.1772282441.git.houwenlong.hwl@antgroup.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------i2y75WnCP7J0ez480mRl2LPE" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------i2y75WnCP7J0ez480mRl2LPE Content-Type: multipart/mixed; boundary="------------nT0luGH0skdzcdB98AO3VOAz"; protected-headers="v1" From: Juergen Gross To: Hou Wenlong , linux-kernel@vger.kernel.org Cc: Boris Ostrovsky , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , xen-devel@lists.xenproject.org Message-ID: Subject: Re: [PATCH 1/2] x86/PVH: Use boot params to pass RSDP address in start_info page References: <76675c4d49d3a8f72252076812ef8f22276230c2.1772282441.git.houwenlong.hwl@antgroup.com> In-Reply-To: <76675c4d49d3a8f72252076812ef8f22276230c2.1772282441.git.houwenlong.hwl@antgroup.com> --------------nT0luGH0skdzcdB98AO3VOAz Content-Type: multipart/mixed; boundary="------------orrsVUFl5m1rKOY4H1tIeSMX" --------------orrsVUFl5m1rKOY4H1tIeSMX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDEuMDMuMjYgMDY6MDQsIEhvdSBXZW5sb25nIHdyb3RlOg0KPiBBZnRlciBjb21taXQg ZTZlMDk0ZTA1M2FmNzUgKCJ4ODYvYWNwaSwgeDg2L2Jvb3Q6IFRha2UgUlNEUCBhZGRyZXNz IGZyb20NCj4gYm9vdCBwYXJhbXMgaWYgYXZhaWxhYmxlIiksIHRoZSBSU0RQIGFkZHJlc3Mg Y2FuIGJlIHBhc3NlZCBpbiBib290DQo+IHBhcmFtcy4gVGhlcmVmb3JlLCBzdG9yZSB0aGUg UlNEUCBhZGRyZXNzIGluIHN0YXJ0X2luZm8gcGFnZSBpbnRvIGJvb3QNCj4gcGFyYW1zIGlu IHRoZSBQVkggZW50cnkgaW5zdGVhZCBvZiByZWdpc3RlcmluZyBhIGRpZmZlcmVudCBjYWxs YmFjay4NCj4gVGhpcyByZW1vdmVzIGFuIGFic29sdXRlIHJlZmVyZW5jZSBkdXJpbmcgdGhl IFBWSCBlbnRyeSBhbmQgaXMgbW9yZQ0KPiBzdGFuZGFyZGl6ZWQuDQo+IA0KPiBTaWduZWQt b2ZmLWJ5OiBIb3UgV2VubG9uZyA8aG91d2VubG9uZy5od2xAYW50Z3JvdXAuY29tPg0KDQpS ZXZpZXdlZC1ieTogSnVlcmdlbiBHcm9zcyA8amdyb3NzQHN1c2UuY29tPg0KDQoNCkp1ZXJn ZW4NCg== --------------orrsVUFl5m1rKOY4H1tIeSMX 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----- --------------orrsVUFl5m1rKOY4H1tIeSMX-- --------------nT0luGH0skdzcdB98AO3VOAz-- --------------i2y75WnCP7J0ez480mRl2LPE 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/Ey8FAmmm4pQFAwAAAAAACgkQsN6d1ii/Ey8k awf/SmZxH+cZSgJr0qTp+hQqI6YFOWEweAJeNxCVDVY0ZINrR6J2UUqQKmJ8OKbmP61QyOqtXjfY 8+tQBCklIYQSwn1iLJz+PmYj9XRVPeI8FL40h10IHS7ZlFWRZC1MwRJGTA7ZhITBWurklcs0YX3V TIGH2RKQAeG2yd0hQ62e+SigCTLwcMFsRsbltzU63b8KbmUe/vHQG8ME2Ab210gKXch/UOfjWChM +P2eiIMh89iT+93rrm4b2FrQaeh1UNBFfDhSZxAVwIYo5zv65pfggho16AJOPQJh6ra3XKx14LxE XWHNsQTfpSkqlb1EbwAUpKQGU6UiyFuR85dhagfZKw== =7hZ6 -----END PGP SIGNATURE----- --------------i2y75WnCP7J0ez480mRl2LPE-- From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:35:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:35:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244765.1544132 (Exim 4.92) (envelope-from ) id 1vxPty-0001h9-T4; Tue, 03 Mar 2026 13:35:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244765.1544132; Tue, 03 Mar 2026 13:35:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPty-0001h1-QP; Tue, 03 Mar 2026 13:35:06 +0000 Received: by outflank-mailman (input) for mailman id 1244765; Tue, 03 Mar 2026 13:35:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxPtx-0001gi-HZ for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:35:05 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c8ad0013-1705-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 14:35:03 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4837634de51so23779425e9.1 for ; Tue, 03 Mar 2026 05:35:03 -0800 (PST) Received: from [10.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-483c3b3ce8fsm352299085e9.4.2026.03.03.05.35.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 05:35:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c8ad0013-1705-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772544903; x=1773149703; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=BOScuocRZ/Rl9yggjOBZAfpMkRprvyewmshNYbrzw8A=; b=Htvyj5/QpHx2UxtK1YGz918JFsdkdO06nQBCGiMwZnpml8jdUBSq1o+qeQsUFr88DJ b+GAJD78GKMJKH3PYFHvUmvuMYq45LlyNcEfhYfKO+C/g+fock9qeWnD5oytxOZKQrL5 0u95AoOHB8o/1PHqyMJINNQBGTABR48fIPUHdHZihrK6Pf73LD3rga7Mg8WTLA/XZGqV 2fzt6cnLNtH9v7xM651Df2yQWMLFabQNKUxCIVUxBO/GvVRq/4/5wvLn6kauJVXfl+Ix g9uOcMdr0T2Ho7zcQn9hFzfra8khmi+wOzbsB+7Iw4+MMXfo6+/ITupaelMVS+CFW97K bWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772544903; x=1773149703; h=content-transfer-encoding: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; bh=BOScuocRZ/Rl9yggjOBZAfpMkRprvyewmshNYbrzw8A=; b=s89rxUEOf1VGWnlDfkl8cb/4bWgabx+esxUvLfQvy6ZgmzUggwyhpXNoZ4CekWC3tW Ukd4KW3FLFRWp6/PI59ddf5tafuhU3S8h+cFO2n2aT30vN5yY81BdCALbRY0Popn8SVw fT4zgxh+oJrpnVdEfeoZF+s8dzq1inTSnvI2Yh5jqahqX4sp5938109CmFh5hum1lTVL Aapqt5IanzmB0c7n/CQHCIyLWsqkt1oaFxnXkRP7E6nnGKioNjh8O9fXNBefDJGbkNDz f4aVBS9/r7v/7j+IOGaPf6LpG6l1WgJmuI4HVGSQb7vaWe6DZlYqtbtgjfoIUArzWEqR ysuw== X-Forwarded-Encrypted: i=1; AJvYcCVCfIVd6q6IBgjOpMwRUEXFWIQzsttyLCdDrwGs4XknVtC5G6amNHTn36/tQ4SxBxv429O22Xa9aIg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx4su3Aww/SugBh7qu3k/0ED5Gk4LBecuU1Jor6Qc9so7CxxXNd G11VvpjVWC1DZDHdQAEI7EwO01bxp72Q+oYXcoUhY1k2K+Tq2LvB/LmqkdOgxTtybA== X-Gm-Gg: ATEYQzw2617Ab3st4wH8NUOqXYEAuYgFH6g0FKTawmqlAo/LkApSdtxRELzt43Nbr4V 5aZsSvUoRNyB2qXJkVfw2T+2Q96XGLYhs7U7sngqNYOScC+UH6TWVcmIaCtSdg4ZHrho3DjFILB GXsRIaTczS8VS6jGwSFoFjGBxpulnPVbTuXpPGF8gQOE0nGIxNa7As/7kdcP1VKYMTZux2p3UMq M1dQgUJDnXRqIY4EbseAfVd6hHUhlrTvK/mFHkMlFSE1nZrd3+gPSlADmASCkd+vna1hGI9W+LT 4fGdXf7bhEhDxvHoaQu62lxrRDRw1wE+coWe8NOCK+MU9fjMG57/aF+25h/Y2u8LR96b4q/spjT FnoXdbOp7mMc2MlOoXlFPINKUmCWcL62lsFzQTdFiurz0gAWYwFNXbemqR3iYcvd14x47vrfVA6 04FjPFRwIoaV3CQBB1If3S1oqfdhmaJ+oqAbmkQAYVY8oULYPwhd4yOlF5wR6ilCJrCuMchfigu qlUSr1FmimOcnKGsP/LJ/kfjA== X-Received: by 2002:a05:600c:4444:b0:475:de12:d3b5 with SMTP id 5b1f17b1804b1-483c9c323d8mr250859045e9.34.1772544902787; Tue, 03 Mar 2026 05:35:02 -0800 (PST) Message-ID: <6357ad3f-85c8-4fe4-a2c8-8b0a0a97f1b3@suse.com> Date: Tue, 3 Mar 2026 14:35:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.02.2026 12:51, Oleksii Kurochko wrote: > Based on Linux kernel v6.16.0. > Note that smp_wmb() is used instead of smp_mb__before_atomic() as what > we want to guarantee that if a bit in irqs_pending_mask is obversable > that the correspondent bit in irqs_pending is observable too. > > Add lockless tracking of pending vCPU interrupts using atomic bitops. > Two bitmaps are introduced: > - irqs_pending — interrupts currently pending for the vCPU > - irqs_pending_mask — bits that have changed in irqs_pending > > The design follows a multi-producer, single-consumer model, where the > consumer is the vCPU itself. Producers may set bits in > irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is > performed only by the consumer via xchg(). The consumer must not write > to irqs_pending and must not act on bits that are not set in the mask. > Otherwise, extra synchronization should be provided. > > On RISC-V interrupts are not injected via guest registers, so pending > interrupts must be recorded in irqs_pending (using the new > vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating > HVIP before returning control to the guest. The consumer side is > implemented in a follow-up patch. > > A barrier between updating irqs_pending and setting the corresponding > mask bit in vcpu_set_interrupt()/vcpu_unset_interrupt() guarantees > that if the consumer observes a mask bit set, the corresponding pending > bit is also visible. This prevents missed interrupts during the flush. > > It is possible that a guest could have pending bit in the hardware > register without being marked pending in irq_pending bitmap as: > According to the RISC-V ISA specification: > Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and > interrupt-enable bits for VS-level software interrupts. VSSIP in hip > is an alias (writable) of the same bit in hvip. > Additionally: > When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only > zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and > hie.VSSIE. > This means the guest may modify vsip.SSIP, which implicitly updates > hip.VSSIP and the bit being written with 1 would also trigger an interrupt > as according to the RISC-V spec: > These conditions for an interrupt trap to occur must be evaluated in a > bounded amount of time from when an interrupt becomes, or ceases to be, > pending in sip, and must also be evaluated immediately following the > execution of an SRET instruction or an explicit write to a CSR on which > these interrupt trap conditions expressly depend (including sip, sie and > sstatus). > What means that IRQ_VS_SOFT must be synchronized separately, what is done > in vcpu_sync_interrupts(). Note, also, that IRQ_PMU_OVF would want to be > synced for the similar reason as IRQ_VS_SOFT, but isn't sync-ed now as > PMU isn't supported now. > > For the remaining VS-level interrupt types (IRQ_VS_TIMER and > IRQ_VS_EXT), the specification states they cannot be modified by the guest > and are read-only because of: > Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable > bits for VS-level external interrupts. VSEIP is read-only in hip, and is > the logical-OR of these interrupt sources: > • bit VSEIP of hvip; > • the bit of hgeip selected by hstatus.VGEIN; and > • any other platform-specific external interrupt signal directed to > VS-level. > Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable > bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the > logical-OR of hvip.VSTIP and any other platform-specific timer interrupt > signal directed to VS-level. > and > When bit 10 of hideleg is zero, vsip.SEIP and vsie.SEIE are read-only zeros. > Else, vsip.SEIP and vsie.SEIE are aliases of hip.VSEIP and hie.VSEIE. > > When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. > Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE. > and also, > Bits sip.SEIP and sie.SEIE are the interrupt-pending and interrupt-enable > bits for supervisor-level external interrupts. If implemented, SEIP is > read-only in sip, and is set and cleared by the execution environment, > typically through a platform-specific interrupt controller. > > Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable > bits for supervisor-level timer interrupts. If implemented, STIP is > read-only in sip, and is set and cleared by the execution environment > Thus, for these interrupt types, it is sufficient to use vcpu_set_interrupt() > and vcpu_unset_interrupt(), and flush them during the call of > vcpu_flush_interrupts() (which is introduced in follow up patch). > > vcpu_sync_interrupts(), which is called just before entering the VM, > slightly bends the rule that the irqs_pending bit must be written > first, followed by updating the corresponding bit in irqs_pending_mask. > However, it still respects the core guarantee that the producer never > clears the mask and only writes to irqs_pending if it is the one that > flipped the corresponding mask bit from 0 to 1. > Moreover, since the consumer won't run concurrently because > vcpu_sync_interrupts() and the consumer path are going to be invoked > sequentially immediately before VM entry, it is safe to slightly relax > this ordering rule in vcpu_sync_interrupts(). > > Signed-off-by: Oleksii Kurochko > --- > Changes in v6: > - Drop for the moment: > /* Read current HVIP and VSIE CSRs */ > v->arch.vsie = csr_read(CSR_VSIE); > from vcpu_sync_interrupts() as it isn't used at the moment and will > be introduced when a usage will be more clear. With this, shouldn't the RV32 related #ifdef in vcpu_sync_interrupts() also go away? > +void vcpu_sync_interrupts(struct vcpu *v) The sole caller passes "current". Are other uses of this function planned? If not either "current" wants directly using here, or minimally the parameter wants renaming to "curr". In fact ... > +{ > + unsigned long hvip = csr_read(CSR_HVIP); ... this suggests it's unlikely for the function to be valid to call with other than "current". Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:44:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:44:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244776.1544142 (Exim 4.92) (envelope-from ) id 1vxQ3A-0003UB-TI; Tue, 03 Mar 2026 13:44:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244776.1544142; Tue, 03 Mar 2026 13: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 ) id 1vxQ3A-0003U3-Pe; Tue, 03 Mar 2026 13:44:36 +0000 Received: by outflank-mailman (input) for mailman id 1244776; Tue, 03 Mar 2026 13:44:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQ39-0003Tx-Li for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:44:35 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1c25cf8d-1707-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 14:44:33 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA1PR03MB6516.namprd03.prod.outlook.com (2603:10b6:806:1c7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 13:44:28 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 13:44:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c25cf8d-1707-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fcjxqzTDm44/i4dbYLm7dbT/1r95675K+oFP+jDFfc3tGV/BcwQorX5TsJgVV7eP243vX93Ebe6bJjRUrZlxNVlfZa8hvlvIwAl4uBtEVYpmv4h2ItKxYto9ytWqxACn34AY0AUPRlLpFQE4Cb8YK0Qx6x1nqpN2GTmSzwDfX5R+KHfGib0QyedjxhkuAA0Ff+auGB46S6QKHtO6W/+B0vZ+hROAvJ5Ev5fm7E7IKQ4CZhDkf2shpaB3cavYHKu2157p/cK3Ro0HJtkUJNXkFymUd872TjbyZwZa1wadqTv1UPwnVqedZLG0gHms0rO+Qn1VkzKplhbn+pKtfKUqYQ== 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=ktuf5dn7Bil6+PtW9UXZZgqOUX3cL1WSNTzz7iLmfZQ=; b=esqSLEoezPD0r0ZOHVATPpDGLADQyHM2lDyaNWdZx/z8knO0mrSMB5gOsMEg4I52pDi8frok5aDycsLNmBDdGtS8xbpyFWCL03w/OrKJMA61Dw4Pkw0+IoPFemLo4rTRuXBRt1z/ZWvmd6bHqbjfSzjR6ZsWhjqUB+oUd0hP6igF6+XtAY5zL3UAtJk64HS/wt4RL+EKJTe+3W6w3Uc9dbQrgKUmSHxdfzqE/soHj2V1gn6VEBOf5ILYdjfsGoiNNQ6HP6m4NgbI9DlxZ/McXKG5DPX8byMZklkD39uHNeiz+jLo5ANdXYLfG1eFERUbIBYhRSPgm7OIFztJX7UxLA== 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=ktuf5dn7Bil6+PtW9UXZZgqOUX3cL1WSNTzz7iLmfZQ=; b=dd+zVXxJBuDe1/O1FBx7gJDxz0jBBTZYxC5rCNCTx9AP6l3hjtGOF58k6WDrferqP7UW52GfBNWOpXVOm5z2363o6t5c1TZ+OmKdFjioFuphy3NPt1j01beuuIxuQ9kxDbRl18YgOH8NMHfxli97H9QuTFUxwMOjW9Erasce+8Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <5593f7e9-8efa-476b-b1f8-3e77c58d8d36@citrix.com> Date: Tue, 3 Mar 2026 13:44:18 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel Subject: Re: [PATCH v4 08/14] x86/traps: Enable FRED when requested To: Jan Beulich References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-9-andrew.cooper3@citrix.com> <0dbf14bc-1505-4a33-bbf8-53c1ea41c7da@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <0dbf14bc-1505-4a33-bbf8-53c1ea41c7da@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LNXP123CA0004.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::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_|SA1PR03MB6516:EE_ X-MS-Office365-Filtering-Correlation-Id: 482b423f-8166-4ca1-8518-08de792af97a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: 7whSGGpqiDN0uQBYB9epxyPA1Q/O8TwmqU2fFKiPthOjSV5SsrCs+DJMsM0kikMJMPxqjvu5RUHApcRzyMo5RZTOSlgqRR7a6BTRbVVz+ilgX2d9WXqyL9L13Z5kTuUMk6iKnYnjU1gPKhsJZVm6a/XGpO2zQQEDDzprj9kDjOzTc2eABQCyH9Qpx0WzF0gD5lyxFqfucYUPlNfhI17MrctqSm43enmQMj7N8G9Rn+aOUxKRATfNu55EWC+djcqGg8WVanx0QfnZy/8SBTq8yaLzq+XxWH1K4KLtpeYJD6bq/kPwTtCAigPeU9wD10v6IHFOQgQRj+pUwXFrCz6cyVY7QobYsJOOX48up5Sh8RYt0/CqMhvwfcrBNO2lpU/7uhv+YD0QO6BZO5o1KwDWLL03monJ4B519TAmnh1Pds5zDSU94gc+eq5NDwlafjWsrLxhSUFZrXRVn/vJEJ15PI7TweTe9P30QAvY3RPODyv3XKf4wZD2J9SIDrH8WraMLu9zBj52MKc0JokxdBBfnoBtv/RmaYWWY4nq77a+zsxVCfeBpAMvUnTM+qcY90EZ5kNg6F6pHoXemSKLAU6GxbPG92tFqaDbeh3//OYPRhtUFU7W8Qr+bUhpizrt/xfrRvhkgaUcEUG2kx2dwUC9tzoyhbD0XekHc37bx/erggUc4UoDG/BQ/GYbUm8LGmhEIwB1ndczXT+b9o7WsxJCLt3TAQvzoYc22DoOe4ih46A= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SWpYWTM3ZVVzUmlHVFVGeDJ4NVRybFhhNE1KbzUzckVMS3YyR21pM3ZQbDdu?= =?utf-8?B?NndyL21iTTEyZ3Qrdk5MZnJWSUIvZ1dHWFB2aERqakVNMGFPdzQ1bjVubmwr?= =?utf-8?B?dTVrVFptUDVHNEFwL25PVUtTTkZ0cmRiejlpemx1eEY0NVJNRC94bDFaOXZr?= =?utf-8?B?cDA3N05ROTZGcmxqRmlaUjBUeGd2QmV2RFQwalM4bXpOaTNHT01xWkRabnk2?= =?utf-8?B?OE5TbnNCMUh5bVQ3a3VsZFJ6NHRybDFwRGlzQmN5WlI4SHpnM1BmYjJuMUJh?= =?utf-8?B?M05qbXpuMnlESjArUjd3d2NOMWxiWkJRbFE0YUpTWFVkVElaMWdPVE4yYTlT?= =?utf-8?B?bFhJMHphT0FZZzkvTHQzRWZrUWswUkFJN0NQY2hFSXR3VnRSZUlISEVlVEpl?= =?utf-8?B?QWJia0RiUU1kR2FKbTdGWitIOVhFejRBcHVJRkI1QkZ6NFFzVGxVQ0VEWFZS?= =?utf-8?B?YTdrTDRlKy9zWm5pVFNzcHlDb2wxVmhXRVYwT1VLbjRTL241bVkzclJmK3Mr?= =?utf-8?B?eTVtQ3l2Rno3K1QrMFU0V0FIZlZTWEJSUy9FT2NTVFJXZGh5TmNoN2x2cG5u?= =?utf-8?B?aDNMTjE1T093RGJTOFVhaS94cDJjcWdpa3pvRllueUtoMlQzWks0UlJkc1RM?= =?utf-8?B?bXdPVkZGY1lWQk45UnhrdlF1MGg4cTF5d29PcmFRUUdXMThMUXpCODBNZUNr?= =?utf-8?B?U2lyUTUzRURpZjU5NFFsSGlhb1Nmb3hSTW4rT2doc0tFWFFxQWw2b0lJUUFO?= =?utf-8?B?RkNmTXVQRURTM0EvMVRxZEY2ZXVZTHpHSFlBdWlsWmkrUTNNaVdKODVlVEtu?= =?utf-8?B?TGZqZWVCWFpWMkt5MVJReG9kNTY2eURISEtHVE5vV09LaDdwcWRLdUtXTnc5?= =?utf-8?B?N2ZUNGhUVWt3QU8rZzg3bXBhQnFDUEpjTEVEQnNqVVBmU29IK1UyMHQyMXNU?= =?utf-8?B?UnhUbkk3K2V6RytqcHZQam9vZWYrdHU0cDhKWjRnRllFbkZHZTByTFRQa21m?= =?utf-8?B?dHA1MzhWVXY2UkpkeDBuOE92Zmx6cHllM2R6UEZZZHpKWi9lcWFHYkY0eDB0?= =?utf-8?B?eWRVWGRyaTVmc1dieU9wTTdsQVRmWCt0NGg5T2pFbTRXaGFCaTBhQlJJSzFt?= =?utf-8?B?dmR0ZW9jTTBsTEpldnhLY1hGZlQrQnVXVzRoQk9QZXA1Z0NyWWtyckxEb1Jo?= =?utf-8?B?TmhNOG14TDNDNEdWdVBicHhaRXNjMERXWDFyMDAxTjZxcVZzOGZMZGhkOXpo?= =?utf-8?B?Q0FMWmd2eUxyZElHUTBNeExMakp6YnNJbGtHbzkxem9xM090cE5tQ0RCbkRF?= =?utf-8?B?bmlnbkhBUDVERTNQVkRzWFhrS3VwVlYxRldNZjJiMmdRa25ISFdjengzWm9R?= =?utf-8?B?eW8yVklmUEJiUmZ0R05Fb0FXZC9LSjVUbzhyc1BRSXFsR2N3TnVQU1N4UGE3?= =?utf-8?B?emR6RGhOekR5T3hLTUs0Nm5LWHltd25STE51Q0ZxYkVkaytqVkpEdHFJUm13?= =?utf-8?B?V2h2dUtJMUFZOTc5QWFLdElKUkNpWGZwK0xpZnVpcEpCV1FIZFFCZEo2S2ZQ?= =?utf-8?B?WHgxcVdpMko4eXA4eDJxY0pOUjlNZG4rc21PTUxnUXZHUSt4MXhUQzdTb2Zn?= =?utf-8?B?UkgrZ0FhU2RqTDk4L2w2cC9HeVVQdUhOcEZxek93VnNPKzh5SlhFb0REKy9z?= =?utf-8?B?Z0ZkRGNZM29la1IxSWE0cTgrNVR3VDg0clM0bHM1amg2ZG1Yd0JvMEtXWGJD?= =?utf-8?B?bm1WQ1RWVGNIUWRQWGI4c3M3K3kwemw3cUNGZm15OVIwZVlyMDBLTEZtUytx?= =?utf-8?B?Ui81WGpBUFJ0bGF2Y0dSQ3lCcjBBb0lyRGJycFQzMlJyNTdnOWMrMnBER2pk?= =?utf-8?B?VVE1bWs1ck93UFRvVlhLR0NZWHJ3SkpTeE0yL1EwYnRtSFlwa1dDZXFnbGJh?= =?utf-8?B?TSt6VFByL2gvZGZjdkFIZ2w2ZnFOT284NXg1ODEzSnhzZFBmSi8yVU0wMnF0?= =?utf-8?B?VjRsZnpncGp6T2VnWXN2VVJTTGFnL05IVDVQVjlsM0JLazVUR0ZEcjlXUDND?= =?utf-8?B?MkZzQ2w1NkZWT2d6eVB1ekptUktPOGkxUTJaaGhxbFQyWDRIQW4xbTJlZWdY?= =?utf-8?B?SVVVTGI3VGtLdUR1YzJYUk5pY0E5YUluUkg2V2JOY1FHRS9sWmpnekZjd2RD?= =?utf-8?B?ZTRmOWhGM1VPNUtVWFJOaHcxQlJGOTFLNldWYTI4VzZGNXE1OEw3QlcrYktx?= =?utf-8?B?MExpbUxkcFQvOUsrOFpXM0xjTW1KOC9UMkVCeHJBL1ErN3JIMDJlTEVCR1Ar?= =?utf-8?B?YURlSWlqeWFjTjRyelNWMkFHdHV4ZEZuS2k3ejlscmFSYTVhb3V6Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 482b423f-8166-4ca1-8518-08de792af97a X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 13:44:21.5265 (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: Rclp8P92I1lVEqU/WK983NQRMs/XSCsg2gXz7NA1EjuDKefxNGuzBJAV/QvlAVc70d0pMprxDvfdWj85fIXkMB8YwcQuv0ElCQEkurvby58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6516 On 02/03/2026 4:12 pm, Jan Beulich wrote: > On 28.02.2026 00:16, Andrew Cooper wrote: >> With the shadow stack and exception handling adjustements in place, we can now >> activate FRED when appropriate. Note that opt_fred is still disabled by >> default until more infrastructure is in place. >> >> Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses >> MSR_STAR (entries from Ring3 only), and MSR_FRED_SSP_SL0 aliases MSR_PL0_SSP >> when CET-SS is active. Otherwise, they're all new MSRs. >> >> Also introduce init_fred_tss(). At this juncture we need a TSS set up, even >> if it is mostly unused. Reinsert the BUILD_BUG_ON() checking the size of the >> TSS against 0x67, this time with a more precise comment. >> >> With init_fred() existing, load_system_tables() and legacy_syscall_init() >> should only be used when setting up IDT delivery. Insert ASSERT()s to this >> effect, and adjust the various init functions to make this property true. >> >> The FRED initialisation path still needs to write to all system table >> registers at least once, even if only to invalidate them. Per the >> documentation, percpu_early_traps_init() is responsible for switching off the >> boot GDT, which also needs doing even in FRED mode. >> >> Finally, set CR4.FRED in traps_init()/percpu_early_traps_init(). >> >> Xen can now boot in FRED mode and run a PVH dom0. PV guests still need more >> work before they can be run under FRED. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > >> [*] PVH Dom0 on an Intel PantherLake CPU. > What other part is this remark connected to? Ah - the commit message.  Specifically, that I've only tested VT-x, not SVM PVH dom0. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 03 13:59:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 13:59:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244785.1544152 (Exim 4.92) (envelope-from ) id 1vxQHW-0005Ol-3c; Tue, 03 Mar 2026 13:59:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244785.1544152; Tue, 03 Mar 2026 13:59:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQHW-0005Oe-0V; Tue, 03 Mar 2026 13:59:26 +0000 Received: by outflank-mailman (input) for mailman id 1244785; Tue, 03 Mar 2026 13:59:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQHU-0005OW-OF for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 13:59:24 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2e88407a-1709-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 14:59:23 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48329eb96a7so38341925e9.3 for ; Tue, 03 Mar 2026 05:59:23 -0800 (PST) Received: from [10.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-48516f74a1dsm4328835e9.2.2026.03.03.05.59.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 05:59:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2e88407a-1709-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772546362; x=1773151162; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=eJb6jyNRbVRCqYi3utXU/8acVkjcEF4cLekP0QdSkZs=; b=IAVuEmyS/8HU4Zrb3A4Syn6T605vVjedC3dOnWVejj84mVcLS7cc9iBrATG5zy9T6w unwxmlEQvVCgvtBZvDCmgQGT/gB4uGt64ls6mIW02K5YPEDbsDHjhsc5pN3EMDisHUYM 0rf22cJ/eg1uMBlVy9oPA+LVCFxuJo1pBEpF+px5O3ov6rp8s8CWzc/Z8qp4fXaZTJvK dbaCRJ1fAkg7LQbo7K8SV7n0kbkWl1rw78n0SISrh5Hi1cDDH5x9XSYtXwYp83d8rw8D JxHV4G33btIPN8YOwIwIXIUa+NDelWY6fERmXBsa3SkDbL3mFoKzMJqYlXIHQTn93Mr7 ripw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772546362; x=1773151162; h=content-transfer-encoding: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; bh=eJb6jyNRbVRCqYi3utXU/8acVkjcEF4cLekP0QdSkZs=; b=epqO9QabfNHA0DB6owcHxJwtnbanEd5kP/bQKrao31On+Tz+HAzOlG2PtzHPCbv1tW OpHr9ErgCmYvSeRDeTHSCbahIf+iYJofuCaNzYRhhA40LKcDKL+WA0N3DHPplPgcKa0A Gg0kdAr3fBS3MrU9hvWx3RnPaaMF1jPiXTOsyH6YnFuG8qul2vBBkUHbxvSQvZrRl/ph vHhtapCqohPdeZGLGXGFk9T/5yCG2IxCQJ1GHf3AQQ+XL085FpioTmBiTVmOwW6d4HSA hL443FEqP1oCmNk54JcRfVDorvHDcxq+XnanwXEbxaC9WAvuHw2izpvL2HPXWHaCztvy hfRg== X-Forwarded-Encrypted: i=1; AJvYcCU49202SRf5auPnZWS9ZzP7E1Tb41wo4GfoR5048s7jrR71dKIbcbUqHDmcA3HgbHiC4Xk+YeyJzls=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxj0v/ZvId6n9w7jxqaW6SNhjtCFpbGhUnFU6hqSrhPXi5fuLqf 4RZtYBZJKhl/JlVsL2dS7ZguxMi259fkmIp+UWHDfyxpNFHvLZnoAQT/xtCySx4Fwg== X-Gm-Gg: ATEYQzx7SRnchRBlmwt292kwN0oTlTNgkrZc1lXt8arG2gSdIuLXvoOTi/1gdyM9Bdh lXmmsZokBgDG7qdDnF34Cs0xfOyZE/rLQPY7ipTlzoRd3OuV9aNsLg9NzBmkciTOftT8GSci2Iv bmgJxnCRkDTy+ufMWHyl/kGn5F5v1AIu3FkmVqitulbIk+JQoKZu1mUG0wSN5dLF2Ezmy8zDvn2 I5iv13bKkwvxEWnNw4G5Wk/9birbEyZCaHdJ1TtjPm/TfOvs2vDywsjAJjXMd0EGOItLskRgiQA W08SCRfiGSjh0SVQ7ogm0m6LmY6lUOM9mHQq+7Y0T7fVUNE9I11Gc4sGjckwK4glCpj/b+3P53o wI2mDDU381QFLt7NqLo5SspKcsmENF9srnepkOR0TiYHrynilbAjUD2NBSiwOoxNQuS2Y7e8kt2 WFSss0oea6Ijt7gNimDuGfwJc8AagFQOWaOo/HKBX+1UmoM5lg/mre4r1COQX2RMe/11UwcuiIT ei7cAk8rLwma/2mjWNivaRs3Q== X-Received: by 2002:a05:600c:3486:b0:480:1e40:3d2 with SMTP id 5b1f17b1804b1-483c9bedadcmr292926195e9.29.1772546362352; Tue, 03 Mar 2026 05:59:22 -0800 (PST) Message-ID: <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> Date: Tue, 3 Mar 2026 14:59:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 11:58, Edwin Török wrote: > --- a/tools/tests/x86_emulator/test_x86_emulator.c > +++ b/tools/tests/x86_emulator/test_x86_emulator.c > @@ -1882,8 +1882,13 @@ int main(int argc, char **argv) > #define decl_insn(which) extern const unsigned char which[], \ > which##_end[] asm ( ".L" #which "_end" ) > #define put_insn(which, insn) ".pushsection .test\n" \ > - #which ": " insn "\n" \ > + ".ifndef "#which"\n" \ > + #which ": \n" \ > + ".endif\n" \ > + insn "\n" \ > + ".ifndef .L"#which"_end\n" \ > ".L" #which "_end:\n" \ > + ".endif\n" \ > ".popsection" Nice idea, but why multiple .ifndef, and why emitting the insn even if the labels are already there (and hence won't be emitted a 2nd time)? Further, if the compiler unrolls a loop and instantiates such a put_insn() twice, it could pick different inputs (where flexibility is allowed). Most present uses (including ones I have pending) meet this requirement (i.e. permit only a single register per operand), but vmovdqu{32,16}_to_mem, evex_vcvtph2ps, vpcompress{d,q,w}, vpdpwssd_{vex1,vex2,evex}, and vmovsh_to_mem don't. {,v}movsd{,_masked}_to_mem, pcmp{e,i}str{i,m} and a few more could also end up being problematic if different addressing was used for the memory operand(s). None of those sit in loops, I think, so we may be safe. But the constraints need properly writing down in a comment, I think. > @@ -5248,7 +5253,7 @@ int main(int argc, char **argv) > memset(res + 3, ~0, 8); > regs.eax = (unsigned long)res; > regs.ecx = ~0; > - for ( i = 0; i < 2; ++i ) > + for (i = 0; i < 2; ++i ) > { > decl_insn(vmovsh_to_mem); Excuse me? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:05:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:05:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244796.1544161 (Exim 4.92) (envelope-from ) id 1vxQNg-00071j-Or; Tue, 03 Mar 2026 14:05:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244796.1544161; Tue, 03 Mar 2026 14:05:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQNg-00071c-Lo; Tue, 03 Mar 2026 14:05:48 +0000 Received: by outflank-mailman (input) for mailman id 1244796; Tue, 03 Mar 2026 14:05:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQNf-00071S-M1 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:05:47 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 128020ed-170a-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 15:05:45 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-482f454be5bso61561095e9.0 for ; Tue, 03 Mar 2026 06:05:45 -0800 (PST) Received: from [10.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-485133426aesm25494955e9.3.2026.03.03.06.05.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 06:05:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 128020ed-170a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772546745; x=1773151545; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=8ihoPi48xkGuWHBXmjYqxnC0s+ZR+a0aSNzSbBs2yQQ=; b=a8VAZRkI+40KDXNSDUb3P6AXnefLn2OfQwV6qkyQvtl3ATm1CFDYCRmmkN6teDloHF KvDcMdV5iAvDI1h+Flk0rjbfCZrXOQzw9NUHMgSD3RHyidDqSkegBD4A4O/s94LXpdXF yXdRBc7OB3mPeWh2fybRGm0z55Ylv7+dINUgDAzuFKPLEE4HmcgsXnEpG8dQGik4h8mW x/hJlOcSrmuj87e0gu5hJzk+xe65ymMr3NabPqJFhfy+sGWtyAunsAjyG2/1HAjCsbqA q0E9Vdtu25yrqWNEIEr6ti29oxtzJLLkUbEyqjEt5uMbWAlaXty1+sXxqPyLExCEDMlY T7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772546745; x=1773151545; h=content-transfer-encoding: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; bh=8ihoPi48xkGuWHBXmjYqxnC0s+ZR+a0aSNzSbBs2yQQ=; b=QbF4fgp8DSdvJFkZjP248NFsGGDMcp07rGKmusqvPw6URAHTzduBaACufM89zvazUf uXdbEKUKTjBYmMW3fnsYFcG792KkFwhr6soF9QNqg4gc+QimvTBl5AqIAosD/6t91qSa 3C3ocSTdQIVT45PB+MzZfLHaj8XYy2847saCWEoBpXlxFEmYvVPolH/UhiiWL25eBlal oh/PoVi6GIuA5gjxa5ZxyWFVtc9GOm/YzL0Hamo8/rz7h7+sHwNlTxQ9yzoep0XtVf9Z sH9JoOcDttBISGnxwUZPAtznqNHP7vNCE7IaisyJT1KdnFmW8aZteQ0aQelxzSrupLSh z3Ng== X-Forwarded-Encrypted: i=1; AJvYcCWYty/LgHDabdipRI+NGykxWscROd4AX0M3ZOylmLufFqJckOMIE3k2zTsCcXZ9tcr7fv8lTvjuY0s=@lists.xenproject.org X-Gm-Message-State: AOJu0YwfJnnQTd9TOJS8T/CQcF/wk8Ng1cvCWkgZmQ9oKDX7Iz5ZY8ZQ l+NS7c+geT4qVeYuIK4B9b/O8U6HnLLMex6KuS1CjUadido3Gh9mYv6ex8oYg5aMEg== X-Gm-Gg: ATEYQzwLBgETlN/wuXZYLfFIG+DtXYaYJKTpInox3Fm6eA7naIl6w5imbCEoXkNHG58 3ekiGx0LlXT3NjUWuglIWVAp2HuFt7NaOuYptIio8a8YJADIa+mTEKvV0pIqKJMyOxoqeKqZ06J DEU9qYNUo/YvNbdrI5R4PiZAc54EM0q+PQwIpas192daOKTF8Yz+wVKDVS6NC7RPXzWUNgnDaFh 88Uown8ifwE4MhKUNlUr5O7QwgxlUyGsPEvlxX5/uyeEHYHokx/OSvg1XMTTsHBgU4TQd4nxwxh mTNDIubMrkIiEneDmyeWP2MU5aMvWBu9v6SRuhsHjW9S1fBsJcxSvV+r49Tqy3jokLB9ZZ1HyBC f+kVeeR+1tr9jgxhThaCPcN/pMAWbjSWVzKUD2J/T5FiltuseLVCb77aNC/lovBERQE0vO7J/6h rJDbVCWhH1q8/QWRzvw48MQuJHnPRL1dsQw6U0GqAKe1+LJKhQbhhKejaHWMSunTuc8PrCOVino 5Sw/MBmGfpMISA= X-Received: by 2002:a05:600c:4f95:b0:483:29f4:26b3 with SMTP id 5b1f17b1804b1-48513a5620amr38725815e9.1.1772546744457; Tue, 03 Mar 2026 06:05:44 -0800 (PST) Message-ID: <5116fc4c-c002-44c0-bda8-5af60a075868@suse.com> Date: Tue, 3 Mar 2026 15:05:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] tools/tests/x86_emulator: fix build on clang-21 To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 11:58, Edwin Török wrote: > clang-21's built-in assembler is enabled by default, but it doesn't > support some mnemonics: > ``` > test_x86_emulator.c:2636:36: error: invalid instruction mnemonic 'fsaves' > 2636 | "fidivs %1\n\t" > test_x86_emulator.c:2640:24: error: invalid instruction mnemonic 'frstors' > 2640 | asm volatile ( "frstors %0" :: "m" (res[25]) : "memory" ); > | ^ > test_x86_emulator.c:4251:24: error: invalid instruction mnemonic 'vpcmpestriq' > 4251 | put_insn(vpcmpestri, > | ^ > ``` Btw, for this last one to work with gcc older than 7.x what I have in a local "helper" patch is # if __GNUC__ < 7//temp put_insn(vpcmpestri, ".byte 0xC4, 0xE3, 0xF9, 0x61, 0x16, 0x7A") # else put_insn(vpcmpestri, "vpcmpestriq $0b01111010, (%1), %%xmm2") # endif > Use the external assembler with Clang for consistency with GCC. > > Signed-off-by: Edwin Török Acked-by: Jan Beulich > --- a/tools/tests/x86_emulator/Makefile > +++ b/tools/tests/x86_emulator/Makefile > @@ -297,6 +297,11 @@ x86_emulate: > > HOSTCFLAGS-x86_64 := -fno-PIE > $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie) > + > +# clang's integrated as does not support some mnemonics: > +# https://github.com/llvm/llvm-project/issues/183635 I see they already confirmed at least the {,v}pcmpestri issue. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:07:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:07:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244805.1544172 (Exim 4.92) (envelope-from ) id 1vxQPb-0007fo-48; Tue, 03 Mar 2026 14:07:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244805.1544172; Tue, 03 Mar 2026 14:07:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQPb-0007fh-15; Tue, 03 Mar 2026 14:07:47 +0000 Received: by outflank-mailman (input) for mailman id 1244805; Tue, 03 Mar 2026 14:07:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQPZ-0007fX-MG for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:07:45 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 592ae95d-170a-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 15:07:44 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso48303835e9.1 for ; Tue, 03 Mar 2026 06:07:44 -0800 (PST) Received: from [10.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-483c3b4410bsm366195305e9.6.2026.03.03.06.07.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 06:07:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 592ae95d-170a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772546863; x=1773151663; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=qTpRZslKdHNhiq4x9+zdcy+FrkRxCVCvl4abBnfa+dg=; b=dBMcjxhNVAW6Y0UT3L22XhdOLt2dxV+ue+6X/le4pGyWpGLt+61bi19YHLTRAnxvMQ gE3usq/gUJgc+xQdwitQ506xBqnYcOrGkQ2X89t/Kxedg9YDL3k5CaC7WB8SWWBzByxV 10O5IK+nRCjGxLh88gh9VF3N9a5sFEgDRqzs6fygc2hSTTini/TLDdSctle4sIBeyCQ1 oj5Sl9QEfHdDs0RjeuGYZMY6y1KN4B8Yl+Mzn1vBr9ixZAcRZ7SEH9aMZta4UAXv0OTe lGdxIL8RnNnNdrGNm7oXi/tGXrJxb4tl4KpJ5oy1CpifqcZCm2agv79kdTjqMlftlmzz xPwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772546863; x=1773151663; h=content-transfer-encoding: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; bh=qTpRZslKdHNhiq4x9+zdcy+FrkRxCVCvl4abBnfa+dg=; b=q157k6/sFkSow5HFv4VvPsIBKKx8XHLrF60Ewc6m7cDi2s6sCjB7WC+SiJYB+aqgWQ UR9bCfStLDMl582vOGBswMkGIH2i5klD9FYw/6KwAKRhw3QiEksXxTeQT1HP9L2o+Db5 eN0Ahfjrx1yiBmiX4Xe+D3xGq1l11y4u49HdFhBAgQdrl7Lqfh8AfShktiShAO1KZgo5 qdM5quPG9NGfqL5p6e/kw3PdJeG4U8X1ffbPN4pMfVdpUd+BmlBLSyqPGpv7W/xQr+y1 7MWt9qCwGA0BU0CDkyzP6+JbMSwqNreVLAGGBS18yJqzT0AFEQePbmBbKjwTp/O8WkSU Vf3Q== X-Forwarded-Encrypted: i=1; AJvYcCUrhLwWw5u4cddqVt/K4zDqV7+8pTRaKtibmXq5HohqfYEu7DBsT8Eq9fMi4Wge1EEnOflfrs1NzMc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy3mLgIdlbqayoMybFPlCgCaf0PbZ4hhu6hxbYVd4hP7CEf9u4v LG951jj7YnXX0GzZHfiBN7ysb7T1puHDdzbLV9yaVoz5yZOu4BRRlxaSJgPDd5ziaw== X-Gm-Gg: ATEYQzzfpFDQ7eWL/vtdk/RE/OnxNp8rKaSU3G8k6t3QCIMdnp65SQhYPOq1zXZvbJx IcJQV2BZtatvut6s2qx9X5iZTJJb9esFOvSBrKUjFhVN3AUCcd68zLVDu8xgHn6sQP6bKHZyP26 WYC25WddNNdGr8j1K2peZB8MLoU5mv7ZHMPIsp7mkxN0ugi6tckqunjymBnMDWY3dSpgoNev9UY y0GjeacOUQ1KqJaQ26JOpuPe+MGH96bQTtU0q2qhbBKsIKxQfOwkwMZHxo2QlhcVt/Wmdic5G/m nrd5P3vfTZildpOgUpc7PyXymuNxIN0s8dvm6nZitFuVqtvj1mmWKVxVLDVaoi2NEgiPkThS0f/ m3ad+mzaMoeVAyUSNwypSj9YrSqCgKV987+OsEB3TKs10iNEVsgb2LKwfe+wNSNwTnczdoEHyFK kZUfNaUtylM3h18sujbdaSwgBd7+9EOfc5jE/4yHlBDyG5A0HIQM2w4TegU3Cm4LV9lXJ2u/K9p cEYQdp0p2x3tgk= X-Received: by 2002:a05:600c:1c15:b0:483:6d4e:9811 with SMTP id 5b1f17b1804b1-483c9c0b6ddmr315268175e9.31.1772546862560; Tue, 03 Mar 2026 06:07:42 -0800 (PST) Message-ID: <02d59353-8d59-4151-8428-dd6458f9165b@suse.com> Date: Tue, 3 Mar 2026 15:07:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 11:58, Edwin Török wrote: > --- a/tools/tests/x86_emulator/test_x86_emulator.c > +++ b/tools/tests/x86_emulator/test_x86_emulator.c > @@ -1100,7 +1100,7 @@ int main(int argc, char **argv) > regs.edi = (unsigned long)res; > rc = x86_emulate(&ctxt, &emulops); > if ( (rc != X86EMUL_OKAY) || > - (*res != ((0x2233445F << 2) | 2)) || > + (*res != ((0x2233445FUL << 2) | 2)) || Why the L when res is an array of unsigned int? With it dropped (happy to do so while committing): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:09:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:09:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244815.1544182 (Exim 4.92) (envelope-from ) id 1vxQRO-0008HF-HT; Tue, 03 Mar 2026 14:09:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244815.1544182; Tue, 03 Mar 2026 14:09:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQRO-0008H8-Dq; Tue, 03 Mar 2026 14:09:38 +0000 Received: by outflank-mailman (input) for mailman id 1244815; Tue, 03 Mar 2026 14:09:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQRM-0008H0-Ni for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:09:36 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9b13f9eb-170a-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 15:09:34 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-480706554beso63433095e9.1 for ; Tue, 03 Mar 2026 06:09:34 -0800 (PST) Received: from [10.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-439abdf5430sm24477539f8f.5.2026.03.03.06.09.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 06:09:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9b13f9eb-170a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772546974; x=1773151774; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=PcPUAgrZWGvWRnkTHeShUzedQXW2PkdQLjlKa7JzF0s=; b=MrZto8OGBEkYEKQuulYj7i0e/kWv8bi7rVG/ipxF2+ujoXpBe5IS6/xlsq8jMetuFl L3i3keEFJIQ28/hG3GA5PPyGqoVs88eU6FxKcEkKVQxt0SgJyogLoayKTlqcC/yAyLYV brx4lJU039w1ta6BDn9N8CB0tXMmkjxo8r0RmDc7UI0wVwo2su8ZeD+V6o3kzlEfJ+lD DL+H2+Bn4HtOpRZQ4Af6M++GULOZtfuUZ2hAraW20q3xpQGgm43oW4fPeOCUd6gpB2HB QhPjSuYNlC9kjsPJATStOjW6FtOa5VCJB9tufNf1zICwVicGyrVLMWEyvw8mng1m26S7 VPvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772546974; x=1773151774; h=content-transfer-encoding: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; bh=PcPUAgrZWGvWRnkTHeShUzedQXW2PkdQLjlKa7JzF0s=; b=LX+w9Us5eJfd/iN8U14sVoD1PzboDnRyu+dcpAwPSmW7HUd2DXJuOGhRnRxqZyyLP8 tUurJeri5D1bsPWYLfrhe6YkYCYntltaY1TvFwq0haj+ZzZjTDmh/EedJdHPe4J2tzl0 A5NHkpsznKkkxZQHf/9SkBUSi9mSzBxPUFWuXaicXvvvs5yeOpWf4oLxkUksGfr4a+tV DwpJxupbk5+2fRJ2dncWNSa2U6PYlnrvmsFCSUzixbqzEl88p60Fn6Vff3BtNTwLEVKS t4E9H8IJenaI2iopdV9m2N0a+qd4LIV3Mwd8QJexqchFURXzpmVZgysIRQWF+Q2/kQVX 0MIg== X-Forwarded-Encrypted: i=1; AJvYcCXKZqLH7RLo1dqcgJ1oVl3yU0414VEyf/enulEG1A0FVo3uaty+BEY3dk8a7r4jwD5RKEIUk1A2ah8=@lists.xenproject.org X-Gm-Message-State: AOJu0YxjXGRfV9+zOCgzMdtX8/CWUINKThYQYnJ98cXDsC0DKe08Y7tw f1Xam1teIMnZFltJogiT8ajx1hN9RxLTac3MpCuH5oy+cBmY2e2R0Pb9SktArbYsZnUwIslt451 5Y/w= X-Gm-Gg: ATEYQzxRe4gvk5efVP2bEU+vn4jVDR4aaWJ8sTQaAvOy0OQ9hyZnLoAdmy8Lh3CjwGV EZaZJpb/g/1ChL6BfjBX/X+zHaXNfDIoGKg/uy15tKDVhJIv7EHMO7lVMVBp3NUDiHpcTIf/aow 5sjAtGHvvd3ER3bGV7jiCR/8xiZGNH9zcYmx2BBzonRZa570TCFCF6IrRB0gue/vrvqMuUhLmjg YgkO5zb0DUbw/Reh4Q45g8BFedD+fQQhWZmxCJCFDu4t8ZzhPdsJTaZLlrTUXzfzoCcM305KAVS 2NVk9GCBubxs8YR4CRkFFmqPHsruSs2nepGUzGITATuRrnKNqFUNQC/VVlwwzqBJFgbCtLGskY3 NkFK32CNAmx5VPvEJh6DTuJcow1vAuRL/OSFTKd71Ic2ibtpKXB5qcDiFWmDhB4W97HKiKVECcY JPBVfgAh0EfKKafISuF2GEyAunJXpx0AmHXGH7AIGDraWfsHYOdGyrCCSJyhquEZL5/QmDxGH3V V1BrxRTvRpaBGs= X-Received: by 2002:a05:600c:548a:b0:483:aa2:6bce with SMTP id 5b1f17b1804b1-483c9bdb0c2mr262897845e9.30.1772546973894; Tue, 03 Mar 2026 06:09:33 -0800 (PST) Message-ID: <803004bf-ab0b-412e-9892-e22db70e918d@suse.com> Date: Tue, 3 Mar 2026 15:09:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift From: Jan Beulich To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <02d59353-8d59-4151-8428-dd6458f9165b@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: <02d59353-8d59-4151-8428-dd6458f9165b@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.03.2026 15:07, Jan Beulich wrote: > On 27.02.2026 11:58, Edwin Török wrote: >> --- a/tools/tests/x86_emulator/test_x86_emulator.c >> +++ b/tools/tests/x86_emulator/test_x86_emulator.c >> @@ -1100,7 +1100,7 @@ int main(int argc, char **argv) >> regs.edi = (unsigned long)res; >> rc = x86_emulate(&ctxt, &emulops); >> if ( (rc != X86EMUL_OKAY) || >> - (*res != ((0x2233445F << 2) | 2)) || >> + (*res != ((0x2233445FUL << 2) | 2)) || > > Why the L when res is an array of unsigned int? With it dropped (happy > to do so while committing): > Acked-by: Jan Beulich I should probably add that nevertheless it's not quite clear to me what use it is to compile the harness source itself with sanitizer options. I can see that to be useful for the core emulator files compiled into the harness binary. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:18:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:18:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244829.1544192 (Exim 4.92) (envelope-from ) id 1vxQaI-0001XY-93; Tue, 03 Mar 2026 14:18:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244829.1544192; Tue, 03 Mar 2026 14:18:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQaI-0001XR-6C; Tue, 03 Mar 2026 14:18:50 +0000 Received: by outflank-mailman (input) for mailman id 1244829; Tue, 03 Mar 2026 14:18:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQaH-0001XL-HR for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:18:49 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e47a8fc0-170b-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 15:18:47 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439b8a3f2bcso1707883f8f.3 for ; Tue, 03 Mar 2026 06:18:47 -0800 (PST) Received: from [10.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-439ba2a58dasm11432271f8f.27.2026.03.03.06.18.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 06:18:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e47a8fc0-170b-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772547526; x=1773152326; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=HuTfQgsOPgXncwtzFb0ToG36NX3pcQJjsDUuwPvdBSs=; b=FDD8nsUFt75xmCdQxlEkGUS/HYkaDSwlzSsKETGNQZ+IJvXMm7IAnc9B43/VgMipMU 1FGJ49WMKMcgY/t56mr8hwoBG/9cm69UJI+AME7IT5wEImcELdLLyhmwtU+De3OR66Ag GQKf7Z2Gnme5IoZkKuMy74+Ame+wn2UV3FrRQ4B7L/U6iUI3IeM7C82ozkhg9ZqJtXIf iO3JzrPC8/ec/5MZ9VFTGOdjHblfAEEhJivcWM86WHAohBmu1DXA3ooH54W0hV0dQmAY yhD9paGP1LiN6Bo2Oq9HFcysEnx1jlDMP0J2KmY883M6CiSb5ZU0JbnVC8aU9P4LlXI4 FpRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772547526; x=1773152326; h=content-transfer-encoding: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; bh=HuTfQgsOPgXncwtzFb0ToG36NX3pcQJjsDUuwPvdBSs=; b=MjuN7tvz6zMP6fIhtolyDvLma2LXZxKnpOlD9qdOH3tebuJ+oJ5qYW2Ovrqo0m15+7 RxV3M+gTeWo29MxytkVnUB13mg0op6t21qK3Pw6wdYAZ3RmbeCQzxrw2jCdMkGYJV0Ua FhG61J3VGm3hsh2Lm/ln7PiLTvGl5XuCftdc2Zf0zjYHDc+DD+Kui+wo+tHq1pSV/UKE RuiPBh59BABaFG19eW8NMEouvTE7jfP1kAOyB6gC4xI8Y+8KwCbvmbMoc+TLaErL9npR FnZ5x9d/tZNIUKN7LkEe/OFytHspfhq7XIm+kTEXS0OAhX/npugeqWPnQjSefMmmdK3V HcAQ== X-Forwarded-Encrypted: i=1; AJvYcCXlfXH6eRT00ZdM44TzZcwkDLamSzM8WjeeiKjYSH+23jDJzpydBKwrDYZyywYwqAacrYcI9y0Z5cM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxJi2/D5aseioPDLSyvWunNvgQ1HLoalLROpgJd5WQ+hM5ZFdXz wNPnAusJ1XdXhyG5+nJ8NTgwxzpKrDVUewYlmTpgQiUn67xUge54Uo5uUVoIAaClYg== X-Gm-Gg: ATEYQzwAFfMjdzkZ+4tSpUDDOxguOJEIdNCZ9DXyodudJhPdsOAvTvgc5ZH9b5tX/du a8GPoas78pcbXDRbqsBgoc3jTGNQHtupzsd7BLWkn1Ra+wXuTvDplv/nuMX/dn+WsgPX67iU3b7 2jOEBWXoDVxhHqAIWaPm/CqXn+KIL0XglmVEPqg2Uwm3ilgrx5d9atZVSXo2N2JmEjeL5SELaC3 8ZnPZk1aZwVd32xCThK1SGPRk2zZKncxOcp0+4fmrak7UVc8SFUxS6F2A9xNlwCQOunsUg0wV3N Z8V/UkdRBUXAFOMNmbgnAJrrkRJK4pkOsSEwkgMQezoG2Kb7Nly2ryT4WQKVZScEIJYf7Cni/11 yspFhaVefkaRn8TRJlFb7HLZUbVxR/NlWtDXNsks527KKuSM58CD8HlY3MwASD1W3XV9ZS/ZPT5 ZbeJvv9yClvMWoaKdAQQgATlkQs0XK1stqF6DxCg2wE0/PZQF9DzjvyKwuljP3qhHLUdAqrqOsK 0cAUGlVt2c3OM0= X-Received: by 2002:a5d:5885:0:b0:435:9cd5:bb2a with SMTP id ffacd0b85a97d-4399de032c0mr28955619f8f.24.1772547526439; Tue, 03 Mar 2026 06:18:46 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 15:18:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/4] tools/tests/x86_emulator: avoid passing NULL to memcpy To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <340f6a9fc4fdd4216f41e4bbdb1234069322d1c8.1772189234.git.edwin.torok@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <340f6a9fc4fdd4216f41e4bbdb1234069322d1c8.1772189234.git.edwin.torok@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27.02.2026 11:58, Edwin Török wrote: > Fixes this `-fsanitize=undefined` error: > ``` > test_x86_emulator.c:614:12: runtime error: null pointer passed as argument 1, which is declared to never be null > /usr/include/string.h:44:28: note: nonnull attribute specified here > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test_x86_emulator.c:614:12 > ``` > > Although this is more of a grey area: I don't see anything in the > standard that'd forbid calling `memset` with NULL and 0, There actually is. In the C99 spec clause 2 refers to section 7.1.4, where null pointer arguments are excluded. Imo for memcpy() etc exceptions should be made for the case where the count is also zero, but sadly nothing like that is there. Nit: Why do you talk of memset() though when memcpy() is what you alter? > but `glibc` > does specify it as non-null, which allows the compiler to make > optimizations assuming it never is NULL, so this is undefined behaviour > only on glibc. > Best to avoid the potential undefined behaviour though. > > Signed-off-by: Edwin Török Acked-by: Jan Beulich with both nits (above and below) addressed. I can again take care of that when committing. (Same remark applies here as to the usefulness of compiling ... > --- a/tools/tests/x86_emulator/test_x86_emulator.c > +++ b/tools/tests/x86_emulator/test_x86_emulator.c ... this file with sanitizer options active.) > @@ -611,7 +611,8 @@ static int fetch( > if ( verbose ) > printf("** %s(CS:%p,, %u,)\n", __func__, (void *)offset, bytes); > > - memcpy(p_data, (void *)offset, bytes); > + if (bytes) Nit: Style. A well formed if() is even visible in context. Jan > + memcpy(p_data, (void *)offset, bytes); > return X86EMUL_OKAY; > } > From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:31:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:31:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244841.1544201 (Exim 4.92) (envelope-from ) id 1vxQm9-0004F4-89; Tue, 03 Mar 2026 14:31:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244841.1544201; Tue, 03 Mar 2026 14: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 ) id 1vxQm9-0004Ex-5c; Tue, 03 Mar 2026 14:31:05 +0000 Received: by outflank-mailman (input) for mailman id 1244841; Tue, 03 Mar 2026 14:31:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxQm8-0004Er-4l for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:31:04 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 99a01732-170d-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 15:31:02 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by DM6PR03MB5162.namprd03.prod.outlook.com (2603:10b6:5:24a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 14:30:57 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 14:30:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 99a01732-170d-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Qd6lXoyfWFhzelmtfKUR0zKnWiMAyLFvxUXm381/AjpOkqgPf/wZgybZInGNz0HRWJio1nyjNl/K81xbDva4Mxr+ialCScyx+fU4v5JkVHDOOSY8wfF8MjNTREeq/xXxq9nCuVLRB3fHUAOP4leThJCwaSAI6edjDmMLtKbVYC25lhIuBwb5bZJNz/bFnrbvNwstmmjZ4WMDlBzRQQh3itsIjaYkehsrEdS/xr0Sfj7kFBODG0CXohAC6QoIFgiNUs6EYb0qP+JqFqLouDDjElwlDsMngQ8jovqoDcXt3c9WrFwCWlF9Qvrm43Zga+K+jz5jf++RQnxvxQYxqH/PYA== 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=CNA/W/W10RAlFstbwozHjga1br7vkdyk0F1vsAPxDBI=; b=ZBZZ48hGWjkuvVd3Hn1tG5vPuOJ+qM7Vogl2eKEE6cq6SCyXvELvzANOlPGhUEruJVBSTQbXoA136Cw+K9it/X8V1udzOjw9XCfJixTqmAMyrwqj+t7OurCCiYhRuSu+JkDCNDDkgRaT0l6bhWdNdwdGhMpWLCLWWlwYml37vbzwtg0qrnLQVih0ggxS0IESyxMhDkyS1AwomYc8stCqe1Ctu/zX0iBplBRhH+woPtZ4dRj9/oEJaevplbiLwOLkZ42XNU1rxOU4FdvWi0vlzDf6Q7NUEKLDhlgB7T+ONCAbLGKW5OmJUCrZHE4MY9C+NA5QwtUw8SlSMDynBSdakg== 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=CNA/W/W10RAlFstbwozHjga1br7vkdyk0F1vsAPxDBI=; b=XgzCocSCK4Y6ukfRuzcdvbWOhjNs2Qdzlt8Gu0DkbjkHzgJGU0srMt75HZHESDSP1BRiEp9ffaMyenobq2PDEojhUDwsILv/QdBVzD9ncJnfTPvb0QwnKA5iY3YNy9tGsMpQIyCbFejnm80F0ORnSd3SnYSu5/cTMil52oMxtF0= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift Thread-Topic: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift Thread-Index: AQHcp9gCO67+yoRhk0SyNFZDTeRIWLWc3oEAgAAAhQCAAAXugA== Date: Tue, 3 Mar 2026 14:30:57 +0000 Message-ID: <28F6CC85-F12E-4C13-B432-EBC6A0D21CCD@citrix.com> References: <02d59353-8d59-4151-8428-dd6458f9165b@suse.com> <803004bf-ab0b-412e-9892-e22db70e918d@suse.com> In-Reply-To: <803004bf-ab0b-412e-9892-e22db70e918d@suse.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.400.21) 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: SA3PR03MB7419:EE_|DM6PR03MB5162:EE_ x-ms-office365-filtering-correlation-id: bf9cca10-afad-4f09-9685-08de79317bce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021; x-microsoft-antispam-message-info: 6Lljb9aDSaAyyOxIMva/hhtrlSC7FTVRnjXZhXmUOVufi3J9eI73+ZkCxTt2RCCsE8YafKP60WTMlS2j2IjfNgLS/1qq20xDYGAr/Uh0XHAoMT1DJr2m2fFre7hxKcRqLqE/tf0pAue2UYcvY2eI/2FqrnH/xjfP9tvVfx9na0QoK8DBFQ9x4FrHDxxgWoQuwumXI48u3bkdYBr7eB0KYQViWl9ascVA0sQR+cu8hgx2jfq4RAm9bZdhrI7dFiVNBRbacQU48LXSs43bo0MfOlDrmERuYtiGMZ0QNiPCHY2ourmQsvhyx3X8qXYZoUN/Ble87WxWny0uTdyGyijw1Y0wBJbuqfyqzsjbAFTcqynzTZW5sRBzlvVEvugaMKiQ2+2CBII5z8cbRbsjvNja6UuR23b/k0/e1zYGfcxEvPf3pYQDkei1JnjHSBKWTLV0CQd/5lqB+MU7J/Lvf7EC3o5N/qaMnz/Y8RwqNbpTXMqXPRip9owiN+crTHP0pgKCXG+sTIsJsRIKCwtt7VLCp7gWz3Cy4fvH56X49WiuwB5e2VlvMRiaH1KhdACb5rQoiknjNJxXsJUwZqaWsb5SECAWQQgEt/qyWQLc4591MAGvc6Ac+eRJzMHlgH7DczOftXdCcK1KEs0GiCl1ynTMxwlbRacHswHgLJ/X7+v1p0z9uxbcr+16DALnlCV+iDVP7Px16/PQdFyiGfOkXKm20h+02ZiZlDMVHtprW+OE99zjLZ38Ta4dkJZ70YI9gMRfSyr0NOCYLZTs8G4ijpfvMSXTWuRxJ5Lq3JUzh2D2rIk= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NFhPNUdpa2FkWWNMREYyVWZzbnA4UEgwU0FKTVRwaXZMMStGTFE1WGpDTDVU?= =?utf-8?B?UUFRNUZGOWcyTlVwK0ZrZjVvdnUrTnF4Zm9XRmVhQzY3UXN1SUZibHJHclpt?= =?utf-8?B?S2dXMHNFeVZGcThyVGNUengyTkNWWFlwU3gyZ2UxTTA1ZVN2WnlRVzM2SnNF?= =?utf-8?B?cEQ0VjQzKzB4Tm9YM3FuSFZCRGRYaXFLTHQydEFYbVBlMVBONS9pdi9nK2Vx?= =?utf-8?B?OWhSRTZXVmtwUG9hekc1Yi8xUGU0NVRxMm5VYTZrazlRcWplZ3l6SXRlRzZR?= =?utf-8?B?OVpEVGlmU2RJN1J0ZUJRcjJZL3EzdlJMbGt5dkNrTTh5UUlRTkN2YnIyWDRV?= =?utf-8?B?NUllS1duM3NsOU5BS3Z2NU1ucGVZeHRNNnFwRFFibCttWTc5cTE5MDFMRmRj?= =?utf-8?B?VDRMTzVYVDdPZ1B3WkVkT0h4UkpOOU1BbmFwY3g2bWFWMXBsdkcvemhrRit3?= =?utf-8?B?Z2hGT202UVJvME1WTFMxZFNmSjlRUFBZVE54MmIyUHJGVEE4TmVFRlZYSGY2?= =?utf-8?B?WU1lZWdubytQblhjODBtVkpjMFJ1eUlmYnZDM25TdjJIQUVKaGRjRFUvSnpL?= =?utf-8?B?L1U0L2VYV0ZUczhNTko0TldLMkNNTUlnbFpqQWxIeGNWajFUSTJGLzhnVC85?= =?utf-8?B?a3RsaDR0cjdqd20rR0hPbk5tVzA3b2lLekZWM1NLUC9mRGNGWWpZdFZPTmdZ?= =?utf-8?B?bzNJZS9WM0ZxU2cyTjVtRmhNZnQvbVpXSWRGK3l1a0NsODZteE94VFlIUlc2?= =?utf-8?B?cFFJdE05eWNMR0JGOVZReEc5NEhmWWhMS0dJMjZndGM4b2V0b0dlUHVkc2hp?= =?utf-8?B?dXRMbm91REdFenZxc0dlbDlYZGFGVXNSMmFoN1dhZzJhSk1CS1pkYytzeDB3?= =?utf-8?B?UXlsK0dvVkswSWZ0eE9CL0N5dDVOL3FkcFZZWllvS0pFUkI0VkRZTzFYTFR2?= =?utf-8?B?cmsxaTZTTzNQd2lNbzIrTzk1djB5QnBUbS9DNEpRdTBSWWtNUmpnNzhLRlpT?= =?utf-8?B?LzA1aTJkRy9jN3QxbkNWQUlyN3FpNkZDL2Q1YjZoK3hkY1dadHdwY2FKRVpw?= =?utf-8?B?U0gxQy9oMGFJaXhsVUVpSTZCYStod0tNR1lSdXlnZ2lpOU54bTY1RDhkeEk5?= =?utf-8?B?aGxheWlQQndFc3BTcHMzRmIwdFd3bkFSclF1dXV2c3VEbW5vSXBiaHU3NXNr?= =?utf-8?B?N1YwOHJ5UlVvWENsaGs3aW9MZFYyWndHYXBIYnNEV1F5ck5aY0pYWkRRaGR3?= =?utf-8?B?b0J0YUc4UjBDaDl2UlhINzBMUFM3czd2SnJQdEtubGZRVWs0QjZIV0dhb090?= =?utf-8?B?a2d4dFRyeTR3M1FwUDEyd0FzemxHQXQzU0E1ZjdFTFlYYkFRU2tRSDkvY1Zr?= =?utf-8?B?MUw5N283eU1RZ0JQYWxmTlZiWlc3ZVAra1IzeEhzc055aGRZVUd4akgybXFs?= =?utf-8?B?QlJjZWppTTFJUHJDcnU3NE5Gd0htTlNrL0JZd0ZpOGxVZWYwQWorNVdEZGk1?= =?utf-8?B?TGladzU1djl2eHpkUUlWcGRWTldKRzBwTGZrd3FvWkNTaVhvQ1hNcFdGZFQ1?= =?utf-8?B?MGE2LzZvU0R2Z2NabmlMWG4rakYvQ1ZaZzViNkdOaTM0bkdra0xHSWIwencz?= =?utf-8?B?ZFNWVldIaHBra1hQVm1kLytSY1N0VStFYXVjTlMydThWSjVtRit1aE5pRmxh?= =?utf-8?B?a2NrNjNGeUlvY291T2tYVWQ0UWpGZXIvTisxSzlhQjYrdjBwNkxXbHExNGhv?= =?utf-8?B?cFN6ckNxTkdVNzBhY3BISENYN2VON1AxOHdjN3Nad09ITlhLYk1VNXIxRHR2?= =?utf-8?B?bGtQRkJ6MmpWblhTTWRZRHJFTXc3VG1pcE52S0tvaG82RUk5ZC9qUmdKVnE0?= =?utf-8?B?SU16TUxUWkJENlJmVlZJRmwva1I2R1FmdjFXNW5iUERPZHQvY1BHUzlnQnl2?= =?utf-8?B?NW5PMWZ5K3djK1dXNmZmK3hMM2ltVHdhS001TDRCaW1UWlhuWUovblkybjdJ?= =?utf-8?B?Wlp2cXNBRk9FVFJNNENHUzhyQzFjOXlnRnl3V2J4VTdyY2VlVUxnbzE2Nk0y?= =?utf-8?B?TUZpR1hpWnlTbTd5VVQ4TUkzWGJNYTlqT2J1RmkxQmptSnNCZ1AzL3BOUk5D?= =?utf-8?B?TmlkM052SnpXU1U5SmJtd2d2NGFFTCtvb0FyZ2dlWUdITUtuRGlURGdCelZI?= =?utf-8?B?d25INWFFY2h0OWk3SDVDUVJMVmdQN2hNRlZQWkR6N25sU0dJbWl6OHpkcVIy?= =?utf-8?B?ODY4VnVWSGpIOWs1L0lKc0YyK3pCOVd4bWhsSlIyM1VOK2J3L1FkYVhtV1ZN?= =?utf-8?B?R2xORGFwRytsMXZFY1ZwWEFUZlFNUFoyREZSeHRtNlh5aTVTQ2M1OXpwK0pD?= =?utf-8?Q?/aGDlEfxhsd8Ejmo=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <497A62DE0D27BE4DABB223FE2F2B30BB@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf9cca10-afad-4f09-9685-08de79317bce X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2026 14:30:57.0647 (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: TXsf9+v0p3RIxAabjCWvq1yNc2eRUUcETu0pLvHtrSuX0tAmDnqSa3cHtdDCw+I1MKk1pVhweFlCELWpHRBXXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5162 DQoNCj4gT24gMyBNYXIgMjAyNiwgYXQgMTQ6MDksIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwMy4wMy4yMDI2IDE1OjA3LCBKYW4gQmV1bGljaCB3cm90 ZToNCj4+IE9uIDI3LjAyLjIwMjYgMTE6NTgsIEVkd2luIFTDtnLDtmsgd3JvdGU6DQo+Pj4gLS0t IGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3Rlc3RfeDg2X2VtdWxhdG9yLmMNCj4+PiArKysg Yi90b29scy90ZXN0cy94ODZfZW11bGF0b3IvdGVzdF94ODZfZW11bGF0b3IuYw0KPj4+IEBAIC0x MTAwLDcgKzExMDAsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQo+Pj4gICAg IHJlZ3MuZWRpICAgID0gKHVuc2lnbmVkIGxvbmcpcmVzOw0KPj4+ICAgICByYyA9IHg4Nl9lbXVs YXRlKCZjdHh0LCAmZW11bG9wcyk7DQo+Pj4gICAgIGlmICggKHJjICE9IFg4NkVNVUxfT0tBWSkg fHwNCj4+PiAtICAgICAgICAgKCpyZXMgIT0gKCgweDIyMzM0NDVGIDw8IDIpIHwgMikpIHx8DQo+ Pj4gKyAgICAgICAgICgqcmVzICE9ICgoMHgyMjMzNDQ1RlVMIDw8IDIpIHwgMikpIHx8DQo+PiAN Cj4+IFdoeSB0aGUgTCB3aGVuIHJlcyBpcyBhbiBhcnJheSBvZiB1bnNpZ25lZCBpbnQ/IFdpdGgg aXQgZHJvcHBlZCAoaGFwcHkNCj4+IHRvIGRvIHNvIHdoaWxlIGNvbW1pdHRpbmcpOg0KPj4gQWNr ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCj4gDQo+IEkgc2hvdWxkIHBy b2JhYmx5IGFkZCB0aGF0IG5ldmVydGhlbGVzcyBpdCdzIG5vdCBxdWl0ZSBjbGVhciB0byBtZSB3 aGF0IHVzZSBpdA0KPiBpcyB0byBjb21waWxlIHRoZSBoYXJuZXNzIHNvdXJjZSBpdHNlbGYgd2l0 aCBzYW5pdGl6ZXIgb3B0aW9ucy4NCg0KDQpJIHdhcyB0cnlpbmcgdG8gc2VlIHdoeSB0aGUgdGVz dHMgd2VyZSBmYWlsaW5nIHdpdGggY2xhbmcsIGJ1dCBub3QgR0NDLg0KVGhhdCBjb3VsZCBhbHNv IGJlIGJlY2F1c2UgY2xhbmcgdGFrZXMgZGlmZmVyZW50IChvcHRpbWlzYXRpb24pIGRlY2lzaW9u cyBvbiBob3cgdG8gaGFuZGxlIHVuZGVmaW5lZCBiZWhhdmlvdXIuDQpJdCB0dXJuZWQgb3V0IHRo YXQgdW5kZWZpbmVkIGJlaGF2aW91ciB3YXNu4oCZdCB0aGUgcmVhc29uIHRoZSByZXN1bHRzIHdl cmUgZGlmZmVyZW50LCBidXQgSSBzZW50IHNvbWUgcGF0Y2hlcyB0byBmaXgNCnNvbWUgb2YgdGhl IChjdXJyZW50bHkgbGF0ZW50KSBidWdzIGl0IHVuY292ZXJlZC4NCg0KPiBJIGNhbiBzZWUgdGhh dA0KPiB0byBiZSB1c2VmdWwgZm9yIHRoZSBjb3JlIGVtdWxhdG9yIGZpbGVzIGNvbXBpbGVkIGlu dG8gdGhlIGhhcm5lc3MgYmluYXJ5Lg0KPiANCg0KRm9yIHNhbml0aXNlcnMgbGlrZSB0aGUgbWVt b3J5IHNhbml0aXNlcnMgKHdoaWNoIGRldGVjdHMgcmVhZHMgZnJvbSB1bmluaXRpYWxpemVkIHZh bHVlcykgSSB0aGluayBpdCBpcyBiZXN0IHRvIGhhdmUgdGhlIHdob2xlIHByb2dyYW0gY29tcGls ZWQgd2l0aCBpdA0KKHRoZSB1bmluaXRpYWxpc2VkIHZhbHVlIGNvdWxkIG9yaWdpbmF0ZSBpbiBh IGRpZmZlcmVudCBmaWxlKS4gT3IgYXQgbGVhc3QgYXMgZmFyIGFzIHJlYXNvbmFibGUgKEnigJlt IG5vdCByZWJ1aWxkaW5nIGxpYmMpLg0KQnV0IGV2ZW4gZm9yIHRoZSBhZGRyZXNzIHNhbml0aXNl ciBhIGJ1ZmZlciBjb3VsZCBiZSBhbGxvY2F0ZWQgKGUuZy4gb24gdGhlIHN0YWNrKSBpbiBhIGRp ZmZlcmVudCBmaWxlIHRoYW4gd2hlcmUgdGhlIGJ1ZyBpcy4NCg0KDQpCZXN0IHJlZ2FyZHMsDQri gJRFZHdpbg0KDQo= From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:49:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:49:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244852.1544211 (Exim 4.92) (envelope-from ) id 1vxR3u-0006Cc-Ma; Tue, 03 Mar 2026 14:49:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244852.1544211; Tue, 03 Mar 2026 14: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 ) id 1vxR3u-0006CV-K2; Tue, 03 Mar 2026 14:49:26 +0000 Received: by outflank-mailman (input) for mailman id 1244852; Tue, 03 Mar 2026 14:49:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxR3t-0006CP-Nn for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:49:25 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2a4010ec-1710-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 15:49:24 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by CH5PR03MB7791.namprd03.prod.outlook.com (2603:10b6:610:211::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 14:49:16 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 14:49:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2a4010ec-1710-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AdO9+cI2B0BjfDgxxvEEK7fM4i2A9Y23YKBUJ0dEh3Q9inltu/LQmmfyqxuGsX6VZLmtjd0CRSg6KYsNi3ahsdmpfsZnJRM1p1V5Avhm2RrHr0JjTTx3BWMKDXQ+hnYGwFBaL0tcWvgFG+4QhHCgxutqEx2ijixu/RDwDNO4HD+9NHr3/PBk61AJ68GFgzQVoTTAdkpwxFBdW9RvKADA/C1n1M2DpC4JLYoYeW7wkyvhBkrAl70Zzd+8rKUSbrLSx9ZVAFltQZWlbtGCkKGpSuX9UeOygg4tYSU9cadbNmozgDDzOFyji/WY2rdj0KrlFe0ppnUeG4RfcexuWz3x0Q== 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=ayOsLpThfJqd4rC0u7zujKcy9FTm8kkwUbInuB/ThCg=; b=QT+yClo5Q/Erah1DagfVXhsV/+nR9I/kGM/jZBugJH4wq5YCBuovCAaQLyxwBovMTvry9rm95zmhYSGbCx0xU/2W6PyLbNzF3LzFzvIKO7C8RUK6oAmb0n+MDMSOOiErFCjwfi8I+9nH+n2oTJMYdtXfhviCsb6I6JpD75lw43qiTzVelkhx4sroEoHElTCnKF0u9ht4kvZyT7IIkdAg1/yh8Grv5of24ah4ClpW944/8+ToRBDPrfxEI/m+EHYUzGV1ZDKqXQPFrzm7ZAZ2+qptm2diG8aR3tsCtdg3hrGs7jKoveKtd8ZUhdSAWIxSJucIDRhQeO43xVJmYUHaxA== 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=ayOsLpThfJqd4rC0u7zujKcy9FTm8kkwUbInuB/ThCg=; b=b6aydSQ/jDyBx+I1Yk18kHP3I8Axm/83M8AlIn/CUS+D8CLga6iasQfzyvwx2geIMnIL6kRwuDl91kP3Auih7/2ghLyMEPtFfYPH+fWTWYX5lBTI4CckfkPdkPDgNf6e+eH6gXy6AHkKIC/dIWSHGBKwG9KlbzMKOkmrBhEYF3I= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift Thread-Topic: [PATCH v2 3/4] tools/tests/x86_emulator: fix undefined behaviour in shift Thread-Index: AQHcp9gCO67+yoRhk0SyNFZDTeRIWLWc3oEAgAALkwA= Date: Tue, 3 Mar 2026 14:49:16 +0000 Message-ID: <7A6049F4-8AAE-4074-97E5-65070E25A165@citrix.com> References: <02d59353-8d59-4151-8428-dd6458f9165b@suse.com> In-Reply-To: <02d59353-8d59-4151-8428-dd6458f9165b@suse.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.400.21) 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: SA3PR03MB7419:EE_|CH5PR03MB7791:EE_ x-ms-office365-filtering-correlation-id: 11caad99-8ad4-4b87-c972-08de79340b49 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: dX+Ti14VDSuKYVfS2yePiB6gUudBtNReOlY8QxyCo2dVWPP2RI2onzFWVmx+QFMqwMpv1/j2p4PCZHHCD1EZrxiqL3SxpMxR68rQEI5PlPhWG9gwazsWQkjlGzYOXanNPTfnIfsyAneK7yshrws4eLR0nLGozDdw5lA3DBwim3ErrPcPw7MG4/ZdkJM/TNHIsn4Q/fqCwKSUnfMJJ/gh39hosGUr6HKpucZsIL39FD9r8A1ukoR29OnG4e1W7u4VS+A/YuzoTrJRCd16lTs5xeBkPqRPXXkkFbzs1vAyOd/6UVvMDs5MnQpD/alWZfKHGeCSfI91apX6AxxgqSYAREmz0K59b/mWjnR2gX1i95dGAjr7UtmJGml2/6cSA7qrc+Vwx1wC65cSF9SRUIAOuXrqs2bsLLhz20/vW3bQv0ChCxDbKUJK45mm1Jx5Ysg2USM37Pmu4aTxMhZ88+tEqoMlDjLh3PcJC0ew4D2lY+SM3yKuKPjV4Ua4zKDlovmrFbVfzGPNJMuWbiNxLweqpiA2/GIFqRcqBZjuSfk9RfGwH2fsuFxWn4L1R+I1lMsXbMh7iC6ZhYRNFvGQhsWkQzyVg+kLyau+uw09JO+dwmIEh7ZqIz5lO7dbq/1UL/tgbDV+9r7GZaVYarhDOnk1QXEF8a2MFRa5RxOSyUVKNaBvmWCsMAAfkax+9KdC1KX6VXa2aWyMUVPqzu+uzvNxr6vBFsu4Y+QIS4+IprZCVPzBTxh8tZb7LMZBlAxRsExJLcDHBSziEo0gyjtYv8VwqfPIGTuFMNJSHLlLmfW7AbE= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RXc2czRvSXpLeitiZnA1TGtwQWFIUTAzTVBFc2dLOVY1OVRaN25zWG5GVGJv?= =?utf-8?B?ZHJuZGFXSWNCbGUwR0tyanJOck9lR3NkdkUzbTFhWHd6ejZPaHZwb2s3NzIv?= =?utf-8?B?VW1vMFhaQXNMRHRiNk1tWksvTnNpb05IVm9tRW9mRXFoV25FUWh2VEhXcy9D?= =?utf-8?B?ZndvWVJMNlczaHJSaGpJcWUwczEwTXN6NzFHOU13KzJGRG50c01mU2hVQjJj?= =?utf-8?B?cWUyend4RmZacXFuNkZUb0x3YnEweUdYQkpUS2NxaDdsL1UzV2hFN2VpWERV?= =?utf-8?B?c0ZWQjFqeVYyaEQyL2FTUE90cktKcW40SFIwcnRIWHRNZklOTEdqV1lqMWNl?= =?utf-8?B?RWpWTXR4NzRSa2FkYkNjSGY1WTBJazBSYS9pZ1Q1MWlTdjBWdVB2TVBhZnR3?= =?utf-8?B?QTl4dTg2NU44TnEwVmZTR1BlZHprdkthb2V1WWF6MXppOEpIWFBtMDVrdFd4?= =?utf-8?B?Zk9GbFdyNnplNEZFR2QxSzhhSFlkTWUvQ2pOVzROTDVRY2h4aGpBTFkzZU1M?= =?utf-8?B?REFVL2k4eENnQVk0MDI1QVlMSEJNbHdkVitOR2Y5bW5kUGx3YjhlTmtFTGFr?= =?utf-8?B?UUZwdGVsa3N0QkFpU25mL21qSFpNT1NiYldsWmN3MVNCeGZDZDBVZDl0L3FO?= =?utf-8?B?cmgrbFdsaTUyeTVZaVdsUkNQZnlYZGJZOVRPNmsxS203bHJaYUZoTFlhWVpi?= =?utf-8?B?YkxOQVpkaVpxckU3cXhOMm05MXBDeVoyNXhwL3VTYXZQT05JUWtMU1ZQbVRZ?= =?utf-8?B?VWxVOTB6c1hTZVVpQWt4OTRSdnlGeS9wWTh4dmpUWWtFMUh6aUw2Y0hjZzFW?= =?utf-8?B?ODBMNFNQa2NOdXUvcWVLeU82eSs1U0JPYytQUW5BZ3V3R2tKN2t5dGs3ZWV5?= =?utf-8?B?M0xtNDZLTFloRTVaQ3JhNXJHa1VRbTlHOXFuemJJRnpRM0YrQVFpZE5qdEJ0?= =?utf-8?B?ZVQyRm4xY1Z4akdrdDZWeS9ncjVCNU1tanliWGNDWDByMkFRbUZzVTk3S3Ry?= =?utf-8?B?SUFmNDZTdFAwUUZ0dks3M0ZwZTZaRVFQaGJuSG9ieFg4TzQ3bGZuVUJPRTNC?= =?utf-8?B?SWwxdWMrV3ptbmRUM2FjTjdNRXAvRkQwUzdzNklSYXNBTnFKRUJUbUlJdU9j?= =?utf-8?B?dWYrd0tSS1hhVWJWeUw4VlFjZXl4RHVBeVZQby9ubTJsTVVsZUpSUUN1M2xj?= =?utf-8?B?Qjl3cnB1RGtnMmJXY2xtMFRQbHdEREdxZ2ZmbXpFVGZhQVNYb0s0WnR4aXo5?= =?utf-8?B?SjNyN1dEZkF3Q3dCMFc2eGFzUU1scjBuQ29PSGpTODhKTDBoMkU4bWhaVkMy?= =?utf-8?B?SG5MeUo0aUZkM0V3NTRUeWc1Rm5MV1gvTjEzSXhJVm42RVZtNGQ0dlIva1Fr?= =?utf-8?B?VDE3bVYrUXVzblBJbEZzUVhQM00vcncveW9nYWZoczRjdytVYWVHaU9rejY1?= =?utf-8?B?T1RCelJJTkZiZk01NmFRTGF4OGUyUk1aSktOaEV6dXF5aFV3R1Q1VVlGdi9Q?= =?utf-8?B?Q1dHMlFEaTdvQ3Y3RHI3Tm41M3NXUnFPQmFNZlEwMCtreDBWRW9VM0Y5eVZP?= =?utf-8?B?b2tvaFptdFZzeWlqRUFQWk55dEoraFd5STk4T0tHNXQ0UUc0aWc2cVNEZHVl?= =?utf-8?B?bk5aandzd1NGeEhCRnAyU0ljMWVjTndnYXRhenoxRy9oZnZzSzYxdVRMMVBY?= =?utf-8?B?L204cFBtVHRTbTY5UFppYWRhMXcwUk04dVVGRXA0dkxFN29Zd3dGMkNDa21T?= =?utf-8?B?aUJqQXVna1oyWWV6VW4xK2U0dnFPQ3pQa1p4RnZoTVNOTmxOcEh3N3NwUGNZ?= =?utf-8?B?djhMUm1sdTZnYkZMQ0loY0xLbndyQUNZbjM2Wk9JNnVQVHRMT0oyWUc1cnZn?= =?utf-8?B?eGtGSFhuL3BldVFUR2JuODZlNnQycXVWZE9uYkhMRjdlZ1I1b1ZMNnlyZmxz?= =?utf-8?B?Sk1sdTRNem5VWWVkNm9QeWNjUmNsSTE2T2dwbldQc2xPY3hkcjhoUFBpdWc4?= =?utf-8?B?aVFXWUhVRHkza2FMVk5FbGVDN0pqazBaZXdmTnRhaC9tNkxNR2dSU0hIQU1P?= =?utf-8?B?clFYb0Y4d3hma3cwRkFFM0Rkd290VkxiWU55Z0orUHVXVGRsa2xlQ1BMaWRi?= =?utf-8?B?N3RDMEJ3c1lmOWVxMzIyNHF2cmFocFdsYWR1VzJEYVJvRTgxaDJMbWg1S0xH?= =?utf-8?B?QkgxTEJ2UHBHUlh1dWxoMmV4cDJhb1VsNkorcjZlbTFjWmI0bHhxUWZhbFIy?= =?utf-8?B?SG9pVnRtN1B0SEI5M2tsTk9OTEVnaUh2UnYrdnB1UUl4cWluSDJ1SnViWkRU?= =?utf-8?B?dTRMNTMwcGd4YWlmd3d1cDdZNzVkcEMzY3J6NEYxWXhhSHFsdTRhWHN0Szdj?= =?utf-8?Q?cUZmL6R+PMXOinQk=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11caad99-8ad4-4b87-c972-08de79340b49 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2026 14:49:16.7481 (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: CHCKyeVhfCrKKY/99ob4ha/9I1Cr9Z9Ka5702NFNqFucGLaj4mh/Y56vA6WKvVsHVXD0fuAehmGInz8MzsQr5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH5PR03MB7791 DQoNCj4gT24gMyBNYXIgMjAyNiwgYXQgMTQ6MDcsIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAyNy4wMi4yMDI2IDExOjU4LCBFZHdpbiBUw7Zyw7ZrIHdy b3RlOg0KPj4gLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3Rlc3RfeDg2X2VtdWxhdG9y LmMNCj4+ICsrKyBiL3Rvb2xzL3Rlc3RzL3g4Nl9lbXVsYXRvci90ZXN0X3g4Nl9lbXVsYXRvci5j DQo+PiBAQCAtMTEwMCw3ICsxMTAwLDcgQEAgaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2 KQ0KPj4gICAgIHJlZ3MuZWRpICAgID0gKHVuc2lnbmVkIGxvbmcpcmVzOw0KPj4gICAgIHJjID0g eDg2X2VtdWxhdGUoJmN0eHQsICZlbXVsb3BzKTsNCj4+ICAgICBpZiAoIChyYyAhPSBYODZFTVVM X09LQVkpIHx8DQo+PiAtICAgICAgICAgKCpyZXMgIT0gKCgweDIyMzM0NDVGIDw8IDIpIHwgMikp IHx8DQo+PiArICAgICAgICAgKCpyZXMgIT0gKCgweDIyMzM0NDVGVUwgPDwgMikgfCAyKSkgfHwN Cj4gDQo+IFdoeSB0aGUgTCB3aGVuIHJlcyBpcyBhbiBhcnJheSBvZiB1bnNpZ25lZCBpbnQ/IFdp dGggaXQgZHJvcHBlZCAoaGFwcHkNCj4gdG8gZG8gc28gd2hpbGUgY29tbWl0dGluZyk6DQoNCllv dSBhcmUgcmlnaHQsIGl0IGlzbuKAmXQgbmVlZGVkLCBtYWtpbmcgaXQgdW5zaWduZWQgaXMgZW5v dWdoIHRvIGF2b2lkIHVuZGVmaW5lZCBiZWhhdmlvdXIuDQoNCkJlc3QgcmVnYXJkcywNCuKAlEVk d2luDQoNCg== From xen-devel-bounces@lists.xenproject.org Tue Mar 03 14:58:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 14:58:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244866.1544222 (Exim 4.92) (envelope-from ) id 1vxRCE-0007vp-Hg; Tue, 03 Mar 2026 14:58:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244866.1544222; Tue, 03 Mar 2026 14:58:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRCE-0007vi-Em; Tue, 03 Mar 2026 14:58:02 +0000 Received: by outflank-mailman (input) for mailman id 1244866; Tue, 03 Mar 2026 14:58:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRCD-0007vb-BB for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 14:58:01 +0000 Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c200::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5e77f4cd-1711-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 15:57:59 +0100 (CET) Received: from DB9PR05CA0004.eurprd05.prod.outlook.com (2603:10a6:10:1da::9) by VI1PR08MB10005.eurprd08.prod.outlook.com (2603:10a6:800:1bf::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 14:57:54 +0000 Received: from DB1PEPF000509E5.eurprd03.prod.outlook.com (2603:10a6:10:1da:cafe::56) by DB9PR05CA0004.outlook.office365.com (2603:10a6:10:1da::9) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.19 via Frontend Transport; Tue, 3 Mar 2026 14:57:50 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB1PEPF000509E5.mail.protection.outlook.com (10.167.242.55) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.16 via Frontend Transport; Tue, 3 Mar 2026 14:57:52 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com (2603:10a6:10:1aa::17) by AM8PR08MB5554.eurprd08.prod.outlook.com (2603:10a6:20b:1c5::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 14:56:50 +0000 Received: from DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b]) by DBAPR08MB5590.eurprd08.prod.outlook.com ([fe80::f68e:1311:9070:68b%4]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 14:56:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5e77f4cd-1711-11f1-b164-2bf370ae4941 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=QUadyBHxJzuQnJiBDFzuoTvJrwMR6HoAu3yLR3UZdiCCAvIL9vIWZOUf3Nw2Fm2qxde5QTy4O3cBQK820JY05yzmzgpQwzvXZyON+iMgxkk68/PfE0szIxJzNnn7zxPNvbpsFS5kE+Fr0YcviO4hpWRNM9aDMhW+5Tk9Gwgui7nwiTq0cgVkg31f5FWcVlFmtBxP7x+0ohrBaOn9lgx8lmCHGTqJrY9pV/wMHBPVvg8vcLemG+Eq+b7tEd4ZpZxHzziYVlrlzR9vC8YRkX17Hfnm/W8Ed3IgROjLtE09ns7F1CgPIoM+05q299UP/s+FS3lOwavbTLcN8YJBjT1GPw== 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=XZJ6unCO6hnV4jRvbsZ0yfL6SFJrbINWnvnbn3XZ/9k=; b=F1zyermFNIMaEh3DaCRY9DXshqLXO3t+OiQPH6DunBo4CIEsyttLX8OnffVq5/phyGBcvFRHCsoOW1h/9rQ4141ZUwQnTeXZ7Od6tw8L3fX34LjhozSYqPUYYyItkYuC8+cnUnOzL+uHGS04rQidFElSmEAyCv8EpBuHDYeuVzhux6cqabH2i8dKlVmOOGG/aGgDRZ8QJUWw/zUlGvEy0X4gIhYeJxOdoaoy2VplOZnJ+1k6EZrxcteA8UN88d++KEZvrr/WbmNz1uHwcT5D2lwnqoc35UxopK6DGj+s+RgWi/C0mKYTV7fimR9fvLpSnrjsOp8kD00gkkOtpnYhWQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=gmail.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=XZJ6unCO6hnV4jRvbsZ0yfL6SFJrbINWnvnbn3XZ/9k=; b=bFUIpUVvipYOrzvUPOfYgLbaGLT995dfi7MX+NEJhDmi9sMP0hg5IXu4tapAF8ZEJxTNy0tImJjWpeN4oCT1YCR0rBz9F2Moc858ILAUhuldEj+RGh/FYoAkYnnvxtYb8WuOKb0cJ6cdpNUYeJ0B/2DuJX3HBN8bVaWLSZkGE5A= 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=ZR+ghtcmeVNLUajld7A4uQ6DlxuVrhFVhy+wGUMgpEzGyusYe07BKZu7N2E5F3PzEaKC+by1zaFHRZHe3CfeNGKp8pz8jeuM4/zr5AVF8FTK3SMEnYF3nAi49YW8vkgtzENT8TJzoSh2JprXn9hSiowb7BQWYDPaB78mbmFfrq0XGcopfxfSYpSVqwnpEvN+TUpzXMbEzftqWbbqRC61FlvV24IXcnurN13Nx3ZN6sC2Qb2r3P6WaT1jFHUdyH6K6aRBc3w1m9s1Ve4Q1kKkFUOFx34WAguVQqIen3v0qbVP7EgewBFhD5AaXMvqFLo2UN/r15u1uFPHw5KYyt3p9w== 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=XZJ6unCO6hnV4jRvbsZ0yfL6SFJrbINWnvnbn3XZ/9k=; b=VMClxGhBoX2uecS0Zg+OsC00Hz4eilpHmQl107OKH0TXX4FKXJ9IzQHy5I/ttd+f9AdrFdDljY3Urj8gJiWrD4zipf3uSwvM6omrD9BGZIiNNOqaRJWAMVNqckHBJ+d5St7ZiEntZaJUwXc6BSJQdcBJsnhjVB490TyAnB3X39dnIgMqGbSEoHycMhg5oKHtaqauYE+tPNgs4B+JJ06Jm1nePeTvc0TjroWr4ho5ytJyb1uGtw1SPEO6F1kMN6f1Y6BC8b6wZ6iPnUZNND2e4lNTYBP1Mv+/wqCKjylD3cJmUUkT+kAMT2QWKEVtAkPMRq7d5kK7ZPPAxQtsnbAwBQ== 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=XZJ6unCO6hnV4jRvbsZ0yfL6SFJrbINWnvnbn3XZ/9k=; b=bFUIpUVvipYOrzvUPOfYgLbaGLT995dfi7MX+NEJhDmi9sMP0hg5IXu4tapAF8ZEJxTNy0tImJjWpeN4oCT1YCR0rBz9F2Moc858ILAUhuldEj+RGh/FYoAkYnnvxtYb8WuOKb0cJ6cdpNUYeJ0B/2DuJX3HBN8bVaWLSZkGE5A= From: Bertrand Marquis To: Oleksii Kurochko CC: "xen-devel@lists.xenproject.org" , Romain Caritey , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Alistair Francis , Connor Davis Subject: Re: [PATCH v6 05/14] xen/time: move ticks<->ns helpers to common code Thread-Topic: [PATCH v6 05/14] xen/time: move ticks<->ns helpers to common code Thread-Index: AQHcpxZBc3YdHjKklE6Q6qyeWG5VUrWc7bSA Date: Tue, 3 Mar 2026 14:56:50 +0000 Message-ID: <2AE980D3-571A-4AB9-A01B-EAA90D3EA0B9@arm.com> References: <545c2af877d519b1186c79fd6108d33e7e52cd3b.1772016457.git.oleksii.kurochko@gmail.com> In-Reply-To: <545c2af877d519b1186c79fd6108d33e7e52cd3b.1772016457.git.oleksii.kurochko@gmail.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.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5590:EE_|AM8PR08MB5554:EE_|DB1PEPF000509E5:EE_|VI1PR08MB10005:EE_ X-MS-Office365-Filtering-Correlation-Id: fb0edb1d-175c-4498-06e9-08de79353efc 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|38070700021; X-Microsoft-Antispam-Message-Info-Original: 3bqowzC5bgtDxXfAxvbi98OnbXlZG7j5dMvHXCRH04JHs3Q6NFI7JoEcLytNvsrW7QTyWcEh6TmQCcWvqyeny421A34uqWinchij+rmPqKIuJuBfpqn/Mq+JxRU0u3Mx1JBUxBYTAiZUH7TnUKn97GZEFC+YmB0EKiSfeZzap2/W/QQSa/UpoWHR1OTXCm8xIbFKvDjYQoTMv29uOUanCHEqVfoMdh9xTk+xKfUJS/C+nIu2KJfEFA8Kqs4QFDBOo1JECYunplsZmtQLIV9bla+MliQM0QffFBZS7MpOfIXrV8NMOMPAHvDVCCDp6qxZJy6l7k3PLHj7OgUXbTkQhTPeaZBDSokHCX+zWuNXammm+TJFiXO66KQhVdDfJNzNW9lXR7mqtE0KmL76Ki5oGG7Q8SbBneVTh19DCIvMV8HvGJxBjDxSAV0fNAcb2xzSqyCXHBjnN4QPi5a1kLKxKAYli+0ablu+hDSc7/5eeafjomxRdjayw9MVFGaTsw4xUQxdZc3tjxvtzbjwGm+IYa45p2hbLRTqWhxdONH+/Gzh0nslvndbeOeG1tOsk/O3r8fNduSWh2v67M4qOb7TRfpM7sQ7hWrq/YfmKdIlrd0tIW/tWr/aED5fFF4idCicwHyRH08l33S825vkR62oswzSUr59fDVe/S3IPef6oMAxOdgAcKl//HWmAuMmyguqC6W+tieEbTiKrIWaAZsowVzeBE6jUSfS3I9FKAXdEo+J/FiW1SEHwx8l8zp2FGYa8GZF0sWrJfvwWYmhJU7Y0a7p7CMADPmlUdiSPwxqWJ8= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBAPR08MB5590.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB5554 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB1PEPF000509E5.eurprd03.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 34dde7f7-89b7-4957-5e7a-08de793519a6 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700013|82310400026|14060799003|35042699022|376014|7416014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: oLbUm7AagHDRimb8k3+GMK2IgwRxnKCzZuTbRLKhcZcpkOZkAGf0Dy2soArGxC/xzMVUhqh3qtFlHUeS+QqK+/YnEGN1j9oMpq/Ia2/AFVhvkUNiZ+2iKs6BpTWcjyi2h4J7P1ObvLbXCVczphYPDVGCVd6m2clmuN0ZeErzr+CU+iA7BbWREB/QSRqgtDI0IPS7Q5H0ocScm8pcU1i+vTqaTtQN7ChquiwXPOjt2Ptj1w9vJpxPFw5lgJx+IUKhwNHVyqHw+WwKja9ZRL3iD01ZsW/0H3uQM4HpWdH4JqpxQSgv8jXridvNFEY7mmK+lfHQVYs1j6XO3QxVeKiQyHequdwn+HqLh2nzJza8u5faYCe9MGHQlnMkvdHhjnxbNjpou0dPU6j0Tb+dYerpGQiWX1dUlOPPPOxLorqTtNkH374L/H6Nn8IAf54GyFxF1xe+NoJ+BP2YXLS4KqhWhFQTM0yz9NVnvpukDJtLEzmjreRH16q930Lw7fChEiVGpmwhwEJ4FRYCuzl+u5Sz+NyZ68ExaHuxv96Hr71jZDZ8DilpKwnzPwnDjVmA4qEprClmy+AFaw4vCLRf3fvg2ndYjo/mR0ekHHZc+YHUzZ0Buap208c0swSjBeGnJIU9HePisY+QX7cxdjy/iPPvrnyfZ6D/lOtFrK3e558F7gh/gFEr66GJtdvOS8NqQtlzvnyGsViqtdvoW+Lq611MtYEswX2pJG3H8BuXGYygUa7FOSPUfGSxLBG6uMUiAjmNQm9XAKxJpDni9AyIxraPdM1nXE2mjIIR2f+qwb9P9jVJ4F9zABnf5UqDw/tNSwUzoYbej9O5jwPuQZzF8XSSzw== 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)(36860700013)(82310400026)(14060799003)(35042699022)(376014)(7416014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: HeEW6N71CBkJ0SIQw5TJn3vGpdvm+ndQShWocCAyngjqkHPal2hTdAiVkhBmgcvq0btzfHFgo3DXF1H0z1mFmp4ac+jvNje+Z7BBu0nQKQLYxlCwuGkcn1wvnTzJMzFzt1eZkzyWufC755DokasWOdIPGqQeclG82JUx63RoKiGxYvl5In/69Tb1c49ghMLcw7MG3ohbu9UkbEzCc+WCauY/n1iLV6SLmuZIRHV99gUotGumgFX8gMdgZCDurSZHlqV2eOXF8v2nipRH9GDhDx6ggOvHqWdbQYammsNiS09oq9fvd7AG7Wn9B6HIbOFMy/i0BBw2hJGiBMG105m6XD+f57hRq9KVezpH6nKZhshiJZ+F50AUxSYjCcKgWTCNhZ0wLO0uN6YGW+nrDwQ2V49fbHCAeMV6tB2YS5g+uMvoIFW5wULOhEE1NpPzTKjP X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 14:57:52.8962 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb0edb1d-175c-4498-06e9-08de79353efc 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: DB1PEPF000509E5.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10005 Hi Oleksii > On 26 Feb 2026, at 12:51, Oleksii Kurochko w= rote: >=20 > ticks_to_ns() and ns_to_ticks() are not architecture-specific, so provide= a > common implementation that is more resilient to overflow than the histori= cal > Arm version. This is not a practical issue for Arm, as the latest ARM ARM > that timer frequency should be fixed at 1 GHz and older platforms used mu= ch > lower rates, which is shy of 32-bit overflow. As the helpers are declared > as static inline, they should not affect x86, which does not use them. >=20 > On Arm, these helpers were historically implemented as out-of-line functi= ons > because the counter frequency was originally defined as static and unavai= lable > to headers [1]. Later changes [2] removed this restriction, but the helpe= rs > remained unchanged. Now they can be implemented as static inline without = any > issues. >=20 > Centralising the helpers avoids duplication and removes subtle difference= s > between architectures while keeping the implementation simple. >=20 > Drop redundant includes where already pulls it = in. >=20 > No functional change is intended. >=20 > [1] ddee56dc2994 arm: driver for the generic timer for ARMv7 > [2] 096578b4e489 xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and > XEN_SYSCTL_topologyinfo to common code >=20 > Suggested-by: Jan Beulich > Signed-off-by: Oleksii Kurochko > Reviewed-by: Jan Beulich Computation is changing a bit from MS to S removing the 1000 factor on arm but i do not think this would have an impact so: Acked-by: Bertrand Marquis Cheers Bertrand > --- > Changes in v4-v6: > - Nothing changed. Only rebase. > --- > Changes in v3: > - Add Reviewed-by: Jan Beulich . > --- > Changes in v2: > - Move ns_to_ticks() and ticks_to_ns() to common code. > --- > xen/arch/arm/include/asm/time.h | 3 --- > xen/arch/arm/time.c | 11 ----------- > xen/arch/arm/vtimer.c | 2 +- > xen/arch/riscv/include/asm/time.h | 5 ----- > xen/arch/riscv/time.c | 1 + > xen/include/xen/time.h | 11 +++++++++++ > 6 files changed, 13 insertions(+), 20 deletions(-) >=20 > diff --git a/xen/arch/arm/include/asm/time.h b/xen/arch/arm/include/asm/t= ime.h > index 49ad8c1a6d47..c194dbb9f52d 100644 > --- a/xen/arch/arm/include/asm/time.h > +++ b/xen/arch/arm/include/asm/time.h > @@ -101,9 +101,6 @@ extern void init_timer_interrupt(void); > /* Counter value at boot time */ > extern uint64_t boot_count; >=20 > -extern s_time_t ticks_to_ns(uint64_t ticks); > -extern uint64_t ns_to_ticks(s_time_t ns); > - > void preinit_xen_time(void); >=20 > void force_update_vcpu_system_time(struct vcpu *v); > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c > index cc3fcf47b66a..a12912a106a0 100644 > --- a/xen/arch/arm/time.c > +++ b/xen/arch/arm/time.c > @@ -27,7 +27,6 @@ > #include > #include > #include > -#include > #include >=20 > uint64_t __read_mostly boot_count; > @@ -47,16 +46,6 @@ unsigned int timer_get_irq(enum timer_ppi ppi) > return timer_irq[ppi]; > } >=20 > -/*static inline*/ s_time_t ticks_to_ns(uint64_t ticks) > -{ > - return muldiv64(ticks, SECONDS(1), 1000 * cpu_khz); > -} > - > -/*static inline*/ uint64_t ns_to_ticks(s_time_t ns) > -{ > - return muldiv64(ns, 1000 * cpu_khz, SECONDS(1)); > -} > - > static __initdata struct dt_device_node *timer; >=20 > #ifdef CONFIG_ACPI > diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c > index d2124b175521..2e85ff2b6e62 100644 > --- a/xen/arch/arm/vtimer.c > +++ b/xen/arch/arm/vtimer.c > @@ -12,13 +12,13 @@ > #include > #include > #include > +#include > #include >=20 > #include > #include > #include > #include > -#include > #include > #include > #include > diff --git a/xen/arch/riscv/include/asm/time.h b/xen/arch/riscv/include/a= sm/time.h > index 1e7801e2ea0e..be3875b9984e 100644 > --- a/xen/arch/riscv/include/asm/time.h > +++ b/xen/arch/riscv/include/asm/time.h > @@ -24,11 +24,6 @@ static inline cycles_t get_cycles(void) > return csr_read(CSR_TIME); > } >=20 > -static inline s_time_t ticks_to_ns(uint64_t ticks) > -{ > - return muldiv64(ticks, MILLISECS(1), cpu_khz); > -} > - > void preinit_xen_time(void); >=20 > #endif /* ASM__RISCV__TIME_H */ > diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c > index e962f8518d78..2c7af0a5d63b 100644 > --- a/xen/arch/riscv/time.c > +++ b/xen/arch/riscv/time.c > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include >=20 > unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. */ > diff --git a/xen/include/xen/time.h b/xen/include/xen/time.h > index fe0d7a578a99..2185dd26a439 100644 > --- a/xen/include/xen/time.h > +++ b/xen/include/xen/time.h > @@ -8,6 +8,7 @@ > #ifndef __XEN_TIME_H__ > #define __XEN_TIME_H__ >=20 > +#include > #include > #include >=20 > @@ -75,6 +76,16 @@ extern void send_timer_event(struct vcpu *v); >=20 > void domain_set_time_offset(struct domain *d, int64_t time_offset_seconds= ); >=20 > +static inline s_time_t ticks_to_ns(uint64_t ticks) > +{ > + return muldiv64(ticks, MILLISECS(1), cpu_khz); > +} > + > +static inline uint64_t ns_to_ticks(s_time_t ns) > +{ > + return muldiv64(ns, cpu_khz, MILLISECS(1)); > +} > + > #include >=20 > #endif /* __XEN_TIME_H__ */ > --=20 > 2.53.0 >=20 From xen-devel-bounces@lists.xenproject.org Tue Mar 03 15:09:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 15:09:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244878.1544231 (Exim 4.92) (envelope-from ) id 1vxRND-0001IT-GD; Tue, 03 Mar 2026 15:09:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244878.1544231; Tue, 03 Mar 2026 15:09:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRND-0001IM-DT; Tue, 03 Mar 2026 15:09:23 +0000 Received: by outflank-mailman (input) for mailman id 1244878; Tue, 03 Mar 2026 15:09:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRNB-0001GQ-RQ for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 15:09:21 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f3840f2e-1712-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 16:09:19 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by PH7PR03MB7416.namprd03.prod.outlook.com (2603:10b6:510:2f2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 15:09:15 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 15:09:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f3840f2e-1712-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=oYb7psW1B0Kwq5gm/OC0OO6XcIZ0B9/48wosGeZapDERuZ7uNU6QupMs3xG9i105neJyjtBIJX9JTmmlrGXVW63xKOQ4587VjmR50XTrvmT+L1JWpJUdrwj2FGNaySXm+EJ1lBzuUji859Kx9pDFbwz4mjkj83+QBSlulBo73PyiRiWQdt3AA3xf14SBSskuJDfmPfU8XxKJcvOGkpi16ncqrRKanXALTxjCdtZdIumF+3fffnZ3PRgIddJqgwnNyas0hruQqc2zF8puttMnERA+/GbuuFgg8UVTPJsS+QMpqGYBrppKyHQXpLZr6c8uvJpqto3uWV4/bUi2IWT3dw== 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=BgbmO7zRl+U0OFXcYkuqQLUwYhfPPxpJt2W+xf5q6pU=; b=AdmoaKbjRXDxmkbOvLWnvnFo1Ab9OTJhlUMprDpWkK9GZ49/PgD9tPMROfh0NXJjLPB1dh40odeCCsHESWcGahTzmY68VigQvRZ/F7S7GbjgeAvNKm8VK/uRYDqGDF5mVI8/EsSUQKeYLH8An+zeYUTv8KH2zoVPaBekSWEqs8yQ6uVlOLt+XXBv9DXkU/5EgCMzi08Lz0Pr1Y1gUCjTjHhDt3H0vdYxwwsNOOT4wZZI8XuPEV9/lB2ibPQf1q2qd5z00dIvtA70KuDVa700VECL+WttEsdoMREV3qg9dDOzAkFTFVZySdDsNHrFZlTUtlay2reTLnGvMpjyqae8gg== 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=BgbmO7zRl+U0OFXcYkuqQLUwYhfPPxpJt2W+xf5q6pU=; b=tc4bA8UHyYHXh0hYpT49A+Wtvbz8z+jHOXIjiC/XJqFEbt/7/e7ciH8RiMGASCUryPPzS5ZMOOX0N6tsbu7lCqiSlJvUC8y7NepE8NgrViZvQnupt9VxLw78yVvqQ5eqmPV8i60+Jxi2ikuKmLMqNkYQgpJTIEWmpvLrUVDqDuw= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Topic: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Index: AQHcp9gBGAcR9pePk0GnYyu6dQzUZLWc3C6AgAATegA= Date: Tue, 3 Mar 2026 15:09:14 +0000 Message-ID: References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> In-Reply-To: <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.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.400.21) 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: SA3PR03MB7419:EE_|PH7PR03MB7416:EE_ x-ms-office365-filtering-correlation-id: dd98ad93-ccf4-4834-3332-08de7936d55a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021; x-microsoft-antispam-message-info: tslpIczhbeZZYJFmM0VDOYkaGpfJa9m7Y7x3SPHAKWlRnmalID5mkGuCDJeYegxlSKE1Sk4P82MSDjg0EIhnviGc9fmi5W871IVqKzbOn9+zlaQ8gzQWQfmGX4bzQXW2y1d/f9MAKgdQRLtpUJBoGoY1/LVT1AeAX16+x2LlXG08LJ8lPLeD0V5nVhceYfQ8iQTrMpuJTRwwG/+ZM4L6DikJfG+tUnzAqhQo8PzyNiwVlzerqwLYvpn8baakyGcg+7Ij8iGvCbt82rBDuY8a+jeSQPExWEw8TvFQHbbbXSKuyyFjpx9jG7R2+hjdX0NK9yJnjvEXh2sqyRY2f8gshL08u8BtFXbgkH0GDOfVxmRoiPLmP0WLcN5Mw45wjituSoHfkO81B9Pk/+2PCNbIgX8kDX917gzWj9n6qwIfq+7zsExTg585PXPIEvAp8p5K7K4yfiRGgf5bnTkIYF5Tbyhcf7whEyklQV/fqt/bZt96mJTbl4MEqR3POhqN1Jj9m14F0n1lrxbpmlcXJUX7+WuJvdqdXbEP1tnEM1ovWBPgJpbEZL1qn3jRbtI7/JhFaSkuC/fDGmTyXq56k0IIubOs+mPWqHdyS6Zvq2nM6/8yIuHJpCzn0xHtykF2wTkSMzKBBVK13lusVHu9EcYoK4B+8NKq0oGyGH9ulJhXNySFZW4fwwLov9wtNHMP/BIVLBgzkU7t8Oz9Yjok6cHb00SONH9qi0u+/K6FeUQx07hHXKbByjIDrRGlPgM+1lsSoK0c+mSKLN2iGZ62zZsUiuiE/VWWoyl1KTkXvmrNbt4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?V2F4RHpDQUN0bzZQYTJoS1g0OWtpaENpUHVOUFFQL1JlNEs4QnV6QWgvb0V0?= =?utf-8?B?MHN6RXlJQzdINDdSbDRkdEp5eEYvaVVLWmtib1N5UzZkTTFEUVN4VnNrRE10?= =?utf-8?B?eldkaEk0d1FRY1pHaGVUdVkwT1VObnFaU2xLa0g2S0Nzd1d5QUZDcFJWOVY4?= =?utf-8?B?dzRINlJLSmRvbWhFRWhzVkRsNDBsemRQUDFTNHpXa2FwRnZ1ZDhJVXdjRWgz?= =?utf-8?B?eFhMWm1NVmFBa3JNRTVLQlloUnBzMEVVUDI5OHJPSkNLbDVMY0xpMndBOG44?= =?utf-8?B?ZncxMkZxSk1xWUJQK21yTXVvaVhuNFRrbkFOVVlNTDJVZjhrZ0xtNnNSSWxC?= =?utf-8?B?alV0SSt6aFU4TW1ZODNEU094Vy90WlVGY041V0FSM2pQOEpTdEtGMDkvZXo5?= =?utf-8?B?dnJoMFNySHZmRGpHOXhJOHA3U0lRdlhURWE0d2s1Mnd4U1J5Q1VIN3oyd0VU?= =?utf-8?B?eVM0RFpoMWsrL3RLSmc2Z0JDRHN2M2xHRmJrS3JOblFYZmlrNU8za0p1U2Q5?= =?utf-8?B?VDNjQUMreWNvTkw0Yy9TYkZrY09pYjBTNTNDWnVGN1phMzVCcXhZc0ZqbGNY?= =?utf-8?B?OWgxUVM4L3ozcU5YN1l4WlhlM1VkUDdoSEdaMzhPVG5NWEZkYlNCS0hWcnVL?= =?utf-8?B?WVNNREh6Q2lRckcyeFJ3SVNGQkV3dDZHRDlSQUxHcmM4MnF6M2x6ZUNTdHdy?= =?utf-8?B?dFplK3NtZ3lMcDJpekxQS0tTUGZjd0VQbU4vWEhZeWdxR0plaXNhaGNkbEVz?= =?utf-8?B?SjNLZi9ETitWbWVybERRTldCN1YyUHU0dExYQXdHN2ZBNjhINHg3Q0hHYmo1?= =?utf-8?B?WmJYT0RWTmU3RWJaSmxGOERxY0J1NjloemI1TUFvdnM1M1RmTjlQQ3kyWGxv?= =?utf-8?B?TDFBbk9MV0huMC90V2FvaEFHRUg5MmNBUDEwWlRGWThwRGVHNklnL3NreThj?= =?utf-8?B?ZjBveXp0VjNPV2JXenExZTBLbXNTQ0hRejF2R3YxdEFjdHZsTlpFSlBtM1Bs?= =?utf-8?B?Z2diNUgyd2pvQnU1MGVUQUlBZlZ1cTlmZ0dCVGs2RFRlbFJPN3JUc1J0VUtY?= =?utf-8?B?WWRyQjl5R0dXZ1NhZWZhU0dna2JYbWZDcE1ZNUNDRjVTZjRieGpsRlIwVzY4?= =?utf-8?B?dGorQkExaEt5bFpkMkZjNUVMZmdiYzJ6R08xTkg4Unk1MnNsRU5ob1dYVEoz?= =?utf-8?B?VzF1YlN6dkljcFhXOFY5VzJQTmlLdDM3MnJlekJ6a1hHdFdoQmxjamg3VTdD?= =?utf-8?B?WHFQYXEwS3NjdXEya21VR0w4cXh4dk92aUdtL0RDZ1Rhdk9KeVQvbFFRM1Zq?= =?utf-8?B?SXJITFdXZGVwWkZFRWpmMFU2bWdXMHhRamo4dC93czQ1Sk9MTnd1MDYvMWtG?= =?utf-8?B?a0lxNkJTWnBOaHkxcXFqWXdaSWJzUkllWnVONkpkYUFDMU8zdVhSbllKYWx4?= =?utf-8?B?QmlPSVVaZXVFOVBLajM3QWR4Z3V6NklESnhUMnFtQU9JK1NEM1BsckNyb3U5?= =?utf-8?B?QkoyUi9rcC9sek1FeHJSSVhsVnVSWTRJdUlEamk1N2NxM1pxQXNxbTFYTE5a?= =?utf-8?B?TzRuaUZoWExscEJFV2hhOGVkK3NRa0YvbWU2ZUFRd1l5Y2JYK0RZSVZCVjZD?= =?utf-8?B?UWdReCtRRzk3RWx6WldOTEl1LzJTWllYVG92L1BiRGF5RHBKMnhHWi9JSk9E?= =?utf-8?B?TkFTMmVoSXpZaWJnRStaSklEa1lRR0VBR0NBMG51RVk1cmJpV1cwaVdUdURV?= =?utf-8?B?a1BOUnRydkcyZXlHZXNsTHhxbmwxYjdPTmZZRmJPVWk4SkhucnY0YnhaMmx0?= =?utf-8?B?ZzVIc3RwdE84QmJ6UURnZnlWV25HN241U3lwb3c2cmZldWFDaXU4QmV2V1I3?= =?utf-8?B?ZS9zUkcrMWk5VjlxOHdqL2FENkFzRG80Zlh3bGdnRFk2WGdTdnFQZzRScURy?= =?utf-8?B?UXhsVDlyeWl2MXJvWXBMbkx2enhjWUJNbGxoQy9rRytwZ2ltRWtLWFpNenFh?= =?utf-8?B?ZGl6WHlBWXlXVU82S3dmZ0pGc0ZVd3BuSzFNSkNYM1ZubGk2Y1pLVjVXTlBM?= =?utf-8?B?Q04wZGdDYjNxSEJLSGJvWTM2OUcxRU94M0RiZkwwM3prZitnejRlZHdGSHVI?= =?utf-8?B?WlQwRE8wK2xER3VubWVHd3NBdmxneWdyT2ZzRG9yVnYrR2V1T3BLNkF6cnc5?= =?utf-8?B?ei95K0pWTzZnbEY4amtzZkJvWEVrMTl0SVFZbGRmS09mVktuMXNuSmJmS000?= =?utf-8?B?cVZRVVVEMWNPNHZMOC82LzVzQ2VQcW5UdDhGKzQvRnF5bWlkekZVamVFR3Zj?= =?utf-8?B?KzFuVmM4RmlqaGQzZDVrSG9YOVo0OEVKSlVML25yWkEyUktEVG9qMVZKQUlz?= =?utf-8?Q?WX+2RsApqvsjxV44=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <06488F99EFA21A4CB374663815975DE5@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd98ad93-ccf4-4834-3332-08de7936d55a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2026 15:09:14.7612 (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: eKx0BYjRCgffVYKd+qoOYoCgf3AySG0gsr3fCU1/VumXt275Vot9zsoWI0DWc2kIR/6FbBrW4QVhcDeLeGjbkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR03MB7416 DQoNCj4gT24gMyBNYXIgMjAyNiwgYXQgMTM6NTksIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAyNy4wMi4yMDI2IDExOjU4LCBFZHdpbiBUw7Zyw7ZrIHdy b3RlOg0KPj4gLS0tIGEvdG9vbHMvdGVzdHMveDg2X2VtdWxhdG9yL3Rlc3RfeDg2X2VtdWxhdG9y LmMNCj4+ICsrKyBiL3Rvb2xzL3Rlc3RzL3g4Nl9lbXVsYXRvci90ZXN0X3g4Nl9lbXVsYXRvci5j DQo+PiBAQCAtMTg4Miw4ICsxODgyLDEzIEBAIGludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJn dikNCj4+ICNkZWZpbmUgZGVjbF9pbnNuKHdoaWNoKSBleHRlcm4gY29uc3QgdW5zaWduZWQgY2hh ciB3aGljaFtdLCBcDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2gjI19lbmRbXSBh c20gKCAiLkwiICN3aGljaCAiX2VuZCIgKQ0KPj4gI2RlZmluZSBwdXRfaW5zbih3aGljaCwgaW5z bikgIi5wdXNoc2VjdGlvbiAudGVzdFxuIiBcDQo+PiAtICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgI3doaWNoICI6ICIgaW5zbiAiXG4iICBcDQo+PiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIi5pZm5kZWYgIiN3aGljaCJcbiIgXA0KPj4gKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICN3aGljaCAiOiBcbiIgXA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICIuZW5kaWZcbiIgXA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluc24g IlxuIiAgXA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIuaWZuZGVmIC5MIiN3 aGljaCJfZW5kXG4iIFwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIuTCIgI3do aWNoICJfZW5kOlxuIiAgXA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIuZW5k aWZcbiIgXA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi5wb3BzZWN0aW9uIg0K PiANCj4gTmljZSBpZGVhLCBidXQgd2h5IG11bHRpcGxlIC5pZm5kZWYsIGFuZCB3aHkgZW1pdHRp bmcgdGhlIGluc24gZXZlbiBpZiB0aGUNCj4gbGFiZWxzIGFyZSBhbHJlYWR5IHRoZXJlIChhbmQg aGVuY2Ugd29uJ3QgYmUgZW1pdHRlZCBhIDJuZCB0aW1lKT8NCg0KSSB0aGluayB3ZSBzdGlsbCBu ZWVkIHRvIGV4ZWN1dGUgdGhlIGluc3RydWN0aW9ucywgc28gdGhleSBjYW4gYmUgY29tcGFyZWQg YWdhaW5zdCB0aGUgZW11bGF0b3IuDQooRXNwZWNpYWxseSB0aGF0IG9uIHRoZSAybmQgbG9vcCB0 aGUgaW5zdHJ1Y3Rpb25zIG1pZ2h0IGdldCBkaWZmZXJlbnQgaW5wdXRzLCANCiBhbmQgdGh1cyBw b3RlbnRpYWxseSBwcm9kdWNlIGRpZmZlcmVudCBvdXRwdXRzKQ0KDQpJSVVDIHRoaXMgd2lsbCBs b29rIGxpa2UgdGhpczoNCg0KLy8gaT0wIHVucm9sbGVkDQphc20gdm9sYXRpbGUoIC8vIC4uLiBm aXJzdCBpbnN0YW5jZSBkZWZpbmVzIHRoZSBsYWJlbCBhbmQgaW5zdHJ1Y3Rpb25zLCBzdG9yZXMg cmVzdWx0KQ0KeDg2X2VtdWxhdGUo4oCmKQ0K4oCmIGNvbXBhcmUgZW11bGF0aW9uIGFuZCBhY3R1 YWwgZXhlY3V0aW9uIHJlc3VsdHMNCg0KLy8gaT0xIHVucm9sbGVkDQphc20gdm9sYXRpbGUgKC8v IOKApiBzZWNvbmQgaW5zdGFuY2UsIGRvZXNu4oCZdCBkZWZpbmUgdGhlIGxhYmVsLCBqdXN0IGV4 ZWN1dGVzIGluc3RydWN0aW9ucywgYW5kIHN0b3JlcyByZXN1bHQpDQp4ODZfZW11bGF0ZSjigKYp DQrigKYgY29tcGFyZSBlbXVsYXRpb24gYW5kIGFjdHVhbCBleGVjdXRpb24gcmVzdWx0cw0KDQpJ ZiB3ZSBkb27igJl0IGVtaXQgdGhlIGluc3RydWN0aW9ucyB3aGVuIHRoZSBsYWJlbCBpcyBhbHJl YWR5IHByZXNlbnQgdGhlbiB0aGUgMm5kIHRpbWUgYXJvdW5kIHdl4oCZbGwgaGF2ZSAoc3RhbGUp IGRhdGEgZnJvbSBpPTAuDQoNCg0KPiANCj4gRnVydGhlciwgaWYgdGhlIGNvbXBpbGVyIHVucm9s bHMgYSBsb29wIGFuZCBpbnN0YW50aWF0ZXMgc3VjaCBhIHB1dF9pbnNuKCkNCj4gdHdpY2UsIGl0 IGNvdWxkIHBpY2sgZGlmZmVyZW50IGlucHV0cyAod2hlcmUgZmxleGliaWxpdHkgaXMgYWxsb3dl ZCkuIE1vc3QNCj4gcHJlc2VudCB1c2VzIChpbmNsdWRpbmcgb25lcyBJIGhhdmUgcGVuZGluZykg bWVldCB0aGlzIHJlcXVpcmVtZW50IChpLmUuDQo+IHBlcm1pdCBvbmx5IGEgc2luZ2xlIHJlZ2lz dGVyIHBlciBvcGVyYW5kKSwgYnV0IHZtb3ZkcXV7MzIsMTZ9X3RvX21lbSwNCj4gZXZleF92Y3Z0 cGgycHMsIHZwY29tcHJlc3N7ZCxxLHd9LCAgdnBkcHdzc2Rfe3ZleDEsdmV4MixldmV4fSwgYW5k DQo+IHZtb3ZzaF90b19tZW0gZG9uJ3QuIHssdn1tb3ZzZHssX21hc2tlZH1fdG9fbWVtLCBwY21w e2UsaX1zdHJ7aSxtfSBhbmQgYQ0KPiBmZXcgbW9yZSBjb3VsZCBhbHNvIGVuZCB1cCBiZWluZyBw cm9ibGVtYXRpYyBpZiBkaWZmZXJlbnQgYWRkcmVzc2luZyB3YXMNCj4gdXNlZCBmb3IgdGhlIG1l bW9yeSBvcGVyYW5kKHMpLg0KPiANCj4gTm9uZSBvZiB0aG9zZSBzaXQgaW4gbG9vcHMsIEkgdGhp bmssIHNvIHdlIG1heSBiZSBzYWZlLiBCdXQgdGhlIGNvbnN0cmFpbnRzDQo+IG5lZWQgcHJvcGVy bHkgd3JpdGluZyBkb3duIGluIGEgY29tbWVudCwgSSB0aGluay4NCg0KR29vZCBwb2ludCwgdGhl cmUgaXMgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiB0aGF0IG11bHRpcGxlIHVzZXMgb2YgdGhlIHNh bWUg4oCcd2hpY2jigJ0gYXJndW1lbnQgY29udGFpbg0KZXhhY3RseSB0aGUgc2FtZSBiaW5hcnkg Zm9ybS4NCklmIHRoZSBmb3JtcyBhcmUgZXF1aXZhbGVudCB0aGUgdGVzdCB3b3VsZCBzdGlsbCBw YXNzIChidXQgcGVyaGFwcyBlbXVsYXRvciB0ZXN0IGNvdmVyYWdlIHdpbGwgYmUgcmVkdWNlZCks DQphbmQgd29yc3QgY2FzZSBpZiB0aGV5IGFyZSBkaWZmZXJlbnQgYW5kIG5vdCBlcXVpdmFsZW50 IGEgdGVzdCBjb3VsZCBmYWlsLg0KSWYgd2Ugc3RhcnQgcnVubmluZyB0aGVzZSB0ZXN0cyBpbiBh IENJIHRoZW4gd2Ugc2hvdWxkIG5vdGljZSBpZiB0aGF0IGhhcHBlbnMgd2l0aCAoZnV0dXJlKSBw YXRjaGVzLg0KDQpBbHNvIGlmIHNvbWVvbmUgaGFwcGVucyB0byB0eXBvIHRoZSBuYW1lIG9mIGEg 4oCYd2hpY2jigJkgaW4gYSBuZXcgdGVzdCBpbiBhIHdheSB0aGF0IGl0IHJldXNlcyBhbiBleGlz dGluZyBvbmUgdGhlbiB0aGV54oCZbGwgbm8NCmxvbmdlciBnZXQgYSBidWlsZCBmYWlsdXJlIChv ciAyIGluZGVwZW5kZW50IHNlcmllcywgYm90aCBhZGRpbmcgdGVzdHMgZm9yIHRoZSBzYW1lIGlu c3RydWN0aW9uKS4NClBlcmhhcHMgdGhpcyBvbmUgY291bGQgYmUgYXZvaWRlZCBpZiBJIGV4dGVu ZCBwdXRfaW5zbiAob3IgZGVjbF9pbnNuKSB0byBjb250YWluIHNvbWUgQyBzeW1ib2xzIHRoYXTi gJlkIGNhdXNlIGEgY29uZmxpY3QuDQoNCldpbGwgdGhpbmsgYWJvdXQgdGhpcyBhbmQgc2VuZCBh IG5ldyB2ZXJzaW9uIGluY2x1ZGluZyB0aGF0IGFuZCB0aGUgY29tbWVudC4NCg0KPiANCj4+IEBA IC01MjQ4LDcgKzUyNTMsNyBAQCBpbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFyZ3YpDQo+PiAg ICAgICAgIG1lbXNldChyZXMgKyAzLCB+MCwgOCk7DQo+PiAgICAgICAgIHJlZ3MuZWF4ID0gKHVu c2lnbmVkIGxvbmcpcmVzOw0KPj4gICAgICAgICByZWdzLmVjeCA9IH4wOw0KPj4gLSAgICAgICAg Zm9yICggaSA9IDA7IGkgPCAyOyArK2kgKQ0KPj4gKyAgICAgICAgZm9yIChpID0gMDsgaSA8IDI7 ICsraSApDQo+PiAgICAgICAgIHsNCj4+ICAgICAgICAgICAgIGRlY2xfaW5zbih2bW92c2hfdG9f bWVtKTsNCj4gDQo+IEV4Y3VzZSBtZT8NCj4gDQoNClNvcnJ5LCBzaG91bGTigJl2ZSBub3RpY2Vk IGJlZm9yZSBzZW5kaW5nIChhIHN0cmF5IGNoYW5nZSBmcm9tIHVuZG9pbmcgdGhlIHZvbGF0aWxl LCB3YXNu4oCZdCBtZWFudCB0byBiZSB0aGVyZSkuDQoNCkJlc3QgcmVnYXJkcywNCuKAlEVkd2lu DQoNCg== From xen-devel-bounces@lists.xenproject.org Tue Mar 03 15:24:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 15:24:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244889.1544242 (Exim 4.92) (envelope-from ) id 1vxRc2-00043P-SA; Tue, 03 Mar 2026 15:24:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244889.1544242; Tue, 03 Mar 2026 15:24:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRc2-00043I-Oo; Tue, 03 Mar 2026 15:24:42 +0000 Received: by outflank-mailman (input) for mailman id 1244889; Tue, 03 Mar 2026 15:24:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRc2-00043C-A2 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 15:24:42 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 187acde9-1715-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 16:24:41 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by PH0PR03MB989099.namprd03.prod.outlook.com (2603:10b6:510:3ae::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 15:24: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%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 15:24:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 187acde9-1715-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QZp+5LTLn345tPyV0VqRmi1Xc9zCGhZ8BpqGsOESK9ns4ui18Fl1FGVF9G1XXXzRFxoa+4epxESO6fJDyZVOjY3u76edkoNq8GcFaC8Z1w/UHdZBQ/WWMSATd9ixeJVxw2ErTsW0j9Xu7sPm+LmXjwIIK8/JK0UnG+Z9AE0WTYwaB/smEfzmz76HzIDltMSoVp0v+cgzGIpZ0tpRLjU34iqnuFmj6Uov6+QShSDtioIY9R4E1CTuXsqXdrxeGTt94F70eCwMApRmSKjfhoQOUgAUlt39XNHQmZ+LSYcoDEbkjDkmf/EiFdsHEOAZowio47m0pfNBEWO10LjNZCBFTg== 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=lKmfsrSHU2A47P2t7ur29OSgAcpnzWZ/Dz6hdWCxs3U=; b=lMXqvIOXHGLuMoIHOoyOGi3DoBnQw5+epFyuZ6Mnh4mKoKtG3OymYi5Vn1trT4kqfRdO7oiMFX1Ehf7J3G4kG6sVibJghC6QPtLjnZS2R2SJJVo+s5rJWSmtVYMNtnPj/gT1WyR3YQXVMzMScZYwHHAunp7MXK8bG0a4hD6tKZbq9+GjUsgsBGeOfT7G9JxK+Drv7gRuXmd+ALH/k1vop61HlZZUAF6sl4cOJ+PaQQKuGLKAbyovUzrPykmpJeom3cfQYjTfARWEPogy7siyVX9hIbVSdU5AtU/pO9juU4aGqxF2EOeUsSAbz4+9sh8jT1F+hHHWZOmsdXUt/B61Sg== 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=lKmfsrSHU2A47P2t7ur29OSgAcpnzWZ/Dz6hdWCxs3U=; b=xUrN9MoTxdnC7GoU6ug4+u28T+d7LsgmO+nzVWZ+UtX1ShzS7w5VRSAGhHh8IkuW/A3j9F4OmboN6nKkAxRpbWuJqnvTltdyBhAPnKMf9b/DsV0DA3dzswv2esaG3gP1CWSOnrI8GXEB9ItWsa/ai2MI9KvP+i2f8TTWYlcGDa8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 3 Mar 2026 15:24:33 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2 4/4] tools/tests/x86_emulator: avoid passing NULL to memcpy To: Jan Beulich , =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= References: <340f6a9fc4fdd4216f41e4bbdb1234069322d1c8.1772189234.git.edwin.torok@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0403.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::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_|PH0PR03MB989099:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c2c0f98-62a0-41df-58d4-08de7938fab6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: g+/14XYyt2nObEwikbDp3wQ1eu8bVDgijHNjYjQvIdx7RvyhcbFG7I2EXHLBgzHnizmUtpBAIz3RY/37FraU/MShRIUQWqqRDFas2dfyZRVSmWuZehFEGCgz+CqvS7/RMizDGYegxbx7n55g2/EfvT9ZjHi25jCgyrzGYGlts0FGG7EcbRjeiLkQo78pRmQSfeC09Qi2yNXcWvMvSQN8z4tZ0Ru4WJb9uq83MaYSxc7njifOSJmmTn6A5avpappGrVJvOnev5vrjA2LSIZPyWDS6srQsvLTU10xyjluZFggzZ3EStCBX9WKezcQf9/XiiepYIV8YzzyruOT1KIL7yDnnNy1HBpRMx7KiggDMBn41aLSQR3ATRidbE9tLVqISMu/kT+/XZnK1v4xidWKydXEJmtoB/glTThHXqvHfMeJ9uDQS+3c1zNXW+96JEc7lqvvGiUlRZh5ZAtx8zHXn1OHO//6Z6RJf0kZrGhn6hxjjvxfPadasPPsxIi1HbSiEWUuTqMtVfMg1VJWW1wSzt2Sy1NE1iiHAMebXS4kNfiC7eIVr1O2R6ymg0ednA15lFm1ov06vC0hkBbVN01GXi9OZicQ9k9zQZCB3KsW7I4I4R5QcGYpy67ZJcEDuc8gLmfpDt/r934QIJg/2AW9a0XTNy/bi+QsYMrs4Cuj7vmXWJVTgrQuQc2QMku7KVNL6Hu5+vnLyjaVnO5lY5Xr0itPCcvxuxSqFtlsWw2HeW+g= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R3hxZ2FZNlFBbFFqR1VBa0NzdlA1Yk13U1ZvdWZvV0pYSUMyelczNUVxMXJi?= =?utf-8?B?b0JDK1RXVllacGVVNXBZRlM5bEVMRmJBdkJ0Y3lUeS90cEV5SFpHcnVZME9F?= =?utf-8?B?UHIwUWhZK3N0OW5BL0VIUjRQS3gxRlh5UnVGZGwvVVVyWlV1bXFzNERLc2Iv?= =?utf-8?B?ZVVOdWd3MmZkMjJ0MllNT0FyTlRVWm5ITlYyRlE1bEJjczJPcnZMWnorZWkx?= =?utf-8?B?cHQrTXR1R1hlUEg5cy9ldURGWjVnWWprWERLK0FySGdjNkJPdktpYmIxQis1?= =?utf-8?B?REFGLzJXUmluWDZJd1YwQjZVd24wWVdYcG1DR2VwUEFSeUs2Yk0rdDR6L2pD?= =?utf-8?B?ZEVZMTZKV2ViV3o1K08yUFd3UFh3b29kU2piTXhpV281c3lIN29uUTBpZExh?= =?utf-8?B?OVlEaHNnQ3k4NUllcXRTYUY3OSsraHFZOVlDVTZwOStJQjFrbEt6cWNZaWlF?= =?utf-8?B?TW1nTWJsVndBUzk4Y0l2cUE5TndKOG5oSWhCbHQyeDdhQlpxcDVscVpUdjhX?= =?utf-8?B?aFQ0TjdCVnJxTnJaU01ERkl6dnhiMjFrTUtnUGhhMmViblh0K1JLV05IWDQ0?= =?utf-8?B?ZkJHWUFWVVEzdS93bDRzOFBUR1V1bkdDdTRwK0NERVFycCtKcHNtcmxNS2xh?= =?utf-8?B?WjhaV2R5U2JYckR6R2hTcGpiUkRwSHlRVXZldGhYRnZpRk1tbWdkeUxkRHox?= =?utf-8?B?RE1WWnRDTC9rc2RwT3lNc1dGcWFFZjZkSjBpMXF4L2poL2tNMEJUOEtGV2sr?= =?utf-8?B?MkFnNXpVVlBjd1p0dytrdE1mcG1nd1V5VHBEZlMrZHQ0dXE0RkJEeERLUUpH?= =?utf-8?B?Mjh3ZzBPdnYraEF6NXNENnh1TEFsOUtCV3FDTTFTRnJ0UlJmZkg5b3BsbVdy?= =?utf-8?B?RnFtNTkyRFhHT1I3Y0FQRU9WMDBLclNpbGdnYTM4Zy9KYThnS1JmUEN0d2dJ?= =?utf-8?B?bSt3ek14V2tDbWdJS2lUNTZGWmc4bTY5eVNOd3hIRUVzNWoxM0g3OGpuUzgx?= =?utf-8?B?ZllZNXdPRmVvWHVxeTR1R1hXN0dVZlZuOUVpcDlFckZGWVpDT0VtMlhvU045?= =?utf-8?B?REhmM1VkdlFqaWt5Qkx0YkU3U3pqdXFoMThPU00vUk1kcG9iSXBQSm9vU1pa?= =?utf-8?B?aEtnd2pRc0NEZXBTK2Q2R1Y3bHJnekppRzNMYUszZWZpTEF6aXZXcW95Zkgr?= =?utf-8?B?RStaSm9nTlltMDdhNzZCdXVLYmhoYjhuTDAzN1U4TGZzYm5rbnU5bHpWWFEz?= =?utf-8?B?RmQrRlJhQndxc0lGTkRzMXFiU1djUk5uUEptODZRbjZ4b0NINmlkUXYzVmVV?= =?utf-8?B?VlZFNUFOTlVLT1pDdGdMNzB2dU9LeWY5Y29CNmRaY2FlT0RMcnlITVN6Q1Fs?= =?utf-8?B?c2hYcjJldEc1cmRDUGFwQVIwM3E5and6TVA5WGRtTGEzUEY4LzNId3BEZlpY?= =?utf-8?B?citWTFJ5WXE1cjdnWmNybEhWYmRtNnZpVDd3N3IzVUorbVZYRGVGYWdNWGxt?= =?utf-8?B?bWt0WTIvRzYyekpSWHR6TGUrQnorUnIrL0d0cWhld282OVkrbzNTcHpOQzNJ?= =?utf-8?B?TkpFeGxUWDlhWEJHN1NaekxBVzV3d0RFUWRpN3U1ck9NTXZObHU3OWtaVkZi?= =?utf-8?B?U0xPbGV6Mm1JajNDM3hTdmlWcktKYUtzTXRuRGFFeEhNdE5TYXc0QWlILzNu?= =?utf-8?B?SStnVHdnaGxnRkVmU3NhamQ3M2s1a3RNUDVnSUNBUCt2d1kyNW9vUmkzeVFy?= =?utf-8?B?VVI4dUxCOXRMS2VQV2Joa1ROZmM5U2puSndTZ3BIVE9zWFhmU29UTitqZ2JJ?= =?utf-8?B?TmIxczRxT0IxQ1c1aUJmd3NmUHdlbnIzNS91RVlSbzNXbHJnV1Rjd1E3Z1Yx?= =?utf-8?B?TXFHbUpybUg3VzNqTHV2VHJDUUs2aUJTcmxweXpSWkZmT1hhMHRpNElZVFlC?= =?utf-8?B?WGF1cWRnaVI5Ulh2WmxXekJLd0hkL0RiM0N1Ry9VZ1VqOTVDbkR6MCtWRXdF?= =?utf-8?B?dE5DRklwaVNsMnpzN05ZZk9ZNzZKVlo1dVp3dTZ4dm5QeTc5RDZCNnhzQ3ZJ?= =?utf-8?B?NHpOWEhXKzAxbmtjVHVmaXJVaEI2NzRYQXB0OElHOHI0VHY1TlBvV2RUZEFz?= =?utf-8?B?WFkwUEFiVHloVmlWRlVXbHJTRmlRZCtHOVo0TUxvQk5PL25hZHF2U29ncDZT?= =?utf-8?B?V25qTmxubTBHdHJIdzJIT25iOVU3ckIrTUVtWGk3WVR3RStiL2txZmVZcElX?= =?utf-8?B?ZWJ3VEtUaTlCRGUrVlU4aFg0VitWMU5xWDVuVVVIeEhBSDRXY29tSHFwTmlu?= =?utf-8?B?SGpTbFV3ais5b1Q4T0FpRmZNZUkySHQ0Skc5VjFNR3UrV1F0aWoxZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c2c0f98-62a0-41df-58d4-08de7938fab6 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 15:24:36.5301 (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: KwL6eSWGOuoPeLZOS5FjzpycNnmkIlhJecCGpLpgrA63/KQEKY0LsLPqlYUEEffnBB1Y2lwmD8Et1qpTIWxrMb6c5XvAkLvEvjnSneOBTQE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB989099 On 03/03/2026 2:18 pm, Jan Beulich wrote: > On 27.02.2026 11:58, Edwin Török wrote: >> Fixes this `-fsanitize=undefined` error: >> ``` >> test_x86_emulator.c:614:12: runtime error: null pointer passed as argument 1, which is declared to never be null >> /usr/include/string.h:44:28: note: nonnull attribute specified here >> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior test_x86_emulator.c:614:12 >> ``` >> >> Although this is more of a grey area: I don't see anything in the >> standard that'd forbid calling `memset` with NULL and 0, > There actually is. In the C99 spec clause 2 refers to section 7.1.4, where null > pointer arguments are excluded. Imo for memcpy() etc exceptions should be made > for the case where the count is also zero, but sadly nothing like that is there. C23 does finally make NULL with a zero length be well defined behaviour for memcpy() and friends, but it's going to be a long time before we can rely on this properly. GCC 15 gains __attribute__((nonzero_if_null)) too. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 03 15:29:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 15:29:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244898.1544252 (Exim 4.92) (envelope-from ) id 1vxRgk-0004iF-C5; Tue, 03 Mar 2026 15:29:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244898.1544252; Tue, 03 Mar 2026 15:29:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRgk-0004i8-9O; Tue, 03 Mar 2026 15:29:34 +0000 Received: by outflank-mailman (input) for mailman id 1244898; Tue, 03 Mar 2026 15:29:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRgj-0004i2-80 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 15:29:33 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c6481837-1715-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 16:29:31 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439b611274bso1591876f8f.3 for ; Tue, 03 Mar 2026 07:29:31 -0800 (PST) Received: from [10.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-439b55d15besm19777387f8f.30.2026.03.03.07.29.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 07:29:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6481837-1715-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772551771; x=1773156571; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=zS3enskoQSQUDWPgiI10AS3enCKqjk/TCB98Gqua3pc=; b=S7m4xWR7HkBE4U88uW0r6z0K62mPdLIA9P8q/q3YbJWdVnNM/bV/QeAC2SqJJOI6sY nhCSHwulaRrPEAZayDEn8S8sgvtoR09KIaLpx3GKJ4E9JFMtvB8DsAPs6G5ZlkxrraDE QRjNXmImCglJevCZTkIchioGPhPvN/NTwLdIeGb+wd4vvqw7eFKlN8vYiLnh8H4rC5W5 tp2vUxiHraDR4AXGZC4NzNI2Tz8YikAqOsvBCW9fI587iYuUChDvFzNfWaDxC3KOFUu1 pH4jxRAmMsmhaZSl88IWGgiCYNl+1ccBIHPBM0ieTY/kXiXT4LPxsEUL8Q6jxH0QL0st ewUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772551771; x=1773156571; h=content-transfer-encoding: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; bh=zS3enskoQSQUDWPgiI10AS3enCKqjk/TCB98Gqua3pc=; b=A9Yrf+xABGxx2yEY7b7EKt0Mde7en2caVL+wg3rdsDhRl6TF1jUEXqedVoaX8J5Umm IKKhBA/ij3mvXn91fGrYVszmFl9H4Ld799GfxwDsntWV2FibB3uDQcXVmOTwGLkA+amj YeHQYmFc5Rm+T7c0yN4aPMKYYh8xW4waKFM/nwCDjFcYbzxzYb3UdabUu1+QgniI0RfR GyCfe14f2nkL7APxbzU1+XFUxR3gfxCUh8vXOtXzE8p2EmHso36mOqRb3MO8O9C8blHw h3hHmO+YW6ak2+1t/Dn+Q/fbpRy1iBHfdra6R9x/1MsLtfiVHZy2H+G+Sp5tHvVoQsK/ 12cA== X-Gm-Message-State: AOJu0YytnaoprUQvEiKkuwRUyzazyTxp0tDUyDLAqKc526FHjDn7IPQO 7u9BRdNSOGrrEoq7f00qm/pi8/Ro70FDY1DAD1OePOGWJtkUayPq50+qVXmFgoIQPg== X-Gm-Gg: ATEYQzzCNNd3UgTYyfcSCvJmcQmKr3i+LxD/FM+jv3XlOeI3uth2BG23nVMG8RUoPnQ rmexY6X2kijB+zfrDKp3J+GkzyUo9sy9BPA471+m1/kM2FwJ0xuvJe2+OAi9qFhFhB3uuv9tLXd GQlHzv8XAjFr5fLkdZPEeWUaqzIH9/St6EOysa9bUPUySmizf6GgXcpbsctVxqpWYbiPiK/DPIh h1vF4Bj/cBPJhnmG4e7hXb2NDvXEvZ5jUpVukS4nUWujihPBgTZ4UEGziPEEdMTDcgXGcBfo6Bc 8pXHhMvIj5AiCiE6utww6XB1k0VtMgTJAPYKcCYHkPmVd07XZIO3euNZt2bWCuOnxL/VXgLGDUl QGu8IjhybZtUp3hqZ3tiybxJntityJtHl6oQLNHsx2H/SEZvBi41fKxne7zdQ+iS8/FA17ApGxV MzINx0+TrZbWBFl2Qk+mR0gYB27kDc7xVIy1juMRC+gmfJHTBeBMTM3V3eGhIlek3tg4rN+KCYG LyJjVPTqne4KRM= X-Received: by 2002:adf:f211:0:b0:439:abcd:b312 with SMTP id ffacd0b85a97d-439abcdb6ccmr17028997f8f.7.1772551770777; Tue, 03 Mar 2026 07:29:30 -0800 (PST) Message-ID: <8098518d-80c3-4e0f-9ce3-299494aa4f14@suse.com> Date: Tue, 3 Mar 2026 16:29:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 05/14] xen/time: move ticks<->ns helpers to common code To: Bertrand Marquis Cc: "xen-devel@lists.xenproject.org" , Romain Caritey , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Alistair Francis , Connor Davis , Oleksii Kurochko References: <545c2af877d519b1186c79fd6108d33e7e52cd3b.1772016457.git.oleksii.kurochko@gmail.com> <2AE980D3-571A-4AB9-A01B-EAA90D3EA0B9@arm.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <2AE980D3-571A-4AB9-A01B-EAA90D3EA0B9@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.03.2026 15:56, Bertrand Marquis wrote: >> On 26 Feb 2026, at 12:51, Oleksii Kurochko wrote: >> >> ticks_to_ns() and ns_to_ticks() are not architecture-specific, so provide a >> common implementation that is more resilient to overflow than the historical >> Arm version. This is not a practical issue for Arm, as the latest ARM ARM >> that timer frequency should be fixed at 1 GHz and older platforms used much >> lower rates, which is shy of 32-bit overflow. As the helpers are declared >> as static inline, they should not affect x86, which does not use them. >> >> On Arm, these helpers were historically implemented as out-of-line functions >> because the counter frequency was originally defined as static and unavailable >> to headers [1]. Later changes [2] removed this restriction, but the helpers >> remained unchanged. Now they can be implemented as static inline without any >> issues. >> >> Centralising the helpers avoids duplication and removes subtle differences >> between architectures while keeping the implementation simple. >> >> Drop redundant includes where already pulls it in. >> >> No functional change is intended. >> >> [1] ddee56dc2994 arm: driver for the generic timer for ARMv7 >> [2] 096578b4e489 xen: move XEN_SYSCTL_physinfo, XEN_SYSCTL_numainfo and >> XEN_SYSCTL_topologyinfo to common code >> >> Suggested-by: Jan Beulich >> Signed-off-by: Oleksii Kurochko >> Reviewed-by: Jan Beulich > > Computation is changing a bit from MS to S removing the 1000 factor on arm > but i do not think this would have an impact so: Well, as the description says, this removal eliminates a theoretical risk of overflow. So there is some "impact". Jan > Acked-by: Bertrand Marquis > > Cheers > Bertrand From xen-devel-bounces@lists.xenproject.org Tue Mar 03 15:37:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 15:37:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244908.1544263 (Exim 4.92) (envelope-from ) id 1vxRnu-0006F5-3c; Tue, 03 Mar 2026 15:36:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244908.1544263; Tue, 03 Mar 2026 15: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 ) id 1vxRnt-0006Ey-W1; Tue, 03 Mar 2026 15:36:57 +0000 Received: by outflank-mailman (input) for mailman id 1244908; Tue, 03 Mar 2026 15:36:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxRns-0006Es-F3 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 15:36:56 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cd9398e3-1716-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 16:36:53 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4834826e5a0so67078705e9.2 for ; Tue, 03 Mar 2026 07:36:53 -0800 (PST) Received: from [10.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-483c3b44207sm373396575e9.7.2026.03.03.07.36.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 07:36:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd9398e3-1716-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772552213; x=1773157013; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=6BgO+d69eIe8i/1P9hdXQKHfptXMFDHOVG9lzJC1iDw=; b=X7UXLeLhxHstlGQinAFphtSe/lCsJ0rVEYPer7tGe6IEa8s1sdXCi9/hwYS9Y1PNd9 9nvGgXYNG7kDyt3loK4AtJoqqDHrD5w7odHLpYu4JOXmrhL8MqNm95sDZoTrzlyqbNc7 sZwVpJFqm9OOFB+UxWBjkuGduF9my0LKPRUsEWorMz2sXVdYyrjPdROMHT4zHGEvwTYI xXLr9Kn90JmmPRvWaR87gK6RyKaQIStnCcFKl/dfEMwZ98+9+QMG0b4Ll3PMgAyYcVUU CTirwY+bPM0qf9gyBPaRQwz5ZRPmGPXvN7m8nnq1qsfqTTmKqmkT4otzzQOXq4Ft/Cbf Q9jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772552213; x=1773157013; h=content-transfer-encoding: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; bh=6BgO+d69eIe8i/1P9hdXQKHfptXMFDHOVG9lzJC1iDw=; b=Cm5ot3/qqateMyiokiHh4xe1CQ3Lsa69ZEhpk5GEeZLz6Q1u848oUox6hT/G5zQmb4 5S+Frlo9TEbXr0ZpNyY4qQyzUWvDfhTHBcAif+05n6Ai+iafCqcO6G+dbjGHyZFWY8SG mwiC4NhcB+7Oh6Nh6EZZC0S7y0Vg1tFx1jKRbyh5su23a0CdBHTHBOrsQE33jSgzHaq+ HrjYXerorUkrC8bGAvb84JOsMfimtImqr4mwItEurKOTbKbKOBpAizvLLEZ5zXdBb5YU H0A4lN0ROfMm/HOwqoVKAaN8pbaJ4P5rgKnjjzP4kEAPjLTIZ8Nddor1VrK6OcICwPS/ Eh8Q== X-Forwarded-Encrypted: i=1; AJvYcCX0xplRgi5+oNDTSKH25pJnm026r6bafOqWIc564f/ecay3zyvAS1ANNx0xDcYyA0KTlurqnP71Wh0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxQW0y8t6id6gfMm1iKjLRtgp9u4WXwsaxdjlp4aiP0ArklScJp QiHb1q5oZ6gVc+5Ksor/5LgBBPFlGXxId3mhyFdjj6wN5tm+EU12lSR04a1ILCVaUg== X-Gm-Gg: ATEYQzz3E1GDYncJYkyvkwfFbR2F1wY3QETkkgT1K7PrNsRSSggK5pRARYgr06f4jDf 7yhxOmfG88BRtbsRBLFyPJ3Cb06Yjah4Xd89mLozPfDtQsX2GpJie7njjTNK5qXUpXoBWOM+NzY N3B+nrdmlyYja/F42jp4mLsCvvK6C1qeEiaT+V4sgCWvqh0/c+/4ZfAGzzpPgx6V8oNgH01hr4t J0Zjthfaj+pN0h3gtGvbf1Cq7kEtCwBWSE+jMfTQQE/9cbboBKtdjUDrUXryLVIhxCHzxsLFO4j VAdaRTlQ8/pc0maGGjJHZHxSpxEjofCXn1AIiD1rEPLzrMVxqyXcop5ZXZQhcEMWSE/bgPTMglW Dd3QieRu5Hk/BeIdIXrIak1Xf/VEe/4pDdBdfg/Ag3XkGiNJLJ3KjaVym8reRbv0744wUVBoB7W fZWpV9jjGevU+H+gpmcZCcIIaoXUIFIqNvLwXQQl8a2vUjHI2tSVVasw+1vMjeEnyG5pcwBwjOe Asrd/phUxjcsFygy0l5iYL//A== X-Received: by 2002:a05:600c:3486:b0:480:3a72:524a with SMTP id 5b1f17b1804b1-483c9bed89emr329853505e9.19.1772552212536; Tue, 03 Mar 2026 07:36:52 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 16:36:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang To: Edwin Torok Cc: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.03.2026 16:09, Edwin Torok wrote: >> On 3 Mar 2026, at 13:59, Jan Beulich wrote: >> On 27.02.2026 11:58, Edwin Török wrote: >>> --- a/tools/tests/x86_emulator/test_x86_emulator.c >>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c >>> @@ -1882,8 +1882,13 @@ int main(int argc, char **argv) >>> #define decl_insn(which) extern const unsigned char which[], \ >>> which##_end[] asm ( ".L" #which "_end" ) >>> #define put_insn(which, insn) ".pushsection .test\n" \ >>> - #which ": " insn "\n" \ >>> + ".ifndef "#which"\n" \ >>> + #which ": \n" \ >>> + ".endif\n" \ >>> + insn "\n" \ >>> + ".ifndef .L"#which"_end\n" \ >>> ".L" #which "_end:\n" \ >>> + ".endif\n" \ >>> ".popsection" >> >> Nice idea, but why multiple .ifndef, and why emitting the insn even if the >> labels are already there (and hence won't be emitted a 2nd time)? > > I think we still need to execute the instructions, so they can be compared against the emulator. Of course, but they cannot be executed without having a label. We use the label to point the emulated IP there, and then we use the end label to check that after emulation the emulated IP has advanced as expected. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 15:56:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 15:56:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244923.1544272 (Exim 4.92) (envelope-from ) id 1vxS6M-0000jG-J2; Tue, 03 Mar 2026 15:56:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244923.1544272; Tue, 03 Mar 2026 15: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 ) id 1vxS6M-0000j9-F3; Tue, 03 Mar 2026 15:56:02 +0000 Received: by outflank-mailman (input) for mailman id 1244923; Tue, 03 Mar 2026 15:56:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxS6K-0000j2-Tf for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 15:56:01 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 75b436c1-1719-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 16:55:55 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by CH4PR03MB7652.namprd03.prod.outlook.com (2603:10b6:610:246::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 15:55:46 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 15:55:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75b436c1-1719-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=MZvr71TLkqMn35tu1XmSDwGBRunKPCdbqdYLOezT4FPLZs3Epco7qs8+ojt/gdCQrzkxbDA4A1LWLPioMjFp+MWJ+/LGxHWA5me2I8/b8GrugD3iuXPn+P0V05iJevxFHNXhs+HIaHXooQZ3u7vHzWoJYoDWNJ+1C9oZ1TzBwBvlcuf3wK+r/YWTN6AxkfQe+3v2BrlOWN9pD+CpqjEYCGt/J0VuVyvXmllPDvhOx8xbL9snmcRzbFyvHqAD721poRbigdYN0H6/F7z5lU5W0YZFzhoQeZ4MeALIIWXMPXsYCjwOt0QrbPXswz3ZEbdkH1CPm05ZGh1ynqvGdsKe6g== 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=Hmuvr/6jLEHfqNNjocyGQ5zaxBM2H0QcvdisHflQEag=; b=RnfrULQM8R9slx81poXubOqSVEFI1yfnAo9hwU2LGMFYVBSI2OHKRNYwFdNLbQzyfCuBGOGlHg+NRYK0R3s+9wRKsV3ikFVgd81kejs2jIayGjb0la1xdGv6mtec3MeYJj6YZsZ//IesNZLNXz5OWjf4V4qmM04NeBqYo8SSVxRsFQKAFJaCpzIh8nD9x9tAEv3TE3yYylgoRoSz0gCurwHh5FKniRMstWBNmrXAZQayShGwtwCi8ya2LP/8TnoajEFV9wyjIPk+8pyuddvDxJ2Yrw6CfuPJ//2x0B64waCD5NSXF9kiprrrSpngrf3B9/ujB9I+bazfOW4P9zTj7Q== 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=Hmuvr/6jLEHfqNNjocyGQ5zaxBM2H0QcvdisHflQEag=; b=mAMO/TSyzm2S2aoMvWBFPqmxzU5ryQ/biWZ12Wxc8PF1oQCPJWxybANvLmrhj/NoM8kHOM//n478ZBsQTN/TjGWE2rm9V4R5rFjmlKFJAJH4JksGZ/Lfrw9gUzfkre4lg+GJj2vvQCh+LH/kK4Km1byGkZ6uKF1XIGbH6yxfnlg= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Topic: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Index: AQHcp9gBGAcR9pePk0GnYyu6dQzUZLWc3C6AgAATegCAAAfEgIAABTyA Date: Tue, 3 Mar 2026 15:55:46 +0000 Message-ID: <004F02CE-B8C8-40B5-8453-C754EBE92022@citrix.com> References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) 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: SA3PR03MB7419:EE_|CH4PR03MB7652:EE_ x-ms-office365-filtering-correlation-id: 6014d258-a11b-47fa-a557-08de793d5546 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021; x-microsoft-antispam-message-info: RLOFx/23VEbJq13XeaZTNnw/FMCScNwlsvDp5W/kpnhhQTYV9Esgb0Iga2VUf5s4TjfXOJxBI69+DeusHGWQlGITuIGAA66ZFLS0JHyX+1ov5VmTfHz+ICG/reAJn8l6RjVgregCKtXxKbGWJH6zG8EeMk3VhSJJ+vT4tSpG1r1KOnj45ED1AXCTh+VOAN2Ym+rvqwVOkg5HnGW8ZQSRz5M8/KBOc6jQq3MOyTCdIQ76BL6TLDUgqKEnFti/L6/98foBaZSsmnZee9kj6W/9d61JVvRYp8Zx4XnCFB+n+yftgPADYCOLv9v8s5Usu84Kfcd+Y/9snrzynRykEb2+CSidmAMYBU4zNRbCOwgE59wp0HQPwtpqAGjiUvMYxV9J6iliPqV8utmNahy/1d3ql5ZL+mlE0nORR76LklxsWvoknNgrio7rqq5Dee4RU0aKQoyPNZgJn9gK3taX4jF/vkM26EHHBLn7oNuw9QjSxNIDtVrAzqqQn4cuaWFC5SreKMLjvobCKBHudS4wmIcs0ZT/kolFuz2BrNlK+I8Q8ym8GCYhAVdEzIoc1/LAXA8Zpxu0ChyevD83PiwD6Vey0DNGxmzPNNfo/1cTWoFjECocflW5gFlETe+zNMby96Eq5w5yweLX/x/marBaaxc//7dVptdjuM69YBqMXVtl3sMGPS2Bx6EehVMU36yVwzwihg/wu/WsBy/b/Hs6R9gthI5FqLitSrocmXhSeh/x4bczU90+lBseaOON+PfzDnXO x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WFRReHhhZjBDdEZjdEhKSjQ1RVJiTU5WSVF0U0oxTnBxNWVtZHBhY2trbVgz?= =?utf-8?B?Smh1M1dacUFBcktXcUFUa1pINVBIS0xHQTBQS2RDRjlxcklEOUVtNTZzWEYr?= =?utf-8?B?dkNnRDJ4ankwNzFEeTlCQ0NpNkpKRTVDN3JvUWpEWHlNSGFUYWgvMENJd3VO?= =?utf-8?B?dFcxaHYyc291L0YxRUFSWTRadDA5dEg4VUtxeld0TVVRa0dieWpUck56aVNs?= =?utf-8?B?RkhMRjBzakxZcWFIU1VtYk1UelcxMHAweldvQk5DR052anIwUm5qYnc1N25u?= =?utf-8?B?TUUwS09nbWVuOFg3T2ZGRVordThlY3NFWE04Q2dWRlhOUXlJWDZlV3hGVXc0?= =?utf-8?B?VWh3MmdPcTlyMDRiTHJuRnhCTlkvVFduMWZwaGRuaERyU1BIS2N2RHZtemFx?= =?utf-8?B?QkNucEY4b2o5bkgrakJzS3F1VEJvUmx6QmdMV0p6UE5tMEhCMjZ3ZC9RTmY0?= =?utf-8?B?a2ptRU1VQjB6RWl6N1Y2Z0wxR0JOTEhNTDJlMVFSc2dqcXoyTWptejFXc1RW?= =?utf-8?B?T1NEQ2VCWnN4NDV3TnV5TWdEWWw5cld2L3ltUDZYbnJiOHJPaml2TjFKWmwx?= =?utf-8?B?QmxYNE82MmtDaEZEU2hBeG1CUEhLVGRIVmh4L0JraTIwcjlDV1crcXl2Zld2?= =?utf-8?B?ZXhXc0hwNWtyWXFXdGdVM0lkR0JFZXZrcVRGZU1BMEozZ0p1UU1xemF2K2tW?= =?utf-8?B?WHJQZUo5NmNIR3pPU2pGTWs0K0tDcjA1TUZpVDQ1NzRGZXdpRjUxNldNR25Y?= =?utf-8?B?dkZYaEJFNTdZL3IwSFNKMWRQcVdud0FneGFZcUY4bGp2cmJVazBtOXZtSnYz?= =?utf-8?B?UjVTZWx2UXQrOW9YOHVrZE9Qekp6dkRQZWl2T0VITjhONFY3OERPQ051cVRG?= =?utf-8?B?T0ozcWo4Wlo1WDNzbFFzbzdoNGFQWFUybzBWQWFkZkdoWkdCK1l6ZTlOREs0?= =?utf-8?B?bXIydDZZVTY5Q0NuMVhvZFk5RVBpU2ZVSFNWWFl3QVFLS2ZPZExaYkxscS94?= =?utf-8?B?b2djQ1VMNHc1UjJDY1ZlMjVpbllLTHFLTSs0cmxVT2czL0lyVkN6NkZtdllp?= =?utf-8?B?QWFySlhWUUdCcjNKbmVKdDdOQklJejNpOE1vMmJaSG95aVpOYkpqTnpVMnAv?= =?utf-8?B?V1hNSVdDNVRjOTZqai80enAzcGhPSE5xL1ZLSnlVbkl3VGIrNHFOU09wRGlB?= =?utf-8?B?Q3I2dy83bHRvSlBOenZ5TXA4cjVqNmRmTXVEOFo3Qmh6YW5aS1dleEhpTFZt?= =?utf-8?B?WVVZcnNxSGl1Vkh6OGdGT2t4eTZWR1VSZUI1TWhjS212QWxIK2ZkQXFidUNL?= =?utf-8?B?bFhEUkdVSWpjVGtseFhTYmdGTzd5bUY4UkpDTGNxMURodS9EL0VxcFpiUGwx?= =?utf-8?B?YkVKeThrZjJlZU8xaHdCYVlxdUZxVGZ6emdtSVFDTE82UEprNEp6OWZzTnFm?= =?utf-8?B?MWc1YlBWeGdHUEloKzdUb3ZSWFJPcWNMejlvTWJoUWU1bklnREtheUNqRk0x?= =?utf-8?B?M1lUd3FXU1FCWkcxU3Rtd3N5Z1hsOUIvdXhjaHFHcXh5MmtJRlNvWThCN0xW?= =?utf-8?B?MHpNNWF4OFU4eC9hWWFPVHhYTUNQY0hIZVFZbU5BRUt1bDF4eEljcmdmN3J0?= =?utf-8?B?YW5XbWMveml4dGFZa1MzREVtMUdvc3JsVlcvVWVGSmhvblZJdTBQVTV4ZjFw?= =?utf-8?B?UTdIT3lQNkNyQlVpWGpHT3cveHNWOSs5Nk1UQ2sxd1ZadjVkVGpTNHhWcUVL?= =?utf-8?B?aUplREZlS2ZsMGdsenZTNmVpOTBTNXZObk5iZlRUMlpWa3VTZlcwSnRuODlN?= =?utf-8?B?YUxyOFAyRWkydEIzV01mbG1GMnRoSjdOd05MeDhWSkNITHF3K1poVExLTVZu?= =?utf-8?B?Q0ZFTTVSZHMrdkZlRkdQRnhkenF5QUgrWk5pV0l2c1IwVzIxTko2UG00Z0Ra?= =?utf-8?B?Z2luVGdrQ2NSVFBDQ3ZSaTV0Uk13V0Q4Q0lmRms0UmJ1a201OWJDc3pLREN5?= =?utf-8?B?aW0reHhyZnhIalhKZXRncTQ1aFErMFR6UTBBTmdkRlVHRWhZQjdGNHl6T0VI?= =?utf-8?B?a2VFc2owTlB6NHNhVDNNaFhMUnV5QlJVTUxqV1Z1cFhhZ2ZjbjhBZFdSMXhO?= =?utf-8?B?Y2hnd09YR1hDcGlYWTNlTlB4N3lCS0FXdzdZTWNoTVozR0RvVys5MjhVK2cy?= =?utf-8?B?aGFacmVHZ3NIVTJaSFBlK0MwdjZ0MUJUUi9DUjdDWk9tMjNlZEVicTFYcW1V?= =?utf-8?B?S3ViNHpoUlZyVUtJTWVIZDRpNHB1TmZqbG95RzYxRkl3VlVsWWZpWGJpOUJQ?= =?utf-8?B?aThYZ2NCVTcrNkxZTncwV2VvSm5za2RpY3VuZ2t4Um5iUXJZaVExRzRIZi80?= =?utf-8?Q?M7OtOIwQHQfxYzZY=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <74A4FED04D101743874A770E142AFC56@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6014d258-a11b-47fa-a557-08de793d5546 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2026 15:55:46.3671 (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: SkbNyzd17M48ZGwgnoVMyQVdH8eXgWOB1Xj5YV+2k1UHkWBaBmbfauTC/y3DcMTReDLZhyzGzZQoDCtdcwAu+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH4PR03MB7652 DQoNCj4gT24gMyBNYXIgMjAyNiwgYXQgMTU6MzYsIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwMy4wMy4yMDI2IDE2OjA5LCBFZHdpbiBUb3JvayB3cm90 ZToNCj4+PiBPbiAzIE1hciAyMDI2LCBhdCAxMzo1OSwgSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1 c2UuY29tPiB3cm90ZToNCj4+PiBPbiAyNy4wMi4yMDI2IDExOjU4LCBFZHdpbiBUw7Zyw7ZrIHdy b3RlOg0KPj4+PiAtLS0gYS90b29scy90ZXN0cy94ODZfZW11bGF0b3IvdGVzdF94ODZfZW11bGF0 b3IuYw0KPj4+PiArKysgYi90b29scy90ZXN0cy94ODZfZW11bGF0b3IvdGVzdF94ODZfZW11bGF0 b3IuYw0KPj4+PiBAQCAtMTg4Miw4ICsxODgyLDEzIEBAIGludCBtYWluKGludCBhcmdjLCBjaGFy ICoqYXJndikNCj4+Pj4gI2RlZmluZSBkZWNsX2luc24od2hpY2gpIGV4dGVybiBjb25zdCB1bnNp Z25lZCBjaGFyIHdoaWNoW10sIFwNCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2gj I19lbmRbXSBhc20gKCAiLkwiICN3aGljaCAiX2VuZCIgKQ0KPj4+PiAjZGVmaW5lIHB1dF9pbnNu KHdoaWNoLCBpbnNuKSAiLnB1c2hzZWN0aW9uIC50ZXN0XG4iIFwNCj4+Pj4gLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICN3aGljaCAiOiAiIGluc24gIlxuIiAgXA0KPj4+PiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIi5pZm5kZWYgIiN3aGljaCJcbiIgXA0KPj4+PiArICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgI3doaWNoICI6IFxuIiBcDQo+Pj4+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAiLmVuZGlmXG4iIFwNCj4+Pj4gKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGluc24gIlxuIiAgXA0KPj4+PiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIi5pZm5kZWYgLkwiI3doaWNoIl9lbmRcbiIgXA0KPj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICIuTCIgI3doaWNoICJfZW5kOlxuIiAgXA0KPj4+PiArICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIi5lbmRpZlxuIiBcDQo+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIi5wb3BzZWN0aW9uIg0KPj4+IA0KPj4+IE5pY2UgaWRlYSwgYnV0IHdoeSBt dWx0aXBsZSAuaWZuZGVmLCBhbmQgd2h5IGVtaXR0aW5nIHRoZSBpbnNuIGV2ZW4gaWYgdGhlDQo+ Pj4gbGFiZWxzIGFyZSBhbHJlYWR5IHRoZXJlIChhbmQgaGVuY2Ugd29uJ3QgYmUgZW1pdHRlZCBh IDJuZCB0aW1lKT8NCj4+IA0KPj4gSSB0aGluayB3ZSBzdGlsbCBuZWVkIHRvIGV4ZWN1dGUgdGhl IGluc3RydWN0aW9ucywgc28gdGhleSBjYW4gYmUgY29tcGFyZWQgYWdhaW5zdCB0aGUgZW11bGF0 b3IuDQo+IA0KPiBPZiBjb3Vyc2UsIGJ1dCB0aGV5IGNhbm5vdCBiZSBleGVjdXRlZCB3aXRob3V0 IGhhdmluZyBhIGxhYmVsLiBXZSB1c2UgdGhlDQo+IGxhYmVsIHRvIHBvaW50IHRoZSBlbXVsYXRl ZCBJUCB0aGVyZSwgYW5kIHRoZW4gd2UgdXNlIHRoZSBlbmQgbGFiZWwgdG8NCj4gY2hlY2sgdGhh dCBhZnRlciBlbXVsYXRpb24gdGhlIGVtdWxhdGVkIElQIGhhcyBhZHZhbmNlZCBhcyBleHBlY3Rl ZC4NCg0KT2ggdGhhdCBtZWFucyB0aGF0IHdlIHdvbuKAmXQgYWN0dWFsbHkgYmUgdGVzdGluZyBh bnl0aGluZyB1c2VmdWwgaW4gaXRlcmF0aW9ucz49MQ0KKHRoZSB0ZXN0IHBhc3NlcywgYnV0IGl0 IHJ1bnMgdGhlIHNhbWUgdGVzdCBhcyBpdCBkaWQgb24gaXRlcmF0aW9uIDApLg0KDQpJIGhhZCBh bm90aGVyIGFwcHJvYWNoIGluIG1pbmQgKGFsd2F5cyB1c2UgYSBsb2NhbGx5IHVuaXF1ZSBsYWJl bCB3aXRoICU9LCBhbmQgdXBkYXRlIGEgQyBwb2ludGVyIHRvIHBvaW50IHRvIGN1cnJlbnQgb25l KSwNCmJ1dCBpdOKAmWQgYmUgdmVyeSBpbnZhc2l2ZS4gV291bGQgaGF2ZSB0byB1c2UgZXh0ZW5k ZWQgYXNtIHN5bnRheCBpbnN0ZWFkIG9mIGJhc2ljLCBidXQgdGhhdCBpc27igJl0IGV2ZW4gdGhl IGJpZ2dlc3QgcHJvYmxlbToNCmFsbCB0aGUgJTAsICUxIHdvdWxkIGdldCBzaGlmdGVkIGJlY2F1 c2UgSeKAmWQgbmVlZCB0byBpbnRyb2R1Y2UgYW5vdGhlciBvdXRwdXQgdmFyaWFibGUuDQpBbmQg aWYgSSBkb27igJl0IGludHJvZHVjZSBhbiBvdXRwdXQgdmFyaWFibGUgdGhlbiBjbGFuZyBjb21w bGV0ZWx5IG9wdGltaXNlcyBhd2F5IHRoZSBwb2ludGVyIG9uIHRoZSBDIHNpZGUsIHRoaW5raW5n IGl0IGlzIG5ldmVyIHdyaXR0ZW4gdG8sDQp2b2xhdGlsZSBtaWdodCBoZWxwLCBidXQgdGhhdOKA mWQgcmVxdWlyZSBldmVuIG1vcmUgY2FzdHMpLg0KUHJvYmFibHkgbm90IHdvcnRoIGdvaW5nIHRv byBkZWVwIG9uIHRoaXMgcGFydGljdWxhciByYWJiaXQgaG9sZS4NCg0KU2luY2UgdGhpcyBpcyBq dXN0IHRlc3QtY29kZSBtYXliZSBJIHNob3VsZCB0cnkgdXNpbmcgLU8wIGluc3RlYWQgZm9yIGNv bXBpbGluZyB0aGUgZW11bGF0b3IgKnRlc3QgY29kZSBvbmx5KiAoaS5lLiBhZGQgTzAgdG8gdGhl IHRlc3RzL3g4Nl9lbXVsYXRvci9NYWtlZmlsZSkNCkkgdHJpZWQgLU9zIGZyb20gaHR0cHM6Ly9s aXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVsLzIwMjMtMDQvbXNnMDAyODMuaHRt bCwgYnV0IC1PcyBpcyAtTzIgd2l0aCAqZXh0cmEqIG9wdGltaXNhdGlvbnMgdG8gcmVkdWNlIGNv ZGUgc2l6ZSBmb3IgY2xhbmcsIHNvIGl0IGRvZXNu4oCZdCByZWFsbHkgdHVybiBhbnkgb3B0aW1p c2F0aW9ucyBvZmYgKGl0IHR1cm5zIG1vcmUgb3B0aW1pc2F0aW9ucyBvbuKApikNCmh0dHBzOi8v Y2xhbmcubGx2bS5vcmcvZG9jcy9Db21tYW5kR3VpZGUvY2xhbmcuaHRtbCNjbWRvcHRpb24tTzAN ClRoYXQgaXNu4oCZdCBuZWNlc3NhcmlseSB0aGUgY29ycmVjdCBzb2x1dGlvbiwgYnV0IGlmIGl0 IHdvcmtzIGl04oCZZCBhdCBsZWFzdCBhbGxvdyB1cyB0byBiZWdpbiBydW5uaW5nIGJvdGggR0ND IGFuZCBjbGFuZyB0ZXN0cyBpbiB0aGUgQ0kuDQoNCg0KQmVzdCByZWdhcmRzLA0K4oCURWR3aW4= From xen-devel-bounces@lists.xenproject.org Tue Mar 03 16:43:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 16:43:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244942.1544282 (Exim 4.92) (envelope-from ) id 1vxSqC-0007VG-1k; Tue, 03 Mar 2026 16:43:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244942.1544282; Tue, 03 Mar 2026 16: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 ) id 1vxSqB-0007V8-UZ; Tue, 03 Mar 2026 16:43:23 +0000 Received: by outflank-mailman (input) for mailman id 1244942; Tue, 03 Mar 2026 16:43:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSqB-0007V2-Ih for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 16:43:23 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 173c1733-1720-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 17:43:22 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-439b97a8a8cso2319868f8f.1 for ; Tue, 03 Mar 2026 08:43:22 -0800 (PST) Received: from [10.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-439c4489279sm2911056f8f.20.2026.03.03.08.43.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 08:43:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 173c1733-1720-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772556201; x=1773161001; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=fVfSyzCJ07n5V8La9UVEMBtwFP68oj3ioMWaN4GLNUw=; b=cKzUAoF70FDBVDKOCr8eMsmqKvwid+U6liUniSISdEDkYCiZ0VJSOQOUpFxGYPZRDG ymJmUAJQhg7NLdfMLFw25dPAPjOiVkFYyekjuR03E10H63kf6MPzVdSUrZNTWFlwFlst 0zmCWprawE9oKNQEAETn2W1Yao4yinDH7gyug1y0RIhAYqSJt78mZphFnn+9RPE/Ba2y GwnaEDsHY/Lry1YUEnmkMZt9GOxmeXcNiGsxvBEQPbcYncCMsm/Qgy6mxM1DLEWbSEpA e4Mwwwo5eC2z2WdeJGuhQP7rjZxxdt/gLyhnfITywxIW95W+Jquh+Zily3Gxaz4ymsu6 1Jxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772556201; x=1773161001; h=content-transfer-encoding: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; bh=fVfSyzCJ07n5V8La9UVEMBtwFP68oj3ioMWaN4GLNUw=; b=UQbLZ9Hp436nEzpH9/OwuD2oAhIpvfuy4YfDaP3X6/xkCjQAMu9DoP6LxzlS+mwlYW lvtucXlC58WNz54rEiJhjbSHhN4lCzCTLoGkRJTzm/50Sn2581cw7LPJ0hfblRZddiZ3 a1k0v4oHnXQuuw1Umw6uWrk7pOT8P+6LDeCmWcmlpOc3V6CBsCa+MVEfmF1qfDyRbYl7 gezxdoS5/iQ5XilHdZTXmj8MY8KOAJOuFOcNFY60NYcIUIKKmBtPUN2sJY8Mj8F0NDcE Hsvk5CsBk4kM7KAL6x3fRp+yQNLb9/+R5Thdxn3a0U8CJtFFBE7FFckzyM7fC47WKvTv OGuA== X-Forwarded-Encrypted: i=1; AJvYcCWXMSVil519MTLCm+7up2gS/6bqkquwbbRIsr4v4re9QS1YgJe0SVEp/LGcnc37J5AgMIhoFKw2whI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwVaTAampdFuBNWKJ1N2uSdrVS79KJdMt5Xj5qiNoZD6Xq0cRvd cWYEGvZf0vK3rw372rwQx7WKloSXwkRdZlnftZPXq6yOsKX9aSgrco5GJ1wJ7t5P/g== X-Gm-Gg: ATEYQzzzz1PUhJ5AslJcGLkVHlz9Trz03TYvwPjxROx+LVt1/MG4AeHhkuzJMRKBFUm I31O1uB8jb8lDTQnmZc4X1Oyd6c4xGKQpPSQpwf8BwaYlX6BKasIL3k6BM5zL8Qe8wDW4lUft44 lTk397SyedA4nusMXxbfMAiPFEaYssHf6mu4THZdmWwPB6jBc0sNFpEejvJ9kipFj9F97o2+rYH zsEM14zf9rNz/y6TX7HVEY4es/l8xLusEaSl3iZirOxgldtjuWbaFssri6stjc2Bi1FSblD0DuZ qIlQjPKsIO6e68lM1KAkYXLKQRlhY0rTc5VCWx6bfk9E45nT9HnNJEG2/Cu/zCrcyQXVwOBBSFm 4ZCAX5WBwDy78Xr4I9kQG0qWfDSVNUIfhM0w/kE5aCr6CrguemYton4bvtkzwQuxnHTHi1QRM4m FB8JWJcMsWj4o952j/IEuW0O4hkLIn+h/5evCVPAKrrY+vDCjTvFs3w+82rzecfuBYsfsrS5bbg S9JE3Gvf874870= X-Received: by 2002:a05:6000:25c3:b0:439:be67:a038 with SMTP id ffacd0b85a97d-439be67a710mr8902339f8f.41.1772556201554; Tue, 03 Mar 2026 08:43:21 -0800 (PST) Message-ID: <0210cf5c-6dc3-4db5-aa2a-0e14e634b463@suse.com> Date: Tue, 3 Mar 2026 17:43:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang To: Edwin Torok Cc: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> <004F02CE-B8C8-40B5-8453-C754EBE92022@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <004F02CE-B8C8-40B5-8453-C754EBE92022@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.03.2026 16:55, Edwin Torok wrote: >> On 3 Mar 2026, at 15:36, Jan Beulich wrote: >> On 03.03.2026 16:09, Edwin Torok wrote: >>>> On 3 Mar 2026, at 13:59, Jan Beulich wrote: >>>> On 27.02.2026 11:58, Edwin Török wrote: >>>>> --- a/tools/tests/x86_emulator/test_x86_emulator.c >>>>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c >>>>> @@ -1882,8 +1882,13 @@ int main(int argc, char **argv) >>>>> #define decl_insn(which) extern const unsigned char which[], \ >>>>> which##_end[] asm ( ".L" #which "_end" ) >>>>> #define put_insn(which, insn) ".pushsection .test\n" \ >>>>> - #which ": " insn "\n" \ >>>>> + ".ifndef "#which"\n" \ >>>>> + #which ": \n" \ >>>>> + ".endif\n" \ >>>>> + insn "\n" \ >>>>> + ".ifndef .L"#which"_end\n" \ >>>>> ".L" #which "_end:\n" \ >>>>> + ".endif\n" \ >>>>> ".popsection" >>>> >>>> Nice idea, but why multiple .ifndef, and why emitting the insn even if the >>>> labels are already there (and hence won't be emitted a 2nd time)? >>> >>> I think we still need to execute the instructions, so they can be compared against the emulator. >> >> Of course, but they cannot be executed without having a label. We use the >> label to point the emulated IP there, and then we use the end label to >> check that after emulation the emulated IP has advanced as expected. > > Oh that means that we won’t actually be testing anything useful in iterations>=1 > (the test passes, but it runs the same test as it did on iteration 0). May I ask for a little less bold statements? Of course the 2nd iteration isn't identical to the 1st. The insn encoding is the same, but the operands (the mask in particular, i.e. the value %k3 holds) aren't. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 16:44:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 16:44:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244949.1544291 (Exim 4.92) (envelope-from ) id 1vxSrg-00080W-B5; Tue, 03 Mar 2026 16:44:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244949.1544291; Tue, 03 Mar 2026 16:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSrg-00080P-8P; Tue, 03 Mar 2026 16:44:56 +0000 Received: by outflank-mailman (input) for mailman id 1244949; Tue, 03 Mar 2026 16:44:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSre-00080F-V8 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 16:44:54 +0000 Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170120001.outbound.protection.outlook.com [2a01:111:f403:c107::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4c9d9331-1720-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 17:44:52 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6623.namprd03.prod.outlook.com (2603:10b6:510:b3::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 16:44:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 16:44:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4c9d9331-1720-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=v7UfKB3gSPFHs70Y5Jz8t6biZNAj/AEnT/F/r3yWUR9PGNbj0ESNxg4u7Q9JLoPX0DQQcwxC1VyrIJ4m7kWTNoSImLzCSCCf43eGpyds66lr3yP93hvnUhgbpLlt570tAbnI9ySPr3Fo2nCoLdLbY4WWLZ6fLiziJ0ACgJv0Il2InhQyE8PUivH8nux5uPPfvXOKjD0NzqhrSyEAT1X2ScW8dvkhqMZDA4U2qsJe7d6+5oabqDMj+vVGGmUzcdsIsUF4E3HGk8lPteEfrRv807pLZL5MCV6vYhBi9P5e1+i92TxktGDRrjPYBEWziD4EVS9tXRuTV05G4m+Yh6ijZg== 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=0APOjVFT3cdvjaAW4vRXuCpNVGbuxVVn2TFVw9aURp8=; b=F9EbZVI7eTUvE8ckCClnjc3CEnCIe0hvLB5qy018iJcX30ft3ZFLpcUvrWl3hdLsjmuhDCmiNUicQq10E/KlhNvwFIHvOdWxImD39MwqC1vaKKPbpLzLDQQjhL7XUHPnMCo5uNAPlHtjz9VSjmHoNm40pHe+P45JVsu5EdP/B6DRz0Z8mcjZVKx8Z+Zs/2UOx0tJ6Ql1MC0WzEoDOoWlbSN4eoOFqci+p6LvexllCwzrO+Ler7U/GUZTr03d2X43Us3qawgezTcwUgBHFOqOsi35EzWVYgdvuHJjyRqhDiLtgK3XKaxDWtJKerYLapbOYCyVAdWa3hNyE5kAvNgh0A== 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=0APOjVFT3cdvjaAW4vRXuCpNVGbuxVVn2TFVw9aURp8=; b=d8bP0TLfAiBdi1I2JNRXFsgSefk+ke1hGXi+XwHcsJOzqnSBWagVELfHEUd/wVneeyemA44XSeJaoaMhQt10qHNlHA/8KRKsZJaXZoJQWeb630hfkGjif5IQfDn0klYXEH7cgxy2mdwFBhSz5tcHl0X99/CnvY9h+JQZua/dgXc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 3 Mar 2026 17:44:44 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Andrew Cooper , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Anthony PERARD Subject: Re: [PATCH v5 1/5] vPCI: introduce private header Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA3P292CA0031.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6623:EE_ X-MS-Office365-Filtering-Correlation-Id: 8a31d27f-5219-4bc0-25d9-08de79442e6a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: 7qHEhBRT3eeOb7lhr5eW7+ufG02dV6GMPWJP/Ggr7ZJ3+jZ4U8NtnPiyY5jyPWRx0yB8N6Z+bnAEIMad/DlqZZNINcbhmjhahpG0f67LKZnXFdEVeDzV46OS4N2HohIGsN6mZlt8+PtWDafG3Ovex4YY6aw2ZMItHiVm+qJI+kUNfvy8kWSMNhs4Jj97qvj+iMZMoV/jS4Fw1EFivBGALDrYTUs1YdD8w908PR88HzYA0wNVE6ht9n2RM7lsz5oSTgkMVRXVDMXMmRpsbjzfzNRn+qz1ZqpHBjahSdh/e8wRtywm9ifxiB0aLshrmMUqnWWm+jnpTX7j19lsCNVZn/8mW/xll1+9dr5CyxrzMFObtp9yZoHV5YZTAy0dAEoJGDjEinDdCtlw5Kdam6OQBlLR9VHvB3yR4N8GCPeVpU+VUCrJdS5vfqyXv1sBiRaw+FNAT4NdsScWrcOFW+2xD8X2eHF57PwZvb/Aa/0aft47/4oGQmohI1qgk55XrriGvVFjrj1uOIxXDuL9H6EmuksnftcloQ+KvKejok5IwttihZVusoMLIhrUjMfdON/Q+OrTBsMeXEQLgL+1AMed/ytPpx6zngqKubqXy93g13ewCBVmvJO9cJEjPLLiU2PcsIdzBZwj56TfD7VgeSRWOZ7hcI4k1mu4EZrVG/Fx/SgJ0ZzU3JdgxqCDAvgbEm4+VdpkkFlQgLs8AAEtanQrM8/CPVP/PF4jtBCWyyd6fzU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RnFJQ2F0YTNZOVYxekRKMnZ2WDN4QjFKdy9wUjlvazFOQ0lzMUdGamRCSmJ0?= =?utf-8?B?eTVidmRBand3WDNqdUFsT2dXeDhJRkJnN0Jnc3B6bkhoZjF3QnVGWnJ4V0Zx?= =?utf-8?B?NWN2ZmVQbzUrMXd5RlF2UUVSY3liak1YU3ZhVnpoRzhnZ2FidXVCQU04Q2Jn?= =?utf-8?B?b3h2a1JZV3RUcFVxVlUycXh3ajJDQ3pKYVpaZ3EwYzdWbk16bGROaFJjVENu?= =?utf-8?B?WWxzazNTVFdzTnVRL1J1U3loZHlQZTZSVE9JSm94ZXJmMU5HLzVCMERlbVJm?= =?utf-8?B?QUxhZmUyODJZR0xTNzg3a1NxcWlHSitlem9KcEs2UXlCeXlsWk5KUy9EdWxx?= =?utf-8?B?RlR5TmVvRndIOFZyN3VpQ0plZ2R3b0pLTFZiQzVpNC82NWF5RHRRMm1rWnF6?= =?utf-8?B?Q2FLZlBEcCthdkE1bTk4Z3MzMDJwK0Roc0NoNzVmc0FWVFB2VngwSVdrVXZ1?= =?utf-8?B?Slh4aVliMCsxK3lIQ1BoSytGbGE2MnQ2WmpEbndnRkhTaHJ1OVVVNmhIQVAx?= =?utf-8?B?V2l1cFNlN21LbHk3QmJuc3JRRWZhMjA2SEI3YXp5aTVCMm5uOHp3ZWZBSVRs?= =?utf-8?B?MkpGdGZkVHlmU1UvTWNOS2w3YXY1SjIyMnhHMjRmQ01FYlY4QnEyR0wra2E5?= =?utf-8?B?MW9HOFI5eVI5dnNLN1dlK2dsVXVkVzdWMlVjZkFoUSttSFZ5R3JDSEZLNE9w?= =?utf-8?B?Qzd0ZW81Rk9YdXJ2RURLQlhZeGhMQ28yNmVObmsvaHgraUxqUTZKdzFNVkh2?= =?utf-8?B?c2RaVlRaTTEySnkxbXBxd3F2QkJseHJhczVFajBFQkF2OFR3QWpwZjhsU3Nq?= =?utf-8?B?VEFzMkJaUlBmTW55ZXc3ZFh5TUI2VGlwU3Q0QnhtOWRlcU40RE9xSktnQTdw?= =?utf-8?B?TExYcy9xTU42VWlqaXFoTk0vaDJ0NnhXdmJBRW40UkxhV2lReTA1R3NXcU16?= =?utf-8?B?T2lDeE5QZUtZRjZUNEc4YVpJNHgzc1ZOS2ZWb3BqbzRicmRzVDkvZUV3cUtV?= =?utf-8?B?WE1aOVA5VEUraFZBOXVuRkpnWDFhSEJhc092djIxKzgyNmxha0V5Mzd0Z04w?= =?utf-8?B?ZlY4QldkQ0dCdWl1L0ZLTkl0RXFnQTVrVi80UUhjdlN5Q2NobHlXbGgxVmFs?= =?utf-8?B?R0tqb005UEZZVWxXTGJzQzdCMnVKWUE0aEp5RzVkRU0vWEVNN0Z4T01YS01Q?= =?utf-8?B?Q0RuL1BwL2QvbVAzd2hNNUVmRjMzUjdvdzl2RFBnaXplcWdqZEc5VFhERUsw?= =?utf-8?B?WTF2S3hkYURXOVFIZlhiaGxHUjZ1aGFVVElNR1JJREUzcXNjSWJKOVVzV0FY?= =?utf-8?B?SThLR1lpUlJ3ViszWmROZzJ4SXkxVTN3ODhUdHdGc1NoakpkRHBIZ2FBRHhD?= =?utf-8?B?Ry9rOUtQcjVEZFZGeVFOTzBwNGczZzJvQnhTWitDTURxS0lVTVhiTkJ3Lzl1?= =?utf-8?B?THZkb0dxT2orUE9yc0wxKzM4M1dDc21GeW93eEhmQmd5T0ZsZ29ZdHZaaUZC?= =?utf-8?B?UjFYZEg1WkFwMHhmS28yZGNJa0ZjNnZIN1NDdTNEaThMc04wS1B6aXFLdU4w?= =?utf-8?B?MWEzc1RieEthUExyemlGTEdXQXpUKzUwUTNxc0NDb0NpTTFTeHk3S0hxbXVC?= =?utf-8?B?QWE5ZUQ3cnNJMCtxWVVrM0ZheGsxbk5VblNUeWYrZmVmL3ZYTmkwMFFWZG9B?= =?utf-8?B?alJzbzI2VGJIQkhWWlBZTmIrR0dZYlZYQVFCVkh1YkZEZFMzYXV0alRlS0tu?= =?utf-8?B?RTVEL1pqaWpNU0M2Lzc4SmR4Q0c4Um1UZ2d5TEVud3hIVFJkbGQxTCs5dlhp?= =?utf-8?B?L3Bab3V5ZUJMMlpsYkV2SDhncE9ZR0E1QTVFeHdDRVRKN0pQRDhNcDF5aFN1?= =?utf-8?B?WUxPWTFhbnYwaGttSlExNGhoWmpSR2p6aFEydkh3RSt5UTVxSyt0dnc0ek1Y?= =?utf-8?B?Zm4zRUZJYVN4cmVJNHJGTGE0NTZOS2M4WS9PMjRxSXNFMzQzSGJBZG1VMDBv?= =?utf-8?B?WURQSjd3Qm9mV1AzbUpTRDdTb3hQckhMQUJtbm1HMXMxYU9SUEdEYW8yYzZ1?= =?utf-8?B?OVZLemZ4SUpIYnNpVFB0OGNMb2lGVmFLbkQzbE1zS2tGRkIvQU90anRxL0tr?= =?utf-8?B?K2ppdjNFbG5OUW82UEJFRjVBSGJwUWZQaHJtb2JXa2doSi9ubDQyb014cjJT?= =?utf-8?B?RG5qUVVmOFdWQ2plZWx5YkszbUk0aXExNXRDNVFwK0dTamxzVFRTRHA5dSsz?= =?utf-8?B?WU0xMXVIRW50S1VOVTk3M09jSmdyWlFZLzhjNHB5Z2tCOXRuUkZocnk5aUhS?= =?utf-8?B?R2Z0U05uZWNnZGtrMTJYemRDZy9DejR4dFZFenJMSnU3ZkxPbnp4dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8a31d27f-5219-4bc0-25d9-08de79442e6a X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 16:44:47.8926 (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: bn+Co/SeESsL0ajZW9IA5CmYVtHJYpHc4QVCqQ6VkOn7vZZbQxGR+fBU1S0QjIhYiJPr8yj0M0tY70DPZNIHMw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6623 On Wed, Feb 25, 2026 at 12:43:01PM +0100, Jan Beulich wrote: > Before adding more private stuff to xen/vpci.h, split it up. In order to > be able to include the private header first in a CU, the per-arch struct > decls also need to move (to new asm/vpci.h files). > > While adjusting the test harness'es Makefile, also switch the pre-existing > header symlink-ing rule to a pattern one. > > Apart from in the test harness code, things only move; no functional > change intended. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné One comment below. The Ack stands regardless of whether you want to change it or not. > --- > Subsequently, at least on x86 more stuff may want moving into asm/vpci.h. > --- > v5: Add new generated header to test harness clean rule and to .gitignore. > Also move vpci_init_header(). > v4: New. > > --- a/.gitignore > +++ b/.gitignore > @@ -154,6 +154,7 @@ tools/tests/x86_emulator/test_x86_emulat > tools/tests/x86_emulator/x86_emulate > tools/tests/x86_emulator/xop*.[ch] > tools/tests/vpci/list.h > +tools/tests/vpci/private.h > tools/tests/vpci/vpci.[hc] > tools/tests/vpci/test_vpci > tools/xcutils/lsevtchn > --- a/tools/tests/vpci/Makefile > +++ b/tools/tests/vpci/Makefile > @@ -14,12 +14,12 @@ else > $(warning HOSTCC != CC, will not run test) > endif > > -$(TARGET): vpci.c vpci.h list.h main.c emul.h > - $(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c > +$(TARGET): vpci.c vpci.h list.h private.h main.c emul.h > + $(CC) $(CFLAGS_xeninclude) -include emul.h -g -o $@ vpci.c main.c > > .PHONY: clean > clean: > - rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h > + rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h private.h > > .PHONY: distclean > distclean: clean > @@ -34,10 +34,10 @@ uninstall: > $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET) > > vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c > - # Remove includes and add the test harness header > - sed -e '/#include/d' -e '1s/^/#include "emul.h"/' <$< >$@ > + sed -e '/#include/d' <$< >$@ > + > +private.h: %.h: $(XEN_ROOT)/xen/drivers/vpci/%.h > + sed -e '/#include/d' <$< >$@ Nit: if you are changing/adding those we might as well do /^#[[:space:]]*include/d, as sometimes we add spaces if the header inclusion is conditional. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 03 16:48:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 16:48:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244959.1544302 (Exim 4.92) (envelope-from ) id 1vxSvH-0000AZ-Pw; Tue, 03 Mar 2026 16:48:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244959.1544302; Tue, 03 Mar 2026 16:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSvH-0000AS-N7; Tue, 03 Mar 2026 16:48:39 +0000 Received: by outflank-mailman (input) for mailman id 1244959; Tue, 03 Mar 2026 16:48:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSvG-0000AK-Q6 for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 16:48:38 +0000 Received: from mail177-30.suw61.mandrillapp.com (mail177-30.suw61.mandrillapp.com [198.2.177.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cfea8744-1720-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 17:48:32 +0100 (CET) Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail177-30.suw61.mandrillapp.com (Mailchimp) with ESMTP id 4fQMFC1GGQzP0K0dQ for ; Tue, 3 Mar 2026 16:48:31 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 3bceb4a3bd1844479c02f3bb66892b6a; Tue, 03 Mar 2026 16:48:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cfea8744-1720-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772556511; x=1772826511; bh=eUNoRhcDYCL60wG3kvxrWXAIPmTJ6jPDfNoSt1z/f7I=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=1S7GZ6RgiqZbcYlkph67vL4+CyQo/kNVNwLFzKuXg+lM0weV9P1h6MK0ijeLaNBd7 p1vAVfWQA7A/9lreNfoy/WafDEZfWsPQeyS/hKQS0ANfQqrmlVW8Ie7Cc6FpzD8jl8 oPuQ+oTLgo9fRpLg91FSHkZdZYOuJXx19GKmHxAePKKEtO94Lse4JSZXIroHMSQCXA b5MoUyFMmzr9ip5gVjY9II10G+3CNYvM7ATrDOv7dcZ/ekyuIZh+ikthYazuR3Zp59 HV6HCL55qOUvRXdavoj3+J67/KoF79niXVHPKD+KgAEXO4qunEMpY0kSxZ/4WZT9v0 K2iEmgky2HFSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772556511; x=1772817011; i=julian.vetter@vates.tech; bh=eUNoRhcDYCL60wG3kvxrWXAIPmTJ6jPDfNoSt1z/f7I=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=tI8lpF4roZ57dmZia2VEbDCLBkOrjzqw3uyE33hPglJRzOr1ZB2RFMMaIsgXVYKs4 SXttZhBw4lW9G1rIJ0xhRrUntSEE/wwplMkmcC6o/89Ie/5FJFjqfvtcVlDB0nYob0 nuFp67ufMnZsfFpSfUfSxAUQy6CzJ7fzIfHcC9M2tZ+3l81RlbjfFnT+UIoScvaVBz frOKkSIYXHyofsMa5kVnNmeOISnHWjSBXLv3pSglZUIDaWFdnv+gtjDKOeaA0dy0HM wkiS9BiyYDwdIBt3uNYPhoGSjOgeHmRJyQEBDxd3RyIbqPEU4tL/1KhUg5oyw/ztK1 gCmDZwtUNrM7w== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH=20v3=202/2]=20x86/ioreq:=20Extend=20ioreq=20server=20to=20support=20multiple=20ioreq=20pages?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772556509850 Message-Id: <151c64e9-a605-410a-b3b0-2c86cdf6fd2c@vates.tech> To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , xen-devel@lists.xenproject.org References: <20260223093831.475769-1-julian.vetter@vates.tech> <20260223093831.475769-2-julian.vetter@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.3bceb4a3bd1844479c02f3bb66892b6a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260303:md Date: Tue, 03 Mar 2026 16:48:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 2/26/26 16:54, Jan Beulich wrote: > On 23.02.2026 10:38, Julian Vetter wrote: >> A single shared ioreq page provides PAGE_SIZE/sizeof(ioreq_t) = 128 >> slots, limiting HVM guests to 128 vCPUs. To support more vCPUs, extend >> the ioreq server to use xvzalloc_array() for allocating a contiguous >> virtual array of ioreq_t slots sized to d->max_vcpus, backed by >> potentially non-contiguous physical pages. >> >> For the GFN-mapped path (x86), page and writable type references are >> obtained directly via check_get_page_from_gfn() and get_page_type() for >> each GFN. The pages are then combined into a single contiguous VA using >> vmap(). The number of ioreq pages is computed at runtime via >> nr_ioreq_pages(d) = DIV_ROUND_UP(d->max_vcpus, IOREQS_PER_PAGE), so >> small VMs only allocate one page. All existing single-page paths >> (bufioreq, legacy clients) remain unchanged. >> >> Mark the now-unused shared_iopage_t in the public header as deprecated. > > For this I think we need to settle on one of two options: Either it was a > mistake that this was used in the hypervisor (and added to the public > interface), in which case the removal of the use may want to be separate > (without, imo, any need to mark the item deprecated in the public header, > as the property remains). Or we deem it legitimate / useful, in which case > you would want to continue using it (in struct ioreq_server). > Thank you Jan for you feedback! It's very appreciated! You're right. But I'm wondering how would dropping the struct work? I looked into QEMU and varstored, and they both use this struct at the moment. But modifications to both of them would be minimal if we decide to drop the struct. And if they want to support multiple ioreq pages we would need to modify this struct anyway to not contain a single struct ioreq, but a pointer or []. >> @@ -89,6 +91,39 @@ static gfn_t hvm_alloc_ioreq_gfn(struct ioreq_server *s) >> return hvm_alloc_legacy_ioreq_gfn(s); >> } >> >> +static gfn_t hvm_alloc_ioreq_gfns(struct ioreq_server *s, >> + unsigned int nr_pages) >> +{ >> + struct domain *d = s->target; >> + unsigned long mask; >> + unsigned int i, run; >> + >> + if ( nr_pages == 1 ) >> + return hvm_alloc_ioreq_gfn(s); >> + >> + /* Find nr_pages consecutive set bits */ >> + mask = d->arch.hvm.ioreq_gfn.mask; >> + >> + for ( i = 0, run = 0; i < BITS_PER_LONG; i++ ) >> + { >> + if ( !test_bit(i, &mask) ) >> + run = 0; >> + else if ( ++run == nr_pages ) >> + { >> + /* Found a run - clear all bits and return base GFN */ >> + unsigned int start = i - nr_pages + 1; >> + unsigned int j; >> + >> + for ( j = start; j <= i; j++ ) >> + clear_bit(j, &d->arch.hvm.ioreq_gfn.mask); > > You using clear_bit() here doesn't make the while operation atomic. There will > need to be synchronization (also with hvm_alloc_ioreq_gfn()), and once that's > there (or if things are suitably synchronized already) __clear_bit() ought to > suffice here. Yes, sorry. I will drop the "legacy gfn multi page" part entirely. In your other reply you wrote: "Thinking about it - isn't this GFN based approach the legacy one? Can't we demand use of the resource mapping approach to support bigger guests?" I didn't fully understand this path is the legacy path. So, I adapted it as well. Now, it's clear to me and I agree with your assement. I will remove the part for the legacy path, and will just check that if we take it, in 'hvm_map_ioreq_gfn' I will do: if ( nr_ioreq_pages(d) > 1 ) return -EOPNOTSUPP; > >> + return _gfn(d->arch.hvm.ioreq_gfn.base + start); >> + } >> + } >> + >> + return INVALID_GFN; >> +} > > Did you consider whether fragmentation could get in the way here, as is usually > the case when doing mixed-size allocations from a single pool? In how far is it > necessary for the GFNs used to be consecutive? Same as above. I will remove this part. > >> @@ -134,16 +181,41 @@ static void hvm_unmap_ioreq_gfn(struct ioreq_server *s, bool buf) >> >> hvm_free_ioreq_gfn(s, iorp->gfn); >> iorp->gfn = INVALID_GFN; >> + return; >> } >> + >> + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) >> + return; >> + >> + nr_pages = nr_ioreq_pages(s->target); >> + >> + for ( i = 0; i < nr_pages; i++ ) >> + { >> + struct page_info *pg = vmap_to_page((char *)s->ioreq + > > Please can you preferably cast to const void * (or void *)? But perhaps you > would better latch the pointer into a local variable anyway, for ... > >> + i * PAGE_SIZE); >> + >> + put_page_and_type(pg); >> + put_page(pg); > >> + } >> + vunmap(s->ioreq); >> + s->ioreq = NULL; > > ... this clearing to move up ahead of any teardown done. > >> + hvm_free_ioreq_gfns(s, s->ioreq_gfn, nr_pages); >> + s->ioreq_gfn = INVALID_GFN; > > This similarly may want moving up. > > As to the loop body, destroy_ring_for_helper() has put_page_and_type(), but > no put_page(). Why is this different here? Yes, sorry. We don't need it here. I dropped it. I now do the same as 'destroy_ring_for_helper'. > >> @@ -173,30 +245,132 @@ static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf) >> >> return rc; >> } >> + >> + /* ioreq: multi-page with contiguous VA */ >> + if ( s->ioreq ) >> + { >> + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) >> + return -EPERM; > > The comment on the other path at least wants referencing here. > >> + return 0; >> + } >> + >> + if ( d->is_dying ) >> + return -EINVAL; >> + >> + nr_pages = nr_ioreq_pages(d); >> + base_gfn = hvm_alloc_ioreq_gfns(s, nr_pages); >> + >> + if ( gfn_eq(base_gfn, INVALID_GFN) ) >> + return -ENOMEM; >> + >> + mfns = xmalloc_array(mfn_t, nr_pages); > > Especially when there are only a few MFNs, this dynamic allocation would be > nice to avoid. If there was a not overly larger upper bound, using a per-CPU > array might also be an option. > > If the dynamic allocation stays, new code wants to use xvmalloc() and > friends. This all goes away for the legacy path we only have a single page so no xmalloc_array anymore. > >> + if ( !mfns ) >> + { >> + hvm_free_ioreq_gfns(s, base_gfn, nr_pages); >> + return -ENOMEM; >> + } >> + >> + /* >> + * Obtain a page reference and writable type reference for each GFN. >> + * No per-page VA is needed; all pages are mapped as a single contiguous >> + * VA via vmap() below. >> + */ > > I think this comment wants to mention prepare_ring_for_helper(), so that if > updates are done there, there's at least a fair chance that people might spot > that changes need doing here as well. > >> + for ( i = 0; i < nr_pages; i++ ) >> + { >> + struct page_info *pg; >> + p2m_type_t p2mt; >> + >> + rc = check_get_page_from_gfn(d, _gfn(gfn_x(base_gfn) + i), > > gfn_add() please > >> + false, &p2mt, &pg); >> + if ( rc ) >> + { >> + if ( rc == -EAGAIN ) >> + rc = -ENOENT; >> + goto fail; >> + } >> + >> + if ( !get_page_type(pg, PGT_writable_page) ) >> + { >> + put_page(pg); >> + rc = -EINVAL; >> + goto fail; >> + } >> + >> + mfns[i] = page_to_mfn(pg); >> + } >> + >> + /* Map all mfns as single contiguous VA */ >> + s->ioreq = vmap(mfns, nr_pages); >> + if ( !s->ioreq ) >> + { >> + rc = -ENOMEM; >> + goto fail; >> + } >> + >> + s->ioreq_gfn = base_gfn; >> + xfree(mfns); >> + >> + return 0; >> + >> + fail: >> + while ( i-- > 0 ) >> + { >> + struct page_info *pg = mfn_to_page(mfns[i]); >> + >> + put_page_and_type(pg); >> + put_page(pg); > > Same issue here - I can't spot which page reference you're dropping. You > obtained only one above. yes, I forgot to call the alloc_domheap_page. > >> @@ -208,6 +382,32 @@ static int hvm_add_ioreq_gfn(struct ioreq_server *s, bool buf) >> >> return rc; >> } >> + >> + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) >> + return 0; >> + >> + nr_pages = nr_ioreq_pages(d); >> + memset(s->ioreq, 0, nr_pages * PAGE_SIZE); >> + >> + for ( i = 0; i < nr_pages; i++ ) >> + { >> + gfn_t gfn = gfn_add(s->ioreq_gfn, i); >> + struct page_info *pg = vmap_to_page((char *)s->ioreq + >> + i * PAGE_SIZE); >> + >> + rc = p2m_add_page(d, gfn, page_to_mfn(pg), 0, p2m_ram_rw); >> + if ( rc ) >> + /* >> + * No rollback of previously added pages: The caller >> + * (arch_ioreq_server_disable) has no error handling path, >> + * and partial failure here will be cleaned up when the >> + * ioreq server is eventually destroyed. >> + */ >> + return rc; > > Shouldn't you continue the loop, to try to add back as many pages as > you can, so the domain encountering problems later is as unlikely as > possible (albeit a single missing page is already bad enough)? > >> @@ -260,9 +259,32 @@ 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 ioreq_page *iorp; >> struct page_info *page; >> >> + if ( !buf ) >> + { >> + if ( s->ioreq ) >> + { >> + /* >> + * If a guest frame has already been mapped (which may happen >> + * on demand if ioreq_server_get_info() is called), then >> + * allocating a page is not permitted. >> + */ >> + if ( !gfn_eq(s->ioreq_gfn, INVALID_GFN) ) >> + return -EPERM; >> + >> + return 0; >> + } >> + >> + s->ioreq = xvzalloc_array(ioreq_t, s->target->max_vcpus); >> + >> + return s->ioreq ? 0 : -ENOMEM; > > At this point you haven't fulfilled what the function is supposed to be > doing. The pages you allocate also aren't associated with the domain, > and you haven't obtained writable references. yes, sorry, same as above I forgot the call to alloc_domheap_page. > >> @@ -812,26 +861,30 @@ 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 = page_to_mfn(s->bufioreq.page); >> rc = 0; >> - break; >> - >> - case XENMEM_resource_ioreq_server_frame_ioreq(0): >> - *mfn = page_to_mfn(s->ioreq.page); >> - 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); >> >> - default: >> rc = -EINVAL; >> - break; >> + if ( idx >= XENMEM_resource_ioreq_server_frame_ioreq(0) && > > You checked this above already, didn't you? > >> + page_idx < nr_ioreq_pages(d) && s->ioreq ) > > The former part of this check also looks redundant with the earlier one. > >> --- a/xen/include/xen/ioreq.h >> +++ b/xen/include/xen/ioreq.h >> @@ -19,9 +19,19 @@ >> #ifndef __XEN_IOREQ_H__ >> #define __XEN_IOREQ_H__ >> >> +#include >> #include >> >> #include >> +#include >> + >> +/* 4096 / 32 = 128 ioreq slots per page */ >> +#define IOREQS_PER_PAGE (PAGE_SIZE / sizeof(ioreq_t)) > > I think the comment wants dropping, as it would end up wrong / useless for > page size different from 4k. I'm also not quite sure the #define is overly > useful, as ... > >> +static inline unsigned int nr_ioreq_pages(const struct domain *d) >> +{ >> + return DIV_ROUND_UP(d->max_vcpus, IOREQS_PER_PAGE); > > ... this is its only use. > > Jan -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 03 16:49:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 16:49:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244964.1544311 (Exim 4.92) (envelope-from ) id 1vxSvd-0000WU-4D; Tue, 03 Mar 2026 16:49:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244964.1544311; Tue, 03 Mar 2026 16: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 ) id 1vxSvd-0000WN-1f; Tue, 03 Mar 2026 16:49:01 +0000 Received: by outflank-mailman (input) for mailman id 1244964; Tue, 03 Mar 2026 16:49:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxSvc-0000AK-2j for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 16:49:00 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df6fbd7b-1720-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 17:48:58 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48374014a77so71472395e9.3 for ; Tue, 03 Mar 2026 08:48:58 -0800 (PST) Received: from [10.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-483c3b89c99sm359127545e9.15.2026.03.03.08.48.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 08:48:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df6fbd7b-1720-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772556537; x=1773161337; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=g0mLQdApzNBJwno5estL6Zp2Cn3YSUdJlxvg63cs+l4=; b=R8LHNYbYbYeRARcn/HkFKmO1sHw607nma4eSm/43ashi7DTRo4+lcQU+mJljhjivrj oPKBpcF3xJxcTXfiJKcbzp8xgOfskYu0HpcMzIzoWqJKU4T27j2RhyEEANCuY+hb9QBW 4R1IUN5ZUvA142m+0o4iwHNubi/lnDzhxWosS6GZmtj53KZwcaiIQ7wwFNnXPeFzQ3UV jM5TGyqbDSBupkUJObBCLS+x7WBCFjGvT0c+cRFdGqxZEiaopn580Gz+fb0GFDYZeCwH wpPMVAjtNq+IRNdt+F14vfNGkVbCO0+YBJKyfOl/UsWdRxNPJZ4nlbGCtaYRMm5dd63v Bg6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772556537; x=1773161337; h=content-transfer-encoding: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; bh=g0mLQdApzNBJwno5estL6Zp2Cn3YSUdJlxvg63cs+l4=; b=eudSrqgL0ltrJqhfgudQCYy/ZaBQxgslUBpvBPGy1+PwBZjzrJEH7TfGWIvF9jmwia jZ+D/rKFCrx70ITuy2Bna7URiwZS9uOS4eSu7qMFIKUNNkm2n3K2FaxdZ5d+xONm2+// whHfJSN/+c5dtSJhmweTm80b88+roODG9qdaUzNaMgKNmPde8ZoDPryMljoqZnihLFMX sOPEGwsw6P7UeH8OLdN99j+o5UhcXKtwulFF0I6mizfi+TWJ+Kv0hplWyGH2wicU/sCc 6ZEqSxdhPH8++tjN8BU2gcfkUxhREBklnZyguf6iTHEjFh52MVJ3aa5MYnclNPdrNr8+ g8QA== X-Gm-Message-State: AOJu0YxLaK8/CtPt8A8mPvZzSRKYwHsKDAKVT7VurjnxYad8r/NJB4KS T4dsAJBjOF7cRemDW5HZOfBg5rNrt7QbOqwCGwlgyqYG9/xQclL0rhE/8yVn9+sxnw== X-Gm-Gg: ATEYQzweH+jwvCBVK9L3vCVecI36++hNzvgJ6VgdJYNcXhbZHhtKEVZaxZgRhDDwAnG b/bAQO+Mv6UNuxuYUmjtOlQ8D4M1hztuvagomliC0v5XQSPCMgWLML9EThUSg5AmjauUFCVBdDQ 4B3765+nUvCHGc1hc4SzHhmaj8bB1B+WBln0KwPqSNtixym79PghVZWbK2PRkIqRalfXj37MwJ1 L6C7e9d9xMSmsFUv7hYYh0IdlCjtnxxXrH/7hhtT5hleHUrI9urlyCs+V8tE2XkAufQFhRMb7jJ ycqIsm+ys0RMu+dMZLfmQOTMh42ndoWOUZKHRF++N66w1bfYw6OSeQh5vckalum6n+W5JKBkJ0+ 6tltj9anEFPnw/HUPBgcv2Kg9W9EgDS93VlEN2KnMMtUeL/B1ZZ/dPFK3P8s/UuYmsbwrsI5P9+ C5KifJ+blnSJRPvw31xB9FpfMy2khMFdogiueoGpVDRrokBCK1HVJQPUXN0Twk0DeYXyli59W0D WXsUnAmFAxnius= X-Received: by 2002:a05:600c:6994:b0:477:c478:46d7 with SMTP id 5b1f17b1804b1-483c9c0b88amr284908735e9.22.1772556537487; Tue, 03 Mar 2026 08:48:57 -0800 (PST) Message-ID: Date: Tue, 3 Mar 2026 17:48:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/5] vPCI: introduce private header To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Andrew Cooper , Julien Grall , Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Anthony PERARD References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03.03.2026 17:44, Roger Pau Monné wrote: > On Wed, Feb 25, 2026 at 12:43:01PM +0100, Jan Beulich wrote: >> Before adding more private stuff to xen/vpci.h, split it up. In order to >> be able to include the private header first in a CU, the per-arch struct >> decls also need to move (to new asm/vpci.h files). >> >> While adjusting the test harness'es Makefile, also switch the pre-existing >> header symlink-ing rule to a pattern one. >> >> Apart from in the test harness code, things only move; no functional >> change intended. >> >> Signed-off-by: Jan Beulich > > Acked-by: Roger Pau Monné Thanks. >> --- a/tools/tests/vpci/Makefile >> +++ b/tools/tests/vpci/Makefile >> @@ -14,12 +14,12 @@ else >> $(warning HOSTCC != CC, will not run test) >> endif >> >> -$(TARGET): vpci.c vpci.h list.h main.c emul.h >> - $(CC) $(CFLAGS_xeninclude) -g -o $@ vpci.c main.c >> +$(TARGET): vpci.c vpci.h list.h private.h main.c emul.h >> + $(CC) $(CFLAGS_xeninclude) -include emul.h -g -o $@ vpci.c main.c >> >> .PHONY: clean >> clean: >> - rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h >> + rm -rf $(TARGET) *.o *~ vpci.h vpci.c list.h private.h >> >> .PHONY: distclean >> distclean: clean >> @@ -34,10 +34,10 @@ uninstall: >> $(RM) -- $(DESTDIR)$(LIBEXEC)/tests/$(TARGET) >> >> vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c >> - # Remove includes and add the test harness header >> - sed -e '/#include/d' -e '1s/^/#include "emul.h"/' <$< >$@ >> + sed -e '/#include/d' <$< >$@ >> + >> +private.h: %.h: $(XEN_ROOT)/xen/drivers/vpci/%.h >> + sed -e '/#include/d' <$< >$@ > > Nit: if you are changing/adding those we might as well do > /^#[[:space:]]*include/d, as sometimes we add spaces if the header > inclusion is conditional. Editing these two like you say would leave an inconsistency with what's further down (and what isn't being touched). I think I'd hence prefer that to be a separate change. Nevertheless, I agree with the intention. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 16:57:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 16:57:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1244981.1544322 (Exim 4.92) (envelope-from ) id 1vxT3Y-0002J5-TY; Tue, 03 Mar 2026 16:57:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1244981.1544322; Tue, 03 Mar 2026 16: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 ) id 1vxT3Y-0002Iy-QM; Tue, 03 Mar 2026 16:57:12 +0000 Received: by outflank-mailman (input) for mailman id 1244981; Tue, 03 Mar 2026 16:57:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxT3W-0002Is-SC for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 16:57:10 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 041fdbe4-1722-11f1-b164-2bf370ae4941; Tue, 03 Mar 2026 17:57:09 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439b790af67so1442721f8f.0 for ; Tue, 03 Mar 2026 08:57:09 -0800 (PST) Received: from [10.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-439c4489279sm2993564f8f.20.2026.03.03.08.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2026 08:57:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 041fdbe4-1722-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772557028; x=1773161828; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=xS72+haNYWCevDvohxWWznv7pyLrld8FU80bvDuP3UY=; b=cpwbe2R0nbSeH5TFdK0I2TqA/85llbju5UnIQYbhLuVqoMhf7Ml6SU59IA14ImDqyz FhyYA/+zvvGyiIYz66adL4mjr5MqIY/u6M5aXhfQewDuMQO8UwpJJ44xTICMeZ2jM9XC gabmD+PYcRUfCCy79G+Ys1xTQvC1p4eYzUVcoRdXxvWTXkX1/FU4cI5QwgYQQTlaz0ym 4dsmkISk1KQjatq73KSYOrrUdXJfyx+pa+V++gPV2ME5s4cFKO2hc5pjl0ZNZtdduaWR qaWJL+oxBuRAtxaNSrHfd5Y6ArlnMpNr66D+bqoX2jNqX86O+jlAbEc89ybx6vNF8YjR ky+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772557028; x=1773161828; h=content-transfer-encoding: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; bh=xS72+haNYWCevDvohxWWznv7pyLrld8FU80bvDuP3UY=; b=wfV6RI8GndZ9FctSHgH19XusCVJYh8odIiODqmWLWLPRPPw35Xsti+MTvEV/fSN5I+ fUDBz+lvzej9ERaeoBGZRVrMLyTJxgqwMLPcTlRmBamdbbwVmLqysqtMwuBk+ebfdMJA Pb8SrTDTt9lU+2rBQomlTfEGVzldz74XrHwNMuDmwQRkolO4yOVY8MqTchbXKMPHGSkQ zojW0eTz04H3Ym5WuZJNqtM2tXP2UFeOAn4tm+VtKwy1Ki4w1Nz6ZzcQJrAvuUGFSC0l QqPgeChNgjr2hqhtZCibPSdYa9sIfy5cYdIaS/5tUhxgA3lvdeawxchg9wfz5aYrJot7 8mWA== X-Forwarded-Encrypted: i=1; AJvYcCWQAWhLGXl9R5P5ozifuXRfv58yRXMLtlYMTVgX6ooZM6Z3JM1k747kum0sQmF0ncN1aLBOSB9JcfI=@lists.xenproject.org X-Gm-Message-State: AOJu0YwOesPmfLcU1ItzYGLW2IiQIhriMklX/F82V9fQQG89jjpWIcpJ gncLiNdlsxkoU5jG9KY5iM15SJjFbmra1q9DNzguzVyQk6Tn4hZZmkIgLpbZguXYKg== X-Gm-Gg: ATEYQzyrU8UZV0GdARh4mSmtIHvF9Ysb1biu8mrWCAFezA/4TaAh/NFJFvmdSUJcTDi LvfhtaSJMXoXn/RtJE5CTKQh6FH5CdtJrLwev2G5L1DuZRSt5v/pFmaSlkN14YRdyAk2ZDd3K3f slQ+pDqLG0MNe19wWFXGMvyim0U/dtmHe7p3R09w6QWtfY0mSpWHu65C8VI9GDWg/D0jghMLUhW 9tZUPUKmdYzORi5zR2wNB+03+kTOz555HOueR3V4udiQZYw1sld3XP/B8lBUW1nBd/Fh+pE//oN yWUatslXe2v4gFbL9fziXZzJLioNsIu2vYOFsVsOTgcg+X1oikt9Tlq2xuMCV6GaHxyfVX8BWaH z1VtFX824p8dSqAS/YjZfkmVlq1jW0R4fXTyUOzHz53uEpkGMmgwujbb0V1KokR7xf+QuyB9YA6 qJN1aSEsMn6S5yenXT2wwKRdQeScgw6v/Y67QRDDNV9hHGJ1wdvhjeDEIeWaQYPT90cBUaUbuuC rQ58Msq3g+kLSI= X-Received: by 2002:adf:e788:0:b0:439:b775:fca2 with SMTP id ffacd0b85a97d-439c10dfa1amr4629127f8f.24.1772557028366; Tue, 03 Mar 2026 08:57:08 -0800 (PST) Message-ID: <79729d02-65ae-4eeb-a66b-e05cdcfe9166@suse.com> Date: Tue, 3 Mar 2026 17:57:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] x86/ioreq: Extend ioreq server to support multiple ioreq pages To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260223093831.475769-1-julian.vetter@vates.tech> <20260223093831.475769-2-julian.vetter@vates.tech> <151c64e9-a605-410a-b3b0-2c86cdf6fd2c@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <151c64e9-a605-410a-b3b0-2c86cdf6fd2c@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03.03.2026 17:48, Julian Vetter wrote: > On 2/26/26 16:54, Jan Beulich wrote: >> On 23.02.2026 10:38, Julian Vetter wrote: >>> A single shared ioreq page provides PAGE_SIZE/sizeof(ioreq_t) = 128 >>> slots, limiting HVM guests to 128 vCPUs. To support more vCPUs, extend >>> the ioreq server to use xvzalloc_array() for allocating a contiguous >>> virtual array of ioreq_t slots sized to d->max_vcpus, backed by >>> potentially non-contiguous physical pages. >>> >>> For the GFN-mapped path (x86), page and writable type references are >>> obtained directly via check_get_page_from_gfn() and get_page_type() for >>> each GFN. The pages are then combined into a single contiguous VA using >>> vmap(). The number of ioreq pages is computed at runtime via >>> nr_ioreq_pages(d) = DIV_ROUND_UP(d->max_vcpus, IOREQS_PER_PAGE), so >>> small VMs only allocate one page. All existing single-page paths >>> (bufioreq, legacy clients) remain unchanged. >>> >>> Mark the now-unused shared_iopage_t in the public header as deprecated. >> >> For this I think we need to settle on one of two options: Either it was a >> mistake that this was used in the hypervisor (and added to the public >> interface), in which case the removal of the use may want to be separate >> (without, imo, any need to mark the item deprecated in the public header, >> as the property remains). Or we deem it legitimate / useful, in which case >> you would want to continue using it (in struct ioreq_server). > > Thank you Jan for you feedback! It's very appreciated! You're right. But > I'm wondering how would dropping the struct work? I looked into QEMU and > varstored, and they both use this struct at the moment. But > modifications to both of them would be minimal if we decide to drop the > struct. And if they want to support multiple ioreq pages we would need > to modify this struct anyway to not contain a single struct ioreq, but a > pointer or []. There may be a misunderstanding here: I said "drop the use" (in the hypervisor, that is), not "drop the struct". There's also no strong need for a pointer or [], as it looks: It being [1] right now is, aiui, a poor man's flexible array. For one, for general use the public headers need to be C89 compatible, i.e. no flexibly arrays unconditionally. While we do have some conditional uses (see XEN_FLEX_ARRAY_DIM), that may not be usable here, as the array is the sole field of the struct. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 03 19:13:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 19:13:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245026.1544375 (Exim 4.92) (envelope-from ) id 1vxVB5-0002NY-K7; Tue, 03 Mar 2026 19:13:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245026.1544375; Tue, 03 Mar 2026 19:13:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxVB5-0002NR-FQ; Tue, 03 Mar 2026 19:13:07 +0000 Received: by outflank-mailman (input) for mailman id 1245026; Tue, 03 Mar 2026 19:13:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxVB4-0002NL-0u for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 19:13:06 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fc11022c-1734-11f1-9ccf-f158ae23cfc8; Tue, 03 Mar 2026 20:12:57 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) 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.20.9654.22; Tue, 3 Mar 2026 19:12:53 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 19:12:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc11022c-1734-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ckPV2KqLhvv0gr4XgNi6DxkH6OB3k1a1bMQddtC6JHPwVrjZEnXwJvE6rUCkJCEuo6u83R1upYugu0LITpJiHwN436c2RynaJjyybbUqDJw7jtsThQtNXwUzDJbOVIpPZqKhDtKoLJDFIrNOY8fXPJukp6Kg0kFR87QM/2DOOMCc59/sE4wywPlzHjDDyw3y5x6s1VwSKMvXBq5yHf2OcHTwKO1hfQxKwsey5i9lx0vHevBIk9XzX8hF+AX3J0HCvVvylyn8fW56Lzc9mKtjcQufAu1zDuMecYbNQsE2D0HqAfyE1WJ9Q8Qj/ezpYtoXXWIcwx6gB2Sy0rNSddsDGQ== 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=gzg/aIEl53JUjWu/8td9aBPGZTL2UamZUBY7hTm/Bio=; b=nRBjflV4iXkbgy8HppncOdzN4XZXuzSl2NJ6eIOu9yFzVq62mjhFixW88zZUfa5S5SMw1J/C37EDndC0bCA+Aqn/BIVGTRQF3NBkoabxrMLsxamAMtJ7MpozqHomg5qnlX/E1ayiJTOZ3L92n70c00aJqP9+v6mJex5cbCPI4XWSQkdZtSKsXvP7kE/C2Pwf/UY9kGy6bWisIr7LSECWQh5FHyf7acRl6tjrYCgPyjBQxLRrIhvo4sJS2VtMeCrXduGygU3wSuA0H/SphLC8XJQVAdblHukIj7mi3zKeAhVAh672ynrv68r0gkTbeK8nPU110oiHuPvEDKdz+uopfg== 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=gzg/aIEl53JUjWu/8td9aBPGZTL2UamZUBY7hTm/Bio=; b=sdA+YwiAKtoqLtjxE0arX9atF68UBuiW4fDsqDgV3NQ2XVwhRWWY1ZcNDkYfKInLAJlfSzNZPd4Dej7pWr5TUJ5zJtqeIUD1HKgiOOV7qMvBZMCLOpFBHBXcQZwN/+iS13/MKE9W1sW2DPwmzYKlIWMdA2yidbOYQrFX4CsdSJA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3db44102-66c2-475b-8588-960ad774ee73@citrix.com> Date: Tue, 3 Mar 2026 19:12:49 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , jbeulich@suse.com, roger.pau@citrix.com Subject: Re: [PATCH] x86: Remove x86 prefixed names from mcheck code To: Kevin Lampis , xen-devel@lists.xenproject.org References: <20260302191900.672460-1-kevin.lampis@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260302191900.672460-1-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0412.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:189::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_|SJ0PR03MB5503:EE_ X-MS-Office365-Filtering-Correlation-Id: 074ad2d5-2e73-4cfc-3dd7-08de7958de60 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: INDE3bGrAXpbFRk8yEaJN3lxyfJ1PlbYTVkpSxWF8wLRggHLtgwg8eBBrjrDQy1yEeYZgPR5GINYurhiAO/02vhQTkfFAAUzrSH274didbAzDEMIZ1QVluWGtPGNbRCBYBE01WzmgjTGzEAyQyUcpIdSKkF1hAV+2Lw+GWyORcWx1TGt/HgjxIB+0M4IGYvbmqKZrKF7j/8FWpDT/NjKQgWW96cYXOb4DnoxOq90QcFuYynL/RmI4URJyGf3yYrnvGn05N/j18FHkfCvJN0ibxEFaMOeWQzBcUxha1c76rOl7enZgHJ66v3wKJ5FMdQtLAJY2UnRMBI+4jhNmG3yZc+E+INPMdif8MORs3EZUFkz3xu/Tt+e3aQ8xl30NgO2L3M1uXSg/nyJoddZa6yzsu2Uj4wIRx9Lmo3bwkngDbF/eT3uLP3BAwePpYDbfm481C4gQlrMsCnokyBIokwRNYkrUNfHaMNDfdIzURJsNBrrq8mvV4v+P2i4eZDEfQuosQu8nJp/8yzFnPYwQLoWrOLk1XSsQUjVqcSz+29WfGN+TUEWcpHhM7ri3ol4jjORJbycQdpYu2vj9qycLdX6XZFD3RHp7Ac5+2uGpOT5B8KtQ8SiollbZ4UfMnqgvUHgw07Yw68PXxD70c9/vzV6WoSo+3OnPXGHUbDUaFkGO/tqD+HQnbtDrPs07+nOpfePQw51FsncxVfLZc+8M+xqqKeFJ3gCGLj4ONg9elb1cYg= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TlRCMG8zNGRjYWd0RXowUUx0dGdwS21yYzdyUi8rK1VaTnI0dDRucVM4aldF?= =?utf-8?B?T1BmaXNvRGt1WjZMTGVDai9JV1RZL2RpN0FidXVySy80NXFDUzk1aXFWVmpk?= =?utf-8?B?SDEyUlo1NVlEMVRxaERsUGRxQzdGN2RnRzNJc3B2SU1DYjhOZ09CSUVqQzNW?= =?utf-8?B?Q3ZvSDgxTFQ4cXRGR2EwNlZiZE5VUHlTK3RqQU1wdG9ISnBnelFmVkYzdU5w?= =?utf-8?B?L3JMSUZNb2JQaldIYjlMVW9zRnVsbmp1VEV3VVZ0SU1JMzlJbDZ2THRjT29n?= =?utf-8?B?aFhMVWwrWEltQk5keWlyUGFzcWlpM3d2OXEvTUdncTBlSkFMUWYvWFNOMHlr?= =?utf-8?B?TWpmODdMVTN1ZldRc2lOdHphZStZT25ZaXZMTDJDd0dvQkhHUFNtQjdLZ1Fp?= =?utf-8?B?c0lOSlBGamhERWlYTHl6dnh3bE9QMzRZVmZ0NVJMQlI4QWxoOHY3dkRmcTJB?= =?utf-8?B?NmJIOXordmVqeHZyZVZQcHpmeWpSS2VqWWdleHFzY2RRZVVLbGFXQVNoQ09O?= =?utf-8?B?UzJ6T01kMUFTV2c1WDgxT2s0WFYyWUp5MjVhSi9iMnErdDUvWjlNNHY3NVZ5?= =?utf-8?B?djFIbStLQ1VhWDgyd1RaM2tBS0h2QXdVd0JQb3N4TXJpWFkwejY0VFJQWU1x?= =?utf-8?B?am0rYU9PNVFRbVpFUEgvTFpWMzltOWFRb2RCVWc0d1ptaUVQSmlVaERKaEJD?= =?utf-8?B?eUZFaVRvbDZTQU1kR3VHVXo5MUd2aXJuNjNneFZtb3dOYWRBZEpxSnNyalRI?= =?utf-8?B?YW9SdWZYM3pESkdoUEV4ZUllVHZyNGliSXFTUldWZEI1MngvVXNWSnpYL2Q5?= =?utf-8?B?VERETGRGbmJkWHZqcVd2ei8reW9XdU9rZHcyM05qU3YyMG9SWE45RXNoaFhh?= =?utf-8?B?THhScENZOExuRE1oMDlGVk1yWGdRam1wR3oxbGJIelo0dnd1SjZhZXkyMHpz?= =?utf-8?B?bWlJdXlnUVBKQWNmdm0yaHhBVnZZclA0N3lwMVI3elIxSzVWZVRveEVvbjlp?= =?utf-8?B?d0ZreWJUYm9DTEMxWndtOThXd1J3UzN3QkpTajFKMnplS1BtbHM4alF1Rkcv?= =?utf-8?B?NXh4ZjExWXU0b04vcTBxRHlaV1pPVS9tYkZwRGIxVjBFcm1ldndoQ20zcUQv?= =?utf-8?B?bnoxb0lETjUvSWFGUnZJeEZKMHZYdUY4Wmk4T2MvOWQ1em5Cd1VQdGJHY0VG?= =?utf-8?B?WVExUU9WbElzV0VYSEVleityQ1lYTGl2UlpsVG5ySUJxU3U1UXBCMXMzUmJu?= =?utf-8?B?M0h5clpnTFZlb3AvNys4aDREemsraXIrMWptWFBpQ1pxUGR3ekFyL1p1LzVu?= =?utf-8?B?ckNLaWRMREFqSFFXUVU5V3lRclBDN2M5SXJyOHVZRk5HQm5MWk1Sdk9aa0pX?= =?utf-8?B?MmdzSm9mYThHblZrcG5FN0pKUThsSEpjRU1MUWh4eHJEcERkV051R1ZGcUxG?= =?utf-8?B?dnlZbCt1SUVLdXcrd3A5TXl0amxuaWZzZ2M1T093OFczOTZUUm9LeXR6bHRO?= =?utf-8?B?QXJDNVhZWnVQUHQ5RGcvVGVSK2R4TzJ4SWdBSlZqaUlXYlVjNDdtSkVsSFNX?= =?utf-8?B?QjV0UDUyQTFwc2orYmdMMnFudEJQb3FFK3RwZ0F2b2tGV1IzVXU2VEZPNldp?= =?utf-8?B?RHpQdThBQm16akFqOVozRGhTNVhIaGY4UEJuNWFQbHkydVlPN1lCbXNXSXZE?= =?utf-8?B?WTkzZy9WMVVjakcrcmNjOXBEWkEvYzV1c0IvZ1owbTc0S1RWSnhCeERheHQ5?= =?utf-8?B?NmpEVFFlRXhXVFM4Zms1UzhHY0ZOSC9RWU1TT1NzTll5WnVQYnNzZUk0emEz?= =?utf-8?B?dFhSZVFteWdMOGYxZFg1MHpxakIvR1FwbEpKeHhMNW9EUS9PN2F0VGJJLzZO?= =?utf-8?B?d2g5cnI0MVJYNFJWMzV1SkNUbjF2clQ3RWc3Sk1IK3ZXK2RUUm9sTGR0Mjlz?= =?utf-8?B?K0Q0blZXZ1NqK2hvc25JZ0RuUEtndmI3dTYycEZaZWMyK0lKVWxkZTRKa3JS?= =?utf-8?B?Q2NFMmdSV2xuTDYrVElsYW9mdkI5cXVhTUVQTVpWa1BBVHIxb3NTdlZBN09L?= =?utf-8?B?SGhHbWhXVTE5YkZySGJTZlpCM24rTXp6Z0VQR3BUbk5iTlNjMlR0MldUYTd1?= =?utf-8?B?Yjd2SW5sNjBqNVRrVkZ0dWhoMExHSEJ6MDRPbGtmV2ZmNnRjZ28rNHpYTFk0?= =?utf-8?B?Q093dkJ4R2dkS0dtekoyWVhINGdQcUhOalROOTdxREhTdEdabThKZTd5Nms2?= =?utf-8?B?bFBJeE5zOEdpbXJpNWZQeWkwVWNMQkZSMDFLU1FDUkdBWlhoUVBkN1hqUkVG?= =?utf-8?B?OC9NSmtkUWl1ZzNzNUtFaHY1QysweW5EWlJya3NOMnVWVVI4Nm5Mdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 074ad2d5-2e73-4cfc-3dd7-08de7958de60 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 19:12:52.8940 (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: 0O1Pxxsx8xdJjkoPDmZb9sREcnWYKeWxyZUiqlyTY+tgYQ2QKGrrnvE+GNGMxahJ+WQ5Or82W+MjwdZ+G670N98eLzmqcnVy6/1sU8Kvfw4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5503 On 02/03/2026 7:19 pm, Kevin Lampis wrote: > struct cpuinfo_x86 > .x86 => .family > .x86_vendor => .vendor > .x86_model => .model > .x86_mask => .stepping > > No functional change. > > This work is part of making Xen safe for Intel family 18/19. > > Signed-off-by: Kevin Lampis > --- > > In xen/arch/x86/cpu/mcheck/mce.c: mcheck_init(...) > Xen only calls `intel_mcheck_init(...)` if family is 6 or 15. > > Linux only calls `mce_intel_feature_init(...)` if family != 5. > > Do we need to do something like extend this switch statement in > `mcheck_init(...)` to include family 18 and 19? Yes, we will want to include 18/19. The Machine Check infrastructure in the Pentium was very primitive, but everything 6 and later should be fine.  I think we'll want to switch to the Linux form here. > > > In xen/arch/x86/cpu/mcheck/mce.c: mce_firstbank(...) > The check > c->family == 6 && c->vendor == X86_VENDOR_INTEL && c->model < 0x1a > > could be re-written as > c->vfm >= INTEL_PENTIUM_PRO && c->vfm < INTEL_NEHALEM_EP > > I don't know if that would be better. There's a subtlety.  This suggestion is for ... > diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c > index 9a91807cfb..10e826e3a6 100644 > --- a/xen/arch/x86/cpu/mcheck/mce.c > +++ b/xen/arch/x86/cpu/mcheck/mce.c > @@ -564,8 +564,8 @@ bool mce_available(const struct cpuinfo_x86 *c) > */ > unsigned int mce_firstbank(struct cpuinfo_x86 *c) > { > - return c->x86 == 6 && > - c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a; > + return c->family == 6 && > + c->vendor == X86_VENDOR_INTEL && c->model < 0x1a; ... here, but you've made a related change ... > diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c > index 839a0e5ba9..9100ce0f6c 100644 > --- a/xen/arch/x86/cpu/mcheck/mce_intel.c > +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c > @@ -711,10 +711,7 @@ static bool mce_is_broadcast(struct cpuinfo_x86 *c) > * DisplayFamily_DisplayModel encoding of 06H_EH and above, > * a MCA signal is broadcast to all logical processors in the system > */ > - if ( c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && > - c->x86_model >= 0xe ) > - return true; > - return false; > + return c->vfm >= INTEL_CORE_YONAH; ... here. It's not safe to have a single inequality like this, unless you're absolutely certain you're inside a c->vendor==$ME region. In both cases here you're replacing a vendor check, suggesting that we might not be within a suitably guarded region.  mce_firstbank() does seem to be used from common code.  mce_is_broadcast() OTOH does look to be fully within an Intel-only region. Otherwise, The vendor encoding in the higher bits will make a false positive/negative match on one side of the inequality. It is safe to use c->vfm >= FOO && v->vfm <= BAR, because constants of another vendor will not be captured. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 03 23:55:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 03 Mar 2026 23:55:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245059.1544420 (Exim 4.92) (envelope-from ) id 1vxZa9-0000ow-GK; Tue, 03 Mar 2026 23:55:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245059.1544420; Tue, 03 Mar 2026 23:55:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxZa9-0000op-Ck; Tue, 03 Mar 2026 23:55:17 +0000 Received: by outflank-mailman (input) for mailman id 1245059; Tue, 03 Mar 2026 23:55:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxZa7-0000oj-QX for xen-devel@lists.xenproject.org; Tue, 03 Mar 2026 23:55:16 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a5d1fe7-175c-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 00:55:12 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 2E0756057A; Tue, 3 Mar 2026 23:55:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07FA5C116C6; Tue, 3 Mar 2026 23:55:09 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a5d1fe7-175c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772582110; bh=xouWky2sw6d1G/taXa1LN4i8BoL1w/j4IygNALCKloo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ybah0X9N1tWItjtGs5gchsKsOnAy4S5/e8M1jCvlKc789VoHQzKTmuXGUtu5LFj0W 4Pu2/n2+bbE303jCAdgUhjDYAPX/6NJzzZtNWBiOAFmGueXeILsVtg+VSnwLIBHmPu tOlC+YKeRblxUpL/H9qRRcLU5niEgXiRt3MNMOMv51akeDAY4xUOtuiZdhaIIUjTcH 1L1uoh0viYpAooewYBZdVM4CFneXgzS5Ge+Jmf7tnbgIwDpfIB44r7TaFmldh1ETiu nEZA0Oxn3eASC0Bh/x+CrUDsCapyEUBVunBJEI8Jjl9fwwjejlq8rCVsgknOdc5mgm gAd9WCIr8rr6Q== Date: Tue, 3 Mar 2026 15:55:09 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: Bertrand Marquis cc: Mykyta Poturai , "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , Michal Orzel , Volodymyr Babchuk Subject: Re: [PATCH v5 2/5] arm/irq: Migrate IRQs during CPU up/down operations In-Reply-To: Message-ID: References: <63892f56f227fae75d78e2ef2ee63887e74c523a.1768293759.git.mykyta_poturai@epam.com> <6080438F-DB60-4A50-8264-1CD04761B196@arm.com> <48a84d44-def9-4181-ac67-5aeb31ffb529@epam.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1743651114-1772582111=:3148344" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1743651114-1772582111=:3148344 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 5 Feb 2026, Bertrand Marquis wrote: > > On 5 Feb 2026, at 14:23, Mykyta Poturai wrote: > > > > On 04.02.26 16:20, Bertrand Marquis wrote: > >> Hi Mykyta. > >> > >>> On 13 Jan 2026, at 09:45, Mykyta Poturai wrote: > >>> > >>> 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 > >>> --- > >>> 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 | 2 ++ > >>> xen/arch/arm/irq.c | 54 ++++++++++++++++++++++++++++++++++ > >>> xen/arch/arm/smpboot.c | 6 ++++ > >>> 3 files changed, 62 insertions(+) > >>> > >>> diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.h > >>> index 09788dbfeb..a0250bac85 100644 > >>> --- a/xen/arch/arm/include/asm/irq.h > >>> +++ b/xen/arch/arm/include/asm/irq.h > >>> @@ -126,6 +126,8 @@ 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 > >>> > >>> +void rebalance_irqs(unsigned int from, bool up); > >>> + > >>> #endif /* _ASM_HW_IRQ_H */ > >>> /* > >>> * Local variables: > >>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > >>> index 7204bc2b68..a32dc729f8 100644 > >>> --- a/xen/arch/arm/irq.c > >>> +++ b/xen/arch/arm/irq.c > >>> @@ -158,6 +158,58 @@ static int init_local_irq_data(unsigned int cpu) > >>> return 0; > >>> } > >>> > >>> +static int cpu_next; > >>> + > >>> +static void balance_irq(int irq, unsigned int from, bool up) > >>> +{ > >>> + struct irq_desc *desc = 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 API. 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 reside on > >>> + * it. Otherwise, we rearrange all interrupts in a round-robin fashion. > >>> + */ > >>> + if ( !up && !cpumask_test_cpu(from, desc->affinity) ) > >>> + goto out; > >> > >> I am a bit lost here on what you are trying to do in the case where > >> a cpu is coming up here, it feels like you are trying to change the > >> affinity of all interrupts in this case to cycle everything. > >> Is it really what is expected ? > >> If affinity was set by a VM on its interrupts, I would not expect > >> Xen to round-robin everything each time a cpu comes up. > >> > > > > The idea is to evenly spread interrupts between CPUs when the new ones > > are being brought online. This is needed to prevent Xen-bound IRQs from > > piling up on CPU 0 when other cores are being offlined and then onlined > > back. It shouldn’t mess with guest affinities, as the code skips > > everything that is assigned to guests and leaves it to be handled by the > > scheduler/vgic. Performance-wise, it should also be okay, as from what > > I’ve seen, there are not many interrupts used by Xen, and I expect CPU > > hotplug operations to be fairly infrequent. > > My fear here is a bit that by removing and adding a cpu we will completely > change irq affinities. I am not so sure that those kind of random assignments > are compatible with embedded or safety use cases and here there is no way > to configure this. > > @Julien, Stefano and Michal: What do you think here ? I think Bertrand's concern is valid. We need to make sure that balance_irq is not called in "normal" or safety use-cases. I am going by the assumption that pCPU offline/online is not going to happen in safety use-cases. So as long as balance_irq is not called unless CPU offline/online happens, then I think we are good. It should definitely not happen on normal boot. There is also the other thought that while I do not like the idea of spreading the IRQ evenly, I also cannot suggest something better (unless we want to keep track of which IRQ used to belong to which dead CPU, but I think that is undesirable). --8323329-1743651114-1772582111=:3148344-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245075.1544460 (Exim 4.92) (envelope-from ) id 1vxbPh-0006p3-5g; Wed, 04 Mar 2026 01:52:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245075.1544460; Wed, 04 Mar 2026 01: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 ) id 1vxbPh-0006oq-2Y; Wed, 04 Mar 2026 01:52:37 +0000 Received: by outflank-mailman (input) for mailman id 1245075; Wed, 04 Mar 2026 01:52:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPf-00069T-UI for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:35 +0000 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [2607:f8b0:4864:20::e33]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d0902bbf-176c-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 02:52:35 +0100 (CET) Received: by mail-vs1-xe33.google.com with SMTP id ada2fe7eead31-5ff0f61abd7so1565773137.1 for ; Tue, 03 Mar 2026 17:52:35 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-94df641e133sm16763221241.5.2026.03.03.17.52.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:33 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0902bbf-176c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589154; x=1773193954; 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; bh=fdxVAJZzyfNVW1udrhdUFVJfrw+pt2l9y2/jEQPXbUc=; b=Z3Wj5ZhrknfJXAYwjf/8Pg4UG03qTY63SA2f7RxeddC1UAacq5mqPz1M0ux7K8WQlh YP16Xf8YvXXDJL8+xpUGLMU3ygvt/VvNAaIFhSBgY5OUxiXH+AQFAHXk+gR6hW9x0sDs +KkCzG85kNnzJjwbo27I4mPYcImcPiNwgkerQ//MoW2h/nKGVznbnq8LtOFVPALr3sHp TRbSemnlsr35iAsyBvyUP5/SW4s7KLu+zNUSq1A2Ny0fI0FdFxHha0neOe/gKcOU5vYd NTyByVdoiPPS2TgbZve3Tb7Vfx45CSEDwN3ED2LDMSKPviwoWHQJDP3Q71Cj3H4m2oRj tUtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589154; x=1773193954; 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; bh=fdxVAJZzyfNVW1udrhdUFVJfrw+pt2l9y2/jEQPXbUc=; b=H26ubfGcJC6yV835Ht3oZ7AR87YGXkS5x8sVfU9jUKejmNlhw97PRvdEyofN5IxNJb 9+nYXfUCXVqaGRTbF6QjwNl++V5MKj9fW/dl1Vz+X2JnU6mRY4iHWaFARHGmAjDO3Nd3 2gGkrP0IKpL9iMIstmvwQi8Gx//qRhbTzXLcs9NbHbD0h/c1f1Akzl92PGLWv7YNlNZY I2KW/Gxndp2vbd3NWm3z9hDcrBRMrmork2LXrPWdNOFhOI8Eso6VP9REy1jhi9Il6Lps SU9kHQzKN/RXaj/c96FUVeIZPkTEVu5vE5R0+hDAOi2K6ryr6qB5zVZtwct0TpeXWTus d9kA== X-Forwarded-Encrypted: i=1; AJvYcCWz4YywgpisIVAYvz2S47Us4Omr45P7MUnwdt93OFr1BBaIYi0NU+8zk4pavCkwKIbS0iI5hHoY6yY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzgnI/45vmTnlgDIvOA+p035S7l1SktuATXsovASLesiizXpYQZ l5AgNdFLefFp9Kmrc24r5l1Fbs1mkHh7Ts55lDCqkQyWugTEC8zd2GuM X-Gm-Gg: ATEYQzxkeI4rF75m1OwuprwN9UQ1wWBKYS868370/9u8SJmCIbxUyD+sJK7P/ZT5EF8 eif9vpjh5l1/gDTbUvlmgU7YUpxX/zdl/VwQ2fsTb/dpC5RwMXe89j5Jh63KNyrY49ZTJQMqUx2 poJ2MJQ6Tu110biBogKMDttvmnMKVOG5OgQwoig600JFyFe3lV5EgainkG2zQHeuOk2PydUH2Jy L0IHNW5etPODQeYwetiFOFveQU1zQUSRgF6jRpAVOBiZm6mrXWvT46/2ITYjqNvpru11jWnVBE5 n0/2wRIyz0UjNxNYyF5Or4AmR8TxvNzm7TsYeTg0QvNp7Xr317YI/8d/4YawvvZLh4PnzvxGtvk ST+YofDhBBcuz/iMjlHNSlbSgeJeu1AfN3mZAc71rXTV3VRxNtwUv94DVn3TmpOcPAIYyGr8YaC KL32j/eXK2w80vs50OzJEdxNGPvJVrv/+camGL9k2rraInlmqA9qedy7mEUw== X-Received: by 2002:a05:6102:2922:b0:5fc:2b19:f7de with SMTP id ada2fe7eead31-5ffaae9984fmr215631137.25.1772589153980; Tue, 03 Mar 2026 17:52:33 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Paolo Bonzini , Peter Xu , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Cc: sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 3/5] physmem: xen: Conditionalize use of the mapcache Date: Wed, 4 Mar 2026 02:52:19 +0100 Message-ID: <20260304015222.979224-4-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260304015222.979224-1-edgar.iglesias@gmail.com> References: <20260304015222.979224-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Conditionalize use of the mapcache. This is in preparation to optionally disable the mapcache at runtime. Signed-off-by: Edgar E. Iglesias --- system/physmem.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/system/physmem.c b/system/physmem.c index e5ff26acec..64e6d50f8f 100644 --- a/system/physmem.c +++ b/system/physmem.c @@ -578,7 +578,8 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat, is_write, true, &as, attrs); mr = section.mr; - if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) { + if (xen_map_cache_enabled() && + memory_access_is_direct(mr, is_write, attrs)) { hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr; *plen = MIN(page, *plen); } @@ -2577,7 +2578,7 @@ static void reclaim_ramblock(RAMBlock *block) { if (block->flags & RAM_PREALLOC) { ; - } else if (xen_enabled()) { + } else if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(block->host); #if !defined(_WIN32) && !defined(EMSCRIPTEN) } else if (block->fd >= 0) { @@ -2736,7 +2737,7 @@ static void *qemu_ram_ptr_length(RAMBlock *block, ram_addr_t addr, len = *size; } - if (xen_enabled() && block->host == NULL) { + if (xen_map_cache_enabled() && block->host == NULL) { /* We need to check if the requested address is in the RAM * because we don't want to map the entire memory in QEMU. * In that case just map the requested area. @@ -2785,7 +2786,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, RAMBlock *block; uint8_t *host = ptr; - if (xen_enabled()) { + if (xen_map_cache_enabled()) { ram_addr_t ram_addr; RCU_READ_LOCK_GUARD(); ram_addr = xen_ram_addr_from_mapcache(ptr); @@ -3787,7 +3788,7 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, if (is_write) { invalidate_and_set_dirty(mr, addr1, access_len); } - if (xen_enabled()) { + if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(buffer); } memory_region_unref(mr); @@ -3898,7 +3899,7 @@ void address_space_cache_destroy(MemoryRegionCache *cache) return; } - if (xen_enabled()) { + if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(cache->ptr); } memory_region_unref(cache->mrs.mr); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245072.1544430 (Exim 4.92) (envelope-from ) id 1vxbPb-00069m-Gu; Wed, 04 Mar 2026 01:52:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245072.1544430; Wed, 04 Mar 2026 01:52:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPb-00069e-CJ; Wed, 04 Mar 2026 01:52:31 +0000 Received: by outflank-mailman (input) for mailman id 1245072; Wed, 04 Mar 2026 01:52:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPa-00069T-2D for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:30 +0000 Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [2607:f8b0:4864:20::a2e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cc37d289-176c-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 02:52:28 +0100 (CET) Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-56a9402b52fso5382138e0c.0 for ; Tue, 03 Mar 2026 17:52:27 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5ffaca9c848sm303553137.10.2026.03.03.17.52.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc37d289-176c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589147; x=1773193947; 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; bh=AZ079vS7A/A4BZyc3h4DSpRr2ArVx5hvIslaT33EcVI=; b=BtFTWad5DkwJTTsn9YQ1I0lkM+rXW2InQx2Wa7mEo0F2eSkCeHecbgeGJ6TO57cIMq IFp+G48Egg51qGHS7eeXSdPoZ6dXfkN/gdYPCW5oixtMU54VsUcSA0bXOb+3wUCnD8pQ /It3WuzQURDfpOn9EmbkcBoz0M22P7GeH99BtR0jleSJTM6h0K+wKzOgtPzWIfpYt04K cRCv3dzStAePmciuDEnIyBwtNmVpl2PIts68CjNbXFGKelLph1riTFYh4cITdpoUyyxu 0YFjZ8bQ1bYfCiWNF35LaPKy9nj7UwQdKsCceywV8KRjNMOqa6Rccw6ExjjEFkQH9LJA fpSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589147; x=1773193947; 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; bh=AZ079vS7A/A4BZyc3h4DSpRr2ArVx5hvIslaT33EcVI=; b=U/hKgEZYSdJV+tj2faztW9/UFaVKgVNA7xFCp+YSHpo2pBkBhSZV+gCziIxE12xgY4 98fMA9dxtW77OBMXE/eM5vGKexBNFCxKZUXbh69YReH8BAEs6M0dub8rCtWbSbHp2Sjz dDhbf0ceTV3Uz6GIPw7rv9XzBS9P9kmeL67XSx4W1tk8ZvAHP5E/a6smvGt0IMT7TdAj 1jqKQEJL2lxjRkC0q48qLDbWVGdKHGUTUXvsltQsZ52++at8DZDNWGFCU6DmlN3HjY3M vlp2KpehFPKmU9k4G6sg0o08iSi1u8FYbyv3UmHyOwpNgPz7LaGCHkHvHiVy4fLL4m48 HHcA== X-Forwarded-Encrypted: i=1; AJvYcCWp8Ku7VL0khdf8aJ6dJxBWwLHVO+ufnxMeyXvvn6FOisqNKWfZgSxoXryN5u6VItGBuJu+mcikJq4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz3iWo59kx+F8YBwh8pPsSqhatEfjZdF4qA19XRdDX/9ZEsJi5K vLVbz9DeyhropXvT/Oj//C8IWRRg0GQH/daDxnhoG7XCGCd4CkKtCZ6a X-Gm-Gg: ATEYQzy2RJNeNWvN9kOtLrLzj5d4NLQ5THl/EUcCZJVk4APZX+W0hbZaypQtnj7WB4n iP8Dbjz5xNbHG/tdbDoFkjSuDo0YcKoT5Jnqp3/DTHMA7qEkidDFfvSqa3GGVymjQxmCRvyfeQS FGaciL64U73ttePDNmJmBkvESqrSTvZ87ChBeN21ZcBZ5nO4KeHwk706L+Of6FUPsjG0BUl17Ja DLCHGMx3qqO7tyKMTbI81kuSivBVO1kneDB/LOG7IkTBtW/AZLGTKqCZyF8GNLj60Wa4tZ6/Xyg dz4p//XLasuXW+naRLPFVc7oCZd2j4/Rv9yeO3xpn0ZzWmYsqSRJX9hB8lrIyN9rM1NNK1zhNOo XvmfAV0KFcnDTWSDCN3nHHdRlkALjiZd3uYwa8c3ir7T7vpWFfdopme/S5fUtcBaFQJBX2kBVpi rs3Oym8X26iK5sWFfeXa5zgM6sdYt8jgibUUSDYzsS8e0zXm6kKd1m2SidnA== X-Received: by 2002:a05:6102:f10:b0:5f7:307e:80d9 with SMTP id ada2fe7eead31-5ffaafc647dmr351581137.28.1772589146690; Tue, 03 Mar 2026 17:52:26 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org Cc: sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 0/5] xen: pvh: Add machine option to disable the mapcache Date: Wed, 4 Mar 2026 02:52:16 +0100 Message-ID: <20260304015222.979224-1-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" This adds a mapcache option to the PVH machines allowing users to disable the mapcache. To remain backwards compatible, the option defaults to "on". When disabled, all guest memory is mapped at startup rather than on demand. Starting QEMU may take longer in this mode, but runtime overhead is reduced and it also enables virtio vhost backends to work. As a trade-off, grants are unavailable without the mapcache and guests with large amounts of RAM can take quite a while to start. Cheers, Edgar Edgar E. Iglesias (5): xen: mapcache: Assert mapcache existance xen: mapcache: Add function to check if the mapcache is enabled physmem: xen: Conditionalize use of the mapcache hw/xen-hvm: Add a mapcache arg to xen_register_ioreq() hw/xen: xenpvh: Add prop to enable/disable the mapcache hw/i386/xen/xen-hvm.c | 2 +- hw/xen/xen-hvm-common.c | 18 +++-- hw/xen/xen-mapcache.c | 16 ++++ hw/xen/xen-pvh-common.c | 134 +++++++++++++++++++++++++++++--- hw/xen/xen_stubs.c | 5 ++ include/hw/xen/xen-hvm-common.h | 3 +- include/hw/xen/xen-pvh-common.h | 2 + include/system/xen-mapcache.h | 1 + system/physmem.c | 13 ++-- 9 files changed, 169 insertions(+), 25 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245074.1544449 (Exim 4.92) (envelope-from ) id 1vxbPf-0006ar-Ui; Wed, 04 Mar 2026 01:52:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245074.1544449; Wed, 04 Mar 2026 01: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 ) id 1vxbPf-0006ai-Qv; Wed, 04 Mar 2026 01:52:35 +0000 Received: by outflank-mailman (input) for mailman id 1245074; Wed, 04 Mar 2026 01:52:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPe-0006Zx-QV for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:34 +0000 Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [2607:f8b0:4864:20::a31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce8e1000-176c-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 02:52:32 +0100 (CET) Received: by mail-vk1-xa31.google.com with SMTP id 71dfb90a1353d-56a94923c0aso2075402e0c.3 for ; Tue, 03 Mar 2026 17:52:32 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56adfad07f5sm2726919e0c.10.2026.03.03.17.52.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce8e1000-176c-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589151; x=1773193951; 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; bh=N0UYcKwpR4k449Oah1OUraSH63dKX72hrhhrlbQ1drM=; b=kiWJ6KCmTQu5frxZQkpJaNaIm7o+k+OMHly41K58/K2HWUtBNFu+MrqgeIHz5iq7uY RucuE9palIbk7iHreLeSTlZYMDDsgqmUCb051qmcRjwinuNGqm3Hh0QhQxLK0Dza6qmN 1fu8fyWymUnu86tm0d8NVJnmiiyDP1i2OBf9sY5PSbH919i6ni0bGGCBEPCUino1vGZf duXaqwjXi2EDaqJan3XCIFQqsX/d99RroEbLNtnlvWtBbV5PECpjjD4rVyeOKbPsHsP6 0Bix8RvTpR6swKf8eRd+1cpUmQGEVoH1mtOfLtPy1kTKOArL54HNfLCrudTfWHLy73vE h+rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589151; x=1773193951; 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; bh=N0UYcKwpR4k449Oah1OUraSH63dKX72hrhhrlbQ1drM=; b=Lhb+WXleCDgVJYxh+pzRXa0GS+Ms4cImq6oLOS5vnMwBxnrj4JqeKxAIskssYRWEZL nnTL/HrBS5lVmJCo7JzkZypYGP9W/UgPIf/6L6zkDhaS+uALc3cebcp29koV2sxBkcPF lWeC82rbPfLBTCq3nt/+BzjuzvSTVm370fNdROoavFMFCjblXNQxRDXb2ONVs0myyjhL EdmnxYcX6m+d145vtUJjAoSSNYDlqs+w4L2ILkw9Q+mFXB1YTA0omMy0zKTwUEGvCsXg BDrqEcVGJKz+FomTzy8xw2mCVPVywUpR1HAzxt17QzMN5q1u6Pyn7ojgQD6VA1WnA+As ZBCQ== X-Forwarded-Encrypted: i=1; AJvYcCVEqpOVu4vEbA4iNDcd3QNnvvaSH3TDAkib6pMQ8Y3HkTZImXyv+RY2BA6HuaM6fT4U/pQoN+DqbgE=@lists.xenproject.org X-Gm-Message-State: AOJu0YyVmGOzZQ1M6FQM8TERPGMWy3SeBfVEbsRRmt5kAcZ4hyaGxfr/ fjvRU1RBn/2vWVOtGXdNW632h3Dgqtp/l1+cbINZ+adf+4kKBQ2HTpn6rbvRcw9U X-Gm-Gg: ATEYQzzYKXsvwy0/CSXqF7bIGgM+yi77xUXuBXFYaElNvfCmaBXXZxZFjy+Xx17sz4o rBYBt7sQXWfrMn2VmxqTxYJHr/iTg0i50AHIwICHsXLFgA8ZLZ8V4gxLFOn1HheDja06chkkLWQ WD/qQzisofSzdkl0TIqASI/jLAh9K96tjyRpRjW2t4+avHJ3lTcb6l+g7QHwdqE2wcCy3RbeAiJ D6yckUVrqp1Vl/EeCn6ThNMRiSOdZR7YLzBJQyq1IrlIDvz/cgTZI8FOi1vHE+b1fBD89JYPgM1 NHyFoZHVyWSPsrz+CXLlJyX3fXuQGp4xkfH76i4BsnkCaVxdjDIZaEAMwz/LhYjdOjP+xOtWn78 LPJh6Z9tUvc8EX0zVRYAApf8hcS9Yqp+enoBXqaFNmjLpxnC9oylrqCErKXPHJQsWmf2K5mHZjG NymRRnU5YG8YYfXNKWaIN6aAVH/t/Um5LITa2Rt6nYMxInlqnUUOtrrflXuQ== X-Received: by 2002:a05:6122:4b83:b0:566:453e:37ae with SMTP id 71dfb90a1353d-56ae778ca3emr237936e0c.13.1772589150849; Tue, 03 Mar 2026 17:52:30 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 2/5] xen: mapcache: Add function to check if the mapcache is enabled Date: Wed, 4 Mar 2026 02:52:18 +0100 Message-ID: <20260304015222.979224-3-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260304015222.979224-1-edgar.iglesias@gmail.com> References: <20260304015222.979224-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add function to check if the mapcache is enabled. No functional change. Signed-off-by: Edgar E. Iglesias --- hw/xen/xen-mapcache.c | 6 ++++++ hw/xen/xen_stubs.c | 5 +++++ include/system/xen-mapcache.h | 1 + 3 files changed, 12 insertions(+) diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index 517e5171b7..a3c162cd4c 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -80,6 +80,12 @@ static MapCache *mapcache_grants_ro; static MapCache *mapcache_grants_rw; static xengnttab_handle *xen_region_gnttabdev; +bool xen_map_cache_enabled(void) +{ + /* Map cache enabled implies xen_enabled(). */ + return xen_enabled() && mapcache; +} + static inline void mapcache_lock(MapCache *mc) { qemu_mutex_lock(&mc->lock); diff --git a/hw/xen/xen_stubs.c b/hw/xen/xen_stubs.c index 5e565df392..a39efb5062 100644 --- a/hw/xen/xen_stubs.c +++ b/hw/xen/xen_stubs.c @@ -29,6 +29,11 @@ bool xen_mr_is_memory(MemoryRegion *mr) g_assert_not_reached(); } +bool xen_map_cache_enabled(void) +{ + return false; +} + void xen_invalidate_map_cache_entry(uint8_t *buffer) { g_assert_not_reached(); diff --git a/include/system/xen-mapcache.h b/include/system/xen-mapcache.h index fa2cff38d1..c46190dd0c 100644 --- a/include/system/xen-mapcache.h +++ b/include/system/xen-mapcache.h @@ -13,6 +13,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr phys_offset, ram_addr_t size); +bool xen_map_cache_enabled(void); void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); uint8_t *xen_map_cache(MemoryRegion *mr, hwaddr phys_addr, hwaddr size, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245073.1544434 (Exim 4.92) (envelope-from ) id 1vxbPb-0006Bx-Pi; Wed, 04 Mar 2026 01:52:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245073.1544434; Wed, 04 Mar 2026 01:52:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPb-0006B6-K6; Wed, 04 Mar 2026 01:52:31 +0000 Received: by outflank-mailman (input) for mailman id 1245073; Wed, 04 Mar 2026 01:52:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPa-00069T-MM for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:30 +0000 Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [2607:f8b0:4864:20::936]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cd6a365f-176c-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 02:52:30 +0100 (CET) Received: by mail-ua1-x936.google.com with SMTP id a1e0cc1a2514c-94dda16ff9fso1914153241.1 for ; Tue, 03 Mar 2026 17:52:29 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5ff1ea1596asm18777740137.9.2026.03.03.17.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd6a365f-176c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589149; x=1773193949; 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; bh=yxu4XRB4FitI2+AcQo8tLZ5+1Awl0R6238sOzIkA3R0=; b=UxSha2V/remXY709hVthtXxJCcOpZq/ReBQ9iYEzmAn2rzakakOt5TDONZQ/2AiGN+ pS27vRc8zU4r+93xgjEw+lXoZENRu7W820wHsM7kDJSVgV1HITW/GD2hGUri912amZBE bsFQe22mp7UozRCcw3L9g5Uf0BOlOv4/qeFP7TxdZOC8plbwVo7PDWM2AIF0QZYdx9fA jKB9FXUyU0HZ2yyqHe19w75CRQ8CRoNUfiRTXi9kRlSYQBEwVbbZzoHc2iJZzSMlpRUP 4AYXR4ufXYv5ZmPHx4sbIFosb8v+HFGBk7v7RLehpPtdYsrj4sMdJdmRMqQb8okcyF/5 A18g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589149; x=1773193949; 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; bh=yxu4XRB4FitI2+AcQo8tLZ5+1Awl0R6238sOzIkA3R0=; b=v6sXoniYP1h0o2tKZma9Yce7oj9WPPzEQ3rJUmBimBmhrDtNlg/y76k1gzIyNiOdvy 3bHVGTiCD/xO82OIDlycmozKK38nFiJm3SqCpqv+NExn/b/Lao38AY3/DskSOmiQUwSX rBDYtcprDRc8qbDQQmYhoonc+fMx4vLRHVwkos7XXYAO/CLmXoVzwQu1XrxygWRVMOhc a5aicooYBhYfX6iqrzffkxuK3Dzp9yutA4aEP2RfFLDqLbCW8bBUaCIerrJ9vIwhg8hV TG+6yTzMo3BPGhgV1/HhH1tvQFZHiQ37Xzj60wKdlgdPm9k2BdqeetDw6+lgUuXOof1z 2RJA== X-Forwarded-Encrypted: i=1; AJvYcCW6el+t/I2GA4Ca74BzEO48h4XxTIiFzKxp4zgmzmO0V+ed1r96DjqlrldMOmFvXo8qjnRADznY7M4=@lists.xenproject.org X-Gm-Message-State: AOJu0YzufG5bYyido0dDj/2I+IgglkqqNqL1yYWJKOxm2Kl63gSvn5EL DBVg3MwHcvqqHInnqPhqVRDWXnqS+F1cb2fxItBVRoPVR0xPG4WafBbe X-Gm-Gg: ATEYQzzkhwjVkZqhDJm0NGzYle6Qhwe/0M2JN/iKxeha0026TU3x/hGcbtrjZ8E3Wim Q6X9yl+A0SkbvEy+jYQNeCwwnXd+TehkLU9lWLkP1pjXCcOdz/51U4ylZil7y99jISIIte1uOcy WwF6U9DhZsqWtzPLLzG5TD207WHRrJu4WB9Z/qvcWlu4OZzH5Wu0X/9bNEjNUGMw1c2CrR4NaOT 60Lbz+rj0EoLxitCA2NZuVJNWsQP8JdGXJHoI9mR7WKmDecMqB3mAuq4tjRF25MLSn2UksGJEUx iF3dbT4shak5uZ0u+VdQF9yRx0IIf/UWLFkb258JZO5WEm9+VkwBLkCpJybvm90qKn9YHvF2XFv Ff583cDyTD5zXWlDb4sGExUEl37El0sODIj/tsNdCeL9Thj9Tcd+3FILE8TQAjfrlynW0enrv3g hnsTyTylm2Q1MGvfEGBkep2O/DvxHAAS5YgphReL/oc9HZrIW+BdPdueKfSA== X-Received: by 2002:a05:6102:c09:b0:5dd:f9c2:551c with SMTP id ada2fe7eead31-5ffaaf1bf2fmr242963137.27.1772589148744; Tue, 03 Mar 2026 17:52:28 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 1/5] xen: mapcache: Assert mapcache existance Date: Wed, 4 Mar 2026 02:52:17 +0100 Message-ID: <20260304015222.979224-2-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260304015222.979224-1-edgar.iglesias@gmail.com> References: <20260304015222.979224-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Assert that the mapcache was created prior to being used. Signed-off-by: Edgar E. Iglesias --- hw/xen/xen-mapcache.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index 11115f6084..517e5171b7 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -464,6 +464,8 @@ uint8_t *xen_map_cache(MemoryRegion *mr, MapCache *mc = mapcache; uint8_t *p; + assert(mapcache); + if (grant) { mc = is_write ? mapcache_grants_rw : mapcache_grants_ro; } @@ -530,6 +532,8 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr) { ram_addr_t addr; + assert(mapcache); + addr = xen_ram_addr_from_mapcache_single(mapcache, ptr); if (addr == RAM_ADDR_INVALID) { addr = xen_ram_addr_from_mapcache_single(mapcache_grants_ro, ptr); @@ -652,6 +656,8 @@ static void xen_invalidate_map_cache_entry_bh(void *opaque) void coroutine_mixed_fn xen_invalidate_map_cache_entry(uint8_t *buffer) { + assert(mapcache); + if (qemu_in_coroutine()) { XenMapCacheData data = { .co = qemu_coroutine_self(), @@ -709,6 +715,8 @@ static void xen_invalidate_map_cache_single(MapCache *mc) void xen_invalidate_map_cache(void) { + assert(mapcache); + /* Flush pending AIO before destroying the mapcache */ bdrv_drain_all(); @@ -776,6 +784,8 @@ uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr, { uint8_t *p; + assert(mapcache); + mapcache_lock(mapcache); p = xen_replace_cache_entry_unlocked(mapcache, old_phys_addr, new_phys_addr, size); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245076.1544470 (Exim 4.92) (envelope-from ) id 1vxbPk-00076R-JS; Wed, 04 Mar 2026 01:52:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245076.1544470; Wed, 04 Mar 2026 01:52:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPk-00076K-DH; Wed, 04 Mar 2026 01:52:40 +0000 Received: by outflank-mailman (input) for mailman id 1245076; Wed, 04 Mar 2026 01:52:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPi-00069T-Ld for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:38 +0000 Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [2607:f8b0:4864:20::e32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d219c63d-176c-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 02:52:38 +0100 (CET) Received: by mail-vs1-xe32.google.com with SMTP id ada2fe7eead31-5ff1703cb9eso1668728137.3 for ; Tue, 03 Mar 2026 17:52:37 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-94df6577693sm16742382241.9.2026.03.03.17.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:35 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d219c63d-176c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589157; x=1773193957; 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; bh=rZOO08zLikZY030P2ehrGV6veLejKIl076oxwM9/gTs=; b=eXk/08fdK1Tui/DCmFmi2fHGK0ecEBAJkf9fZhkl1StlYMNMxgHBwFl5Zh3hE+5J9K n3Axy7FwydzUkCjGruiBggDhzTwBFnX+XydUkvdMPEbTaooYHFRrCcQeS9qoE5s1wq9n VcZLo5bWtuNjuv3sm/3UurFdkkVx0eGuVJj6V4nWA5hm40Li+amUkVb/xMf/HweDevf0 T1adE0UmZsPsvl2RZMQQiKLNQ7sfMJUw/EvCbTGsbLa6TQvrHtDoRL4DS4IkTmhUPMmd QhEuw/N92QpYUxRKnrTBtuzcNE1eV7tsUoLffZh+RkkT2lXRhKlyH//IBf5FiPmMnhTH rSxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589157; x=1773193957; 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; bh=rZOO08zLikZY030P2ehrGV6veLejKIl076oxwM9/gTs=; b=pzVvZ6lUx14VYhmPDknIA+rBv5qpbwaF5yg6DyVY2iPaE3v+bX8ASSvfnhsNwQDfwb IDP0isornjJouAwj1g1EXW5eiP3CmF4yDpxdhsfqdta7DrzS1LQG6H7BIu7BrMLEs0to rzvjKW3Oy5QwZlBWH0M9wp/yyVqWLAX7C78/CxNA9PRWI/h81hlc9syYf8Q043Z15xec l7hIo50n7zS31SQVDSasdeVr7oiH+WukaBVKqKcTG/2IuHLYzykwROZmAX91dh9ylPBx 8g1PjV5MemLeUZACjprzz4I3w8GHlGR/O3vJUDx1eoQWFV2APpDr/Uf9gftpSK4su5uU YDsg== X-Forwarded-Encrypted: i=1; AJvYcCWpCdSYjNYFtOfymWwWkoO0PRuYTEz2mXGdL9xXH/mzB6YwxiZSAxNQ0PB35gmVlL588vxvl5kKafs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz5TK0+LKbDoD07VeqXWgp5w0GxmuIkRgPB9Tk0A9MyRDjaV2Ul quEPzGVZ+lpD43e6o/LFP6ooNwrM65T9RUqzlcnuMEPmFSDYj3W26922 X-Gm-Gg: ATEYQzyKvPXp69wkaW+SZy9If/u3e1kyxj2Nz3PavIIxG6FycVm09ztBsinxHjDTp9p 2eMks7a9J1YrhOHjb2MEa5j2nuD/eCkIgOYPGgLYdbj47VYTihGGivv/7jBOsu5mtrZt4VZMdEr 4ogTgbJxMkC/ZyEuSq5ii3QGOj+Cqo7hntjTdtsCJGQlEHakUB8zV8VC7+l2Bc+BDrPwTEh5HbN fSKl4MjXNGM8LtZ2X1lFxxCLahJhzERHePF8HwaZMHO6JhN8nnoma1yEzuve/H1vJl1bhXGsFft uFT/anz47nxkKFzvZUmH7EicRJ23NI9Gg1aHMXovABZLcygwX0oNA+WNWYxR8XO+Pvu9pR65jKb k7vrvWnW+22CGuaKxpqGpdER2+XcihPFB1ljULBUFOPXJ8ApTnJFJHWuW5FioBJZOiTYhSmC7+2 ip+o1ZVDro6X7kpMCUZKZ3XiF+UFG5vGK9kiMyS+t+MIRFFYciSxTQM6Z7EA== X-Received: by 2002:a05:6102:c52:b0:5fe:13bc:f13a with SMTP id ada2fe7eead31-5ffaafb23f5mr239107137.36.1772589156590; Tue, 03 Mar 2026 17:52:36 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" , "Michael S. Tsirkin" , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 4/5] hw/xen-hvm: Add a mapcache arg to xen_register_ioreq() Date: Wed, 4 Mar 2026 02:52:20 +0100 Message-ID: <20260304015222.979224-5-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260304015222.979224-1-edgar.iglesias@gmail.com> References: <20260304015222.979224-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add a mapcache argument to xen_register_ioreq() allowing the caller to optionally disable the mapcache. All callers still call it with mapcache = true so there's no functional change yet. Signed-off-by: Edgar E. Iglesias --- hw/i386/xen/xen-hvm.c | 2 +- hw/xen/xen-hvm-common.c | 18 ++++++++++++------ hw/xen/xen-pvh-common.c | 3 ++- include/hw/xen/xen-hvm-common.h | 3 ++- 4 files changed, 17 insertions(+), 9 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index a6e1683885..c7bfcaae8e 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -622,7 +622,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory) xen_register_ioreq(state, max_cpus, HVM_IOREQSRV_BUFIOREQ_ATOMIC, - &xen_memory_listener); + &xen_memory_listener, true); xen_is_stubdomain = xen_check_stubdomain(state->xenstore); diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index 59c73dfaeb..8c825588ae 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -473,7 +473,9 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req) case IOREQ_TYPE_TIMEOFFSET: break; case IOREQ_TYPE_INVALIDATE: - xen_invalidate_map_cache(); + if (xen_map_cache_enabled()) { + xen_invalidate_map_cache(); + } break; case IOREQ_TYPE_PCI_CONFIG: cpu_ioreq_config(state, req); @@ -823,7 +825,8 @@ void xen_shutdown_fatal_error(const char *fmt, ...) static void xen_do_ioreq_register(XenIOState *state, unsigned int max_cpus, - const MemoryListener *xen_memory_listener) + const MemoryListener *xen_memory_listener, + bool mapcache) { int i, rc; @@ -874,11 +877,13 @@ static void xen_do_ioreq_register(XenIOState *state, state->bufioreq_local_port = rc; } /* Init RAM management */ + if (mapcache) { #ifdef XEN_COMPAT_PHYSMAP - xen_map_cache_init(xen_phys_offset_to_gaddr, state); + xen_map_cache_init(xen_phys_offset_to_gaddr, state); #else - xen_map_cache_init(NULL, state); + xen_map_cache_init(NULL, state); #endif + } qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state); @@ -901,7 +906,8 @@ err: void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, uint8_t handle_bufioreq, - const MemoryListener *xen_memory_listener) + const MemoryListener *xen_memory_listener, + bool mapcache) { int rc; @@ -922,7 +928,7 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, state->has_bufioreq = handle_bufioreq != HVM_IOREQSRV_BUFIOREQ_OFF; rc = xen_create_ioreq_server(xen_domid, handle_bufioreq, &state->ioservid); if (!rc) { - xen_do_ioreq_register(state, max_cpus, xen_memory_listener); + xen_do_ioreq_register(state, max_cpus, xen_memory_listener, mapcache); } else { warn_report("xen: failed to create ioreq server"); } diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index 1381310fc7..4fade017bb 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -202,7 +202,8 @@ static void xen_pvh_init(MachineState *ms) xen_pvh_init_ram(s, sysmem); xen_register_ioreq(&s->ioreq, ms->smp.max_cpus, xpc->handle_bufioreq, - &xen_memory_listener); + &xen_memory_listener, + true); if (s->cfg.virtio_mmio_num) { xen_create_virtio_mmio_devices(s); diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h index e1beca062f..d177ff14ea 100644 --- a/include/hw/xen/xen-hvm-common.h +++ b/include/hw/xen/xen-hvm-common.h @@ -91,7 +91,8 @@ void xen_device_unrealize(DeviceListener *listener, DeviceState *dev); void xen_hvm_change_state_handler(void *opaque, bool running, RunState rstate); void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, uint8_t handle_bufioreq, - const MemoryListener *xen_memory_listener); + const MemoryListener *xen_memory_listener, + bool mapcache); void cpu_ioreq_pio(ioreq_t *req); #endif /* HW_XEN_HVM_COMMON_H */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 01:52:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 01:52:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245078.1544480 (Exim 4.92) (envelope-from ) id 1vxbPn-0007OM-60; Wed, 04 Mar 2026 01:52:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245078.1544480; Wed, 04 Mar 2026 01:52:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPn-0007O6-1X; Wed, 04 Mar 2026 01:52:43 +0000 Received: by outflank-mailman (input) for mailman id 1245078; Wed, 04 Mar 2026 01:52:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxbPl-0006Zx-Ks for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 01:52:41 +0000 Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [2607:f8b0:4864:20::a2e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d32c1eae-176c-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 02:52:39 +0100 (CET) Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-567543b8989so2639712e0c.2 for ; Tue, 03 Mar 2026 17:52:39 -0800 (PST) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56ae7a29c2esm466482e0c.7.2026.03.03.17.52.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 17:52:37 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d32c1eae-176c-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772589159; x=1773193959; 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; bh=EJHpqZ1+MwG7a9L0vy9H75K3KJbsmHXRI7gW76g6PSg=; b=mAYm6R8oWjRsnuWOl4DBP7sOPudwDWUMllJejwXFDBR/Q3ibHyA/eLP+XQqOciQV5T exjjsg+Sp6EJf7ccf0EmA6IUh1zaedmx3zqw6prfk5mJJdCXXIeG1p/I54P7gTmlB7gr lAeDm4W/7489uVX9c2jXDuz/Jq/C4CBQ7TiG/JhYimEc9uVFdOPXYpIpn5aFero4GSn6 p9uNP0CSPe+SeI294jdX+5KwnD+ZmO7pvpaeuHVn6QeYpcjFXmid1WzosCV+sjKykBW9 WTX+7S69bAY9nWhPSHOGbYwHdxyrQxGOSa1ZhTM89TY7Mr90l1krP8zXOGe2vEL0nZzY 43lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772589159; x=1773193959; 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; bh=EJHpqZ1+MwG7a9L0vy9H75K3KJbsmHXRI7gW76g6PSg=; b=qGoQ6Rzt9WG/BrT64FV4VPtaK0JF1mj1KELo9LpNTnKjwAuzhgFOIhgEiD3SqTrBwf HUcWgXCh544TuQVtyI91LZy6ebePkOh9rD5vNPibwnZTCZvuPlZrarURzBcmdPOjfDU+ zOxLn5DTet6lTXCQv8w1SXo0strWIur50YlXXckbEIKxHtMxcP6KbCS83PP6G2PMpy/F Mjf0RnbHWYO36e/zXKBLHGNFX82CO7jnHiR67g11uFrMYBIqKqHtXH90JclOp0k3GbiQ Z8G4D5z8zAxhuH2sXRDqLMue+GEajSr/r6iFk8rGoy6maWQR3/POwlWDSLqlImcXytV/ NzCg== X-Forwarded-Encrypted: i=1; AJvYcCWxhc1pf65F2dId+gclMwMXmpzMYPZTnvtC3Al6Aezd1GO8WIbqU1uO1q4xh+TSo6VLipyys3RlS5Q=@lists.xenproject.org X-Gm-Message-State: AOJu0YzsmrDe5O1vPvXRBO+Ve8cQVd08mNUf5EOP1yJi6sl7a9SNgPoX cTDjDRrq1Q/3ZJ8E5u4ti+6Hy4QMHQitohig9L+1KLlyWQG95jYdrBKy X-Gm-Gg: ATEYQzwg3aD9HPcgocmcgLFCMWd0EVktUTJvhuio5c3ldVg4Qceml4/6kUQSH8Enz8p cm3ig/4i5adrTzPJKRSGxgnK3VXE06Pm8+v3OhNjkYPyiRmbYvwco+X1EhP8qC0XkD/GBLaSjNA RI/plYwPQwQwTdAnBGQ+qPdh3n2+KbOT9r3kR+GFSbwjhHTN1j/f623d1DjYQ1K2bhk1Z7QxaV8 dJ5fI9FEyCo9U4qghnYACgzMcJksewl+Mb1FarXRVb689Rv5LlGLXWko1t8VM8Ta3bYE4ASM/FB e/yYI92TKltXO9mzIHrzlWjcVwpTbWfP/qerEBD9N9VKZMifgBZePG6StjVjycz/JTmmnzR32wv BRk8gr9gWeW1cn7fChNT2HjLAdcMWGlX3nTCDBNbFrij2mtOIOgcdxp59YbqkxD6x0vP+tb/16e b4afYegtQZZSSTuNtqeBFEOMyWi/LHqlNV2tbODCbIT7nnjdib5+VixOdTJcf2SVwK60w+ X-Received: by 2002:a05:6122:2a43:b0:55b:305b:4e47 with SMTP id 71dfb90a1353d-56ae78214b9mr229902e0c.19.1772589158517; Tue, 03 Mar 2026 17:52:38 -0800 (PST) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PATCH v1 5/5] hw/xen: xenpvh: Add prop to enable/disable the mapcache Date: Wed, 4 Mar 2026 02:52:21 +0100 Message-ID: <20260304015222.979224-6-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260304015222.979224-1-edgar.iglesias@gmail.com> References: <20260304015222.979224-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add a machine property to enable/disable the mapcache. Default it to enabled for backwards compatibility. Signed-off-by: Edgar E. Iglesias --- hw/xen/xen-pvh-common.c | 133 +++++++++++++++++++++++++++++--- include/hw/xen/xen-pvh-common.h | 2 + 2 files changed, 124 insertions(+), 11 deletions(-) diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index 4fade017bb..cca37202ff 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -29,6 +29,69 @@ static const MemoryListener xen_memory_listener = { .priority = MEMORY_LISTENER_PRIORITY_ACCEL, }; +/* + * Map foreign RAM in bounded chunks so we don't build a PFN array for the + * entire guest size (which can be huge for large guests). We reserve a VA + * range once and then MAP_FIXED each chunk into place. + */ +#define XEN_PVH_MAP_CHUNK_PAGES 65535 + +static void *xen_map_guest_ram(XenPVHMachineState *s, + uint64_t addr, uint64_t size) +{ + size_t total_pages = size >> XC_PAGE_SHIFT; + size_t chunk_pages = MIN(XEN_PVH_MAP_CHUNK_PAGES, total_pages); + g_autofree xen_pfn_t *pfns = NULL; + void *base = NULL; + size_t offset; + + if (!total_pages) { + goto done; + } + + base = mmap(NULL, size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (base == MAP_FAILED) { + base = NULL; + goto done; + } + + pfns = g_new0(xen_pfn_t, chunk_pages); + if (!pfns) { + munmap(base, size); + base = NULL; + goto done; + } + + for (offset = 0; offset < total_pages; offset += chunk_pages) { + size_t num_pages = MIN(chunk_pages, total_pages - offset); + void *mapped; + size_t i; + + for (i = 0; i < num_pages; i++) { + pfns[i] = (addr >> XC_PAGE_SHIFT) + offset + i; + } + + mapped = xenforeignmemory_map2( + xen_fmem, xen_domid, + (uint8_t *)base + (offset << XC_PAGE_SHIFT), + PROT_READ | PROT_WRITE, MAP_FIXED, + num_pages, pfns, NULL); + if (!mapped) { + munmap(base, size); + base = NULL; + goto done; + } + } +done: + if (!base) { + /* We can't recover from this. */ + error_report("FATAL: Failed to foreign-map %" PRIx64 " - %" PRIx64, + addr, addr + size); + exit(EXIT_FAILURE); + } + return base; +} + static void xen_pvh_init_ram(XenPVHMachineState *s, MemoryRegion *sysmem) { @@ -45,22 +108,42 @@ static void xen_pvh_init_ram(XenPVHMachineState *s, block_len = s->cfg.ram_high.base + ram_size[1]; } - memory_region_init_ram(&xen_memory, NULL, "xen.ram", block_len, - &error_fatal); + if (s->cfg.mapcache) { + memory_region_init_ram(&xen_memory, NULL, "xen.ram", + block_len, &error_fatal); + memory_region_init_alias(&s->ram.low, NULL, "xen.ram.lo", &xen_memory, + s->cfg.ram_low.base, ram_size[0]); + if (ram_size[1] > 0) { + memory_region_init_alias(&s->ram.high, NULL, "xen.ram.hi", + &xen_memory, + s->cfg.ram_high.base, ram_size[1]); + } + } else { + void *p; + + p = xen_map_guest_ram(s, s->cfg.ram_low.base, ram_size[0]); + memory_region_init_ram_ptr(&s->ram.low, NULL, "xen.ram.lo", + ram_size[0], p); + if (ram_size[1] > 0) { + p = xen_map_guest_ram(s, s->cfg.ram_high.base, ram_size[1]); + memory_region_init_ram_ptr(&s->ram.high, NULL, "xen.ram.hi", + ram_size[1], p); + } + } - memory_region_init_alias(&s->ram.low, NULL, "xen.ram.lo", &xen_memory, - s->cfg.ram_low.base, ram_size[0]); + /* Map them onto QEMU's address-space. */ memory_region_add_subregion(sysmem, s->cfg.ram_low.base, &s->ram.low); if (ram_size[1] > 0) { - memory_region_init_alias(&s->ram.high, NULL, "xen.ram.hi", &xen_memory, - s->cfg.ram_high.base, ram_size[1]); memory_region_add_subregion(sysmem, s->cfg.ram_high.base, &s->ram.high); } - /* Setup support for grants. */ - memory_region_init_ram(&xen_grants, NULL, "xen.grants", block_len, - &error_fatal); - memory_region_add_subregion(sysmem, XEN_GRANT_ADDR_OFF, &xen_grants); + /* Grants are only supported when the mapcache is on. */ + if (s->cfg.mapcache) { + /* Setup support for grants. */ + memory_region_init_ram(&xen_grants, NULL, "xen.grants", block_len, + &error_fatal); + memory_region_add_subregion(sysmem, XEN_GRANT_ADDR_OFF, &xen_grants); + } } static void xen_set_irq(void *opaque, int irq, int level) @@ -203,7 +286,7 @@ static void xen_pvh_init(MachineState *ms) xen_register_ioreq(&s->ioreq, ms->smp.max_cpus, xpc->handle_bufioreq, &xen_memory_listener, - true); + s->cfg.mapcache); if (s->cfg.virtio_mmio_num) { xen_create_virtio_mmio_devices(s); @@ -285,6 +368,20 @@ XEN_PVH_PROP_MEMMAP(pci_ecam) XEN_PVH_PROP_MEMMAP(pci_mmio) XEN_PVH_PROP_MEMMAP(pci_mmio_high) +static void xen_pvh_set_mapcache(Object *obj, bool value, Error **errp) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + xp->cfg.mapcache = value; +} + +static bool xen_pvh_get_mapcache(Object *obj, Error **errp) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + return xp->cfg.mapcache; +} + static void xen_pvh_set_pci_intx_irq_base(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) @@ -338,6 +435,12 @@ do { \ OC_MEMMAP_PROP_SIZE(c, prop_name, name); \ } while (0) + object_class_property_add_bool(oc, "mapcache", xen_pvh_get_mapcache, + xen_pvh_set_mapcache); + object_class_property_set_description(oc, "mapcache", + "Set on/off to enable/disable the " + "mapcache"); + /* * We provide memmap properties to allow Xen to move things to other * addresses for example when users need to accomodate the memory-map @@ -377,6 +480,13 @@ do { \ #endif } +static void xen_pvh_instance_init(Object *obj) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + xp->cfg.mapcache = true; +} + static void xen_pvh_class_init(ObjectClass *oc, const void *data) { MachineClass *mc = MACHINE_CLASS(oc); @@ -395,6 +505,7 @@ static const TypeInfo xen_pvh_info = { .parent = TYPE_MACHINE, .abstract = true, .instance_size = sizeof(XenPVHMachineState), + .instance_init = xen_pvh_instance_init, .class_size = sizeof(XenPVHMachineClass), .class_init = xen_pvh_class_init, }; diff --git a/include/hw/xen/xen-pvh-common.h b/include/hw/xen/xen-pvh-common.h index 0ed07c5694..0209b798f3 100644 --- a/include/hw/xen/xen-pvh-common.h +++ b/include/hw/xen/xen-pvh-common.h @@ -84,6 +84,8 @@ struct XenPVHMachineState { /* PCI */ MemMapEntry pci_ecam, pci_mmio, pci_mmio_high; uint32_t pci_intx_irq_base; + + bool mapcache; } cfg; }; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 08:43:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 08:43:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245159.1544514 (Exim 4.92) (envelope-from ) id 1vxhpF-0001Ku-5S; Wed, 04 Mar 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 1245159.1544514; Wed, 04 Mar 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 ) id 1vxhpF-0001Kn-2C; Wed, 04 Mar 2026 08:43:25 +0000 Received: by outflank-mailman (input) for mailman id 1245159; Wed, 04 Mar 2026 08:43:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxhpD-0001Kd-J9 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 08:43:23 +0000 Received: from DU2PR03CU002.outbound.protection.outlook.com (mail-northeuropeazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c200::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 332792e7-17a6-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 09:43:21 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by VI1PR03MB9967.eurprd03.prod.outlook.com (2603:10a6:800:1cf::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 08:43:18 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9654.022; Wed, 4 Mar 2026 08:43:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 332792e7-17a6-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C/sBq7GzQNju3brhaa+lc9en+jSOLkC3ROVAOVBBbBDBweNRTrkcs9qshkNgtrlig1+blA/KnB8sHwtH3cGXnqMQkGazdCG9pvIiquDhgYJ4ApzDuH4ZOBqOjvdoeQ5M/ZMh++4ofJ3Rlx77rb1l262pdpbksKMXefpWvNq1lXeU6xLl014iAPhU8cV6ZBFb+YN5+Iq+x/jU07VS12tmYy/vdIozvRmD1o7Uai/RKXSLSg2FqNMCTd73pnJpodTghqXauWEPQHirosJDCtIwUuBaqys35iruZZFW19cYpr9iFYY86oocQNesgIfGoE19fb356OFY01zc88BivVwXnw== 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=yPPd+9bG9DMhsZYzJXoIamo/bE/AclPIQLCu1r+C2PY=; b=P0znn4PWnOvSbvqt3me/5QKQzbWVdtny9Ig/8Kacbcz7RpCnGcC/DwEAPG6k+e1uVSL+go//8jou6Mzy1pT6R2udAJC8jzFlSM6ObqFc/MR7tfPAJSVZDtbVB14DgLWgFudlqcLETqr+9YWA/uxvu5RCd6OFqXoWLYJoddlCAp42jXz65MmMBZjZpYoWv2l3XdBg1srg8fmewYIefA0Oa8r7m9h9O1RRBAmyjxzWZnJES1bnZOye/0BUF4aqIHFUBRR59FXf/59+0hS+kyTFTy6urco3bkrGXHPabxwrnas+Pi5L/90dL3X49G/drU3XUWcSHUbSmMHsfIBINRiwEQ== 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=yPPd+9bG9DMhsZYzJXoIamo/bE/AclPIQLCu1r+C2PY=; b=neDmCZb45Exb3XAnED4O/FfWP4lAtANNz7ANctyUqsFyOdo2zt0xtlq/FUhTC4SrwPd5Vzu5GwNlOUWRhA2YXtxNzggHEn1coYSyWOEh8YREM0gNWS+4XiVaYMxQ+kjhOw00isfwB72Ex+zs2lgnapucSKJVyGi0U+jhJmadRFmflYPyqaZLoGx86Z82ihkuxQhhgrazSTslx4OL5AqTt1/9YcoqbAPNHOYq3svSqSKNlFDG2o7qmw10lG4iH4TWxkSw5f/q9RxRoEsEyW5sum5451dMh+1FQdhdwj0NmS8dfJ0ReJMuimQE+LaL8NrMILTMoBFgklsbttOPk852mA== From: Mykyta Poturai To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= CC: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v1 4/6] vpci: add SR-IOV support for PVH Dom0 Thread-Topic: [PATCH v1 4/6] vpci: add SR-IOV support for PVH Dom0 Thread-Index: AQHb/W/XkRTIlDBdSUyf2rny+l8q37RHbCEAgVf+4gA= Date: Wed, 4 Mar 2026 08:43:17 +0000 Message-ID: <8da9f137-a897-4438-9524-85836e0170a1@epam.com> References: In-Reply-To: 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_|VI1PR03MB9967:EE_ x-ms-office365-filtering-correlation-id: 2d6907d5-8bf4-405d-e2f2-08de79ca14ed x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024|7053199007|38070700021; x-microsoft-antispam-message-info: mwaq49TErWt5FJbiPJMezo3kmOtOMI+A5U7vXfOVVtVRWEfspu+n1+nUiLJmlqYybjlCpmouPFZkUiKFeIyJSdQ7qAuzGoBaNmDoSui7AQfMxkmFIDBhK/SZXAfnYpaIf4/s76/37kA97TXNTvsoFzZ7z4X+QuLZ202HkKB7mxZIQF7yAKIRYsb6+az2ZW7mqOGCqvFB9Vu4nEKxhcQMc6HZNKrNnaG5z43ClHFHgU4pY+/UdSwXqiH7MCDVewCuq8Cls5YfoIMEAxR9IVkU7DsX4kfATSMn8OKvDd+4pigwktkr76eFI2dNYGOlkyjHLAlrwoV0g0XkkJ044owzZ4Evo20S2jrgVTKAQhWMCC2OPiBLWIv+oLsL2gTpgu1bv513blXIk0YLDhAhg0GXnOSme7fyms4BAs3oVn8qi1hZ1vbaFaNqAEsm0zQ1HKmUfc6BFuse38XQKTDj8Hkr2eAXqas9TOQsW5NCOaA8tqbvltymt9PaMtuS+Z9PKLEBhCEDGDaejbxxY4+XdejRJ1n+ERzMo9o1qGGWE1GPGBuYUF2BbkrS1qU6nCeDNw1OxhcEXRmPiF8X3d0nMDdMx1E7mReGi+SxHjGSmNBSeu7Hmg1v84SpsiE0B+O0J8GniL9VaLlGz8gJflJuoDSplpJjfSJn6FcYQtUVtJNzqdL96dsLRMRR7/asatVnWFwIvThhZFMitN34nLMbbD+cih5R67MgJL60gK0kMII1VT0= 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)(366016)(376014)(7416014)(1800799024)(7053199007)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cXVZYUp5R29id2U5QVhaakhZdDRCQXdtQWhzbGJ5N0R3NnRzQ1cweTN0ZjJr?= =?utf-8?B?TERTQjVrZXhOQU5JNXl1SUE4MlBDbTlOUkp4eDdlKys4ak9IYzNPOVI0MHAr?= =?utf-8?B?QzJnWng3M3BoRzRqWHVQWnJZOG5oWTQwMmpSaVJROENrT0RFc3RBSlZLY0NG?= =?utf-8?B?cnY2cnk2aXZXTnRtZjVROTJOYjIwdlcwSDVEVzFCMDRFaC9RcXMwTThiVU9U?= =?utf-8?B?ZHhoQ3B3OHJZT3psUHZKdWdKdDJhU2dTWFdLQmxyVlpscUpPa0o4ay9PNDkw?= =?utf-8?B?MXdsNG1taFowelhuYkFwSFkyczJQek11SldJQTJQRElVbExSdnNsY3Vma01u?= =?utf-8?B?MldCNUVvVmR2VXpZYWs0bTBQL3h4czg1QVgwcG5ldlV2NWFkSTF0cEtRaUQ4?= =?utf-8?B?bktMZUVGcXZYNytxY2hacDJ3YkVOZ1hpc0dBWG10a2VLaEk1NXhBYnVWWFlH?= =?utf-8?B?WjMrYTJGc2NYY0xYc2dEK2RJbktxUXVMSFJqZkxidzhHMVF6aTJGanpaMnBi?= =?utf-8?B?OG4ycW9RTkpraVVCOEIrTGNVN2R0cFlUdWx1L1hVQ1czZmdmN3B1RzZybWFG?= =?utf-8?B?dGpPajdOTGR2Tk9zdUVsSnlKY296akY1eTliVVVKK25zSUk3c3FxZk9tOUg5?= =?utf-8?B?SjR6V0dQVExZZ1h0amR6ZUFxRGNXREVJMDNMZm5pTnVMWEdFNHUvMlBCL0Rx?= =?utf-8?B?a1U1dXpZT3h4ZStzdGFKQm54NmcrSjhUZWE3R2FMb1AxWDJYVFZvOUI4anVG?= =?utf-8?B?ZjJCTXZ2amUrZFpaWnhuYnB5cWNyRlo3aTZBTlYyU1FuMjFTdXhZcjF3NjBm?= =?utf-8?B?NVpqVlhEUlFIR1I5RDBsSVFHVEwzSzhSYitmZDQ1LzQrdHdRRGY0U1B5SldT?= =?utf-8?B?T0tzOHFhZTk0SzdNa1gwbnpnNUdEMG04eVlsTGRBeDVqT01aSUdIbXJNVUV2?= =?utf-8?B?UllMN3hFcXdJRnBINFlzTlR3SkFCMXBXL0Y1bHRhZjY5SkhHWXZJc2FJRXlY?= =?utf-8?B?SDY3NXFoUzVUQUpyVnR6UTNhTmFSZVZxVVhQNXh2eDBrMmlMRnZVclVGbXYw?= =?utf-8?B?SmliMVhrMFE0eCtlMzd0cHlIY3hyK1YvZ0czOFpXaEtVckppOXRDSk5ybTh1?= =?utf-8?B?eENLeWx6MUdoMy9VNXRVVVhKMXcrMXU2cWo3RHIzY2xnMnNLeWNQVi83d0Fy?= =?utf-8?B?S21LMFhoVEN3L0ZmQ1ZPWWp3bVYrZ3Jxak8ydGJ0N1k3amRsY1hGQUorV1oy?= =?utf-8?B?SG5ZcW5tdExocnkzMG1mMTFNQ2Q5WlRkOXB0MjVEKzJiUnMyRzlwVm1ZRlBs?= =?utf-8?B?SE5ySll5SUZjRnpqdnYzYndHQ1Zici9oMFRWQzFNUTYrdDNKYVRQZzhUYnBV?= =?utf-8?B?aWp0WGp5YXI5VFVzWGlERkJ0NXFXUkMrRXNYTzRYcWY2UlNxc1gvdXBtUm9i?= =?utf-8?B?K25BcWhieEszZ1VYbE5XR3E5TU52S0dhUnJPMDNnT0p6Q3NpWEphSVVBYXBz?= =?utf-8?B?NzdZTTBHMEc0eUE0Nk9PeHlDY1hVR3BWVlNjb1g4MnFSdi9CSkFjRC9Zencw?= =?utf-8?B?Q1lpMFB3Nmc5d0I3VTYzRWJycUsvK3pyY1hTSTkxZmp6ZjZMSlpIUnNUN2to?= =?utf-8?B?b1hXS3I0RFhvV3RFc2JxZUc1SmYzWFZOM0JFMGNnRHNnbUl1dmNENDNXSDJJ?= =?utf-8?B?T2k1Vk12YzcyZXpta01DU0hvKzFGeEFiTm5Wc3pmN2d2dThMWXluWWlWMXZm?= =?utf-8?B?ck1tT2psSzhOUXVjOUJiWWJrVEVHVmlDZFZUOXVjWHVBN25nc2RNT05GT0Nk?= =?utf-8?B?U25GUk44VUtaVGNHcWdKQVUxNVlEODVUNFFibmh6S3VJallNL2dOR1ZrTTdk?= =?utf-8?B?SGg4djhyc1l5cWw5bGhVWGZVcm9xUWloS2FiR0MzTFo0WmFvYXFhQVdzYml1?= =?utf-8?B?VDYrTnJvYmFkR3BITXBVR25DTGYrUEorb0FpNlVxa2Fqcmdoa3NpN0lzSTA5?= =?utf-8?B?SzZ5eVZScmRqTDN6WC9NMGxvZS9hcFdROU16b0h6MmUyZm0zMEIvRU9JMS9Z?= =?utf-8?B?THgyV0FYRVg4cmV3QkhqSkVVVldXbFFINFl5dVc3Vzl3a1FXZFBTZzltMW9m?= =?utf-8?B?VCtsK1BXaUFsN1Fnc2pUWnZxRXJPWWJQazQzaGM4bExGeE92YWN3QUNZd1Nu?= =?utf-8?B?UG9CWnZoeHEybS91c2R2dHo2NDQ2VUx1ODJaczRnbUQwTTl2ZG1pNC95TS9i?= =?utf-8?B?MFM1WkVzTGZVRCtUMWlPb2VuMWZnT0VTeUJ3TzRrWXFRNm0xSGZNYU1SQ20w?= =?utf-8?B?SjRUM0NMdHpHc1p6eXhzditMV2o5NnRnUERzSXkxUXNKeVRBV2VGWGZ2WURO?= =?utf-8?Q?lvxHlnigs4osGxrU=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <77FC0C094C3BFA40853C69866B7A0A38@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d6907d5-8bf4-405d-e2f2-08de79ca14ed X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2026 08:43:17.4438 (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: Kakk8C64pydenQ3Ofn9HJNjo6FXg9WKWMSxZZc/LTcVQuJHk8g7/xco8FIFQAJ2VZMW4F87SRgw6PQatg5axzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB9967 T24gNy8yOC8yNSAxNDozMywgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToNCj4gT24gRnJpLCBKdWwg MjUsIDIwMjUgYXQgMDI6MjQ6MzNQTSArMDAwMCwgTXlreXRhIFBvdHVyYWkgd3JvdGU6DQo+PiBG cm9tOiBTdGV3YXJ0IEhpbGRlYnJhbmQgPHN0ZXdhcnQuaGlsZGVicmFuZEBhbWQuY29tPg0KPj4N Cj4+IFRoaXMgY29kZSBpcyBleHBlY3RlZCB0byBvbmx5IGJlIHVzZWQgYnkgcHJpdmlsZWdlZCBk b21haW5zLA0KPj4gdW5wcml2aWxlZ2VkIGRvbWFpbnMgc2hvdWxkIG5vdCBnZXQgYWNjZXNzIHRv IHRoZSBTUi1JT1YgY2FwYWJpbGl0eS4NCj4+DQo+PiBJbXBsZW1lbnQgUlcgaGFuZGxlcnMgZm9y IFBDSV9TUklPVl9DVFJMIHJlZ2lzdGVyIHRvIGR5bmFtaWNhbGx5DQo+PiBtYXAvdW5tYXAgVkYg QkFSUy4gUmVjYWxjdWxhdGUgQkFSIHNpemVzIGJlZm9yZSBtYXBwaW5nIFZGcyB0byBhY2NvdW50 DQo+PiBmb3IgcG9zc2libGUgY2hhbmdlcyBpbiB0aGUgc3lzdGVtIHBhZ2Ugc2l6ZSByZWdpc3Rl ci4NCj4+DQo+PiBSZWxpZXMgb24gZG9tMCB0byBlbmFibGUgU1ItSU9WIGFuZCBQSFlTREVWT1Ag dG8gaW5mb3JtIFhlbiBhYm91dA0KPj4gYWRkaXRpb24vcmVtb3ZhbCBvZiBWRnMuDQo+IA0KPiBX aHkgSSdtIG5vdCBvcHBvc2VkIHRvIGFsbG93aW5nIHJlZ2lzdHJhdGlvbiBvZiBkZXZpY2VzIHVz aW5nDQo+IFBIWVNERVZPUCwgY2FuJ3QgWGVuIGRldGVjdCB0aGUgYWRkaXRpb24gb2YgdGhlIFZG cyBhbmQgYWRkIHRoZW0NCj4gaXRzZWxmPw0KPiANCj4gV2hlbiBJIHdvcmtlZCBvbiB0aGlzIGxv bmcgdGltZSBhZ28sIHRoZSB2ZXJzaW9uIG9mIHRoZSBzZXJpZXMgdGhhdCBJDQo+IHBvc3RlZCBo YWQgcmVnaXN0cmF0aW9uIG9mIHRoZSBWRnMgZG9uZSBieSBYZW4gYWxzbzoNCj4gDQo+IGh0dHBz Oi8vbG9yZS5rZXJuZWwub3JnL3hlbi1kZXZlbC8yMDE4MDcxNzA5NDgzMC41NDgwNi0xMi1yb2dl ci5wYXVAY2l0cml4LmNvbS8NCj4gDQo+Pg0KPj4gU2lnbmVkLW9mZi1ieTogU3Rld2FydCBIaWxk ZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCj4+IFNpZ25lZC1vZmYtYnk6IE15 a3l0YSBQb3R1cmFpIDxteWt5dGFfcG90dXJhaUBlcGFtLmNvbT4NCj4+IC0tLQ0KPj4gICBDSEFO R0VMT0cubWQgICAgICAgICAgICAgIHwgICAzICstDQo+PiAgIFNVUFBPUlQubWQgICAgICAgICAg ICAgICAgfCAgIDIgLQ0KPj4gICB4ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlIHwgICAyICstDQo+ PiAgIHhlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgfCAgIDMgKw0KPj4gICB4ZW4vZHJpdmVycy92 cGNpL3NyaW92LmMgIHwgMjM1ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr DQo+PiAgIHhlbi9kcml2ZXJzL3ZwY2kvdnBjaS5jICAgfCAgIDEgKw0KPj4gICB4ZW4vaW5jbHVk ZS94ZW4vdnBjaS5oICAgIHwgICA3ICstDQo+PiAgIDcgZmlsZXMgY2hhbmdlZCwgMjQ3IGluc2Vy dGlvbnMoKyksIDYgZGVsZXRpb25zKC0pDQo+PiAgIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vZHJp dmVycy92cGNpL3NyaW92LmMNCj4+DQo+PiBkaWZmIC0tZ2l0IGEvQ0hBTkdFTE9HLm1kIGIvQ0hB TkdFTE9HLm1kDQo+PiBpbmRleCA1ZjMxY2EwOGZlLi43YjBlOGJlYjc2IDEwMDY0NA0KPj4gLS0t IGEvQ0hBTkdFTE9HLm1kDQo+PiArKysgYi9DSEFOR0VMT0cubWQNCj4+IEBAIC0yMyw4ICsyMyw3 IEBAIFRoZSBmb3JtYXQgaXMgYmFzZWQgb24gW0tlZXAgYSBDaGFuZ2Vsb2ddKGh0dHBzOi8va2Vl cGFjaGFuZ2Vsb2cuY29tL2VuLzEuMC4wLw0KPj4gICAgLSBPbiB4ODY6DQo+PiAgICAgIC0gT3B0 aW9uIHRvIGF0dGVtcHQgdG8gZml4dXAgcDJtIHBhZ2UtZmF1bHRzIG9uIFBWSCBkb20wLg0KPj4g ICAgICAtIFJlc2l6YWJsZSBCQVJzIGlzIHN1cHBvcnRlZCBmb3IgUFZIIGRvbTAuDQo+PiAtICAg LSBTdXBwb3J0IFBDSSBwYXNzdGhyb3VnaCBmb3IgSFZNIGRvbVVzIHdoZW4gZG9tMCBpcyBQVkgg KG5vdGUgU1ItSU9WDQo+PiAtICAgICBjYXBhYmlsaXR5IHVzYWdlIGlzIG5vdCB5ZXQgc3VwcG9y dGVkIG9uIFBWSCBkb20wKS4NCj4+ICsgICAtIFN1cHBvcnQgUENJIHBhc3N0aHJvdWdoIGZvciBI Vk0gZG9tVXMgd2hlbiBkb20wIGlzIFBWSC4NCj4gDQo+IERvbid0IHlvdSBuZWVkIHRvIG1vdmUg dGhpcyBvdXQgb2YgdGhlIHg4NiBzcGVjaWZpYyBzZWN0aW9uPw0KPiANCj4gQWNjb3JkaW5nIHRv IHRoZSBjb3ZlciBsZXR0ZXIgeW91IGFyZSB0ZXN0aW5nIG9uIGFuIEFSTSBib2FyZCwgc28gdGhp cw0KPiBwcm9iYWJseSBuZWVkcyB0byBiZSBwdXQgaW4gYSBub24tYXJjaCBwYXJ0IG9mIENIQU5H RUxPRz8NCj4gDQo+PiAgICAgIC0gU21va2UgdGVzdHMgZm9yIHRoZSBGcmVlQlNEIFhlbiBidWls ZHMgaW4gQ2lycnVzIENJLg0KPj4gICANCj4+ICAgIC0gT24gQXJtOg0KPj4gZGlmZiAtLWdpdCBh L1NVUFBPUlQubWQgYi9TVVBQT1JULm1kDQo+PiBpbmRleCA2YTgyYTkyMTg5Li44MzBiNTk4NzE0 IDEwMDY0NA0KPj4gLS0tIGEvU1VQUE9SVC5tZA0KPj4gKysrIGIvU1VQUE9SVC5tZA0KPj4gQEAg LTE3MCw4ICsxNzAsNiBAQCB1bmV4cGVjdGVkIGJlaGF2aW9yIG9yIGlzc3VlcyBvbiBzb21lIGhh cmR3YXJlLg0KPj4gICANCj4+ICAgQXQgbGVhc3QgdGhlIGZvbGxvd2luZyBmZWF0dXJlcyBhcmUg bWlzc2luZyBvbiBhIFBWSCBkb20wOg0KPj4gICANCj4+IC0gICogUENJIFNSLUlPVi4NCj4+IC0N Cj4+ICAgICAqIE5hdGl2ZSBOTUkgZm9yd2FyZGluZyAobm1pPWRvbTAgY29tbWFuZCBsaW5lIG9w dGlvbikuDQo+PiAgIA0KPj4gICAgICogTUNFIGhhbmRsaW5nLg0KPj4gZGlmZiAtLWdpdCBhL3hl bi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUgYi94ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlDQo+PiBp bmRleCBhN2M4YTMwYTg5Li5mZTFlNTdiNjRkIDEwMDY0NA0KPj4gLS0tIGEveGVuL2RyaXZlcnMv dnBjaS9NYWtlZmlsZQ0KPj4gKysrIGIveGVuL2RyaXZlcnMvdnBjaS9NYWtlZmlsZQ0KPj4gQEAg LTEsMiArMSwyIEBADQo+PiAtb2JqLXkgKz0gdnBjaS5vIGhlYWRlci5vIHJlYmFyLm8NCj4+ICtv YmoteSArPSB2cGNpLm8gaGVhZGVyLm8gcmViYXIubyBzcmlvdi5vDQo+PiAgIG9iai0kKENPTkZJ R19IQVNfUENJX01TSSkgKz0gbXNpLm8gbXNpeC5vDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2RyaXZl cnMvdnBjaS9oZWFkZXIuYyBiL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMNCj4+IGluZGV4IGY5 NDdmNjUyY2QuLjBhODQwYzZkY2MgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vZHJpdmVycy92cGNpL2hl YWRlci5jDQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jDQo+PiBAQCAtODM5LDYg KzgzOSw5IEBAIHN0YXRpYyBpbnQgY2ZfY2hlY2sgaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYg KnBkZXYpDQo+PiAgIA0KPj4gICAgICAgQVNTRVJUKHJ3X2lzX3dyaXRlX2xvY2tlZCgmcGRldi0+ ZG9tYWluLT5wY2lfbG9jaykpOw0KPj4gICANCj4+ICsgICAgaWYgKCBwZGV2LT5pbmZvLmlzX3Zp cnRmbiApDQo+PiArICAgICAgICByZXR1cm4gMDsNCj4+ICsNCj4+ICAgICAgIHN3aXRjaCAoIHBj aV9jb25mX3JlYWQ4KHBkZXYtPnNiZGYsIFBDSV9IRUFERVJfVFlQRSkgJiAweDdmICkNCj4+ICAg ICAgIHsNCj4+ICAgICAgIGNhc2UgUENJX0hFQURFUl9UWVBFX05PUk1BTDoNCj4+IGRpZmYgLS1n aXQgYS94ZW4vZHJpdmVycy92cGNpL3NyaW92LmMgYi94ZW4vZHJpdmVycy92cGNpL3NyaW92LmMN Cj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0DQo+PiBpbmRleCAwMDAwMDAwMDAwLi42NDA0MzBlM2U5 DQo+PiAtLS0gL2Rldi9udWxsDQo+PiArKysgYi94ZW4vZHJpdmVycy92cGNpL3NyaW92LmMNCj4+ IEBAIC0wLDAgKzEsMjM1IEBADQo+PiArLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0y LjAtb25seSAqLw0KPj4gKy8qDQo+PiArICogSGFuZGxlcnMgZm9yIGFjY2Vzc2VzIHRvIHRoZSBT Ui1JT1YgY2FwYWJpbGl0eSBzdHJ1Y3R1cmUuDQo+PiArICoNCj4+ICsgKiBDb3B5cmlnaHQgKEMp IDIwMTggQ2l0cml4IFN5c3RlbXMgUiZEDQo+IA0KPiBJZiB0aGVyZSdzIGEgQ2l0cml4IGNvcHly aWdodCBoZWFkZXIgaGVyZSwgc2hvdWxkbid0IHRoZXJlIGJlIGENCj4gbWF0Y2hpbmcgU2lnbmVk LW9mZi1ieSBmcm9tIHNvbWVvbmUgYXQgQ2l0cml4IChJIHRoaW5rIHRoYXQncyBsaWtlbHkNCj4g bWUpPw0KPiANCj4gT3RoZXJ3aXNlIGlmIHRoZXJlJ3Mgbm8gY29udGVudCBhdXRob3JlZCBieSBh IENpdHJpeCBlbXBsb3llZSB0aGUNCj4gY29weXJpZ2h0IG5vdGljZSBtdXN0IGJlIHJlbW92ZWQu ICBXZSBuZWVkIHRvIGJlIGNhcmVmdWwgd2l0aA0KPiBjb3B5cmlnaHQgYW5kIGF0dHJpYnV0aW9u Lg0KPiANCj4gQW5kIGluIGFueSBjYXNlIHRoZSBkYXRlIHNob3VsZCBiZSB1cGRhdGVkLg0KPiAN Cg0KQ2FuIEkgYWRkIHlvdXIgU09CIG9yIGlzIGl0IGJldHRlciB0byByZW1vdmUgdGhlIGNvcHly aWdodD8gTG9va2luZyBhdCANCnRoZSBwYXRjaGVzIHlvdSBwcm92aWRlZCwgSSB0aGluayB0aGlz IG9uZXMgd2VyZSBkZWZpbml0ZWx5IGJhc2VkIG9uIA0KdGhlbSwgYnV0IHRoZXJlIGFyZSBhbHNv IGEgbG90IG9mIGNoYW5nZXMgc2luY2UgdGhlbi4NCg0KLS0gDQpNeWt5dGE= From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:34:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:34:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245180.1544552 (Exim 4.92) (envelope-from ) id 1vxic5-00011s-1t; Wed, 04 Mar 2026 09:33:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245180.1544552; Wed, 04 Mar 2026 09:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxic4-00011k-VD; Wed, 04 Mar 2026 09:33:52 +0000 Received: by outflank-mailman (input) for mailman id 1245180; Wed, 04 Mar 2026 09:33:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxic2-00011U-Mc for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:33:50 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3e475509-17ad-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 10:33:48 +0100 (CET) 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 6249KdIv1455844 for ; Wed, 4 Mar 2026 09:33:45 GMT Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cpj1801me-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 04 Mar 2026 09:33:45 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2ae65d5cc57so62979005ad.2 for ; Wed, 04 Mar 2026 01:33:44 -0800 (PST) Received: from [10.219.57.109] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae541358d4sm76250575ad.75.2026.03.04.01.33.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 01:33:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e475509-17ad-11f1-b164-2bf370ae4941 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= olej/QuVyiT3XCCYbNDROqVlMJ/ZiroIS/6G24fqqXw=; b=jG7fGQ4v5uKwi+m6 jYRS3LTZutxZaRvtn8jkQxwWB2a0rTwd5e4FuO+g0wWd5G6gGJcJF4AE1G5i+wFk OVKDaM+De548acZWpPzF3QrgKX7M0ybyyo9T9nH5iq1FCKDwI9itphQ7adIazLDh RCVUSxnyEZWmuQHAooPZDGtWaMjcWZ8Cwxhrap9wNj/tneGiKaSjMDD1SK277er9 zx1qlz8KOShYrjRR+IbVJPOroaviNiAlxyRY0ZMUgNqTvVo0VGxfRXNQzqpcimU5 5LEprhOHTQYA/7ocebT16KTOpnKkzt3JtoAKgir2XJgo30Zc72Ql1lf/KJbK5HwK TOtKHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772616824; x=1773221624; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=olej/QuVyiT3XCCYbNDROqVlMJ/ZiroIS/6G24fqqXw=; b=PGuhz+lm2m3hsnHBlQw9ib9vrdWL7CD5Rv6Q/rlGSVnpzXQZLlXVtME4VDaiKobjHv VtElYb6VUdOiwGqeLHdlJynZIwDsURbo+8WN5qvVTyTAjUbcDArllaE+2a3Io45jHirb jRyE4dLv9LjY2U+kqj8P+cqQqZ44FFj/MGd69Wi1sL4MvXFdoJduHPGvLD5F36gKJrMz /lJP/yZQFFtI073Ee2H3WNB1PoAyS9sTC7ruk/aqJhUa7V7SeqGRfTzVPGiQ9Nqgr2NH oZRpfE/qvwT8sKt/BrJ8gviUHWeMkJkV0VwJyC3bAEx9GjDcNXBURxs4PnAJSg1q5z9R tUYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772616824; x=1773221624; h=content-transfer-encoding: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; bh=olej/QuVyiT3XCCYbNDROqVlMJ/ZiroIS/6G24fqqXw=; b=Jaxt53OhTfZXBu749Fa1hR8sjCG9S1HsaKCUVz7sRxrzs+yxButdtnAIPT275k/eSe f1ee6KZws0pkaEvG1YGnJ79RL3Z3JUT9/5odZDZ7qAJRp/W6S2uWSIec3FC46cfxWNJ5 xWJvg/0d3hB3CHiwBS6znaToCh+2rfdjjqHYrZOElJ+k07fxAre5Tfo7Pq1UXbavNg5P pEVlAtczOwV5EBWg9j55fyQWmzfO/1KWgFDb8td1SnczCQcnLAR82iFUO0mzGwQYDAAG a9BdZsxNZWHbgzI1U6MZS93O/RFqikOiFlKfxXaMSZ/jgQ/hPqOawNZPMK6aLGH2W/tc gspw== X-Forwarded-Encrypted: i=1; AJvYcCWsTIJdfWlkQzZuNnZi/SACM1zuCJobPa3ap5pL2iY1HJ2ct9PR6QyDlCj9NbwvU6dURjXUnNQ+EjU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwCHkBQIo83NZob4ivxUtk7yEZ7srQw1nCr3tTridg14jOqdp95 MCLW1H/yhMuyiTShjbsk7asPLvwO9tBcOuhN1d3HcCiW32ZlffH0hLVLWLJvGR2LzJPEZlBz8mZ v8H2H0kmqEFJDgGQEMJFTrbokN7wG554mJwCJMxBKlRkEqxGshYrZYemPTfrDqJK4CMBMqw== X-Gm-Gg: ATEYQzwNnOkY2vJEWWGxuni3ow4OFgo/Li1tmFlfPrBc8V+wu0CZC4lHWSOavpKgAVF dCtfS8ovF91UW/YYkMbPQQ4cGUNEZJiD6NWo49Jk+nCZIFlaZUm6XKemNZHsfBKObmzQdM3Fbau ECMTISAob9LeY+K8SyWYGPzEs2JEvulgCqrJhUI2KlDd7BXZ0YrW2QlQFDNm7hakmriu3FvbplQ dtnfkmAtZKC74MA96/KPY5u2IAH9M3FVd6Y9mQsXQrobUve+3wFtMvwrOXGBcutFVxYAs4dgbij BAfqZkuCyx3ggIwDS4xn9n1VNAgxhUGZM0ts2ubBiHuafZ/UpOSrTMEZxR5heGYB3Yk+WGPWv22 xI4pYUW2O+sYoEIMLwPnAc+7vmRkuMoDS8Cop4XY/72DjX85JIen2MGbW X-Received: by 2002:a17:903:3586:b0:2ae:483f:b23b with SMTP id d9443c01a7336-2ae6aaae620mr19109905ad.32.1772616824005; Wed, 04 Mar 2026 01:33:44 -0800 (PST) X-Received: by 2002:a17:903:3586:b0:2ae:483f:b23b with SMTP id d9443c01a7336-2ae6aaae620mr19109655ad.32.1772616823507; Wed, 04 Mar 2026 01:33:43 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 15:02:14 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() To: Marc Zyngier Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> <86342janlx.wl-maz@kernel.org> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: <86342janlx.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: gPrIPuWDPDWSv3sVI6dBGPwhrJQWIOml X-Proofpoint-ORIG-GUID: gPrIPuWDPDWSv3sVI6dBGPwhrJQWIOml X-Authority-Analysis: v=2.4 cv=Ed7FgfmC c=1 sm=1 tr=0 ts=69a7fc79 cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=EUspDBNiAAAA:8 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=xEgsDuFUHT4EKXnybycA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDA3MiBTYWx0ZWRfXww1T3Whyklwa ls5pvfv5Ox03jQhQiuelVVgiI9b1bg86e9xxsPgFbH9kSX6b3Sj993+bAHRVaIoqjBnVn34ZpNk A60OwvZYXzgj9idW1admPHNmeC3WRjL1d40jROM6yMTIEs9EHs6gpYv60KHeLbTOhYzdvIwGh2t RjlXD666y4q8CvElXYI2UGnwmQwbDJOuME+qP52ar2D+xXbc8FK/1vUwoZcHy/50hugIhihq7+V 4rkS3xhdu5A3ehSR3WQMPRHnWJJ05ySf6F5V+qK7uFoQXP7VDNQHaQi1uZHc0oxk5dLOmHfemP0 jHRv5K3HJHb72FPSgI0F7pCCBXhfkKpYlxlxsedgtV3wfas03oRw73m90n1cxfyuGd+60Y9EoMr SiyZ7YmEYCEFjhSz6cWLm3Kb8cdQbAeDXTLSKnmuOreNXgSmggj6EAwYXPoX46Z/eyI++h1DtNH tg0aHV9VgbrQxyl7uFg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040072 On 3/1/2026 3:16 PM, Marc Zyngier wrote: > On Sun, 01 Mar 2026 08:34:19 +0000, > Vijayanand Jitta wrote: >> >> From: Robin Murphy >> >> Since we now have quite a few users parsing "iommu-map" and "msi-map" >> properties, give them some wrappers to conveniently encapsulate the >> appropriate sets of property names. This will also make it easier to >> then change of_map_id() to correctly account for specifier cells. >> >> Reviewed-by: Rob Herring (Arm) >> Reviewed-by: Frank Li >> Signed-off-by: Robin Murphy >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/cdx/cdx_msi.c | 3 +-- >> drivers/iommu/of_iommu.c | 4 +--- >> drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- >> drivers/of/irq.c | 3 +-- >> drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- >> drivers/pci/controller/pcie-apple.c | 3 +-- >> drivers/xen/grant-dma-ops.c | 3 +-- >> include/linux/of.h | 14 ++++++++++++++ >> 8 files changed, 22 insertions(+), 16 deletions(-) >> >> diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c >> index 91b95422b263..63b3544ec997 100644 >> --- a/drivers/cdx/cdx_msi.c >> +++ b/drivers/cdx/cdx_msi.c >> @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, >> int ret; >> >> /* Retrieve device ID from requestor ID using parent device */ >> - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", >> - NULL, &dev_id); >> + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); >> if (ret) { >> dev_err(dev, "of_map_id failed for MSI: %d\n", ret); >> return ret; >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c >> index 6b989a62def2..a511ecf21fcd 100644 >> --- a/drivers/iommu/of_iommu.c >> +++ b/drivers/iommu/of_iommu.c >> @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, >> struct of_phandle_args iommu_spec = { .args_count = 1 }; >> int err; >> >> - err = of_map_id(master_np, *id, "iommu-map", >> - "iommu-map-mask", &iommu_spec.np, >> - iommu_spec.args); >> + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); >> if (err) >> return err; >> >> diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c >> index d36b278ae66c..b63343a227a9 100644 >> --- a/drivers/irqchip/irq-gic-its-msi-parent.c >> +++ b/drivers/irqchip/irq-gic-its-msi-parent.c >> @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u >> >> struct device_node *msi_ctrl __free(device_node) = NULL; >> >> - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); >> + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); >> } >> >> static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, >> diff --git a/drivers/of/irq.c b/drivers/of/irq.c >> index 6367c67732d2..e37c1b3f8736 100644 >> --- a/drivers/of/irq.c >> +++ b/drivers/of/irq.c >> @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) >> * "msi-map" or an "msi-parent" property. >> */ >> for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { >> - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", >> - "msi-map-mask", msi_np, &id_out)) >> + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) >> break; >> if (!of_check_msi_parent(parent_dev->of_node, msi_np)) >> break; >> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c >> index a5b8d0b71677..bff8289f804a 100644 >> --- a/drivers/pci/controller/dwc/pci-imx6.c >> +++ b/drivers/pci/controller/dwc/pci-imx6.c >> @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) >> u32 sid = 0; >> >> target = NULL; >> - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", >> - &target, &sid_i); >> + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); >> if (target) { >> of_node_put(target); >> } else { >> @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) >> } >> >> target = NULL; >> - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", >> - &target, &sid_m); >> + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); >> >> /* >> * err_m target >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c >> index 2d92fc79f6dd..a0937b7b3c4d 100644 >> --- a/drivers/pci/controller/pcie-apple.c >> +++ b/drivers/pci/controller/pcie-apple.c >> @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d >> dev_dbg(&pdev->dev, "added to bus %s, index %d\n", >> pci_name(pdev->bus->self), port->idx); >> >> - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", >> - "iommu-map-mask", NULL, &sid); >> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); >> if (err) >> return err; >> >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c >> index c2603e700178..1b7696b2d762 100644 >> --- a/drivers/xen/grant-dma-ops.c >> +++ b/drivers/xen/grant-dma-ops.c >> @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, >> struct pci_dev *pdev = to_pci_dev(dev); >> u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); >> >> - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, >> - iommu_spec.args)) { >> + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { >> dev_dbg(dev, "Cannot translate ID\n"); >> return -ESRCH; >> } >> diff --git a/include/linux/of.h b/include/linux/of.h >> index be6ec4916adf..824649867810 100644 >> --- a/include/linux/of.h >> +++ b/include/linux/of.h >> @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, >> return of_property_read_u32(np, propname, (u32*) out_value); >> } >> >> +static inline int of_map_iommu_id(const struct device_node *np, u32 id, >> + struct device_node **target, u32 *id_out) >> +{ >> + return of_map_id(np, id, "iommu-map", "iommu-map-mask", >> + target, id_out); >> +} >> + >> +static inline int of_map_msi_id(const struct device_node *np, u32 id, >> + struct device_node **target, u32 *id_out) >> +{ >> + return of_map_id(np, id, "msi-map", "msi-map-mask", >> + target, id_out); >> +} >> + > > Any particular reason why this is made inline instead of out of line > in of/base.c? Also, some documentation would be helpful for the > aspiring hackers dipping into this. > > Other than that, > > Acked-by: Marc Zyngier > > M. > Thanks Marc. I made them static inline mainly because they’re just trivial wrappers around of_map_id(), so keeping them in include/linux/of.h avoids adding new global symbols/exports and keeps the callsites simple (similar to the existing of_property_read_*() inline wrappers). That said, I don’t have a strong preference—if you’d rather have out-of-line helpers in drivers/of/base.c, I’m happy to respin accordingly. Re Documentation, Sure I'll add comments for of_map_iommu_id() and of_map_msi_id() in follow up patch. Thanks, Vijay From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:34:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:34:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245186.1544563 (Exim 4.92) (envelope-from ) id 1vxicj-0001V3-EG; Wed, 04 Mar 2026 09:34:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245186.1544563; Wed, 04 Mar 2026 09: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 ) id 1vxicj-0001Uw-AF; Wed, 04 Mar 2026 09:34:33 +0000 Received: by outflank-mailman (input) for mailman id 1245186; Wed, 04 Mar 2026 09:34:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxich-0001Ug-P6 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:34:31 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 56c78cb7-17ad-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 10:34:28 +0100 (CET) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6245Sf2Y2861376 for ; Wed, 4 Mar 2026 09:34:27 GMT Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cp2c9kcsc-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 04 Mar 2026 09:34:27 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-359918118ebso7750008a91.2 for ; Wed, 04 Mar 2026 01:34:27 -0800 (PST) Received: from [10.219.57.109] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359a8d65b31sm500720a91.0.2026.03.04.01.34.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 01:34:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 56c78cb7-17ad-11f1-9ccf-f158ae23cfc8 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= HgNePX7ca+FZHnkRpuhdJQZhOY6UQv+RvgcyupQpELQ=; b=JFVTiT7lxucAne5+ vWI+HQTpVk9V3jWmx1PWUucrFvamP0yDOFY034alLz3ZBgzIEfMi0MS4uquN1hh8 EI7aXuxp6dMz6qO68oU/aQSWUICNJo/sGcNoD0kPndEVtSWs5OCjVP5rcLH80Phg ky3wGQTwGMI2mB5E91AT27+H0OF6l0sY8Q3oWToivevSOK2GADQjRFKwWcBWEA11 9S/eTjbdqGKh/aZMhmaHEf1pdgu2dgjd13zO95DicZf3Ff6fn+rEkPSwwJQABuHd scgJ1dbD5faRcuu9tqpogs2bthEi90+/7K8PlySiEJVEWT4ZR/QIh7aqipwVG5tU 9sDJBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772616866; x=1773221666; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=HgNePX7ca+FZHnkRpuhdJQZhOY6UQv+RvgcyupQpELQ=; b=Scrxj3RuAIAsTGa1+PiBWfh9OJccHtZbcPIEWh5DcpqJ+CsrqQ8xCPxAv3oXIWobFV olxOsS5FLy881tULhe6OarqbQW1eHKq7IHNPAxabPH9Uc3ftlSuPNm7VIfGQdp9LhTEX wvzQ88aPcAOVHpun/B/xLuwcqAXEVKWEwKMc7IBn/OCgJhK3G4hKl4TgeZzd9F1dAkSm j3ziyC29nzOqvy0zY/HF8SQnyGIMS48+SdzmOLwwDC+YqPuKRuSmPqBWVZWisvsGfhJZ 3unf/8pzAdA2IiRaso2p8+cr4gA5GTZ51Bkty4eWWA3KWiK/CWZJ4Lo69vBq9IX38RIO jBiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772616866; x=1773221666; h=content-transfer-encoding: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; bh=HgNePX7ca+FZHnkRpuhdJQZhOY6UQv+RvgcyupQpELQ=; b=AXBWGlIkxU8qsG3Zo+M12hT5/I8wFTUjw6hU4N0tZEiIJKYHD58AxcLn9l8SSCodsi BB7J3xMo43RSKwWZez9+jFXwHJrz/EMOvfOYNdckD9/bLkr8Cy46Y4LYSoePRRLjd1VL QBgcLmkjAoDcurKlSuQ8uNpC6mt+WVcGkFtGELIjf2+SJ+8Ff+hhZXJPCxjPlJP4LiL9 xBD0BUJe4ivZLv8JQZ8CkOyMpGkICMuux5adB//1VvOeznwqVCK0lbSUaHVD7EklbzVh lQcVAcUgVvH2Sa3LCBK/Ig5yqi2YUZ8x6uIVP1wTVQ1Tji2RHuMhL8oL0wysVIxZLgzw K+Hg== X-Forwarded-Encrypted: i=1; AJvYcCXdfqEmXyhjMaLmFK011eHM3frTtEg8Tg1PG4u1it7syIW5JcBtMKZOlOoItS2h6TcatGdfM7iIk0A=@lists.xenproject.org X-Gm-Message-State: AOJu0YwLQq2T7NtgxWTZgdmkHd2RmffbuNbW1pDFiEOmipeXGKDEOtx2 VnrV94j2HJDxEOhe30R6hVojCncnEAI3QxCSGpGhU8wTVu1KUkaClZf3qnL9fJ2y73dPDy9hYWj +Jkddn2+Va9eKshB+cMHPbvobhgw9e6e8CW1JuwZWIdcezY3cvolVYWwzt5u8nDnNdfsSPg== X-Gm-Gg: ATEYQzzpvzUnNV0eXqHO/pg8138364tI6B+Y0+7Xy3dMvAX1hGY5wpP7v7/E7cnRpFe ZsBqw29JkSZ7k3Vu6ngSygI/rwWQLBQrLxGGbqgQBG4Crpq4Fh/R2vTYgTrpgA4si0QlK5EnjAe mFnFbBsh+FqLbN9ju+M0zCbAD42aoAdFmTGUg7P+setE3Y+zWmysO99iDsj6mECu2Cb8mVECvPF bHzb096RupU4Km+/uvwHcqxZaHKowi0XkT1+n2LRRctodpGRwu1g6JKuA50zvFMBVFTwT2KvWzB KQWN2xG76MjHImXs2Dn3d+avedXrsyj+uvVU6UCDXTQnOKDFtmviIYc2VQi+lpFUIayyoSg85s3 sZEafp2jyUtRW3JGsmgOkMW20pOAEt+KgVUBZDcxinL1/P5lpFelxLEyt X-Received: by 2002:a17:90b:2691:b0:349:2154:eef4 with SMTP id 98e67ed59e1d1-359a69c0d3dmr1241348a91.5.1772616866193; Wed, 04 Mar 2026 01:34:26 -0800 (PST) X-Received: by 2002:a17:90b:2691:b0:349:2154:eef4 with SMTP id 98e67ed59e1d1-359a69c0d3dmr1241312a91.5.1772616865529; Wed, 04 Mar 2026 01:34:25 -0800 (PST) Message-ID: <4bc86c4d-3a4e-4ece-a01f-dce735ee9bd3@oss.qualcomm.com> Date: Wed, 4 Mar 2026 15:04:13 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct To: Dmitry Baryshkov Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDA3MiBTYWx0ZWRfXwOt5a71sSCNJ 7kNpE5LkbgtC8k5WXPJjy4Q1iRJhINCvWGcbwjx+89cO+5ADR5HaDWIDX/DY4hJb44IpCj6nbtu +Chy01zsq7MG+PXdfRntYyT/5om3+he5pPkxP0DhzKGKDWo9bWn9O95snSnUCK3DecN5De0/Huz Q4HKHcY9zTckDH0dXRI8ajJWqn9QS95BhYZk8dfxdbMWHwYYBn8O9v8BOi+XnPIrEAXA/7Ko4IL eRrtSCbPg2dSykGXYrq/44rI0gF+jQ6bYM8ByraQLAOPLbJJtERiyKW1/SBs74E0hsx1wpieLJn 6b1rkz7WudvyglT82YbsWEoCclH6VfZiQOzGf0QJpGjDXzOUcS2/obn5n8jTd2c/W/O8DOgrvu7 rdhUgx6F/Q70TpuG86K7+hKYkL+dTh+7gZ/I+wDLMY5fJTxERAphyCPSUb1xYHPqzpnu80lj4jZ 7V4C51dRclE8jJwfOPg== X-Proofpoint-ORIG-GUID: SHv01H7QYpiVWvg2iJORcrsAdPAmGW9b X-Proofpoint-GUID: SHv01H7QYpiVWvg2iJORcrsAdPAmGW9b X-Authority-Analysis: v=2.4 cv=EefFgfmC c=1 sm=1 tr=0 ts=69a7fca3 cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=MLUpyK7X_zb698vRSG8A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 bulkscore=0 adultscore=0 impostorscore=0 phishscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040072 On 3/1/2026 3:32 PM, Dmitry Baryshkov wrote: > On Sun, Mar 01, 2026 at 02:04:20PM +0530, Vijayanand Jitta wrote: >> From: Charan Teja Kalla >> >> Change of_map_id() to take a pointer to struct of_phandle_args >> instead of passing target device node and translated IDs separately. >> Update all callers accordingly. >> >> Subsequent patch will make use of the args_count field in >> struct of_phandle_args. >> >> Suggested-by: Rob Herring (Arm) >> Signed-off-by: Charan Teja Kalla >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/iommu/of_iommu.c | 2 +- >> drivers/of/base.c | 37 +++++++++++++++++------------------ >> drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- >> drivers/pci/controller/pcie-apple.c | 4 +++- >> drivers/xen/grant-dma-ops.c | 2 +- >> include/linux/of.h | 21 +++++++++++++------- >> 6 files changed, 44 insertions(+), 30 deletions(-) >> > >> @@ -2193,11 +2193,10 @@ int of_map_id(const struct device_node *np, u32 id, >> } >> >> pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, >> - id, target && *target ? *target : NULL); >> + id, arg->np ? arg->np : NULL); > > Is it just 'args->np' then? If it's NULL, it's NULL anyway. > Right, will update this. >> >> /* Bypasses translation */ >> - if (id_out) >> - *id_out = id; >> + arg->args[0] = id; >> return 0; >> } >> EXPORT_SYMBOL_GPL(of_map_id); >> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c >> index bff8289f804a..74fc603b3f84 100644 >> --- a/drivers/pci/controller/dwc/pci-imx6.c >> +++ b/drivers/pci/controller/dwc/pci-imx6.c >> @@ -1139,12 +1139,18 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) >> { >> struct device *dev = imx_pcie->pci->dev; >> struct device_node *target; >> + struct of_phandle_args iommu_spec = { .args_count = 1 }; >> u32 sid_i, sid_m; >> int err_i, err_m; >> u32 sid = 0; >> >> target = NULL; >> - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); >> + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); >> + if (!err_i) { >> + target = iommu_spec.np; >> + sid_i = iommu_spec.args[0]; >> + } >> + >> if (target) { >> of_node_put(target); >> } else { >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c >> index a0937b7b3c4d..e1d4b37d200d 100644 >> --- a/drivers/pci/controller/pcie-apple.c >> +++ b/drivers/pci/controller/pcie-apple.c >> @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d >> { >> u32 sid, rid = pci_dev_id(pdev); >> struct apple_pcie_port *port; >> + struct of_phandle_args iommu_spec = { .args_count = 1 }; >> int idx, err; >> >> port = apple_pcie_get_port(pdev); >> @@ -764,10 +765,11 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d >> dev_dbg(&pdev->dev, "added to bus %s, index %d\n", >> pci_name(pdev->bus->self), port->idx); >> >> - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); >> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); >> if (err) >> return err; > > of_node_put(iommu_spec.np); > Sure, will add this. >> >> + sid = iommu_spec.args[0]; >> mutex_lock(&port->pcie->lock); >> >> idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0); >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c >> index 1b7696b2d762..5f1d6540049a 100644 >> --- a/drivers/xen/grant-dma-ops.c >> +++ b/drivers/xen/grant-dma-ops.c >> @@ -325,7 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, >> struct pci_dev *pdev = to_pci_dev(dev); >> u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); >> >> - if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { >> + if (of_map_iommu_id(np, rid, &iommu_spec)) { >> dev_dbg(dev, "Cannot translate ID\n"); >> return -ESRCH; >> } >> diff --git a/include/linux/of.h b/include/linux/of.h >> index 824649867810..9d72d76f909d 100644 >> --- a/include/linux/of.h >> +++ b/include/linux/of.h >> @@ -463,7 +463,7 @@ bool of_console_check(const struct device_node *dn, char *name, int index); >> >> int of_map_id(const struct device_node *np, u32 id, >> const char *map_name, const char *map_mask_name, >> - struct device_node **target, u32 *id_out); >> + struct of_phandle_args *arg); >> >> phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); >> >> @@ -929,7 +929,7 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag >> >> static inline int of_map_id(const struct device_node *np, u32 id, >> const char *map_name, const char *map_mask_name, >> - struct device_node **target, u32 *id_out) >> + struct of_phandle_args *arg) >> { >> return -EINVAL; >> } >> @@ -1458,17 +1458,24 @@ static inline int of_property_read_s32(const struct device_node *np, >> } >> >> static inline int of_map_iommu_id(const struct device_node *np, u32 id, >> - struct device_node **target, u32 *id_out) >> + struct of_phandle_args *arg) > > Document that it's the caller's responsibility to of_node_put() returned > node. As it can be seen from the previous comment, it's not obvious. > Sure, will add comment regarding this. >> { >> - return of_map_id(np, id, "iommu-map", "iommu-map-mask", >> - target, id_out); >> + return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); >> } >> >> static inline int of_map_msi_id(const struct device_node *np, u32 id, >> struct device_node **target, u32 *id_out) > > Is there a reason for chaning the of_map_iommu_id() args but not > of_map_msi_id() args? > Thanks for pointing this out. I’ll update the series to keep of_map_iommu_id() and of_map_msi_id() aligned. >> { >> - return of_map_id(np, id, "msi-map", "msi-map-mask", >> - target, id_out); >> + struct of_phandle_args msi_spec = { .np = *target, .args_count = 1 }; > > Which driver passes something being worth of storing in .np? > You're right, There is no need to store these input args. Will remove these initializations. Thanks, Vijay >> + int ret; >> + >> + ret = of_map_id(np, id, "msi-map", "msi-map-mask", &msi_spec); >> + if (!ret) { >> + *target = msi_spec.np; >> + *id_out = msi_spec.args[0]; >> + } >> + >> + return ret; >> } >> >> #define of_for_each_phandle(it, err, np, ln, cn, cc) \ >> >> -- >> 2.34.1 >> > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:34:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:34:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245188.1544572 (Exim 4.92) (envelope-from ) id 1vxicw-0001s0-Kw; Wed, 04 Mar 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 1245188.1544572; Wed, 04 Mar 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 ) id 1vxicw-0001rp-HW; Wed, 04 Mar 2026 09:34:46 +0000 Received: by outflank-mailman (input) for mailman id 1245188; Wed, 04 Mar 2026 09:34:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxicv-0001Ug-LK for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:34:45 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5fe27856-17ad-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 10:34:43 +0100 (CET) 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 6249Kun41456217 for ; Wed, 4 Mar 2026 09:34:42 GMT Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cpj1801tv-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 04 Mar 2026 09:34:42 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-354490889b6so23311371a91.3 for ; Wed, 04 Mar 2026 01:34:42 -0800 (PST) Received: from [10.219.57.109] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359a8d65b31sm500720a91.0.2026.03.04.01.34.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 01:34:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5fe27856-17ad-11f1-9ccf-f158ae23cfc8 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= eL/MxpDDt/5/2ALudUSxO1nN1iy4vdaNTzKBdYqEsSk=; b=eKEnwxk08ZSuuIb5 kLnhOzDXKxPW3zLqbJ5i4X54fIBV8ekw6WA+QDZnIeum2m6HgZKdTzX4cPzMLchr 5neNVC9YrL0B3EGsnHNgfXT05VeYt225ETdM/AVXVP7//SkXB+1NzN8TeDk5RuFC 27wO/Anxs1VGEBZa4acXnCLLVSO0dORMonWjSO3FqxuXk8a43Wx2H73d1BKdA4cE cxQQpibSkWaWAkJiWBDKtr7fW54WyW1SeY84/O6qB+m+jZ3tI0VcQa8JbqlDPGP8 LB1IrM9dcfY+1udtjPx+AYfb3o7TgoA/Gyl6T/sV5VyaqTfN5LbziEYbwNJlrEhZ gV/dBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772616882; x=1773221682; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=eL/MxpDDt/5/2ALudUSxO1nN1iy4vdaNTzKBdYqEsSk=; b=ennUz2CnSnfHhWAsZQPKMoTlyZlJOcl+ytMWVqlJCjrzijy0eFi4Ib9+ZqUdRXCmBZ 7GMwNlgjypji+YRjUTKlVWFsyJxFA2F3Yd6J0/SW+Ztf2c4RkMSBs5bMevwFn9vw/2Zv 6h+JavABYIyfZR9crcItTZ9Hvze2Zt2QxFNCmScU6fMHullPJzRhZPsBD881U5BW33cZ 9p4gaRQEsJjpJdoJb1KLW3FpV0WzqeTo4cAjhKytwcjBSPRvOcvGrvc4sitO8DDFOMth WEohUjgdX6xv/7VRzZh7/S/D4acdRMa1ljWuO7Lfb7lVE3Jf03LcX5BqG/XGYm12RNXS SDtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772616882; x=1773221682; h=content-transfer-encoding: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; bh=eL/MxpDDt/5/2ALudUSxO1nN1iy4vdaNTzKBdYqEsSk=; b=rmzfFFcVpaPlDklLhtZUS0kuX3BTP5wrM+PQdX64WvD004x1MComuMpOluYdp151tS KQ2CYuKgpa1HeSHNuqI35wzVtXf95G884k7plsV1crd42Rx2BMSmaG73/Ryo6MKNIFKY AigvAtIIVmA/0UXQ2fi/ENICwce7K3yK3HU1pPRZ4AZBsiTaHUr0PuSOuOhoeP0ydijZ riVx2fwgPTJmyrmGHZO3rlh0pbPBScl8/K15RuODGWekuFB2IFWw0B+9W8TJWWsK0+EE W17ZpiuGl9WIbocA/JWkyPmSI2TE69kKi/OFe/5NdRhysqM9LfBbFahlhcVbQZHBaUc8 rWKw== X-Forwarded-Encrypted: i=1; AJvYcCWuslrIOsmXuHK1N0mfoiPbwl1+4LhmUePGqbyt+2PwKk3CnvnUA9vV1istBLK79g6io2Yv5s/xlhI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxBgtl5Qn1kKnpSmKlm+1UKG0QMqe4FJbhYBs10IvsEWUUzW+NT Fudz3XPpjHYAgrWaW63hWwenN4BzAwYXwz4LlZ2UFvM6ZgX6Dn3Yyxi7o7sJQ6pVgUfiFNySGn0 r49wzYVbLbEAJQ8qPylLavS9Bru75/75WTOjzGtOR0hasLeRhAWCQLO3BZcBy5+xAJc3rxA== X-Gm-Gg: ATEYQzzm1DsrKmEqLktGKreb0POrpKchuBNEicZkUvejojB8ywTz13yPXhMYfno6q/i I04VVc3SjCG3REzentz1+iZ3LELXPB5c5XC99eMVW3+KatiaBzJj4agrVfbHX6GDqYJ6FpQ+LxE 4eaVe1MmRZhr2Cg/7XnB7WH4YmpGeXGHX0orpvaZn3jrxqB0QvctuAMvnU9DmTab1W2G0aM+/xd 6xwPKaHRH2qOShtQkAjVc79SsS5NPBv7ISE9137EcGti2ktdsQH2aoxYAsPCjDHgE3eGYrBPrKY 9U4wXcql8PVkod2aa6JJN96QIyrkXZpYM40FVu76LSQhror/RuhAerEmGM9BVMXPAfWIw1saz/W eRamQPtZ2sIfXHa5yLWdVeBfqtqJ525uWPEl6NMINyDZZRR6wKNS1c5P7 X-Received: by 2002:a17:90b:5784:b0:359:8cad:bcdc with SMTP id 98e67ed59e1d1-359a69d6372mr1471625a91.10.1772616881617; Wed, 04 Mar 2026 01:34:41 -0800 (PST) X-Received: by 2002:a17:90b:5784:b0:359:8cad:bcdc with SMTP id 98e67ed59e1d1-359a69d6372mr1471607a91.10.1772616881094; Wed, 04 Mar 2026 01:34:41 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 15:04:30 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 2/3] of: factor arguments passed to of_map_id() into a struct To: Dmitry Baryshkov Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-2-4d1bceecc5e1@oss.qualcomm.com> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: XspXn515PnmnapL6GL7n1AZwCDAJaH6V X-Proofpoint-ORIG-GUID: XspXn515PnmnapL6GL7n1AZwCDAJaH6V X-Authority-Analysis: v=2.4 cv=Ed7FgfmC c=1 sm=1 tr=0 ts=69a7fcb2 cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=kVzFkbBwBCoyR44kgfkA:9 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDA3MiBTYWx0ZWRfXxxBom8ZN0eMZ ispw6LZFd724n/Lb2bSCbI97PalpwYGNviVBwg7V8X8l4atLFg0FwPvWFsZJloDKzV2QEVu5648 Zy6euuaAcfJEMSPdJVoP6LQO7GVQ+fjiBBtAtmcdvFl78flzK/iNMkkzUaDkgefRmlsGLqx3/Ub ngTtzPCpmakoFZ8Ssh6/7RAeww2VoljqT/CUdAQBQ4Ec1293HyjbosEj7pZ8lsoOt5bSOC9mnR9 nTRK4TDmtFvZOrWk4HP5vQO+0NPmh2q839jWIGBoHWbfHKt74N+xh81o1Lh8zUUSgz2OTdXT8H8 GySTwTgwkP0JHDdx0ztdDmvHPdUbTaWO2KyoMJg1GWedBVEyWA67oLDDvlnssE94LCZcG1AjovK LxZhbCP5F+gRna1r5FrkBazyN4FuqbcK2QVt70Fq5+z4bQkeyziyRDsLuoIuD7Mk0okte1aHNiX OwAgJ37QruQsmGpyAzA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040072 On 3/1/2026 4:29 PM, Dmitry Baryshkov wrote: > On Sun, Mar 01, 2026 at 02:04:20PM +0530, Vijayanand Jitta wrote: >> From: Charan Teja Kalla >> >> Change of_map_id() to take a pointer to struct of_phandle_args >> instead of passing target device node and translated IDs separately. >> Update all callers accordingly. >> >> Subsequent patch will make use of the args_count field in >> struct of_phandle_args. >> >> Suggested-by: Rob Herring (Arm) >> Signed-off-by: Charan Teja Kalla >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/iommu/of_iommu.c | 2 +- >> drivers/of/base.c | 37 +++++++++++++++++------------------ >> drivers/pci/controller/dwc/pci-imx6.c | 8 +++++++- >> drivers/pci/controller/pcie-apple.c | 4 +++- >> drivers/xen/grant-dma-ops.c | 2 +- >> include/linux/of.h | 21 +++++++++++++------- >> 6 files changed, 44 insertions(+), 30 deletions(-) >> >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c >> index a0937b7b3c4d..e1d4b37d200d 100644 >> --- a/drivers/pci/controller/pcie-apple.c >> +++ b/drivers/pci/controller/pcie-apple.c >> @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d >> { >> u32 sid, rid = pci_dev_id(pdev); >> struct apple_pcie_port *port; >> + struct of_phandle_args iommu_spec = { .args_count = 1 }; > > Hmm, I didn't notice this. Parsing functions are expected to ignore > of_phandle_args before the parsing. So passing .args_count = 1 is > strange. > You're right, This is not required. I'll remove these initializations in next series. Thanks, Vijay >> int idx, err; >> >> port = apple_pcie_get_port(pdev); > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:35:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:35:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245201.1544582 (Exim 4.92) (envelope-from ) id 1vxidR-0002WW-Rw; Wed, 04 Mar 2026 09:35:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245201.1544582; Wed, 04 Mar 2026 09:35:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxidR-0002WO-P7; Wed, 04 Mar 2026 09:35:17 +0000 Received: by outflank-mailman (input) for mailman id 1245201; Wed, 04 Mar 2026 09:35:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxidQ-0001p4-6i for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:35:16 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 71bcb6dd-17ad-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 10:35:14 +0100 (CET) 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 6245TGeh1679276 for ; Wed, 4 Mar 2026 09:35:12 GMT Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cp73ha95s-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 04 Mar 2026 09:35:12 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-c70f137aa4aso3935512a12.2 for ; Wed, 04 Mar 2026 01:35:12 -0800 (PST) Received: from [10.219.57.109] ([202.46.23.19]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c73790f881esm1186795a12.10.2026.03.04.01.35.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 01:35:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 71bcb6dd-17ad-11f1-b164-2bf370ae4941 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= t80u5LhNs8dedbnLQe3vnPgp0bI1VMt5bD83HvKUNdE=; b=g1/MgbWp9GnnXzTd dYgjmB5pE0P9xO0EdT20U1vIXpi5wS3RFe61V/EBK+qRPr9eONuDqjb9UYV2umU/ XCP7CoOKVrwU57sHnaAy4LUA4efHqaLUfjweLNBhhI7Q2qzZR8QazjyrvWniEyPb QQYK28Z1sRZka2ZE29KDYJXFNg/0EdRPi/TmeNbb4jH6w3G5fmFZKHC+H/PiUrdc PTgx64nHg5jzDRyyzQ51s1Le/VaT5IGp7W8hsfQ7Yb6zp3JOAUrD3gO0jK5zYDmi 9lS2S2AOKeuSXQde+RvkHYShPDF/QlA7jTobiMPM3THAv1Ntk1wMS10nDiGYvKV5 Hm/DGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772616912; x=1773221712; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=t80u5LhNs8dedbnLQe3vnPgp0bI1VMt5bD83HvKUNdE=; b=BII/8yAkyBbmFkPTGyuSFcqj4pFgi9dfWM2SQ5ZmWXAFxh9vXEM9cQs9AbkvNH6BkV KL874RIZmQTLxh6xukjolnlazzx0xeUXbJw656UBNNRvf+D7NnhQi4PRePCIBb99vahp FGcTDxUxsmy494iayct4UHMfM0d0UoNaMC1XqDhWFmwvHcKABRCrHfWT0pLuBpOIUmv1 koM2DECMdLAFfS27sF31J3pE3zuI47qOwZ8L82TKH7VsHGcjbvv0TDizf6E9ElBreu/b Cnm0JfjcXqvwtM2dhicwmGHKDiQSEXj+wxVMjpdfz0gofdsBoKoJFZSiKUj+1R3lsEYK KcOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772616912; x=1773221712; h=content-transfer-encoding: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; bh=t80u5LhNs8dedbnLQe3vnPgp0bI1VMt5bD83HvKUNdE=; b=rn1poLbPXeTnQGW9wAze76Vli0JZFZ/Cznk8U6unaJFTtXwun8m91aP2XWOKkuuQbL GkluF8C8BneNiBA5e1uQaeVGQQ4ST6B9FP/vR8Z7/Zo7ZaOnWZgGjQCcg/HO5zPLmTyI 053D5A2Wt6HHvTVrxPMLbtys5tLZUHzLVcAXITLQAGPo/cPiFbTsPBjkcMmDO5i5psgk 0+Ax81QwSeqlpkF82ZWz34eIoHDRILRX15yDgvmeqIsd4BQtfxf1P02DgegGpgnMqb82 /lF7mJ+2ZceRJ+BHd7QtJJu0ipFIzY1OVsJc1T7OC+vgWwlEevRr79j84yEYE6QprZti sBUg== X-Forwarded-Encrypted: i=1; AJvYcCUYvu4Kjs/7DMWVtNSnwsmhjLM6lXAlV3N3ZDfO/BbqOXTqt9JVgWvFgAbG0NhRguq98KXD9HgfqKo=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy3iBvf+jB32ceqx0At695JlnoYcxnzEJyRkxXV9ZLv+YBbIrGK gH0qVTB85uuYnmiSvsMAMEJ37IGf/D46L814sRFRFDUGsDkXILfZcY0R2H+7mp/xpe0B0TUcP2P 2JB3fRqXTBlczIbyQaBKbOc083T96X+peUV5/Xac+3VH3+f8k0xOyRgERGKt4QoVhFMzG0A== X-Gm-Gg: ATEYQzzs0F4MEFCfRBLTKON1rdIwpIjmkzf96ejFNBBvfaSfoeAW0O1MRRe5c1mJn6h eUhVXsmwvIa9kEe8nrKbTRlEVpnu3QrmxHXX1j5SSI+thg6g8z7jDcfmwtZa2PKGmJ9asEH4Yzk qDlLD7GEZy9rrD7nCvExPf4/MrpxkgKKj5bip+19Yzby/hSUl/AJWtFvgPq3nQY47Pp6wied70h 9tZfZ1UnJvITyZLOMPrfNMWUCoVuOaT3hjK2KTyFqKVWMwSc3rGlO1XbpOluS76VBK0ZO+KcOkm KRMFV+I06L8QjGmyxP14j8vfshbm4/65omeCYMK0M0H3YqnJ1uNxRLPpRWowLLlni/QnhAiWgIw T28KC7cf1N91eiKUv7qOACtWCGmR2nzbTibZw3wB5dmnGUKKpRuncrp2Q X-Received: by 2002:a05:6a21:608a:b0:35b:9ba2:8cd5 with SMTP id adf61e73a8af0-3982e2036d4mr1560336637.56.1772616911557; Wed, 04 Mar 2026 01:35:11 -0800 (PST) X-Received: by 2002:a05:6a21:608a:b0:35b:9ba2:8cd5 with SMTP id adf61e73a8af0-3982e2036d4mr1560306637.56.1772616910991; Wed, 04 Mar 2026 01:35:10 -0800 (PST) Message-ID: <9aa4c1d3-713e-4137-8042-a73bea8e8f34@oss.qualcomm.com> Date: Wed, 4 Mar 2026 15:04:59 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v9 3/3] of: Respect #{iommu,msi}-cells in maps To: Dmitry Baryshkov Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-3-4d1bceecc5e1@oss.qualcomm.com> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: gl-nuMCTUihnsaDRqu-7thYD4wiimU3o X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDA3MiBTYWx0ZWRfX7Y/fPWeiWDGa IYW3syFEoAjVe2OtnCmYrrVwMdOB3HtTeamV19XnP5jQRTtiGLo0dw1tS1zxz3Kp01dXGkgQ1Ww 2VtVf7W8zd2sjH1WXROe1npXT5FK306XWno2i6MSvJmMyxdQD9U0o3FJ2lKoZNFymGPvBrnNkkE k2GgfOE78hXeA7pbIQUJEJBit8k3lFivTYBdwcRuX/EUplZ4d0sM8nGbbADmJInPxqIheV+zDdn b14Kn6AH6AM5jV4n5vMbmhhfVxUJasusSY9QvbmPqMdn3G3EXEDo3faXwDnWfPYg+edrBgvAg47 ec6EGz3oW1C0yls1J/UdRESo2yODBpWlQM6yoQlAzrv5ak1x5FDBNwTeSYvcaWXvzOF3bIH5hlo /YRFzoNeyri4v9cCBBFYfpA5txkyxjPDZv/mPmJxP/WJGU0mwyLgV2uUKQl2wJXv+2pL27SjKUE Ge6CFGWgeXABRORpKFg== X-Proofpoint-ORIG-GUID: gl-nuMCTUihnsaDRqu-7thYD4wiimU3o X-Authority-Analysis: v=2.4 cv=BpWQAIX5 c=1 sm=1 tr=0 ts=69a7fcd0 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=j4ogTh8yFefVWWEFDRgCtg==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=7CQSdrXTAAAA:8 a=EUspDBNiAAAA:8 a=FlLgGEtdp7AnL9SkOqcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_05,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 bulkscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 phishscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040072 On 3/1/2026 3:44 PM, Dmitry Baryshkov wrote: > On Sun, Mar 01, 2026 at 02:04:21PM +0530, Vijayanand Jitta wrote: >> From: Robin Murphy >> >> So far our parsing of {iommu,msi}-map properites has always blindly >> assumed that the output specifiers will always have exactly 1 cell. >> This typically does happen to be the case, but is not actually enforced >> (and the PCI msi-map binding even explicitly states support for 0 or 1 >> cells) - as a result we've now ended up with dodgy DTs out in the field >> which depend on this behaviour to map a 1-cell specifier for a 2-cell >> provider, despite that being bogus per the bindings themselves. >> >> Since there is some potential use in being able to map at least single >> input IDs to multi-cell output specifiers (and properly support 0-cell >> outputs as well), add support for properly parsing and using the target >> nodes' #cells values, albeit with the unfortunate complication of still >> having to work around expectations of the old behaviour too. >> >> Since there are multi-cell output specifiers, the callers of of_map_id() >> may need to get the exact cell output value for further processing. >> Added support for that part --charan >> >> Signed-off-by: Robin Murphy >> Signed-off-by: Charan Teja Kalla >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/iommu/of_iommu.c | 2 +- >> drivers/of/base.c | 117 +++++++++++++++++++++++++++++++++++++---------- >> include/linux/of.h | 16 +++---- >> 3 files changed, 102 insertions(+), 33 deletions(-) >> > >> /** >> * of_map_id - Translate an ID through a downstream mapping. >> * @np: root complex device node. >> * @id: device ID to map. >> * @map_name: property name of the map to use. >> + * @cells_name: property name of target specifier cells. >> * @map_mask_name: optional property name of the mask to use. >> * @arg: of_phandle_args structure, >> * which includes: >> @@ -2118,18 +2145,19 @@ int of_find_last_cache_level(unsigned int cpu) >> * >> * Return: 0 on success or a standard error code on failure. >> */ >> -int of_map_id(const struct device_node *np, u32 id, >> - const char *map_name, const char *map_mask_name, >> - struct of_phandle_args *arg) >> +int of_map_id(const struct device_node *np, u32 id, const char *map_name, >> + const char *cells_name, const char *map_mask_name, >> + struct of_phandle_args *arg) > > Some extra whitespace-related noise in here. Last line wasn't changed, > so there is no need to touch it. > Thanks for pointing this, Will fix it in next series. >> { >> u32 map_mask, masked_id; >> - int map_len; >> + int map_bytes, map_len, offset = 0; >> + bool bad_map = false; >> const __be32 *map = NULL; >> >> if (!np || !map_name || !arg) >> return -EINVAL; >> >> - map = of_get_property(np, map_name, &map_len); >> + map = of_get_property(np, map_name, &map_bytes); >> if (!map) { >> if (arg->np) >> return -ENODEV; >> @@ -2138,11 +2166,9 @@ int of_map_id(const struct device_node *np, u32 id, >> return 0; >> } >> >> - if (!map_len || map_len % (4 * sizeof(*map))) { >> - pr_err("%pOF: Error: Bad %s length: %d\n", np, >> - map_name, map_len); >> - return -EINVAL; >> - } >> + if (map_bytes % sizeof(*map)) >> + goto err_map_len; >> + map_len = map_bytes / sizeof(*map); >> >> /* The default is to select all bits. */ >> map_mask = 0xffffffff; >> @@ -2155,27 +2181,63 @@ int of_map_id(const struct device_node *np, u32 id, >> of_property_read_u32(np, map_mask_name, &map_mask); >> >> masked_id = map_mask & id; >> - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { >> + >> + while (offset < map_len) { >> struct device_node *phandle_node; >> - u32 id_base = be32_to_cpup(map + 0); >> - u32 phandle = be32_to_cpup(map + 1); >> - u32 out_base = be32_to_cpup(map + 2); >> - u32 id_len = be32_to_cpup(map + 3); >> + u32 id_base, phandle, id_len, id_off, cells = 0; >> + const __be32 *out_base; >> + >> + if (map_len - offset < 2) >> + goto err_map_len; >> + >> + id_base = be32_to_cpup(map + offset); >> >> if (id_base & ~map_mask) { >> - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n", >> - np, map_name, map_name, >> - map_mask, id_base); >> + pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n", >> + np, map_name, map_mask_name, map_mask, id_base); >> return -EFAULT; >> } >> >> - if (masked_id < id_base || masked_id >= id_base + id_len) >> - continue; >> - >> + phandle = be32_to_cpup(map + offset + 1); >> phandle_node = of_find_node_by_phandle(phandle); >> if (!phandle_node) >> return -ENODEV; >> >> + if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) { >> + pr_err("%pOF: missing %s property\n", phandle_node, cells_name); >> + return -EINVAL; >> + } > > This will trigger the cells_name property check even if later we > discover that we have a "bad" map. Is it intended / required? > It’s intended. We need the cells value here because determining whether a map is “bad” depends on it, as mentioned in description of of_check_bad_map this is specifically for the case where the DT has an iommu-map pointing to a 2‑cell IOMMU node but only provides 1 cell in the map entry. >> + >> + if (map_len - offset < 3 + cells) > > of_node_put(phandle_node); > >> + goto err_map_len; >> + >> + if (offset == 0 && cells == 2) { > > ... if it's not required, then the bad_map check can be moved before the > loop. > Given that, the bad_map check can’t be moved before the loop, because we only call of_check_bad_map() when cells == 2. >> + bad_map = of_check_bad_map(map, map_len); >> + if (bad_map) { >> + pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n", >> + np, map_name, cells_name); >> + cells = 1; >> + } >> + } >> + >> + out_base = map + offset + 2; >> + offset += 3 + cells; >> + >> + id_len = be32_to_cpup(map + offset - 1); >> + if (id_len > 1 && cells > 1) { >> + /* >> + * With 1 output cell we reasonably assume its value >> + * has a linear relationship to the input; with more, >> + * we'd need help from the provider to know what to do. >> + */ >> + pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n", >> + np, map_name, id_len, cells); >> + return -EINVAL; >> + } >> + id_off = masked_id - id_base; >> + if (masked_id < id_base || id_off >= id_len) >> + continue; >> + >> if (arg->np) >> of_node_put(phandle_node); >> else >> @@ -2184,11 +2246,14 @@ int of_map_id(const struct device_node *np, u32 id, >> if (arg->np != phandle_node) >> continue; >> >> - arg->args[0] = masked_id - id_base + out_base; >> + for (int i = 0; i < cells; i++) >> + arg->args[i] = (id_off + be32_to_cpu(out_base[i])); >> + >> + arg->args_count = cells; >> >> pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", >> - np, map_name, map_mask, id_base, out_base, >> - id_len, id, masked_id - id_base + out_base); >> + np, map_name, map_mask, id_base, be32_to_cpup(out_base), >> + id_len, id, id_off + be32_to_cpup(out_base)); > > Again, having whitespace changes doesn't simplify reviewing. > Will fix this in next series. Thanks, Vijay >> return 0; >> } >> >> @@ -2198,5 +2263,9 @@ int of_map_id(const struct device_node *np, u32 id, >> /* Bypasses translation */ >> arg->args[0] = id; >> return 0; >> + >> +err_map_len: >> + pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes); >> + return -EINVAL; >> } >> EXPORT_SYMBOL_GPL(of_map_id); > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:39:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:39:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245220.1544592 (Exim 4.92) (envelope-from ) id 1vxihr-0003Yd-Fs; Wed, 04 Mar 2026 09:39:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245220.1544592; Wed, 04 Mar 2026 09:39:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxihr-0003YW-DI; Wed, 04 Mar 2026 09:39:51 +0000 Received: by outflank-mailman (input) for mailman id 1245220; Wed, 04 Mar 2026 09:39:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxihp-0003YK-DR for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:39:49 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 142f61de-17ae-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 10:39:46 +0100 (CET) Received: from MN2PR19CA0011.namprd19.prod.outlook.com (2603:10b6:208:178::24) by DS0PR12MB7701.namprd12.prod.outlook.com (2603:10b6:8:133::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 09:39:40 +0000 Received: from BL6PEPF0001AB4D.namprd04.prod.outlook.com (2603:10b6:208:178:cafe::a1) by MN2PR19CA0011.outlook.office365.com (2603:10b6:208:178::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.22 via Frontend Transport; Wed, 4 Mar 2026 09:39:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB4D.mail.protection.outlook.com (10.167.242.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 4 Mar 2026 09:39:40 +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.17; Wed, 4 Mar 2026 03:39:39 -0600 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.17; Wed, 4 Mar 2026 01:39:39 -0800 Received: from XIR-MICHALO-L1.xilinx.com (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 4 Mar 2026 03:39:38 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 142f61de-17ae-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L6jq/dXyVjlvypLOSHux/j2bTfTLJY6CZ/cGvdfdnEOOVeQl0q0AjECWX2S5pQ7oZk/eqwou1Gv5mOAtCCR8jTpAl80iF12dhjwr2j12YK6ohPix1mEnd2r+Jp4ImzB/+Gx1qUo5wp4VqzZ7UvD66FHMrWJX5HJepOxRc31GF0EL7uGJEj3tF61e1NTzzVHvpod/b+AxrY9Q52s6oYsXTP0KVXhPy+KNi0QJi7BfBIA/SBrpeZzT/vyhyw5o6zLlgoZGGbYFq5bYVT2XZHM5G88POKT9EzcIpQV8G13wsYgG3TN8NiJJeqYeb4qDe1szV5xZgFNFE8c7Sk3OEDNX/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=5HQu2M+0XHijYHerBIMV7/hGMJZUp9enctuOgoOndY8=; b=fwlVcU2ypkmmkM7ZyWR8eC/bWnoF2zMzoHktik/fHh3ItozMPAOmDCPLyPpzuZvS/LBnwKR1HOpOj4QhCFpIfnCL1HZSo3CIPTF4SwM6aTW6gq6K3Cg4EzkRtVf4lOh62UWsNerdFgR/hfpZhxHnTtwbcHy1I1VeFwpzwZVlg8QsaKrRIREwRuveh3crhOEuK7v4fk/6pKhgijUaUxxsxO25Fc1NfgNS/I8dFY/OjDwHl9n5SQ1lMZiEqTPT4NH0Qe2G505RlaMuPT3wWAh8XrwJYqSVeKi3EespII64eoBxbkkB/3ovW2JQ/bi1CfKZotXuCbXIyCeUl95WEr1sRA== 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=5HQu2M+0XHijYHerBIMV7/hGMJZUp9enctuOgoOndY8=; b=hmu5kVqc6g4xzKcNhm9fsb152ZocRME9SbSN2YOGMpB2FkLjLJiUOY2mPu3a50A6rS/8sYw6uKQ9Jm0ey+NSYUDMWWnfJnarELQP+VSk47vMRYycuvpYo22EszYAgF2g0E5kF8AUaK3hHG3oOCGjFwgJNGw0h8zQe/qg8sbMIbQ= 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 To: CC: Michal Orzel , Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk Subject: [PATCH v2] arm/mm: Fix resource handling in xenmem_add_to_physmap_one Date: Wed, 4 Mar 2026 10:39:23 +0100 Message-ID: <20260304093923.14293-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: BL6PEPF0001AB4D:EE_|DS0PR12MB7701:EE_ X-MS-Office365-Filtering-Correlation-Id: 7fccc3d3-e1c7-47cd-6857-08de79d1f52e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: d/4vmiIJ7oH3DeVwJkwLjlekR94sGlpT90yi55KecnApcmtSaJPZbSFH2vDfHgKSwHAR6HtzrtyDTHN5zFIgw4whHFSfz/Vwetqbd2tQ6RI+ODrp8zdykY70cob1ixbQJLONS8JykPrRjFuS+vh0nxoJqBp9HCc73hqeQeD+FKuxgByQSxCESmc/MzKi4L1FLucUDAoDisj2G47lurTuP32mW+sFQGo4NabXlxzbR42m4EAJ5AE1bSPYZUdTWIHd1EjVvR+ARpa7niNJxf6/7DUJMKl+iS1rCrwoJRLAbZ+BZ8CZEM0/InmCl+QOkILYmbhyr49OGRttxNIllgVhqAjeGZnwOWatdRHYy70SQOk7iIwT9Om4q8QLksTIP0PpsYrGVUxjsmgtRIJgChPGSKYEkBtiZc/Xczc5NBscA+lM9xsFoCOJpHdpWNAJY8viKaPiGsCtLly5gsBNhfbOg1uQ6w7X3hnRBYJ0Gh8jIvaDcnu9ugggj7amZ1B/1AneRTC6bSJKpcKxmHpNI9Dbk8grnUImG6OAt9ZIS8Zb9J6AXpbPdnDR6BxNobHvkm6xJPPWhc/xrtBeUy0fbxzKO3PY5QmtkMWzdt/ow1FYdwNGeN2O7GC5TsOCL5c+ebVWsa5dmeM5GYCCebUG6YkMXIyqPTAR5V4XSA2IsuMDfwPa/sLPrd1SFbY3O76p+NlO++zia7q57abB7Wf0cVbLvcoHp5hyskEkHBL8ttyuweFQKjMUvNzcj12sc9RGq264KGq6cP8shUX8w5SlAo334A== 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)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: AhwGVb3skTKE/FeJrQLeNpYDgXuvEnIcO4Ywy8EcQ0mtkv82jriXHS5/KabXkWLWsb6J3dWp5s22AXd7HLnWs8C0Zsv9aPyWDkRk4lquuBcUnV7XdbSyzFV5wmYv5Gv7TfabSV9MW+BkTMji+IAeGCSty0FjyJfVOco6/okWJBQnSEulmyMFpYgqa/+8/FI5EwI1A/dyQvhdsrKYzVa18Sn13fCh4vCWeHgMCACSHhWcs6IzIVFBDAnhKF5XbZlj6hgcCK9pBYm2wsmypSwfe7zdQ+MQVjsRDXopLBdMhfuM0ON0zYOPPtDJu/RV1pRNig7XPBn17fuVkN3wlUcyi8V4kalQHItPZxomvojcOdqPMhisBi08ZPjpRzbE5iqeNnDAXuTjVC4RuRnKPlHImiX6Wv1nfZVO81Nk5GdPoD3lcfvRsvvApuhJpTrYutbD X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 09:39:40.1421 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7fccc3d3-e1c7-47cd-6857-08de79d1f52e 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: BL6PEPF0001AB4D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB7701 The current implementation of xenmem_add_to_physmap_one() does not check for or remove existing mappings at the target GFN before inserting new mappings. This can lead to pages not being properly freed (until domain destruction) when replaced. Add a proper old mapping detection and cleanup: * Check for existing mappings at the target GFN before insertion * For special pages: unmap without freeing (not owned by domain) * For MMIO mappings: reject with -EPERM (questionable) * For grant mappings: reject with -EPERM (cleanup not implemented in p2m_put_l3_page) * For RAM and foreign mappings: properly remove via guest_remove_page() * Optimize same-MFN remapping: detect and return early (no-op) Fix XENMAPSPACE_dev_mmio by inlining its permission check and logic into the main switch statement, allowing it to go through the same cleanup path as other mapping types. This removes the early return that bypassed cleanup. The now-unused map_dev_mmio_page() function is removed. Foreign mappings are allowed to be removed (matching x86 behavior) because proper cleanup via p2m_put_foreign_page() is already implemented in p2m_put_l3_page(). Grant mappings are rejected because cleanup is not yet implemented. Add new helpers p2m_is_grant() and p2m_is_mmio(). Note: There are race conditions due to multiple P2M lock/unlock cycles during the check-remove-insert sequence. These are documented and subject to future improvements. Signed-off-by: Michal Orzel --- Changes in v2: - handle all the spaces - drop references - add a comment about races (not handled in this attempt) guest_remove_page would work on MMIO, but for now I decided to take a conservative approach and reject it. --- xen/arch/arm/include/asm/p2m.h | 9 ++++- xen/arch/arm/mm.c | 73 +++++++++++++++++++++++++++++++--- xen/arch/arm/p2m.c | 18 --------- 3 files changed, 74 insertions(+), 26 deletions(-) diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h index 010ce8c9ebbd..d88f4f65c7bc 100644 --- a/xen/arch/arm/include/asm/p2m.h +++ b/xen/arch/arm/include/asm/p2m.h @@ -149,6 +149,11 @@ static inline p2m_type_t arch_dt_passthrough_p2m_type(void) #define P2M_RAM_TYPES (p2m_to_mask(p2m_ram_rw) | \ p2m_to_mask(p2m_ram_ro)) +/* MMIO types */ +#define P2M_MMIO_TYPES (p2m_to_mask(p2m_mmio_direct_dev) | \ + p2m_to_mask(p2m_mmio_direct_nc) | \ + p2m_to_mask(p2m_mmio_direct_c)) + /* Grant mapping types, which map to a real frame in another VM */ #define P2M_GRANT_TYPES (p2m_to_mask(p2m_grant_map_rw) | \ p2m_to_mask(p2m_grant_map_ro)) @@ -159,6 +164,8 @@ static inline p2m_type_t arch_dt_passthrough_p2m_type(void) /* Useful predicates */ #define p2m_is_ram(_t) (p2m_to_mask(_t) & P2M_RAM_TYPES) +#define p2m_is_mmio(_t) (p2m_to_mask(_t) & P2M_MMIO_TYPES) +#define p2m_is_grant(_t) (p2m_to_mask(_t) & P2M_GRANT_TYPES) #define p2m_is_foreign(_t) (p2m_to_mask(_t) & P2M_FOREIGN_TYPES) #define p2m_is_any_ram(_t) (p2m_to_mask(_t) & \ (P2M_RAM_TYPES | P2M_GRANT_TYPES | \ @@ -318,8 +325,6 @@ int unmap_regions_p2mt(struct domain *d, unsigned long nr, mfn_t mfn); -int map_dev_mmio_page(struct domain *d, gfn_t gfn, mfn_t mfn); - int p2m_insert_mapping(struct domain *d, gfn_t start_gfn, unsigned long nr, mfn_t mfn, p2m_type_t t); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 6df8b616e464..0cee65d5ab5a 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -166,10 +167,11 @@ int xenmem_add_to_physmap_one( unsigned long idx, gfn_t gfn) { - mfn_t mfn = INVALID_MFN; + mfn_t mfn = INVALID_MFN, mfn_old; int rc; - p2m_type_t t; + p2m_type_t t, p2mt_old; struct page_info *page = NULL; + struct p2m_domain *p2m = p2m_get_hostp2m(d); switch ( space ) { @@ -237,13 +239,73 @@ int xenmem_add_to_physmap_one( break; } case XENMAPSPACE_dev_mmio: - rc = map_dev_mmio_page(d, gfn, _mfn(idx)); - return rc; + if ( !iomem_access_permitted(d, idx, idx) ) + return 0; + + mfn = _mfn(idx); + t = p2m_mmio_direct_c; + break; default: return -ENOSYS; } + /* + * Release the old page reference if it was present. + * + * TODO: There are race conditions in this code due to multiple lock/unlock + * cycles: + * + * Race #1: Between checking the old mapping and removing it, another CPU + * could replace the mapping. We would then remove the wrong mapping. + * + * Race #2: Between removing the old mapping and inserting the new one, + * another CPU could insert a different mapping. We would then silently + * overwrite it. + * + * For now, we accept these races as they require concurrent + * xenmem_add_to_physmap_one operations on the same GFN, which is not a + * normal usage pattern. + */ + p2m_read_lock(p2m); + mfn_old = p2m_get_entry(p2m, gfn, &p2mt_old, NULL, NULL, NULL); + p2m_read_unlock(p2m); + + if ( mfn_valid(mfn_old) && !mfn_eq(mfn, mfn_old) ) + { + if ( is_special_page(mfn_to_page(mfn_old)) ) + { + /* Just unmap, don't free */ + p2m_write_lock(p2m); + rc = p2m_set_entry(p2m, gfn, 1, INVALID_MFN, + p2m_invalid, p2m->default_access); + p2m_write_unlock(p2m); + if ( rc ) + goto out; + } + else if ( p2m_is_mmio(p2mt_old) || p2m_is_grant(p2mt_old) ) + { + /* Reject MMIO and grant replacements */ + rc = -EPERM; + goto out; + } + else + { + /* Allow RAM and foreign - both have proper cleanup */ + rc = guest_remove_page(d, gfn_x(gfn)); + if ( rc ) + goto out; + } + } + else if ( mfn_valid(mfn_old) ) + { + /* Mapping already exists. Drop the references taken above */ + if ( page != NULL ) + put_page(page); + + return 0; + } + /* * Map at new location. Here we need to map xenheap RAM page differently * because we need to store the valid GFN and make sure that nothing was @@ -255,8 +317,6 @@ int xenmem_add_to_physmap_one( rc = guest_physmap_add_entry(d, gfn, mfn, 0, t); else { - struct p2m_domain *p2m = p2m_get_hostp2m(d); - p2m_write_lock(p2m); if ( gfn_eq(page_get_xenheap_gfn(mfn_to_page(mfn)), INVALID_GFN) ) { @@ -276,6 +336,7 @@ int xenmem_add_to_physmap_one( p2m_write_unlock(p2m); } + out: /* * For XENMAPSPACE_gmfn_foreign if we failed to add the mapping, we need * to drop the reference we took earlier. In all other cases we need to diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index fb03978a19af..c91568926e4c 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -200,24 +200,6 @@ int unmap_mmio_regions(struct domain *d, return p2m_remove_mapping(d, start_gfn, nr, mfn); } -int map_dev_mmio_page(struct domain *d, gfn_t gfn, mfn_t mfn) -{ - int res; - - if ( !iomem_access_permitted(d, mfn_x(mfn), mfn_x(mfn)) ) - return 0; - - res = p2m_insert_mapping(d, gfn, 1, mfn, p2m_mmio_direct_c); - if ( res < 0 ) - { - printk(XENLOG_G_ERR "Unable to map MFN %#"PRI_mfn" in %pd\n", - mfn_x(mfn), d); - return res; - } - - return 0; -} - int guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t mfn, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 09:57:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 09:57:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245241.1544630 (Exim 4.92) (envelope-from ) id 1vxiyr-0007BS-7o; Wed, 04 Mar 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 1245241.1544630; Wed, 04 Mar 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 ) id 1vxiyr-0007BL-3o; Wed, 04 Mar 2026 09:57:25 +0000 Received: by outflank-mailman (input) for mailman id 1245241; Wed, 04 Mar 2026 09:57:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxiyq-0007BC-7l for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 09:57:24 +0000 Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [2607:f8b0:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 89773025-17b0-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 10:57:22 +0100 (CET) Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-7d4c307db9aso4228262a34.3 for ; Wed, 04 Mar 2026 01:57:22 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 89773025-17b0-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1772618241; cv=none; d=google.com; s=arc-20240605; b=l1PuMxzQteA966OJCLvlfkBgRV7o6qV1ZozuZRmQnUbBKg+jDaZxeJEKM5f1I5NX3O SmoW3hLEpMfS5uo+GlVVy6hm7ztJ/iehmhHdbT6CSYgjpzwAkVGEGev6/1w01WgTQNEQ mM0oWl3xIiUygpL1eK2YegaDt+Ny/aGE8WnPp5+8uDLdUM34idAhZgejypcctj5jI46G 8WdCh6gPkSyuxAni+osuw8d0YWJlAUz69QGmgRhyJ71TfYi0C86/RL7MpXYHgXOoQB4i Ur1uyHosYhSR3jMF9xaqleEoNyUSlc1LaI00lwiNJdZv5aneEMxx/XlYTCDiTBS8jPUF AsDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=NJrv+HwIDbQuRAZOh72iXVEhQflBFsynWIP/XUoI34s=; fh=wNLC6Hyb5Ukz/ErppBRQBwv8vwa/OMsdh6R8bnNsiPU=; b=do9ni7nGjwR5h1EoJTZmLjV5VSNSN11cAA4C62E5MPMdB1cgS5I+6ImoD7/UVWdrKe /Jzf3x8E28VcwIJBvNTmZsQFGqJYnYMKmbkpYgE3q5k6vrh72NR0rtniC6IJkLfrMuSJ /kPtD8nk9D8aSfgyQJOcXb1HH/ca4S5WC6idXEfT6svFYcLO2GTkFImo897vbFE8YESJ iWxlkw9of0QiKF1xrIAYzvcfwTmZAGppMLKj3SM6Av6cD6J3gn0ltrFdpJ1gS3HVMxgF 0X1Z4HsDu9EEa2FZO3a2XYjiWg14kICFowpO0xho/ETrAKpzDXA6/ROTJWzHJ4a+yOrC R8dQ==; 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=1772618241; x=1773223041; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NJrv+HwIDbQuRAZOh72iXVEhQflBFsynWIP/XUoI34s=; b=t+Gh2fklY7L0rvrtpXWmXFwAdthgrf7J3iRVzvibznI3mUlXnqFCy53vVcwb96300R qEU8ZeJOGctfhJSWcrCrqLVNbQJsP317Pn97fXkcHhk6KLHK+MXjKs/dB4rq2OmSbjU7 PYzxELUu70bqOpD4PH2BmpIuZzDuXB4TdyPALYfr9q+GKz8MphaHhTzgk5OWYDCGzzLV Svfc/gJYuWN8DfgoMEV3Fu9nXnP/0uOXV6WVCTef3aBVPpYR2v1Afav3ndJl3YC5+eqj BgcetwY6BrWgM2hZ2o1cv8kjJKR6pHI7+2Y6ClsfxNFvnpzASK1D6Ag6E6YOslUUfAy3 fFNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772618241; x=1773223041; h=content-transfer-encoding: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; bh=NJrv+HwIDbQuRAZOh72iXVEhQflBFsynWIP/XUoI34s=; b=niPNjRdCUnYagSKscFlGJSvazKd7REXjUtlgsiK9dpqeghaIRtEjk4emiI8/LEukIb 6+tNe5sci4Is3W4pL6Ka93ln6csJh23AVf1BDUJoVhXSFAvzmhWTnC0crpDZZiYHFxKj Tfz0C23IcJJQ+M6Iu87eS1ObTBzc525T++qp3XhV9f3FJej2fBwziTfOe7z1Zpi8OZ9y 4Q2z5KodJu5+/yK/gdTqsLqYzIQqRUINT126CZ3cx99IAkPtvwre/LYkBW/M5wTP9sWf sMneW7lpaXaOjUEZR69Lhfxoh6Ob3ZKvLNnLJdL7JE/8XDxu+4jFt2p5RrIvMyZZ7FAb MNxw== X-Gm-Message-State: AOJu0YybnKqOqoT4RHxBT+khese2HnoVb5WsXIFgKU4vBjSXZZsbpQ8p ifEB3wMxR5lu31lWzal9klP5n2OjO4moj9uX2IgjuHemVPijT6NuOGqWeEKwXGqYwlr2ZNW/YK9 qG6e8dHeFxsC97/O9/IZzmOSUwZkcu8tye+vA7PiGjA== X-Gm-Gg: ATEYQzyxKRfCay8bG243yuhMWLfHDdGp2x89bJA+CZq3aGuam+LiQMelf6gOWVPHAeH NzSBn5GtvAKLMwAcxc98eKj5tz2nzDcXiwgL1JyRgJQ8CYB/o+kM5MiYfmiaMAI8+uf9DoKgijM AoIXN9geaW4a9l+6wlX8Ms7sutRr76emzH5rqomGkUmdwOZRcKZMiKYlCGjNMOX38ht3QFpLzkw 1uw1b+UefUGPucGwV+p228Q/No5HwwmghNfdz9Vt1hsl9ey77M8hihKA1fcWmp64yRKp6LMDcrW gvOgplZXCxujepXe9/X3z3CuyRc2Vtte+iKcyw== X-Received: by 2002:a05:6830:6004:b0:7cf:d9ba:c9a6 with SMTP id 46e09a7af769-7d6bf9196c9mr735966a34.0.1772618240772; Wed, 04 Mar 2026 01:57:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jens Wiklander Date: Wed, 4 Mar 2026 10:57:09 +0100 X-Gm-Features: AaiRm53rXnOqjPZrccAyxOHhScQz_4AYLdc_7WKEWrK1obIrIo_QP1oyH_ODXJU Message-ID: Subject: Re: [PATCH v2 2/4] xen/arm: ffa: Cache SP partition info at init To: Bertrand Marquis Cc: xen-devel@lists.xenproject.org, Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 4:44=E2=80=AFPM Bertrand Marquis wrote: > > FFA_PARTITION_INFO_GET currently queries the SPMC on each call and walks = the > RX buffer every time. The SP list is expected to be static, so repeated > firmware calls and validation are unnecessary. > > Cache the SPMC partition-info list at init time, keeping only secure > endpoints, and reuse the cached entries for SP count and partition-info > responses. Initialize the VM create/destroy subscriber lists from the cac= hed > list and free the cache on init failure. > > SP partition info now reflects the init-time snapshot and will not change= . > > Signed-off-by: Bertrand Marquis > --- > Changes since v1: > - removed unneeded NULL assignment after XFREE > - remove warned usage and only rely on printk_once to warn on the 15-bit > convention > - rework ffa_partinfo_init cleanup > - ensure we do not do unaligned accesses when building the SP cache > - enforce SPMC partinfo size to be at least 1.1 structure size when > creating and remove tests when using the cache > --- > xen/arch/arm/tee/ffa_partinfo.c | 216 +++++++++++++++++++++----------- > 1 file changed, 146 insertions(+), 70 deletions(-) > > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index 6a6f3ffb822e..b933becaa55a 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -6,6 +6,8 @@ > #include > #include > #include > +#include > +#include > > #include > #include > @@ -33,6 +35,10 @@ static uint16_t subscr_vm_created_count __read_mostly; > static uint16_t *subscr_vm_destroyed __read_mostly; > static uint16_t subscr_vm_destroyed_count __read_mostly; > > +/* SP list cache (secure endpoints only); populated at init. */ > +static void *sp_list __read_mostly; > +static uint32_t sp_list_count __read_mostly; > +static uint32_t sp_list_entry_size __read_mostly; Nit: prefer an empty line here, but it's fixed in a later patch. Looks good: Reviewed-by: Jens Wiklander Cheers, Jens > static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t fla= gs, > uint32_t *count, uint32_t *fpi_siz= e) > { > @@ -79,92 +85,84 @@ static int32_t ffa_copy_info(void **dst, void *dst_en= d, const void *src, > return FFA_RET_OK; > } > > -static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_count= ) > +static uint16_t ffa_sp_entry_read_id(const void *entry) > { > - uint32_t src_size; > - > - return ffa_partition_info_get(uuid, FFA_PARTITION_INFO_GET_COUNT_FLA= G, > - sp_count, &src_size); > + return get_unaligned_t(uint16_t, > + (const uint8_t *)entry + > + offsetof(struct ffa_partition_info_1_0, id)); > } > > -static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_co= unt, > - void **dst_buf, void *end_buf, > - uint32_t dst_size) > +static bool ffa_sp_entry_matches_uuid(const void *entry, struct ffa_uuid= uuid) > { > - int32_t ret; > - int32_t release_ret; > - uint32_t src_size, real_sp_count; > - void *src_buf; > - uint32_t count =3D 0; > - bool notify_fw =3D false; > + struct ffa_uuid sp_uuid; > > - /* We need to use the RX buffer to receive the list */ > - src_buf =3D ffa_rxtx_spmc_rx_acquire(); > - if ( !src_buf ) > - return FFA_RET_DENIED; > + if ( ffa_uuid_is_nil(uuid) ) > + return true; > > - ret =3D ffa_partition_info_get(uuid, 0, &real_sp_count, &src_size); > - if ( ret ) > - goto out; > - notify_fw =3D true; > + memcpy(&sp_uuid, > + (const uint8_t *)entry + > + offsetof(struct ffa_partition_info_1_1, uuid), > + sizeof(sp_uuid)); > + return ffa_uuid_equal(uuid, sp_uuid); > +} > > - /* Validate the src_size we got */ > - if ( src_size < sizeof(struct ffa_partition_info_1_0) || > - src_size >=3D FFA_PAGE_SIZE ) > +static int32_t ffa_get_sp_count(struct ffa_uuid uuid, uint32_t *sp_count= ) > +{ > + uint32_t count =3D 0; > + uint32_t n; > + > + for ( n =3D 0; n < sp_list_count; n++ ) > { > - ret =3D FFA_RET_NOT_SUPPORTED; > - goto out; > + void *entry =3D sp_list + n * sp_list_entry_size; > + > + if ( ffa_sp_entry_matches_uuid(entry, uuid) ) > + count++; > } > > - /* > - * Limit the maximum time we hold the CPU by limiting the number of = SPs. > - * We just ignore the extra ones as this is tested during init in > - * ffa_partinfo_init so the only possible reason is SP have been add= ed > - * since boot. > - */ > - if ( real_sp_count > FFA_MAX_NUM_SP ) > - real_sp_count =3D FFA_MAX_NUM_SP; > + *sp_count =3D count; > > - /* Make sure the data fits in our buffer */ > - if ( real_sp_count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / src_siz= e ) > - { > - ret =3D FFA_RET_NOT_SUPPORTED; > - goto out; > - } > + if ( !ffa_uuid_is_nil(uuid) && !count ) > + return FFA_RET_INVALID_PARAMETERS; > > - for ( uint32_t sp_num =3D 0; sp_num < real_sp_count; sp_num++ ) > - { > - struct ffa_partition_info_1_1 *fpi =3D src_buf; > + return FFA_RET_OK; > +} > > - /* filter out SP not following bit 15 convention if any */ > - if ( FFA_ID_IS_SECURE(fpi->id) ) > - { > - /* > - * If VM is 1.0 but firmware is 1.1 we could have several en= tries > - * with the same ID but different UUIDs. In this case the VM= will > - * get a list with several time the same ID. > - * This is a non-compliance to the specification but 1.0 VMs= should > - * handle that on their own to simplify Xen implementation. > - */ > +static int32_t ffa_get_sp_partinfo(struct ffa_uuid uuid, uint32_t *sp_co= unt, > + void **dst_buf, void *end_buf, > + uint32_t dst_size) > +{ > + int32_t ret; > + uint32_t count =3D 0; > + uint32_t n; > > - ret =3D ffa_copy_info(dst_buf, end_buf, src_buf, dst_size, s= rc_size); > - if ( ret ) > - goto out; > + for ( n =3D 0; n < sp_list_count; n++ ) > + { > + void *entry =3D sp_list + n * sp_list_entry_size; > > - count++; > - } > + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > + continue; > + > + /* > + * If VM is 1.0 but firmware is 1.1 we could have several entrie= s > + * with the same ID but different UUIDs. In this case the VM wil= l > + * get a list with several time the same ID. > + * This is a non-compliance to the specification but 1.0 VMs sho= uld > + * handle that on their own to simplify Xen implementation. > + */ > + ret =3D ffa_copy_info(dst_buf, end_buf, entry, dst_size, > + sp_list_entry_size); > + if ( ret ) > + return ret; > > - src_buf +=3D src_size; > + count++; > } > > *sp_count =3D count; > > -out: > - release_ret =3D ffa_rxtx_spmc_rx_release(notify_fw); > - if ( release_ret ) > - gprintk(XENLOG_WARNING, > - "ffa: Error releasing SPMC RX buffer: %d\n", release_ret= ); > - return ret; > + if ( !ffa_uuid_is_nil(uuid) && !count ) > + return FFA_RET_INVALID_PARAMETERS; > + > + return FFA_RET_OK; > } > > static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_= index, > @@ -435,6 +433,13 @@ static int32_t ffa_direct_req_send_vm(uint16_t sp_id= , uint16_t vm_id, > return res; > } > > +static void ffa_sp_list_cache_free(void) > +{ > + XFREE(sp_list); > + sp_list_count =3D 0; > + sp_list_entry_size =3D 0; > +} > + > static void uninit_subscribers(void) > { > subscr_vm_created_count =3D 0; > @@ -443,6 +448,63 @@ static void uninit_subscribers(void) > XFREE(subscr_vm_destroyed); > } > > +static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, > + uint32_t fpi_size) > +{ > + const uint8_t *src =3D buf; > + uint32_t secure_count =3D 0; > + uint32_t n, idx =3D 0; > + > + if ( fpi_size < sizeof(struct ffa_partition_info_1_1) || > + fpi_size >=3D FFA_PAGE_SIZE ) > + return false; > + > + if ( count > (FFA_RXTX_PAGE_COUNT * FFA_PAGE_SIZE) / fpi_size ) > + return false; > + > + for ( n =3D 0; n < count; n++ ) > + { > + const uint8_t *entry =3D src + n * fpi_size; > + uint16_t id =3D ffa_sp_entry_read_id(entry); > + > + if ( !FFA_ID_IS_SECURE(id) ) > + { > + printk_once(XENLOG_ERR > + "ffa: Firmware is not using bit 15 convention fo= r IDs !!\n"); > + printk(XENLOG_ERR > + "ffa: Secure partition with id 0x%04x cannot be used\= n", > + id); > + continue; > + } > + > + secure_count++; > + } > + > + if ( secure_count ) > + { > + sp_list =3D xzalloc_bytes(secure_count * fpi_size); > + if ( !sp_list ) > + return false; > + } > + > + sp_list_count =3D secure_count; > + sp_list_entry_size =3D fpi_size; > + > + for ( n =3D 0; n < count; n++ ) > + { > + const uint8_t *entry =3D src + n * fpi_size; > + uint16_t id =3D ffa_sp_entry_read_id(entry); > + > + if ( !FFA_ID_IS_SECURE(id) ) > + continue; > + > + memcpy(sp_list + idx * fpi_size, entry, fpi_size); > + idx++; > + } > + > + return true; > +} > + > static bool init_subscribers(void *buf, uint16_t count, uint32_t fpi_siz= e) > { > uint16_t n; > @@ -538,7 +600,7 @@ bool ffa_partinfo_init(void) > if ( e ) > { > printk(XENLOG_ERR "ffa: Failed to get list of SPs: %d\n", e); > - goto out; > + goto out_release_rx; > } > notify_fw =3D true; > > @@ -546,15 +608,29 @@ bool ffa_partinfo_init(void) > { > printk(XENLOG_ERR "ffa: More SPs than the maximum supported: %u = - %u\n", > count, FFA_MAX_NUM_SP); > - goto out; > + goto out_release_rx; > + } > + > + if ( !ffa_sp_list_cache_init(spmc_rx, count, fpi_size) ) > + { > + printk(XENLOG_ERR "ffa: Failed to cache SP list\n"); > + goto out_release_rx; > } > > - ret =3D init_subscribers(spmc_rx, count, fpi_size); > + if ( !init_subscribers(sp_list, sp_list_count, sp_list_entry_size) ) > + goto out_free_sp_cache; > > -out: > + ret =3D true; > + goto out_release_rx; > + > +out_free_sp_cache: > + ffa_sp_list_cache_free(); > + > +out_release_rx: > e =3D ffa_rxtx_spmc_rx_release(notify_fw); > if ( e ) > printk(XENLOG_WARNING "ffa: Error releasing SPMC RX buffer: %d\n= ", e); > + > return ret; > } > > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 10:18:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 10:18:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245255.1544639 (Exim 4.92) (envelope-from ) id 1vxjJ6-0002Zk-Uy; Wed, 04 Mar 2026 10:18:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245255.1544639; Wed, 04 Mar 2026 10:18:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxjJ6-0002Zd-SO; Wed, 04 Mar 2026 10:18:20 +0000 Received: by outflank-mailman (input) for mailman id 1245255; Wed, 04 Mar 2026 10:18:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxjJ5-0002ZS-EK for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 10:18:19 +0000 Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [2607:f8b0:4864:20::236]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 75bcb0f8-17b3-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 11:18:17 +0100 (CET) Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-46391f4c1f9so4357560b6e.0 for ; Wed, 04 Mar 2026 02:18:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 75bcb0f8-17b3-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1772619496; cv=none; d=google.com; s=arc-20240605; b=YpmkWmfUSBSbqjH0tXLDKGjPGH/4GCLal/7rNudIpJv/riqc0eV27VLStkgzMCADIs c1PyicM1fBM01E7JBfrWXPpsMazCJmBTN6xVTdxLwd6sG01m5B6wj0NuMPee9TrmXEf8 B4wIqIupQ5eo7vLmC2hZKdnHaoiWp9JGrCe7WIe7Fl+cfEpTkgwf4VXVV2SeMUmXbm49 XR7x8PLXeZRQ47oYjfdy/w1YZ6w0f52oGnuhVuYejjURS+2I915I8T1GpQhDmaTiAo2d rVa56IXuvSJMqtOgHmCBWAMrDlfnK2JZm3iLiaScyOWBuRntMZXYZmMOHtr6rM2pebkp fXJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JpRotDvDJ+H6v67uMsFM80otTZemd09qTEWD769DE6g=; fh=wNLC6Hyb5Ukz/ErppBRQBwv8vwa/OMsdh6R8bnNsiPU=; b=FxkQD7GIdEXOOUTxrR9IbWgWpAPi10PtymObVjpFAVqYzPlS7xMGyRDwiD2oovNgVD 8icau4kgGDwc76djs8/w9sup9isUoieJzGVwVe5mH8PNxwpKV/8xVQxoxZnRJbcfrqVQ bqOuTqd3ihgq8Se0eGXGENiqQAlSdu32Vq/w3HhF7BSPMX8jUpP/rAmM183gREReaaSW sR5xU50s6qXyuczPII57bufBmgUQfy1tJQuLT+iOTl/hYiMiiHC0ZLYP1o7+/UFm4niE 6e789IaStBrL3AtGs+eCAF3MubEL3Fca5F5k+FWiwb60QvqoAJG/sYxcXXA8D/Avt0M+ pzCw==; 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=1772619496; x=1773224296; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JpRotDvDJ+H6v67uMsFM80otTZemd09qTEWD769DE6g=; b=wbVUYNQ4pEbSf/8MFFXMbMEVSoEsF+9HDSrEiFmji8Pog5cO2PpJ/vusYakKnYHWaO WmezaO8fXqrt1NH/G45HerdQKA+/DuAeoj1X+gqZt62RXkvpomQ4q/g0/4PMFLbBcVXl 3LHy7DfCt8pGSvOUKVV4SJAxyrEfHcBRWhPFfKnwgolg5iPHqiTKDLhrDymtxayLB0zJ 8Q2MEaLnpzLzVob4KfRkS+WDvb0ol8G9/WE2v3baPrdbZ+BjB1I1/V4q+v70FEfyUqno moA9QKaC1rbyhXLzXTT8CAxnBq3t8RkS5w+XM7cRJtOOfJPJ0S7zs+xlBFuljhB7cLyE CLYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772619496; x=1773224296; h=content-transfer-encoding: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; bh=JpRotDvDJ+H6v67uMsFM80otTZemd09qTEWD769DE6g=; b=YKbjydRe8YRthVr59bhYAM5GDPIdlAUwTgRShgN9HF153NVo9nYbR4vPdh8uirgBBE DdQqTUMoNL3k1jDd3htoAvs2EGxKC8Y4dRo3l0xSU4l7zPkdnGH46f5tcHXxEreWFfvV aB321Cbuo0ZIEIfIuwrOr43CQUgsIKWlQ4RpgQJuRDAKX6SNWJChkOX3Bqz12gk4G4W0 RxNMucgQX+PvFNZz05DZ/sozGTwLJdl+LZFDCdsohl4ecEWOhUdIYjr3yJzViIhpU92D ntC0Lan0x6VKX2r1Vl1C3eHPkmuFVfumEaWvat3klng7LWhel02peN7HBBshp34/z7ua /DpA== X-Gm-Message-State: AOJu0YxmWogP8Mq4zJBQw2qk2YBZ7t6laN96J/JyL2RcKZUacKrl4ldp DY1pio9/dP5W3XB9AISmRcw9ysy/mD3wT9Ypn6QlwFdvJnVs6+wcMyIbkOs5+pp72hlIfx2iQw4 yG5Zy+V3UU+vMdghhc65l4n/1s3reeGh9rgdSZ2tBSA== X-Gm-Gg: ATEYQzyGJlCmqO2C/llGxIEZz8dSYmV6wKYbJJjOS/wkv4nFHStK/Ghvse18leBekjE MopIiAkicIyQhZjxNWBen9kwjnnNCB2zsROpAqIEmuejsccIyBWybGxTorkjAlc0E2s1ALlC8xC Bx3TozUSuylkhhN16YttYlYztmWgNiq+FjZ8DN1JfdpmtueXyW+cKVvhvHnnxBHtzQANoufNq5Z HGXqL6sM5BWtJ/WGZat8W7D1R1Gl26kNgWuUMTCaE0Dit5zOyyTHCoCS4VBY6x66cgvRE7S3CxR EMNLJEcfu56jekyW7potLkQZ0pDnDW4YSo9Ndw== X-Received: by 2002:a05:6808:1523:b0:45f:174a:1297 with SMTP id 5614622812f47-4651a930c51mr840103b6e.0.1772619496138; Wed, 04 Mar 2026 02:18:16 -0800 (PST) MIME-Version: 1.0 References: <055bed7c55f298a0916518fb61929bfc7dac6ef2.1772464956.git.bertrand.marquis@arm.com> In-Reply-To: <055bed7c55f298a0916518fb61929bfc7dac6ef2.1772464956.git.bertrand.marquis@arm.com> From: Jens Wiklander Date: Wed, 4 Mar 2026 11:18:04 +0100 X-Gm-Features: AaiRm51qC8uak2_7R9TRz35VgYWwssl2010_OAlaPhSqRjGyzz2y8BEJ2whLgc0 Message-ID: Subject: Re: [PATCH v2 3/4] xen/arm: ffa: Drop SP subscriber lists To: Bertrand Marquis Cc: xen-devel@lists.xenproject.org, Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 4:44=E2=80=AFPM Bertrand Marquis wrote: > > The init-time SP cache already contains partition properties, but the > code still builds separate subscriber arrays for VM created/destroyed > notifications. That duplicates state and allocation. > > Use the cached SP list directly to: > - decide which SPs receive created/destroyed notifications > - build the per-domain destroy bitmap > - skip destroy notifications for SPs not notified on create > > Also switch cached SP entry field reads in VM create/destroy > notification paths to unaligned-safe helpers, as cache entries are > variable-size and should not be dereferenced via struct pointers. > > No functional changes. > > Signed-off-by: Bertrand Marquis > --- > Changes since v1: > - use unaligned-safe reads for cached SP entry fields > (id/partition_properties) in VM create/destroy notification paths > --- > xen/arch/arm/tee/ffa_partinfo.c | 170 +++++++++----------------------- > 1 file changed, 47 insertions(+), 123 deletions(-) Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index b933becaa55a..419e19510f6f 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -29,12 +29,6 @@ struct ffa_partition_info_1_1 { > uint8_t uuid[16]; > }; > > -/* SPs subscribing to VM_CREATE and VM_DESTROYED events */ > -static uint16_t *subscr_vm_created __read_mostly; > -static uint16_t subscr_vm_created_count __read_mostly; > -static uint16_t *subscr_vm_destroyed __read_mostly; > -static uint16_t subscr_vm_destroyed_count __read_mostly; > - > /* SP list cache (secure endpoints only); populated at init. */ > static void *sp_list __read_mostly; > static uint32_t sp_list_count __read_mostly; > @@ -92,6 +86,14 @@ static uint16_t ffa_sp_entry_read_id(const void *entry= ) > offsetof(struct ffa_partition_info_1_0, id)); > } > > +static uint32_t ffa_sp_entry_read_partition_properties(const void *entry= ) > +{ > + return get_unaligned_t(uint32_t, > + (const uint8_t *)entry + > + offsetof(struct ffa_partition_info_1_0, > + partition_properties)); > +} > + > static bool ffa_sp_entry_matches_uuid(const void *entry, struct ffa_uuid= uuid) > { > struct ffa_uuid sp_uuid; > @@ -440,14 +442,6 @@ static void ffa_sp_list_cache_free(void) > sp_list_entry_size =3D 0; > } > > -static void uninit_subscribers(void) > -{ > - subscr_vm_created_count =3D 0; > - subscr_vm_destroyed_count =3D 0; > - XFREE(subscr_vm_created); > - XFREE(subscr_vm_destroyed); > -} > - > static bool ffa_sp_list_cache_init(const void *buf, uint32_t count, > uint32_t fpi_size) > { > @@ -505,79 +499,6 @@ static bool ffa_sp_list_cache_init(const void *buf, = uint32_t count, > return true; > } > > -static bool init_subscribers(void *buf, uint16_t count, uint32_t fpi_siz= e) > -{ > - uint16_t n; > - uint16_t c_pos; > - uint16_t d_pos; > - struct ffa_partition_info_1_1 *fpi; > - > - if ( fpi_size < sizeof(struct ffa_partition_info_1_1) ) > - { > - printk(XENLOG_ERR "ffa: partition info size invalid: %u\n", fpi_= size); > - return false; > - } > - > - subscr_vm_created_count =3D 0; > - subscr_vm_destroyed_count =3D 0; > - for ( n =3D 0; n < count; n++ ) > - { > - fpi =3D buf + n * fpi_size; > - > - /* > - * We need to have secure partitions using bit 15 set convention= for > - * secure partition IDs. > - * Inform the user with a log and discard giving created or dest= roy > - * event to those IDs. > - */ > - if ( !FFA_ID_IS_SECURE(fpi->id) ) > - { > - printk_once(XENLOG_ERR > - "ffa: Firmware is not using bit 15 convention fo= r IDs !!\n"); > - printk(XENLOG_ERR > - "ffa: Secure partition with id 0x%04x cannot be used\= n", > - fpi->id); > - } > - else > - { > - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_CREATED= ) > - subscr_vm_created_count++; > - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_DESTROY= ED ) > - subscr_vm_destroyed_count++; > - } > - } > - > - if ( subscr_vm_created_count ) > - subscr_vm_created =3D xzalloc_array(uint16_t, subscr_vm_created_= count); > - if ( subscr_vm_destroyed_count ) > - subscr_vm_destroyed =3D xzalloc_array(uint16_t, > - subscr_vm_destroyed_count); > - if ( (subscr_vm_created_count && !subscr_vm_created) || > - (subscr_vm_destroyed_count && !subscr_vm_destroyed) ) > - { > - printk(XENLOG_ERR "ffa: Failed to allocate subscription lists\n"= ); > - uninit_subscribers(); > - return false; > - } > - > - for ( c_pos =3D 0, d_pos =3D 0, n =3D 0; n < count; n++ ) > - { > - fpi =3D buf + n * fpi_size; > - > - if ( FFA_ID_IS_SECURE(fpi->id) ) > - { > - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_CREATED= ) > - subscr_vm_created[c_pos++] =3D fpi->id; > - if ( fpi->partition_properties & FFA_PART_PROP_NOTIF_DESTROY= ED ) > - subscr_vm_destroyed[d_pos++] =3D fpi->id; > - } > - } > - > - return true; > -} > - > - > - > bool ffa_partinfo_init(void) > { > bool ret =3D false; > @@ -617,52 +538,39 @@ bool ffa_partinfo_init(void) > goto out_release_rx; > } > > - if ( !init_subscribers(sp_list, sp_list_count, sp_list_entry_size) ) > - goto out_free_sp_cache; > - > ret =3D true; > goto out_release_rx; > > -out_free_sp_cache: > - ffa_sp_list_cache_free(); > - > out_release_rx: > e =3D ffa_rxtx_spmc_rx_release(notify_fw); > if ( e ) > printk(XENLOG_WARNING "ffa: Error releasing SPMC RX buffer: %d\n= ", e); > - > + if ( !ret ) > + ffa_sp_list_cache_free(); > return ret; > } > > -static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start, > - uint16_t end, uint16_t sp_id) > +static void vm_destroy_bitmap_init(struct ffa_ctx *ctx, > + unsigned int first_unnotified) > { > unsigned int n; > > - for ( n =3D start; n < end; n++ ) > + for ( n =3D 0; n < sp_list_count; n++ ) > { > - if ( subscr[n] =3D=3D sp_id ) > - return true; > - } > - > - return false; > -} > + const void *entry =3D sp_list + n * sp_list_entry_size; > + uint32_t partition_props =3D > + ffa_sp_entry_read_partition_properties(entry); > > -static void vm_destroy_bitmap_init(struct ffa_ctx *ctx, > - unsigned int create_signal_count) > -{ > - unsigned int n; > + if ( !(partition_props & FFA_PART_PROP_NOTIF_DESTROYED) ) > + continue; > > - for ( n =3D 0; n < subscr_vm_destroyed_count; n++ ) > - { > /* > * Skip SPs subscribed to the VM created event that never was > * notified of the VM creation due to an error during > * ffa_domain_init(). > */ > - if ( is_in_subscr_list(subscr_vm_created, create_signal_count, > - subscr_vm_created_count, > - subscr_vm_destroyed[n]) ) > + if ( (partition_props & FFA_PART_PROP_NOTIF_CREATED) && > + n >=3D first_unnotified ) > continue; > > set_bit(n, ctx->vm_destroy_bitmap); > @@ -671,32 +579,42 @@ static void vm_destroy_bitmap_init(struct ffa_ctx *= ctx, > > int32_t ffa_partinfo_domain_init(struct domain *d) > { > - unsigned int count =3D BITS_TO_LONGS(subscr_vm_destroyed_count); > + unsigned int count =3D BITS_TO_LONGS(sp_list_count); > struct ffa_ctx *ctx =3D d->arch.tee; > unsigned int n; > + unsigned int first_unnotified =3D sp_list_count; > int32_t res; > > - if ( !ffa_fw_supports_fid(FFA_MSG_SEND_DIRECT_REQ_32) ) > + if ( !ffa_fw_supports_fid(FFA_MSG_SEND_DIRECT_REQ_32) || !sp_list_co= unt ) > return 0; > > ctx->vm_destroy_bitmap =3D xzalloc_array(unsigned long, count); > if ( !ctx->vm_destroy_bitmap ) > return -ENOMEM; > > - for ( n =3D 0; n < subscr_vm_created_count; n++ ) > + for ( n =3D 0; n < sp_list_count; n++ ) > { > - res =3D ffa_direct_req_send_vm(subscr_vm_created[n], ffa_get_vm_= id(d), > + const void *entry =3D sp_list + n * sp_list_entry_size; > + uint32_t partition_props =3D > + ffa_sp_entry_read_partition_properties(entry); > + uint16_t id =3D ffa_sp_entry_read_id(entry); > + > + if ( !(partition_props & FFA_PART_PROP_NOTIF_CREATED) ) > + continue; > + > + res =3D ffa_direct_req_send_vm(id, ffa_get_vm_id(d), > FFA_MSG_SEND_VM_CREATED); > if ( res ) > { > printk(XENLOG_ERR "ffa: Failed to report creation of vm_id %= u to %u: res %d\n", > - ffa_get_vm_id(d), subscr_vm_created[n], res); > + ffa_get_vm_id(d), id, res); > + first_unnotified =3D n; > break; > } > } > - vm_destroy_bitmap_init(ctx, n); > + vm_destroy_bitmap_init(ctx, first_unnotified); > > - if ( n !=3D subscr_vm_created_count ) > + if ( first_unnotified !=3D sp_list_count ) > return -EIO; > > return 0; > @@ -711,18 +629,24 @@ bool ffa_partinfo_domain_destroy(struct domain *d) > if ( !ctx->vm_destroy_bitmap ) > return true; > > - for ( n =3D 0; n < subscr_vm_destroyed_count; n++ ) > + for ( n =3D 0; n < sp_list_count; n++ ) > { > + const void *entry; > + uint16_t id; > + > if ( !test_bit(n, ctx->vm_destroy_bitmap) ) > continue; > > - res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], ffa_get_v= m_id(d), > + entry =3D sp_list + n * sp_list_entry_size; > + id =3D ffa_sp_entry_read_id(entry); > + > + res =3D ffa_direct_req_send_vm(id, ffa_get_vm_id(d), > FFA_MSG_SEND_VM_DESTROYED); > > if ( res && printk_ratelimit() ) > printk(XENLOG_WARNING > "%pd: ffa: Failed to report destruction of vm_id %u t= o %u: res %d\n", > - d, ffa_get_vm_id(d), subscr_vm_destroyed[n], res); > + d, ffa_get_vm_id(d), id, res); > > /* > * For these two error codes the hypervisor is expected to resen= d > @@ -734,7 +658,7 @@ bool ffa_partinfo_domain_destroy(struct domain *d) > clear_bit(n, ctx->vm_destroy_bitmap); > } > > - if ( bitmap_empty(ctx->vm_destroy_bitmap, subscr_vm_destroyed_count)= ) > + if ( bitmap_empty(ctx->vm_destroy_bitmap, sp_list_count) ) > XFREE(ctx->vm_destroy_bitmap); > > return !ctx->vm_destroy_bitmap; > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 10:44:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 10:44:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245266.1544649 (Exim 4.92) (envelope-from ) id 1vxji0-0007M8-TL; Wed, 04 Mar 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 1245266.1544649; Wed, 04 Mar 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 ) id 1vxji0-0007M1-Qh; Wed, 04 Mar 2026 10:44:04 +0000 Received: by outflank-mailman (input) for mailman id 1245266; Wed, 04 Mar 2026 10:44:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxjhz-0007Lr-7u for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 10:44:03 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0e5674f7-17b7-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 11:44:01 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4806f3fc50bso71249335e9.0 for ; Wed, 04 Mar 2026 02:44:01 -0800 (PST) Received: from [10.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-4851887fc54sm48841655e9.10.2026.03.04.02.44.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 02:44:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0e5674f7-17b7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772621041; x=1773225841; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=QYAuifAC8Um5lkP5nfFAspiUlL5BmUJFZgO7RjydX+o=; b=CiNOssJ1TbC8MSJmizdZ0Hur9HOqW9ImuLE8OwX3WdgRP0KhVI29jggepvrFEADLqH LYrpw3ljjUbkxEboqfnYc4HJ74yLe3EAyCMHxad6w+SMXDd9b9I28r0eAYZi5+4lKrhG E79u1Gkp1210H1WEqKj/U4Yt555gmByPNTKzcfetXd5LjL1Iie8FhTYXTQba+sknX3Hv z2F3VZ8hnlruMH91OUQP9fQyM6/1Dd9nO8/pNQ54Jfs/j7Lo3yAna1blB1wfrlZrRZQb W0r1jhD5w9ivQFptigTL7HBqAYmIgQpkxyoN0acoW+reyeV8hr2Lq/ybkL8NqeWMvANG G3Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772621041; x=1773225841; h=content-transfer-encoding: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; bh=QYAuifAC8Um5lkP5nfFAspiUlL5BmUJFZgO7RjydX+o=; b=u96xQG6/41fOo79wCcGIeebw2zYKrze0XxmZhUWukSMlOXDYWn+aIo6YRD0wkPurkv DrnEEBCYOCMGCdEosgxYHIa88NNKQO6IEPFRv7CK5Z0tDXKOkQQ5BuKshAS3Ct6Y9MK8 FcJoeDxXjWqekdk2NzZS/6r2rm6o2XmF/L13Or0zXoKk0Z8oBDQ7yFpYUswy9v6TeQeL pmo2limMsDRvEjgk/SvWwF3FjevampSqYgS2/vnDT887OIknUPp+RVWdUyK4zeVS0N7l JFnVI7x68SKt1AiWTR6/qES7QPHyNJkuhRUmnfnK7tNppAi2sEZcq1GufqCtmL7nly7c QysQ== X-Forwarded-Encrypted: i=1; AJvYcCWt5W3N2X6OCxeigJyEw26Fwcnjx9uLU0AM5xqFz2GSvoZ0t7G34xXKIDcFHFwGpWNCX13KlTro+k4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwzXY6EF8a2sh6dM0N+1KrBzWLE54zjOiKdX/dKtCzr/wmDwRJL UCyBefpPlDd4WujhoEtlSQE8QlIRBZL32t0Tu0b86p/Xv0ZZGD2D5IB6dpmWO6uTVA== X-Gm-Gg: ATEYQzwZy7K3RaSVatVcy2ur+H/B9gkY9RzUTnwHN/qiUA4Z/3Bn/4vo3iOmAewIA6j yCQ/jZ0FraBBVrhGF6k6J7jfUXPJ8ek2usDRo48bWTzgREb346FnAtyPFeLN5wBMox50TRhZNSd 6V7gUX0ysPOZzsBDtDoHsVt2fXg/aKIF5fHZczBQMnUjPvCumdY7+ipHh+Z2NQW8pDDQTYLj3Rr rcIYky3cwBaDKhfRivVr2lLkiqdAClRwyZg6Maka0iZad0zQ3li5xnrF8l9p997LTYi8AwPYEsG aIMW8y+hrIWPP8MuTtXC7m9a16KkXs5aLsv0bQXUnu9LLOptRrcRgX5154of/PPDXZwsnIK1rYF VXpEeM0oZIbekWXXzBHzIzcVJOtC6hrz6Nw35ghg6g6eDbhNAkRsHfP4SdwuFtPRaMdUuoXRFhj 3BVwPJ6pz2RH+g5QA26fhpHAsDxStuWmuwAztvI4ssCk3jVXbCxgmc6pzuPcasXvwxafZhZaHAV 82/xqYMaAsPhgY= X-Received: by 2002:a05:600c:608c:b0:483:bcff:7948 with SMTP id 5b1f17b1804b1-48519847972mr24952405e9.10.1772621040831; Wed, 04 Mar 2026 02:44:00 -0800 (PST) Message-ID: <639231a2-c8c4-43c8-84a2-b4797e88d9fb@suse.com> Date: Wed, 4 Mar 2026 11:43:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] arm/mm: Fix resource handling in xenmem_add_to_physmap_one To: Michal Orzel Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260304093923.14293-1-michal.orzel@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304093923.14293-1-michal.orzel@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 10:39, Michal Orzel wrote: > @@ -237,13 +239,73 @@ int xenmem_add_to_physmap_one( > break; > } > case XENMAPSPACE_dev_mmio: > - rc = map_dev_mmio_page(d, gfn, _mfn(idx)); > - return rc; > + if ( !iomem_access_permitted(d, idx, idx) ) > + return 0; > + > + mfn = _mfn(idx); > + t = p2m_mmio_direct_c; > + break; > > default: > return -ENOSYS; > } > > + /* > + * Release the old page reference if it was present. > + * > + * TODO: There are race conditions in this code due to multiple lock/unlock > + * cycles: > + * > + * Race #1: Between checking the old mapping and removing it, another CPU > + * could replace the mapping. We would then remove the wrong mapping. > + * > + * Race #2: Between removing the old mapping and inserting the new one, > + * another CPU could insert a different mapping. We would then silently > + * overwrite it. Can't such races be abused in a security relevant way, e.g. causing leaks of some sort? > + * For now, we accept these races as they require concurrent > + * xenmem_add_to_physmap_one operations on the same GFN, which is not a > + * normal usage pattern. > + */ > + p2m_read_lock(p2m); > + mfn_old = p2m_get_entry(p2m, gfn, &p2mt_old, NULL, NULL, NULL); > + p2m_read_unlock(p2m); > + > + if ( mfn_valid(mfn_old) && !mfn_eq(mfn, mfn_old) ) > + { > + if ( is_special_page(mfn_to_page(mfn_old)) ) > + { > + /* Just unmap, don't free */ > + p2m_write_lock(p2m); > + rc = p2m_set_entry(p2m, gfn, 1, INVALID_MFN, > + p2m_invalid, p2m->default_access); > + p2m_write_unlock(p2m); > + if ( rc ) > + goto out; > + } > + else if ( p2m_is_mmio(p2mt_old) || p2m_is_grant(p2mt_old) ) > + { > + /* Reject MMIO and grant replacements */ > + rc = -EPERM; > + goto out; > + } > + else > + { > + /* Allow RAM and foreign - both have proper cleanup */ > + rc = guest_remove_page(d, gfn_x(gfn)); > + if ( rc ) > + goto out; > + } > + } > + else if ( mfn_valid(mfn_old) ) > + { > + /* Mapping already exists. Drop the references taken above */ > + if ( page != NULL ) > + put_page(page); > + > + return 0; Is this correct regardless of p2mt_old? > + } !mfn_valid(mfn_old) doesn't imply there was no valid mapping. It could be an MMIO one with an MFN which simply has no associated struct page_info. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 10:44:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 10:44:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245268.1544660 (Exim 4.92) (envelope-from ) id 1vxjiG-0007eX-4v; Wed, 04 Mar 2026 10:44:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245268.1544660; Wed, 04 Mar 2026 10:44:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxjiG-0007eQ-1v; Wed, 04 Mar 2026 10:44:20 +0000 Received: by outflank-mailman (input) for mailman id 1245268; Wed, 04 Mar 2026 10:44:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxjiE-0007dg-Bp for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 10:44:18 +0000 Received: from mail-oa1-x2b.google.com (mail-oa1-x2b.google.com [2001:4860:4864:20::2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1655a109-17b7-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 11:44:16 +0100 (CET) Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-4152698e745so702070fac.1 for ; Wed, 04 Mar 2026 02:44:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1655a109-17b7-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1772621054; cv=none; d=google.com; s=arc-20240605; b=Y1zBp6fGmxJsW1WCuy9jCleg26qqAY2WFx4DenpauXdPPdl4vWRGfEP2iMm0haYLO6 pbeBjsYiOk39pKbBMofbGlvA80kK/4mIyG/6b7aRe91lwDn+9uewzGQdXHFdPXou1WpC Zk7G/1hvEpmKjwSRulP7Qa+tWZlkjyc256+Sf3P8P4+i88ofYYnhJ493gS8Z8gQHFlgW FVNvuIGMq4gb+N8iWBA8E7eGaskzkybjd6nPUzdo7RHj6GKtInjJfYVhE3q+HPaV63BL 4dfOYhhajRHaoBd3+6TJe1yC/hJZn0eutA0VetZyL9G/SJC/OURRbuOdBU27XpZI/ttw Ml9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=GxCxuIeq0ZlkpJHq3FJYHVbyqA6Ag06ecfzQyA5N5dQ=; fh=wNLC6Hyb5Ukz/ErppBRQBwv8vwa/OMsdh6R8bnNsiPU=; b=UIYoTqjW3FNt1YPi0kDLkGDYpSnTBQD3SAOPR2LYvypyOYbboRkddku3fBn9mZXU2v xCRfHSqbqHqO17nw0Kfqe2Luk19BJem1ViprVYca8ouDTxv8nfIQq5DygE4wEbnbFIeS y8r5jVWszgvmye0spS5qQrGpFdPdL2nv53mx1jFpGHiiJyu+reKPNgYxqb1a1IRbgCTT JxZMIy0iGmOfdWP+pghgvoAeJl1XKaj/8WjrCl3YN0xO6iAGyc0L5iFxJZ6nLbd6ppyD FIvF3vXKD4Z7MD0TsXosk9esakxzv+0vGep42ABa28GSOnZzvfsynuzZfCf3M6wzRlSY zWIw==; 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=1772621054; x=1773225854; darn=lists.xenproject.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GxCxuIeq0ZlkpJHq3FJYHVbyqA6Ag06ecfzQyA5N5dQ=; b=SJLINArzjfaBNxiVgVmUl8wXsZLCbblfHgg0j81x6YduThLu7PbAN6P5shw6QH21is xKLLZ5mOlBIwRIMPL0CBEKap8xBywxFL4SfPe9LScSH6wzZtHWMeCphuKAbHwgOqkbHd V6xRSkcaay03U73zMRdA1n8rs0vfwi5BjWXB0ZIjZFLDxr//HUn/b8GCP8x5jO7PANe3 YrW34uWPzXKHk3byR7QvZAmEbIDqtQ3ILfhkS+9hqs8kfGx6zTOJNeOhpvQ1So+IYhIB YFI5JOD18q5QYj4omEvDBKitKWaNumWMsryqkJy7x1T2pEOmiq/uvwKuMcL1AkVKCUeq GwPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772621054; x=1773225854; h=content-transfer-encoding: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; bh=GxCxuIeq0ZlkpJHq3FJYHVbyqA6Ag06ecfzQyA5N5dQ=; b=fKlCz5eZBUlS3zAMMRRpVrJUVXBG2D8ym+U64XCaUyg8/Sl6q+k96e/D7f9Y6ibX73 vPU/cXqtitMTdGyJ0KUIlFKVomO+ehdFypI5xWtOLbCzcet7P40VNQaiU+9fX5x0i3+I scp4VEMsHQIgXF+XGKIzT95d+uL82+UAWY+TWqNR9SXjOHL06aK8Dl9c0H0MqwsiOec/ yk3699s+pVoDIqmtSV1yBSVGY3Clk8BbpCedIZLKskmbIALTPIxwrsPDW0MrOKXYqN0H jmSxY3h1VX/O4TvB17iv07pz/F2AxCAZFK+gMaItCtOnBG4cvYpt8rrHHVLophCrjsn3 mqpg== X-Gm-Message-State: AOJu0Yww5ErXZ0NKoXKXaZLDgwApur7Qi1y+onsz4fyZebJpZzG1QS4c Ulw9aLeYy1AQWZ3D5aJX171ZQlB7ha/Hz2E1T9bDnE57YL5rs2Pld5HZzqggc5ynsc3sjtx4uM9 DBMd/8ykOVA00+zd5sRFwm2Ebb/8pQYxiz/WYFt3FYg== X-Gm-Gg: ATEYQzwPpmkR3CexVA1vMwCICtyyWQ6JWZpAKu5k40WV9IhbVRKvWGwXN2sC+y0jdXQ mYIKCTgd1hE/1VZ2V8KnE71cMzrQC8kF91lSl9mi2PD7Xuu9XU6bVY6URJF6L6fJd/2YsSwvaKU nUzPvw+2fjM6Ghem71W0caBZrlhvARRdZvh4v6bN75vVwt02qWBD3+x19wa82EWfXkHTM5vhXE6 HD6qopkUhexg1JPYzz2n6Pc9NZFvhA+c669wXdgMSC9iSSQxtdqSgZ2qa4MggVdL6Q3r85QmrS3 hdvgDn38H9rdouSHOLaGCaxib6zstm9cfJE8QQ== X-Received: by 2002:a05:6870:f2aa:b0:40f:c84:e59b with SMTP id 586e51a60fabf-416aba6999bmr906334fac.30.1772621053783; Wed, 04 Mar 2026 02:44:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jens Wiklander Date: Wed, 4 Mar 2026 11:44:02 +0100 X-Gm-Features: AaiRm53ynxyazzqty8FDyjUylSW0eVwQ7WkkuOEBqe5vudRypS-nm3kCiGgnB4A Message-ID: Subject: Re: [PATCH v2 4/4] xen/arm: ffa: Add cached GET_REGS support To: Bertrand Marquis Cc: xen-devel@lists.xenproject.org, Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bertrand, On Mon, Mar 2, 2026 at 4:44=E2=80=AFPM Bertrand Marquis wrote: > > FF-A v1.2 defines PARTITION_INFO_GET_REGS for register-based partition > info retrieval, but Xen currently only supports the buffer-based GET > path for guests. > > Implement GET_REGS using the cached SP list and VM entries, including > the register window layout and input validation. Track VM list changes > via the partinfo tag and use it to validate GET_REGS tag inputs. Ensure > that when a non-Nil UUID is specified, the UUID fields in both GET and > GET_REGS results are MBZ as required by the specification. > > PARTITION_INFO_GET_REGS is available to v1.2 guests, returning cached SP > entries and VM entries with UUIDs zeroed for non-Nil UUID queries. > > Also publish VM membership updates (VM count, ctx list, and partinfo > tag) under the same write-locked section so GET_REGS sees coherent state > and concurrent changes are reliably reported via RETRY. > > Signed-off-by: Bertrand Marquis > --- > Changes since v1: > - ignore x4-x17 not being zero and x3 bits 63-32 not being zero (defined > as SBZ in the spec) > - detect tag changes during GET_REGS handling and return RETRY > - remove strict check of sp_list_entry_size, larger cache entry sizes > will now be accepted > - publish VM count, ctx list, and partinfo tag updates under > ffa_ctx_list_rwlock for coherent visibility > --- > xen/arch/arm/tee/ffa.c | 23 +++- > xen/arch/arm/tee/ffa_partinfo.c | 200 ++++++++++++++++++++++++++++++++ > xen/arch/arm/tee/ffa_private.h | 4 +- > 3 files changed, 223 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index aa43ae2595d7..d6cae67e1a48 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -44,6 +44,11 @@ > * - doesn't support signalling the secondary scheduler of pending > * notification for secure partitions > * - doesn't support notifications for Xen itself > + * o FFA_PARTITION_INFO_GET/GET_REGS: > + * - v1.0 guests may see duplicate SP IDs when firmware provides UUIDs > + * - SP list is cached at init; SPMC tag changes are not tracked > + * between calls > + * - SP list is capped at FFA_MAX_NUM_SP entries > * > * There are some large locked sections with ffa_spmc_tx_lock and > * ffa_spmc_rx_lock. Especially the ffa_spmc_tx_lock spinlock used > @@ -183,10 +188,11 @@ static bool ffa_negotiate_version(struct cpu_user_r= egs *regs) > > if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > { > - /* One more VM with FF-A support available */ > - inc_ffa_vm_count(); > write_lock(&ffa_ctx_list_rwlock); > + /* Publish VM membership changes atomically with tag updates= . */ > + inc_ffa_vm_count(); > list_add_tail(&ctx->ctx_list, &ffa_ctx_head); > + ffa_partinfo_inc_tag(); > write_unlock(&ffa_ctx_list_rwlock); > } > > @@ -341,6 +347,12 @@ static void handle_features(struct cpu_user_regs *re= gs) > case FFA_FEATURE_SCHEDULE_RECV_INTR: > ffa_set_regs_success(regs, GUEST_FFA_SCHEDULE_RECV_INTR_ID, 0); > break; > + case FFA_PARTITION_INFO_GET_REGS: > + if ( ACCESS_ONCE(ctx->guest_vers) >=3D FFA_VERSION_1_2 ) > + ffa_set_regs_success(regs, 0, 0); > + else > + ffa_set_regs_error(regs, FFA_RET_NOT_SUPPORTED); > + break; > > case FFA_NOTIFICATION_BIND: > case FFA_NOTIFICATION_UNBIND: > @@ -402,6 +414,9 @@ static bool ffa_handle_call(struct cpu_user_regs *reg= s) > case FFA_PARTITION_INFO_GET: > ffa_handle_partition_info_get(regs); > return true; > + case FFA_PARTITION_INFO_GET_REGS: > + ffa_handle_partition_info_get_regs(regs); > + return true; > case FFA_RX_RELEASE: > e =3D ffa_rx_release(ctx); > break; > @@ -625,9 +640,11 @@ static int ffa_domain_teardown(struct domain *d) > > if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) && ACCESS_ONCE(ctx->guest_vers)= ) > { > - dec_ffa_vm_count(); > write_lock(&ffa_ctx_list_rwlock); > + /* Publish VM membership changes atomically with tag updates. */ > + dec_ffa_vm_count(); > list_del(&ctx->ctx_list); > + ffa_partinfo_inc_tag(); > write_unlock(&ffa_ctx_list_rwlock); > } > > diff --git a/xen/arch/arm/tee/ffa_partinfo.c b/xen/arch/arm/tee/ffa_parti= nfo.c > index 419e19510f6f..16da5ee567db 100644 > --- a/xen/arch/arm/tee/ffa_partinfo.c > +++ b/xen/arch/arm/tee/ffa_partinfo.c > @@ -29,10 +29,39 @@ struct ffa_partition_info_1_1 { > uint8_t uuid[16]; > }; > > +/* Registers a3..a17 (15 regs) carry partition descriptors, 3 regs each.= */ > +#define FFA_PARTINFO_REG_MAX_ENTRIES \ > + ((15 * sizeof(uint64_t)) / sizeof(struct ffa_partition_info_1_1)) > + > /* SP list cache (secure endpoints only); populated at init. */ > static void *sp_list __read_mostly; > static uint32_t sp_list_count __read_mostly; > static uint32_t sp_list_entry_size __read_mostly; > + > +/* SP list is static; tag only moves when VMs are added/removed. */ > +static atomic_t ffa_partinfo_tag =3D ATOMIC_INIT(1); > + > +void ffa_partinfo_inc_tag(void) > +{ > + atomic_inc(&ffa_partinfo_tag); > +} > + > +static inline uint16_t ffa_partinfo_get_tag(void) > +{ > + /* > + * Tag moves with VM list changes only. > + * > + * Limitation: we cannot detect an SPMC tag change between calls bec= ause we > + * do not retain the previous SPMC tag; we only refresh it via the m= andatory > + * start_index=3D0 call and assume it stays stable while combined_ta= g (our > + * VM/SP-count tag) is used for guest validation. This means SPMC ta= g > + * changes alone will not trigger RETRY. > + */ > + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > + return atomic_read(&ffa_partinfo_tag) & GENMASK(15, 0); > + else > + return 1; > +} Please add an empty line here. > static int32_t ffa_partition_info_get(struct ffa_uuid uuid, uint32_t fla= gs, > uint32_t *count, uint32_t *fpi_siz= e) > { > @@ -140,6 +169,7 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid uu= id, uint32_t *sp_count, > for ( n =3D 0; n < sp_list_count; n++ ) > { > void *entry =3D sp_list + n * sp_list_entry_size; > + void *dst_pos; > > if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > continue; > @@ -151,11 +181,20 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid = uuid, uint32_t *sp_count, > * This is a non-compliance to the specification but 1.0 VMs sho= uld > * handle that on their own to simplify Xen implementation. > */ > + dst_pos =3D *dst_buf; > ret =3D ffa_copy_info(dst_buf, end_buf, entry, dst_size, > sp_list_entry_size); > if ( ret ) > return ret; > > + if ( !ffa_uuid_is_nil(uuid) && > + dst_size >=3D sizeof(struct ffa_partition_info_1_1) ) > + { > + struct ffa_partition_info_1_1 *fpi =3D dst_pos; > + > + memset(fpi->uuid, 0, sizeof(fpi->uuid)); > + } > + > count++; > } > > @@ -167,6 +206,38 @@ static int32_t ffa_get_sp_partinfo(struct ffa_uuid u= uid, uint32_t *sp_count, > return FFA_RET_OK; > } > > +static uint16_t ffa_get_sp_partinfo_regs(struct ffa_uuid uuid, > + uint16_t start_index, > + uint64_t *out_regs, > + uint16_t max_entries) > +{ > + uint32_t idx =3D 0; > + uint16_t filled =3D 0; > + uint32_t n; > + > + for ( n =3D 0; n < sp_list_count && filled < max_entries; n++ ) > + { > + void *entry =3D sp_list + n * sp_list_entry_size; > + > + if ( !ffa_sp_entry_matches_uuid(entry, uuid) ) > + continue; > + > + if ( idx++ < start_index ) > + continue; > + > + memcpy(&out_regs[filled * 3], entry, > + sizeof(struct ffa_partition_info_1_1)); > + if ( !ffa_uuid_is_nil(uuid) ) > + { > + out_regs[filled * 3 + 1] =3D 0; > + out_regs[filled * 3 + 2] =3D 0; > + } > + filled++; > + } > + > + return filled; > +} > + > static int32_t ffa_get_vm_partinfo(struct ffa_uuid uuid, uint32_t start_= index, > uint32_t *vm_count, void **dst_buf, > void *end_buf, uint32_t dst_size) > @@ -383,6 +454,135 @@ out: > } > } > > +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs) > +{ > + struct domain *d =3D current->domain; > + struct ffa_ctx *ctx =3D d->arch.tee; > + struct ffa_uuid uuid; > + uint32_t sp_count =3D 0, vm_count =3D 0, total_count; > + uint16_t start_index, tag; > + uint16_t num_entries =3D 0; > + uint64_t x3 =3D get_user_reg(regs, 3); > + int32_t ret =3D FFA_RET_OK; > + uint64_t out_regs[18] =3D { 0 }; > + unsigned int n; > + uint16_t tag_out, tag_end; > + > + if ( ACCESS_ONCE(ctx->guest_vers) < FFA_VERSION_1_2 ) > + { > + ret =3D FFA_RET_NOT_SUPPORTED; > + goto out; > + } > + > + /* > + * Registers a3..a17 (15 regs) carry partition descriptors, 3 regs e= ach. > + * For FF-A 1.2, that yields a maximum of 5 entries per GET_REGS cal= l. > + * Enforce the assumed layout so window sizing stays correct. > + */ > + BUILD_BUG_ON(FFA_PARTINFO_REG_MAX_ENTRIES !=3D 5); > + > + start_index =3D x3 & GENMASK(15, 0); > + tag =3D (x3 >> 16) & GENMASK(15, 0); > + > + /* Start index must allow room for up to 5 entries without 16-bit ov= erflow. */ Nit: The line above is over 80 columns. With or without the line above fixed. Looks good. Reviewed-by: Jens Wiklander Cheers, Jens > + if ( start_index > (GENMASK(15, 0) - (FFA_PARTINFO_REG_MAX_ENTRIES -= 1)) ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out; > + } > + > + uuid.val[0] =3D get_user_reg(regs, 1); > + uuid.val[1] =3D get_user_reg(regs, 2); > + > + tag_out =3D ffa_partinfo_get_tag(); > + > + if ( start_index =3D=3D 0 ) > + { > + if ( tag ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out; > + } > + } > + else if ( tag !=3D tag_out ) > + { > + ret =3D FFA_RET_RETRY; > + goto out; > + } > + > + if ( ffa_uuid_is_nil(uuid) ) > + { > + if ( IS_ENABLED(CONFIG_FFA_VM_TO_VM) ) > + vm_count =3D get_ffa_vm_count(); > + else > + vm_count =3D 1; /* Caller VM only */ > + } > + > + ret =3D ffa_get_sp_count(uuid, &sp_count); > + if ( ret ) > + goto out; > + > + total_count =3D sp_count + vm_count; > + > + if ( total_count =3D=3D 0 || start_index >=3D total_count ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out; > + } > + > + if ( start_index < sp_count ) > + num_entries =3D ffa_get_sp_partinfo_regs(uuid, start_index, &out= _regs[3], > + FFA_PARTINFO_REG_MAX_ENTR= IES); > + > + if ( num_entries < FFA_PARTINFO_REG_MAX_ENTRIES ) > + { > + uint32_t vm_start =3D start_index > sp_count ? > + start_index - sp_count : 0; > + uint32_t filled =3D 0; > + void *vm_dst =3D &out_regs[3 + num_entries * 3]; > + void *vm_end =3D &out_regs[18]; > + > + ret =3D ffa_get_vm_partinfo(uuid, vm_start, &filled, &vm_dst, vm= _end, > + sizeof(struct ffa_partition_info_1_1))= ; > + if ( ret !=3D FFA_RET_OK && ret !=3D FFA_RET_NO_MEMORY ) > + goto out; > + > + num_entries +=3D filled; > + } > + > + if ( num_entries =3D=3D 0 ) > + { > + ret =3D FFA_RET_INVALID_PARAMETERS; > + goto out; > + } > + > + /* > + * Detect list changes while building the response so the caller can= retry > + * with a coherent snapshot tag. > + */ > + tag_end =3D ffa_partinfo_get_tag(); > + if ( tag_end !=3D tag_out ) > + { > + ret =3D FFA_RET_RETRY; > + goto out; > + } > + > + out_regs[0] =3D FFA_SUCCESS_64; > + out_regs[2] =3D ((uint64_t)sizeof(struct ffa_partition_info_1_1) << = 48) | > + ((uint64_t)tag_end << 32) | > + ((uint64_t)(start_index + num_entries - 1) << 16) | > + ((uint64_t)(total_count - 1) & GENMASK(15, 0)); > + > + for ( n =3D 0; n < ARRAY_SIZE(out_regs); n++ ) > + set_user_reg(regs, n, out_regs[n]); > + > + return; > + > +out: > + if ( ret ) > + ffa_set_regs_error(regs, ret); > +} > + > static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id, > uint8_t msg) > { > diff --git a/xen/arch/arm/tee/ffa_private.h b/xen/arch/arm/tee/ffa_privat= e.h > index 1a632983c860..c291f32b56ff 100644 > --- a/xen/arch/arm/tee/ffa_private.h > +++ b/xen/arch/arm/tee/ffa_private.h > @@ -289,7 +289,7 @@ > #define FFA_MSG_SEND2 0x84000086U > #define FFA_CONSOLE_LOG_32 0x8400008AU > #define FFA_CONSOLE_LOG_64 0xC400008AU > -#define FFA_PARTITION_INFO_GET_REGS 0x8400008BU > +#define FFA_PARTITION_INFO_GET_REGS 0xC400008BU > #define FFA_MSG_SEND_DIRECT_REQ2 0xC400008DU > #define FFA_MSG_SEND_DIRECT_RESP2 0xC400008EU > > @@ -452,6 +452,8 @@ bool ffa_partinfo_init(void); > int32_t ffa_partinfo_domain_init(struct domain *d); > bool ffa_partinfo_domain_destroy(struct domain *d); > void ffa_handle_partition_info_get(struct cpu_user_regs *regs); > +void ffa_handle_partition_info_get_regs(struct cpu_user_regs *regs); > +void ffa_partinfo_inc_tag(void); > > int32_t ffa_endpoint_domain_lookup(uint16_t endpoint_id, struct domain *= *d_out, > struct ffa_ctx **ctx_out); > -- > 2.52.0 > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 11:44:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 11:44:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245320.1544687 (Exim 4.92) (envelope-from ) id 1vxkei-0000l9-S9; Wed, 04 Mar 2026 11:44:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245320.1544687; Wed, 04 Mar 2026 11:44:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxkei-0000l2-Oz; Wed, 04 Mar 2026 11:44:44 +0000 Received: by outflank-mailman (input) for mailman id 1245320; Wed, 04 Mar 2026 11:44:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxkeh-0000kc-C8 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 11:44:43 +0000 Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c201::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 84f93f8c-17bf-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 12:44:37 +0100 (CET) Received: from DB8PR06CA0038.eurprd06.prod.outlook.com (2603:10a6:10:120::12) by VI1PR08MB5519.eurprd08.prod.outlook.com (2603:10a6:803:133::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 11:44:24 +0000 Received: from DU6PEPF0000A7E1.eurprd02.prod.outlook.com (2603:10a6:10:120:cafe::6d) by DB8PR06CA0038.outlook.office365.com (2603:10a6:10:120::12) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.22 via Frontend Transport; Wed, 4 Mar 2026 11:43:58 +0000 Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DU6PEPF0000A7E1.mail.protection.outlook.com (10.167.8.40) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 4 Mar 2026 11:44:24 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com (2603:10a6:102:84::13) by PA4PR08MB6206.eurprd08.prod.outlook.com (2603:10a6:102:ea::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 11:43:21 +0000 Received: from PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e]) by PR3PR08MB5593.eurprd08.prod.outlook.com ([fe80::aae1:6871:afc4:620e%4]) with mapi id 15.20.9654.022; Wed, 4 Mar 2026 11:43:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 84f93f8c-17bf-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=x/PnP8ZejarHUbct6/iwbajkuCTwkvOtTtBgqAKrXTfz2ZxAwNVAaT2zyAoag6YadQLR6iHWhuLNYD79qrR+VWXdvSwaMGREcqntpmHYzRQA1nDRL1OaDJcHhX0VyCk1Vbv+NQWOM52+xMtymKFOhxTIk5hl4y6ZNrUf/3WUa6RpgltEyRqgBAjye3UtUjUHF4WvcoNuBzd3k60GJV0UcjxKYiX79GvhYZ0QaRtcDdSt3mL7KFiOoe4OU6Pq9fJaRCqAHRQn9RkTzgat5xgdXXAN+3UXCkkjN0WpJ/AHXdtyZ4BryK+49vjbExrzwIITsTe3kApCWupH1T0mvYPuhQ== 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=BMV26NOhbn4/xROmOocUyhrnyNxy916bRW2XhBd1/8o=; b=R1RIEieS8+VvgIxqS0u0Ux0MdRaYTsUdgSHEpQm7VH0nf+hA9Fh+vroncMUQzcfQvm2NmWnI4ye9xPQde7CIFBe/YHgAnQQmTuWHkgL8+K/YL2T9kETK/HWv9G4sNW4jr/Uian8nGuhdS5l3mK8+U6JHSTLxAHZAiW7cq1OoyvfZzNyRcjmVjkDO4WSNp16IwsHzbQbY7lA1gAzy4L/gTVENNGLl+xk0b71dXtni+WVOjpmTrCswFg75rHMFAtBNc95eblE5NaIulWPqRg1fkGcFLn7JtmA79zIF41fXDG87t/32WOMbQQL0fDEjsg/J1sLnnpOhmDvQ8ZkQmDLFlQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=linaro.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=BMV26NOhbn4/xROmOocUyhrnyNxy916bRW2XhBd1/8o=; b=kbxWOq3u5nuQgD1L990uEo1ZCLz64+/JutDrQtEX6Km5tEes00v3D9vOVsCUCgfSjQ23SOFwU8Kh75dcssKJvXLxuDWvXZZecXmXJNswRFaS5y7mlgCUG9qWz3SvihjRvM7iqeAmb5hfeqjeIMkR6GDbx+jLDZCtqbttkyYcSJ8= 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=frbX2MzNQsk6ZinpbEwUyixUDk/2KWc7qoK6HvSqhmBi8cM7uK9gxaQSeymTZmlFzX1ABi3v2Kev7cOpktqIulV3Ie0sgt4nKEOgjxd5C2s6zm/fMvjJNbM+QaOS5F+dr6RjodLpdmiXe4fF+SWiX3x0ABNVd1bFCU4hnA+ApulYYeKdPdD3zw2tbZqnGqLqPvxT8CtmCJ2DxssqIHKQ9IkI3y+xdtEZ75nVGI/46xwNt/6dt+v7OLqwDHpKfp8o+NWZthuMW6dIpCij+nit8DZu9rTXDRps6cNUf6vmVofGhY9Bjj47J/c0116J68SXownK1ZCkh8EByfnPYiKYWQ== 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=BMV26NOhbn4/xROmOocUyhrnyNxy916bRW2XhBd1/8o=; b=R6i4Gl8g6ELHu4n40VCmkcL3d4ZD6MrNUf9K7mJAuZtaHr/xVtJUhoVwksk6q3lLQ2+kHMR/sHOO0LxN649UShJMxbKjHyNSiTUsWoNQP1IqbYqz44ofibhFwW8+8mSj6i0VgT/EJElvCFytXufTUQ58AlX5IVaRVIKzT7UM2usTjk1D9HghjRVFQf/glo+kDQD0ejv/GI9oiLrSMxzW3pYG3kAe8MIdfPRIy7tupop93VGAccs5J0uBRPnGaueKNClrtkI1XLdTARMq8mJ5GDqKj0WBRze7AiSQYCPupLzaHKQWLFmIKHzkiI58uyG2k4vE0cOqrKO83fKawV6STQ== 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=BMV26NOhbn4/xROmOocUyhrnyNxy916bRW2XhBd1/8o=; b=kbxWOq3u5nuQgD1L990uEo1ZCLz64+/JutDrQtEX6Km5tEes00v3D9vOVsCUCgfSjQ23SOFwU8Kh75dcssKJvXLxuDWvXZZecXmXJNswRFaS5y7mlgCUG9qWz3SvihjRvM7iqeAmb5hfeqjeIMkR6GDbx+jLDZCtqbttkyYcSJ8= From: Bertrand Marquis To: Jens Wiklander CC: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel Subject: Re: [PATCH v2 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Topic: [PATCH v2 4/4] xen/arm: ffa: Add cached GET_REGS support Thread-Index: AQHcqluMWNwuk1kC7USqgRLmbYWnX7WeMukAgAAQhgA= Date: Wed, 4 Mar 2026 11:43:20 +0000 Message-ID: <41F57B75-742A-4EC0-9C24-BEDBB78C5A60@arm.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: PR3PR08MB5593:EE_|PA4PR08MB6206:EE_|DU6PEPF0000A7E1:EE_|VI1PR08MB5519:EE_ X-MS-Office365-Filtering-Correlation-Id: 582fafde-b8b9-4314-8d1b-08de79e3625f 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|376014|38070700021; X-Microsoft-Antispam-Message-Info-Original: vA/n6LPW/ch8J/F7pfKcTajGvM2LlKDZHKv5oNZmLKCiRaoF6MugrFDX+uQT8ZgJzoPnAS244BqSsEyyyFl3mcLImr9WpR4B8D+2GVapbzNnCQy+85ZT66Ka8EHAcHgO/5VYSH60DTa6l/HoTR2YfD21cfcK3KXuUxYbFQe8DNp+MCYTcsH/006z+WRB4vC3emxDMYFlzrFtpyhGO1LibcqnQcjkAZxq4434/WDs4IXJ3xeFF0s9MyjASUhEMNH1ZQFsxOmi3WNq/Y59S8W4t+k4ducyLuXP8AVBIwuLTg7YJSU6VsXOZiZMZ09eNUDCzUOCctmbr4h3NrngmLtThETo6qCa8oiitxp41MD7iegwT2O6Ay4KTnDE/FCJe3ILSnlf+ThYoEV1CGbkmriczusMSua6bf8d8SwMEsWmUCzY+l3SgH6k+HgisiQ0aVJYVtpX8IYiyc/9DXyJVWTSwnX+bwvUwwI00t8wJPObvvnaxeg6KyMcLDCImKdML2hrxi18xSBjbtXVWPyBWT1J2+iO1FANVp0hDEGwx7cQeXCs+at1VhXX5o7jNo/iuc0tWFGd51S79KGrIE8Wp/+t8WXpl8kpsI6d7m1KS4xdQqZ/5k5jn5o/Z1f0WBGbNzdTl2k3RGY/DGLh2xjl0OUjI9RrVVeh/LI9lQ2u9PzzKARVavLbsFqBHs7TCpgUjVHryyiOEREgnMn5Zb3QsH6WvhJyHQApuTJZcxzMdq1MQ3HCChFtHnHnlSoh0PLsi28HzG5SnQ2Ufng78X6iPW5vqNeClm8gEN4g0NwsD1TurhI= 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)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6206 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DU6PEPF0000A7E1.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1fa8c3e6-b87d-498e-a5b9-08de79e33c5a X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|14060799003|82310400026|376014|36860700016|35042699022|7053199007; X-Microsoft-Antispam-Message-Info: YMnGOMfHmnzLsCoE0XYdEERtwjdSv+BEvYoKF7nFBUdSaKwmbl2A3UJCNVYaeNllH1LTj3SaICs8puGDZalqapTA8MuoSb+I7xS/G1pvX+5MVMShAlJ7ftiQqphzLjDbSQ9dVUeONMAtMLKwIO9DEMR72SH9hftIjlVw8daIywKf4uEv/MamEAsJi1b5pfibuDkayUMGO0JG3ydsAtqWY6V6gHpvYO5dKq1RXhEjKvs6Cg6gMumseFkSwKuZOEOUL2V7mI/1pinct0lU4XR00v5L9sEohmJG69/yk2fQ6x0rRTpWhuiRRUZMi28nY+M58hvim+B2ddRqbdH8QjF0xj/Op+7NBCJluZkUPzGiLllpgusnmvPe+sr5MaKQsSOtSGT1x9rjl+BfbMFy254qQhEImiaaiIdFeBb5XhTWODWx6PHK0qwRqCg+BI2Wja34RXod79xrM3zqYNDZDIBfedd4NPYDhCWVt5DSl+B+Y2aPfQaw7HJA3jVHdWEPlW7/9keAls+mXUsdUzyQym4dJM/vhdLxdvJcjZVS6Fa624LN86VsrWez4Wtn9V+7fR0jCuD+8b1UkrkiGpXL+gIyIkVRUPGiTY7ZqvUw2JbRWnEOpy6CV3NpM/ZrkYzT0UKN7OVyvhRTSDN+eMxAaCJzKoE+DCawuvo9uktNbYS9e2wIySI5laqZZf0bC5FzYUEjz4/LBodlAipfgo3Jvrg/9Hgjxha34+HJveUCox3JyvT4bw66ajirHLp/L5SA0e5XS4cRcPOsOSkVhVWoAUiSiA== 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)(1800799024)(14060799003)(82310400026)(376014)(36860700016)(35042699022)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Q93ig35uGBDnqx88ZA5OP3F9f1Q0xbM1EKb9bphIYGs8oNowftT+o74oGPkcyNKQGsLz/uRzACu16h6JPx2d9fbIaKfrZGnkoJlnqBkexhkZZY5zw8SHAv8EgRRPj0TX4eg7ALwQuqm/4TeWKi2EI0uxYJOIH39GAPfBTb8JQ20rChHxXnuBBkCC123iAwgrudWesRiESG0iTg5v1CXnFjwNwxfLoU/DhQFYOaVbvvbqtWmmreP/yv09kRyoc30OYcoT+OyaH1EZZQUiT0oHWcicrWFVTsevr5q/T5XFc11KzGMJr+OoayLd7j2zIU5oaKV4lZ/uZKAr3EisFgdlF/Ne6mB4pyklx0CpTz+RY85kV2x/kIQjCb2nbbpvS7I+U/INeiNPsiyNIPpWFFrXl9pOkC0djdo/4aGK/MCv3xSaphRSizcRJi/LcqL6sNgJ X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 11:44:24.7026 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 582fafde-b8b9-4314-8d1b-08de79e3625f 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: DU6PEPF0000A7E1.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5519 DQoNCj4gT24gNCBNYXIgMjAyNiwgYXQgMTE6NDQsIEplbnMgV2lrbGFuZGVyIDxqZW5zLndpa2xh bmRlckBsaW5hcm8ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEJlcnRyYW5kLA0KPiANCj4gT24gTW9u LCBNYXIgMiwgMjAyNiBhdCA0OjQ04oCvUE0gQmVydHJhbmQgTWFycXVpcw0KPiA8YmVydHJhbmQu bWFycXVpc0Bhcm0uY29tPiB3cm90ZToNCj4+IA0KPj4gRkYtQSB2MS4yIGRlZmluZXMgUEFSVElU SU9OX0lORk9fR0VUX1JFR1MgZm9yIHJlZ2lzdGVyLWJhc2VkIHBhcnRpdGlvbg0KPj4gaW5mbyBy ZXRyaWV2YWwsIGJ1dCBYZW4gY3VycmVudGx5IG9ubHkgc3VwcG9ydHMgdGhlIGJ1ZmZlci1iYXNl ZCBHRVQNCj4+IHBhdGggZm9yIGd1ZXN0cy4NCj4+IA0KPj4gSW1wbGVtZW50IEdFVF9SRUdTIHVz aW5nIHRoZSBjYWNoZWQgU1AgbGlzdCBhbmQgVk0gZW50cmllcywgaW5jbHVkaW5nDQo+PiB0aGUg cmVnaXN0ZXIgd2luZG93IGxheW91dCBhbmQgaW5wdXQgdmFsaWRhdGlvbi4gVHJhY2sgVk0gbGlz dCBjaGFuZ2VzDQo+PiB2aWEgdGhlIHBhcnRpbmZvIHRhZyBhbmQgdXNlIGl0IHRvIHZhbGlkYXRl IEdFVF9SRUdTIHRhZyBpbnB1dHMuIEVuc3VyZQ0KPj4gdGhhdCB3aGVuIGEgbm9uLU5pbCBVVUlE IGlzIHNwZWNpZmllZCwgdGhlIFVVSUQgZmllbGRzIGluIGJvdGggR0VUIGFuZA0KPj4gR0VUX1JF R1MgcmVzdWx0cyBhcmUgTUJaIGFzIHJlcXVpcmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uLg0KPj4g DQo+PiBQQVJUSVRJT05fSU5GT19HRVRfUkVHUyBpcyBhdmFpbGFibGUgdG8gdjEuMiBndWVzdHMs IHJldHVybmluZyBjYWNoZWQgU1ANCj4+IGVudHJpZXMgYW5kIFZNIGVudHJpZXMgd2l0aCBVVUlE cyB6ZXJvZWQgZm9yIG5vbi1OaWwgVVVJRCBxdWVyaWVzLg0KPj4gDQo+PiBBbHNvIHB1Ymxpc2gg Vk0gbWVtYmVyc2hpcCB1cGRhdGVzIChWTSBjb3VudCwgY3R4IGxpc3QsIGFuZCBwYXJ0aW5mbw0K Pj4gdGFnKSB1bmRlciB0aGUgc2FtZSB3cml0ZS1sb2NrZWQgc2VjdGlvbiBzbyBHRVRfUkVHUyBz ZWVzIGNvaGVyZW50IHN0YXRlDQo+PiBhbmQgY29uY3VycmVudCBjaGFuZ2VzIGFyZSByZWxpYWJs eSByZXBvcnRlZCB2aWEgUkVUUlkuDQo+PiANCj4+IFNpZ25lZC1vZmYtYnk6IEJlcnRyYW5kIE1h cnF1aXMgPGJlcnRyYW5kLm1hcnF1aXNAYXJtLmNvbT4NCj4+IC0tLQ0KPj4gQ2hhbmdlcyBzaW5j ZSB2MToNCj4+IC0gaWdub3JlIHg0LXgxNyBub3QgYmVpbmcgemVybyBhbmQgeDMgYml0cyA2My0z MiBub3QgYmVpbmcgemVybyAoZGVmaW5lZA0KPj4gIGFzIFNCWiBpbiB0aGUgc3BlYykNCj4+IC0g ZGV0ZWN0IHRhZyBjaGFuZ2VzIGR1cmluZyBHRVRfUkVHUyBoYW5kbGluZyBhbmQgcmV0dXJuIFJF VFJZDQo+PiAtIHJlbW92ZSBzdHJpY3QgY2hlY2sgb2Ygc3BfbGlzdF9lbnRyeV9zaXplLCBsYXJn ZXIgY2FjaGUgZW50cnkgc2l6ZXMNCj4+ICB3aWxsIG5vdyBiZSBhY2NlcHRlZA0KPj4gLSBwdWJs aXNoIFZNIGNvdW50LCBjdHggbGlzdCwgYW5kIHBhcnRpbmZvIHRhZyB1cGRhdGVzIHVuZGVyDQo+ PiAgZmZhX2N0eF9saXN0X3J3bG9jayBmb3IgY29oZXJlbnQgdmlzaWJpbGl0eQ0KPj4gLS0tDQo+ PiB4ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jICAgICAgICAgIHwgIDIzICsrKy0NCj4+IHhlbi9hcmNo L2FybS90ZWUvZmZhX3BhcnRpbmZvLmMgfCAyMDAgKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysNCj4+IHhlbi9hcmNoL2FybS90ZWUvZmZhX3ByaXZhdGUuaCAgfCAgIDQgKy0NCj4+IDMg ZmlsZXMgY2hhbmdlZCwgMjIzIGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pDQo+PiANCj4+ IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jIGIveGVuL2FyY2gvYXJtL3RlZS9m ZmEuYw0KPj4gaW5kZXggYWE0M2FlMjU5NWQ3Li5kNmNhZTY3ZTFhNDggMTAwNjQ0DQo+PiAtLS0g YS94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYS5j DQo+PiBAQCAtNDQsNiArNDQsMTEgQEANCj4+ICAqICAgLSBkb2Vzbid0IHN1cHBvcnQgc2lnbmFs bGluZyB0aGUgc2Vjb25kYXJ5IHNjaGVkdWxlciBvZiBwZW5kaW5nDQo+PiAgKiAgICAgbm90aWZp Y2F0aW9uIGZvciBzZWN1cmUgcGFydGl0aW9ucw0KPj4gICogICAtIGRvZXNuJ3Qgc3VwcG9ydCBu b3RpZmljYXRpb25zIGZvciBYZW4gaXRzZWxmDQo+PiArICogbyBGRkFfUEFSVElUSU9OX0lORk9f R0VUL0dFVF9SRUdTOg0KPj4gKyAqICAgLSB2MS4wIGd1ZXN0cyBtYXkgc2VlIGR1cGxpY2F0ZSBT UCBJRHMgd2hlbiBmaXJtd2FyZSBwcm92aWRlcyBVVUlEcw0KPj4gKyAqICAgLSBTUCBsaXN0IGlz IGNhY2hlZCBhdCBpbml0OyBTUE1DIHRhZyBjaGFuZ2VzIGFyZSBub3QgdHJhY2tlZA0KPj4gKyAq ICAgICBiZXR3ZWVuIGNhbGxzDQo+PiArICogICAtIFNQIGxpc3QgaXMgY2FwcGVkIGF0IEZGQV9N QVhfTlVNX1NQIGVudHJpZXMNCj4+ICAqDQo+PiAgKiBUaGVyZSBhcmUgc29tZSBsYXJnZSBsb2Nr ZWQgc2VjdGlvbnMgd2l0aCBmZmFfc3BtY190eF9sb2NrIGFuZA0KPj4gICogZmZhX3NwbWNfcnhf bG9jay4gRXNwZWNpYWxseSB0aGUgZmZhX3NwbWNfdHhfbG9jayBzcGlubG9jayB1c2VkDQo+PiBA QCAtMTgzLDEwICsxODgsMTEgQEAgc3RhdGljIGJvb2wgZmZhX25lZ290aWF0ZV92ZXJzaW9uKHN0 cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gDQo+PiAgICAgICAgIGlmICggSVNfRU5BQkxF RChDT05GSUdfRkZBX1ZNX1RPX1ZNKSApDQo+PiAgICAgICAgIHsNCj4+IC0gICAgICAgICAgICAv KiBPbmUgbW9yZSBWTSB3aXRoIEZGLUEgc3VwcG9ydCBhdmFpbGFibGUgKi8NCj4+IC0gICAgICAg ICAgICBpbmNfZmZhX3ZtX2NvdW50KCk7DQo+PiAgICAgICAgICAgICB3cml0ZV9sb2NrKCZmZmFf Y3R4X2xpc3Rfcndsb2NrKTsNCj4+ICsgICAgICAgICAgICAvKiBQdWJsaXNoIFZNIG1lbWJlcnNo aXAgY2hhbmdlcyBhdG9taWNhbGx5IHdpdGggdGFnIHVwZGF0ZXMuICovDQo+PiArICAgICAgICAg ICAgaW5jX2ZmYV92bV9jb3VudCgpOw0KPj4gICAgICAgICAgICAgbGlzdF9hZGRfdGFpbCgmY3R4 LT5jdHhfbGlzdCwgJmZmYV9jdHhfaGVhZCk7DQo+PiArICAgICAgICAgICAgZmZhX3BhcnRpbmZv X2luY190YWcoKTsNCj4+ICAgICAgICAgICAgIHdyaXRlX3VubG9jaygmZmZhX2N0eF9saXN0X3J3 bG9jayk7DQo+PiAgICAgICAgIH0NCj4+IA0KPj4gQEAgLTM0MSw2ICszNDcsMTIgQEAgc3RhdGlj IHZvaWQgaGFuZGxlX2ZlYXR1cmVzKHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KPj4gICAg IGNhc2UgRkZBX0ZFQVRVUkVfU0NIRURVTEVfUkVDVl9JTlRSOg0KPj4gICAgICAgICBmZmFfc2V0 X3JlZ3Nfc3VjY2VzcyhyZWdzLCBHVUVTVF9GRkFfU0NIRURVTEVfUkVDVl9JTlRSX0lELCAwKTsN Cj4+ICAgICAgICAgYnJlYWs7DQo+PiArICAgIGNhc2UgRkZBX1BBUlRJVElPTl9JTkZPX0dFVF9S RUdTOg0KPj4gKyAgICAgICAgaWYgKCBBQ0NFU1NfT05DRShjdHgtPmd1ZXN0X3ZlcnMpID49IEZG QV9WRVJTSU9OXzFfMiApDQo+PiArICAgICAgICAgICAgZmZhX3NldF9yZWdzX3N1Y2Nlc3MocmVn cywgMCwgMCk7DQo+PiArICAgICAgICBlbHNlDQo+PiArICAgICAgICAgICAgZmZhX3NldF9yZWdz X2Vycm9yKHJlZ3MsIEZGQV9SRVRfTk9UX1NVUFBPUlRFRCk7DQo+PiArICAgICAgICBicmVhazsN Cj4+IA0KPj4gICAgIGNhc2UgRkZBX05PVElGSUNBVElPTl9CSU5EOg0KPj4gICAgIGNhc2UgRkZB X05PVElGSUNBVElPTl9VTkJJTkQ6DQo+PiBAQCAtNDAyLDYgKzQxNCw5IEBAIHN0YXRpYyBib29s IGZmYV9oYW5kbGVfY2FsbChzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+ICAgICBjYXNl IEZGQV9QQVJUSVRJT05fSU5GT19HRVQ6DQo+PiAgICAgICAgIGZmYV9oYW5kbGVfcGFydGl0aW9u X2luZm9fZ2V0KHJlZ3MpOw0KPj4gICAgICAgICByZXR1cm4gdHJ1ZTsNCj4+ICsgICAgY2FzZSBG RkFfUEFSVElUSU9OX0lORk9fR0VUX1JFR1M6DQo+PiArICAgICAgICBmZmFfaGFuZGxlX3BhcnRp dGlvbl9pbmZvX2dldF9yZWdzKHJlZ3MpOw0KPj4gKyAgICAgICAgcmV0dXJuIHRydWU7DQo+PiAg ICAgY2FzZSBGRkFfUlhfUkVMRUFTRToNCj4+ICAgICAgICAgZSA9IGZmYV9yeF9yZWxlYXNlKGN0 eCk7DQo+PiAgICAgICAgIGJyZWFrOw0KPj4gQEAgLTYyNSw5ICs2NDAsMTEgQEAgc3RhdGljIGlu dCBmZmFfZG9tYWluX3RlYXJkb3duKHN0cnVjdCBkb21haW4gKmQpDQo+PiANCj4+ICAgICBpZiAo IElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19WTSkgJiYgQUNDRVNTX09OQ0UoY3R4LT5ndWVz dF92ZXJzKSApDQo+PiAgICAgew0KPj4gLSAgICAgICAgZGVjX2ZmYV92bV9jb3VudCgpOw0KPj4g ICAgICAgICB3cml0ZV9sb2NrKCZmZmFfY3R4X2xpc3Rfcndsb2NrKTsNCj4+ICsgICAgICAgIC8q IFB1Ymxpc2ggVk0gbWVtYmVyc2hpcCBjaGFuZ2VzIGF0b21pY2FsbHkgd2l0aCB0YWcgdXBkYXRl cy4gKi8NCj4+ICsgICAgICAgIGRlY19mZmFfdm1fY291bnQoKTsNCj4+ICAgICAgICAgbGlzdF9k ZWwoJmN0eC0+Y3R4X2xpc3QpOw0KPj4gKyAgICAgICAgZmZhX3BhcnRpbmZvX2luY190YWcoKTsN Cj4+ICAgICAgICAgd3JpdGVfdW5sb2NrKCZmZmFfY3R4X2xpc3Rfcndsb2NrKTsNCj4+ICAgICB9 DQo+PiANCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jIGIv eGVuL2FyY2gvYXJtL3RlZS9mZmFfcGFydGluZm8uYw0KPj4gaW5kZXggNDE5ZTE5NTEwZjZmLi4x NmRhNWVlNTY3ZGIgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5m by5jDQo+PiArKysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wYXJ0aW5mby5jDQo+PiBAQCAtMjks MTAgKzI5LDM5IEBAIHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xIHsNCj4+ICAgICB1aW50 OF90IHV1aWRbMTZdOw0KPj4gfTsNCj4+IA0KPj4gKy8qIFJlZ2lzdGVycyBhMy4uYTE3ICgxNSBy ZWdzKSBjYXJyeSBwYXJ0aXRpb24gZGVzY3JpcHRvcnMsIDMgcmVncyBlYWNoLiAqLw0KPj4gKyNk ZWZpbmUgRkZBX1BBUlRJTkZPX1JFR19NQVhfRU5UUklFUyBcDQo+PiArICAgICgoMTUgKiBzaXpl b2YodWludDY0X3QpKSAvIHNpemVvZihzdHJ1Y3QgZmZhX3BhcnRpdGlvbl9pbmZvXzFfMSkpDQo+ PiArDQo+PiAvKiBTUCBsaXN0IGNhY2hlIChzZWN1cmUgZW5kcG9pbnRzIG9ubHkpOyBwb3B1bGF0 ZWQgYXQgaW5pdC4gKi8NCj4+IHN0YXRpYyB2b2lkICpzcF9saXN0IF9fcmVhZF9tb3N0bHk7DQo+ PiBzdGF0aWMgdWludDMyX3Qgc3BfbGlzdF9jb3VudCBfX3JlYWRfbW9zdGx5Ow0KPj4gc3RhdGlj IHVpbnQzMl90IHNwX2xpc3RfZW50cnlfc2l6ZSBfX3JlYWRfbW9zdGx5Ow0KPj4gKw0KPj4gKy8q IFNQIGxpc3QgaXMgc3RhdGljOyB0YWcgb25seSBtb3ZlcyB3aGVuIFZNcyBhcmUgYWRkZWQvcmVt b3ZlZC4gKi8NCj4+ICtzdGF0aWMgYXRvbWljX3QgZmZhX3BhcnRpbmZvX3RhZyA9IEFUT01JQ19J TklUKDEpOw0KPj4gKw0KPj4gK3ZvaWQgZmZhX3BhcnRpbmZvX2luY190YWcodm9pZCkNCj4+ICt7 DQo+PiArICAgIGF0b21pY19pbmMoJmZmYV9wYXJ0aW5mb190YWcpOw0KPj4gK30NCj4+ICsNCj4+ ICtzdGF0aWMgaW5saW5lIHVpbnQxNl90IGZmYV9wYXJ0aW5mb19nZXRfdGFnKHZvaWQpDQo+PiAr ew0KPj4gKyAgICAvKg0KPj4gKyAgICAgKiBUYWcgbW92ZXMgd2l0aCBWTSBsaXN0IGNoYW5nZXMg b25seS4NCj4+ICsgICAgICoNCj4+ICsgICAgICogTGltaXRhdGlvbjogd2UgY2Fubm90IGRldGVj dCBhbiBTUE1DIHRhZyBjaGFuZ2UgYmV0d2VlbiBjYWxscyBiZWNhdXNlIHdlDQo+PiArICAgICAq IGRvIG5vdCByZXRhaW4gdGhlIHByZXZpb3VzIFNQTUMgdGFnOyB3ZSBvbmx5IHJlZnJlc2ggaXQg dmlhIHRoZSBtYW5kYXRvcnkNCj4+ICsgICAgICogc3RhcnRfaW5kZXg9MCBjYWxsIGFuZCBhc3N1 bWUgaXQgc3RheXMgc3RhYmxlIHdoaWxlIGNvbWJpbmVkX3RhZyAob3VyDQo+PiArICAgICAqIFZN L1NQLWNvdW50IHRhZykgaXMgdXNlZCBmb3IgZ3Vlc3QgdmFsaWRhdGlvbi4gVGhpcyBtZWFucyBT UE1DIHRhZw0KPj4gKyAgICAgKiBjaGFuZ2VzIGFsb25lIHdpbGwgbm90IHRyaWdnZXIgUkVUUlku DQo+PiArICAgICAqLw0KPj4gKyAgICBpZiAoIElTX0VOQUJMRUQoQ09ORklHX0ZGQV9WTV9UT19W TSkgKQ0KPj4gKyAgICAgICAgcmV0dXJuIGF0b21pY19yZWFkKCZmZmFfcGFydGluZm9fdGFnKSAm IEdFTk1BU0soMTUsIDApOw0KPj4gKyAgICBlbHNlDQo+PiArICAgICAgICByZXR1cm4gMTsNCj4+ ICt9DQo+IA0KPiBQbGVhc2UgYWRkIGFuIGVtcHR5IGxpbmUgaGVyZS4NCg0KYWNrDQoNCj4gDQo+ PiBzdGF0aWMgaW50MzJfdCBmZmFfcGFydGl0aW9uX2luZm9fZ2V0KHN0cnVjdCBmZmFfdXVpZCB1 dWlkLCB1aW50MzJfdCBmbGFncywNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdWludDMyX3QgKmNvdW50LCB1aW50MzJfdCAqZnBpX3NpemUpDQo+PiB7DQo+PiBAQCAt MTQwLDYgKzE2OSw3IEBAIHN0YXRpYyBpbnQzMl90IGZmYV9nZXRfc3BfcGFydGluZm8oc3RydWN0 IGZmYV91dWlkIHV1aWQsIHVpbnQzMl90ICpzcF9jb3VudCwNCj4+ICAgICBmb3IgKCBuID0gMDsg biA8IHNwX2xpc3RfY291bnQ7IG4rKyApDQo+PiAgICAgew0KPj4gICAgICAgICB2b2lkICplbnRy eSA9IHNwX2xpc3QgKyBuICogc3BfbGlzdF9lbnRyeV9zaXplOw0KPj4gKyAgICAgICAgdm9pZCAq ZHN0X3BvczsNCj4+IA0KPj4gICAgICAgICBpZiAoICFmZmFfc3BfZW50cnlfbWF0Y2hlc191dWlk KGVudHJ5LCB1dWlkKSApDQo+PiAgICAgICAgICAgICBjb250aW51ZTsNCj4+IEBAIC0xNTEsMTEg KzE4MSwyMCBAQCBzdGF0aWMgaW50MzJfdCBmZmFfZ2V0X3NwX3BhcnRpbmZvKHN0cnVjdCBmZmFf dXVpZCB1dWlkLCB1aW50MzJfdCAqc3BfY291bnQsDQo+PiAgICAgICAgICAqIFRoaXMgaXMgYSBu b24tY29tcGxpYW5jZSB0byB0aGUgc3BlY2lmaWNhdGlvbiBidXQgMS4wIFZNcyBzaG91bGQNCj4+ ICAgICAgICAgICogaGFuZGxlIHRoYXQgb24gdGhlaXIgb3duIHRvIHNpbXBsaWZ5IFhlbiBpbXBs ZW1lbnRhdGlvbi4NCj4+ICAgICAgICAgICovDQo+PiArICAgICAgICBkc3RfcG9zID0gKmRzdF9i dWY7DQo+PiAgICAgICAgIHJldCA9IGZmYV9jb3B5X2luZm8oZHN0X2J1ZiwgZW5kX2J1ZiwgZW50 cnksIGRzdF9zaXplLA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwX2xpc3RfZW50 cnlfc2l6ZSk7DQo+PiAgICAgICAgIGlmICggcmV0ICkNCj4+ICAgICAgICAgICAgIHJldHVybiBy ZXQ7DQo+PiANCj4+ICsgICAgICAgIGlmICggIWZmYV91dWlkX2lzX25pbCh1dWlkKSAmJg0KPj4g KyAgICAgICAgICAgICBkc3Rfc2l6ZSA+PSBzaXplb2Yoc3RydWN0IGZmYV9wYXJ0aXRpb25faW5m b18xXzEpICkNCj4+ICsgICAgICAgIHsNCj4+ICsgICAgICAgICAgICBzdHJ1Y3QgZmZhX3BhcnRp dGlvbl9pbmZvXzFfMSAqZnBpID0gZHN0X3BvczsNCj4+ICsNCj4+ICsgICAgICAgICAgICBtZW1z ZXQoZnBpLT51dWlkLCAwLCBzaXplb2YoZnBpLT51dWlkKSk7DQo+PiArICAgICAgICB9DQo+PiAr DQo+PiAgICAgICAgIGNvdW50Kys7DQo+PiAgICAgfQ0KPj4gDQo+PiBAQCAtMTY3LDYgKzIwNiwz OCBAQCBzdGF0aWMgaW50MzJfdCBmZmFfZ2V0X3NwX3BhcnRpbmZvKHN0cnVjdCBmZmFfdXVpZCB1 dWlkLCB1aW50MzJfdCAqc3BfY291bnQsDQo+PiAgICAgcmV0dXJuIEZGQV9SRVRfT0s7DQo+PiB9 DQo+PiANCj4+ICtzdGF0aWMgdWludDE2X3QgZmZhX2dldF9zcF9wYXJ0aW5mb19yZWdzKHN0cnVj dCBmZmFfdXVpZCB1dWlkLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdWludDE2X3Qgc3RhcnRfaW5kZXgsDQo+PiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50NjRfdCAqb3V0X3JlZ3MsDQo+PiArICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MTZfdCBtYXhfZW50cmllcykNCj4+ICt7DQo+ PiArICAgIHVpbnQzMl90IGlkeCA9IDA7DQo+PiArICAgIHVpbnQxNl90IGZpbGxlZCA9IDA7DQo+ PiArICAgIHVpbnQzMl90IG47DQo+PiArDQo+PiArICAgIGZvciAoIG4gPSAwOyBuIDwgc3BfbGlz dF9jb3VudCAmJiBmaWxsZWQgPCBtYXhfZW50cmllczsgbisrICkNCj4+ICsgICAgew0KPj4gKyAg ICAgICAgdm9pZCAqZW50cnkgPSBzcF9saXN0ICsgbiAqIHNwX2xpc3RfZW50cnlfc2l6ZTsNCj4+ ICsNCj4+ICsgICAgICAgIGlmICggIWZmYV9zcF9lbnRyeV9tYXRjaGVzX3V1aWQoZW50cnksIHV1 aWQpICkNCj4+ICsgICAgICAgICAgICBjb250aW51ZTsNCj4+ICsNCj4+ICsgICAgICAgIGlmICgg aWR4KysgPCBzdGFydF9pbmRleCApDQo+PiArICAgICAgICAgICAgY29udGludWU7DQo+PiArDQo+ PiArICAgICAgICBtZW1jcHkoJm91dF9yZWdzW2ZpbGxlZCAqIDNdLCBlbnRyeSwNCj4+ICsgICAg ICAgICAgICAgICBzaXplb2Yoc3RydWN0IGZmYV9wYXJ0aXRpb25faW5mb18xXzEpKTsNCj4+ICsg ICAgICAgIGlmICggIWZmYV91dWlkX2lzX25pbCh1dWlkKSApDQo+PiArICAgICAgICB7DQo+PiAr ICAgICAgICAgICAgb3V0X3JlZ3NbZmlsbGVkICogMyArIDFdID0gMDsNCj4+ICsgICAgICAgICAg ICBvdXRfcmVnc1tmaWxsZWQgKiAzICsgMl0gPSAwOw0KPj4gKyAgICAgICAgfQ0KPj4gKyAgICAg ICAgZmlsbGVkKys7DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcmV0dXJuIGZpbGxlZDsNCj4+ ICt9DQo+PiArDQo+PiBzdGF0aWMgaW50MzJfdCBmZmFfZ2V0X3ZtX3BhcnRpbmZvKHN0cnVjdCBm ZmFfdXVpZCB1dWlkLCB1aW50MzJfdCBzdGFydF9pbmRleCwNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdWludDMyX3QgKnZtX2NvdW50LCB2b2lkICoqZHN0X2J1ZiwNCj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZW5kX2J1ZiwgdWludDMy X3QgZHN0X3NpemUpDQo+PiBAQCAtMzgzLDYgKzQ1NCwxMzUgQEAgb3V0Og0KPj4gICAgIH0NCj4+ IH0NCj4+IA0KPj4gK3ZvaWQgZmZhX2hhbmRsZV9wYXJ0aXRpb25faW5mb19nZXRfcmVncyhzdHJ1 Y3QgY3B1X3VzZXJfcmVncyAqcmVncykNCj4+ICt7DQo+PiArICAgIHN0cnVjdCBkb21haW4gKmQg PSBjdXJyZW50LT5kb21haW47DQo+PiArICAgIHN0cnVjdCBmZmFfY3R4ICpjdHggPSBkLT5hcmNo LnRlZTsNCj4+ICsgICAgc3RydWN0IGZmYV91dWlkIHV1aWQ7DQo+PiArICAgIHVpbnQzMl90IHNw X2NvdW50ID0gMCwgdm1fY291bnQgPSAwLCB0b3RhbF9jb3VudDsNCj4+ICsgICAgdWludDE2X3Qg c3RhcnRfaW5kZXgsIHRhZzsNCj4+ICsgICAgdWludDE2X3QgbnVtX2VudHJpZXMgPSAwOw0KPj4g KyAgICB1aW50NjRfdCB4MyA9IGdldF91c2VyX3JlZyhyZWdzLCAzKTsNCj4+ICsgICAgaW50MzJf dCByZXQgPSBGRkFfUkVUX09LOw0KPj4gKyAgICB1aW50NjRfdCBvdXRfcmVnc1sxOF0gPSB7IDAg fTsNCj4+ICsgICAgdW5zaWduZWQgaW50IG47DQo+PiArICAgIHVpbnQxNl90IHRhZ19vdXQsIHRh Z19lbmQ7DQo+PiArDQo+PiArICAgIGlmICggQUNDRVNTX09OQ0UoY3R4LT5ndWVzdF92ZXJzKSA8 IEZGQV9WRVJTSU9OXzFfMiApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHJldCA9IEZGQV9SRVRf Tk9UX1NVUFBPUlRFRDsNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKyAgICB9DQo+PiArDQo+ PiArICAgIC8qDQo+PiArICAgICAqIFJlZ2lzdGVycyBhMy4uYTE3ICgxNSByZWdzKSBjYXJyeSBw YXJ0aXRpb24gZGVzY3JpcHRvcnMsIDMgcmVncyBlYWNoLg0KPj4gKyAgICAgKiBGb3IgRkYtQSAx LjIsIHRoYXQgeWllbGRzIGEgbWF4aW11bSBvZiA1IGVudHJpZXMgcGVyIEdFVF9SRUdTIGNhbGwu DQo+PiArICAgICAqIEVuZm9yY2UgdGhlIGFzc3VtZWQgbGF5b3V0IHNvIHdpbmRvdyBzaXppbmcg c3RheXMgY29ycmVjdC4NCj4+ICsgICAgICovDQo+PiArICAgIEJVSUxEX0JVR19PTihGRkFfUEFS VElORk9fUkVHX01BWF9FTlRSSUVTICE9IDUpOw0KPj4gKw0KPj4gKyAgICBzdGFydF9pbmRleCA9 IHgzICYgR0VOTUFTSygxNSwgMCk7DQo+PiArICAgIHRhZyA9ICh4MyA+PiAxNikgJiBHRU5NQVNL KDE1LCAwKTsNCj4+ICsNCj4+ICsgICAgLyogU3RhcnQgaW5kZXggbXVzdCBhbGxvdyByb29tIGZv ciB1cCB0byA1IGVudHJpZXMgd2l0aG91dCAxNi1iaXQgb3ZlcmZsb3cuICovDQo+IA0KPiBOaXQ6 IFRoZSBsaW5lIGFib3ZlIGlzIG92ZXIgODAgY29sdW1ucy4NCg0KUmlnaHQsIGhvdyBkaWQgaSBt aXNzIHRoYXQuDQoNCj4gDQo+IFdpdGggb3Igd2l0aG91dCB0aGUgbGluZSBhYm92ZSBmaXhlZC4g TG9va3MgZ29vZC4NCj4gUmV2aWV3ZWQtYnk6IEplbnMgV2lrbGFuZGVyIDxqZW5zLndpa2xhbmRl ckBsaW5hcm8ub3JnPg0KDQpUaGFua3MsDQoNCkkgd2lsbCBjaGVjayBpZiB0aG9zZSBjYW4gYmUg Zml4ZWQgb24gY29tbWl0IG90aGVyd2lzZSBpIHdpbGwgZml4IHRob3NlIDIgYW5kDQpzdWJtaXQg YSB2MyB3aXRoIHlvdXIgUi1iIG9uIGFsbCBwYXRjaGVzIDotKQ0KDQpDaGVlcnMNCkJlcnRyYW5k DQoNCj4gDQo+IENoZWVycywNCj4gSmVucw0KPiANCj4+ICsgICAgaWYgKCBzdGFydF9pbmRleCA+ IChHRU5NQVNLKDE1LCAwKSAtIChGRkFfUEFSVElORk9fUkVHX01BWF9FTlRSSUVTIC0gMSkpICkN Cj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7 DQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICB1dWlkLnZh bFswXSA9IGdldF91c2VyX3JlZyhyZWdzLCAxKTsNCj4+ICsgICAgdXVpZC52YWxbMV0gPSBnZXRf dXNlcl9yZWcocmVncywgMik7DQo+PiArDQo+PiArICAgIHRhZ19vdXQgPSBmZmFfcGFydGluZm9f Z2V0X3RhZygpOw0KPj4gKw0KPj4gKyAgICBpZiAoIHN0YXJ0X2luZGV4ID09IDAgKQ0KPj4gKyAg ICB7DQo+PiArICAgICAgICBpZiAoIHRhZyApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAg ICAgcmV0ID0gRkZBX1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7DQo+PiArICAgICAgICAgICAgZ290 byBvdXQ7DQo+PiArICAgICAgICB9DQo+PiArICAgIH0NCj4+ICsgICAgZWxzZSBpZiAoIHRhZyAh PSB0YWdfb3V0ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9SRVRSWTsN Cj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlmICggZmZh X3V1aWRfaXNfbmlsKHV1aWQpICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgaWYgKCBJU19FTkFC TEVEKENPTkZJR19GRkFfVk1fVE9fVk0pICkNCj4+ICsgICAgICAgICAgICB2bV9jb3VudCA9IGdl dF9mZmFfdm1fY291bnQoKTsNCj4+ICsgICAgICAgIGVsc2UNCj4+ICsgICAgICAgICAgICB2bV9j b3VudCA9IDE7IC8qIENhbGxlciBWTSBvbmx5ICovDQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAg cmV0ID0gZmZhX2dldF9zcF9jb3VudCh1dWlkLCAmc3BfY291bnQpOw0KPj4gKyAgICBpZiAoIHJl dCApDQo+PiArICAgICAgICBnb3RvIG91dDsNCj4+ICsNCj4+ICsgICAgdG90YWxfY291bnQgPSBz cF9jb3VudCArIHZtX2NvdW50Ow0KPj4gKw0KPj4gKyAgICBpZiAoIHRvdGFsX2NvdW50ID09IDAg fHwgc3RhcnRfaW5kZXggPj0gdG90YWxfY291bnQgKQ0KPj4gKyAgICB7DQo+PiArICAgICAgICBy ZXQgPSBGRkFfUkVUX0lOVkFMSURfUEFSQU1FVEVSUzsNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0K Pj4gKyAgICB9DQo+PiArDQo+PiArICAgIGlmICggc3RhcnRfaW5kZXggPCBzcF9jb3VudCApDQo+ PiArICAgICAgICBudW1fZW50cmllcyA9IGZmYV9nZXRfc3BfcGFydGluZm9fcmVncyh1dWlkLCBz dGFydF9pbmRleCwgJm91dF9yZWdzWzNdLA0KPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRkZBX1BBUlRJTkZPX1JFR19NQVhfRU5UUklFUyk7DQo+PiAr DQo+PiArICAgIGlmICggbnVtX2VudHJpZXMgPCBGRkFfUEFSVElORk9fUkVHX01BWF9FTlRSSUVT ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgdWludDMyX3Qgdm1fc3RhcnQgPSBzdGFydF9pbmRl eCA+IHNwX2NvdW50ID8NCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RhcnRfaW5k ZXggLSBzcF9jb3VudCA6IDA7DQo+PiArICAgICAgICB1aW50MzJfdCBmaWxsZWQgPSAwOw0KPj4g KyAgICAgICAgdm9pZCAqdm1fZHN0ID0gJm91dF9yZWdzWzMgKyBudW1fZW50cmllcyAqIDNdOw0K Pj4gKyAgICAgICAgdm9pZCAqdm1fZW5kID0gJm91dF9yZWdzWzE4XTsNCj4+ICsNCj4+ICsgICAg ICAgIHJldCA9IGZmYV9nZXRfdm1fcGFydGluZm8odXVpZCwgdm1fc3RhcnQsICZmaWxsZWQsICZ2 bV9kc3QsIHZtX2VuZCwNCj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6 ZW9mKHN0cnVjdCBmZmFfcGFydGl0aW9uX2luZm9fMV8xKSk7DQo+PiArICAgICAgICBpZiAoIHJl dCAhPSBGRkFfUkVUX09LICYmIHJldCAhPSBGRkFfUkVUX05PX01FTU9SWSApDQo+PiArICAgICAg ICAgICAgZ290byBvdXQ7DQo+PiArDQo+PiArICAgICAgICBudW1fZW50cmllcyArPSBmaWxsZWQ7 DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgaWYgKCBudW1fZW50cmllcyA9PSAwICkNCj4+ICsg ICAgew0KPj4gKyAgICAgICAgcmV0ID0gRkZBX1JFVF9JTlZBTElEX1BBUkFNRVRFUlM7DQo+PiAr ICAgICAgICBnb3RvIG91dDsNCj4+ICsgICAgfQ0KPj4gKw0KPj4gKyAgICAvKg0KPj4gKyAgICAg KiBEZXRlY3QgbGlzdCBjaGFuZ2VzIHdoaWxlIGJ1aWxkaW5nIHRoZSByZXNwb25zZSBzbyB0aGUg Y2FsbGVyIGNhbiByZXRyeQ0KPj4gKyAgICAgKiB3aXRoIGEgY29oZXJlbnQgc25hcHNob3QgdGFn Lg0KPj4gKyAgICAgKi8NCj4+ICsgICAgdGFnX2VuZCA9IGZmYV9wYXJ0aW5mb19nZXRfdGFnKCk7 DQo+PiArICAgIGlmICggdGFnX2VuZCAhPSB0YWdfb3V0ICkNCj4+ICsgICAgew0KPj4gKyAgICAg ICAgcmV0ID0gRkZBX1JFVF9SRVRSWTsNCj4+ICsgICAgICAgIGdvdG8gb3V0Ow0KPj4gKyAgICB9 DQo+PiArDQo+PiArICAgIG91dF9yZWdzWzBdID0gRkZBX1NVQ0NFU1NfNjQ7DQo+PiArICAgIG91 dF9yZWdzWzJdID0gKCh1aW50NjRfdClzaXplb2Yoc3RydWN0IGZmYV9wYXJ0aXRpb25faW5mb18x XzEpIDw8IDQ4KSB8DQo+PiArICAgICAgICAgICAgICAgICAgKCh1aW50NjRfdCl0YWdfZW5kIDw8 IDMyKSB8DQo+PiArICAgICAgICAgICAgICAgICAgKCh1aW50NjRfdCkoc3RhcnRfaW5kZXggKyBu dW1fZW50cmllcyAtIDEpIDw8IDE2KSB8DQo+PiArICAgICAgICAgICAgICAgICAgKCh1aW50NjRf dCkodG90YWxfY291bnQgLSAxKSAmIEdFTk1BU0soMTUsIDApKTsNCj4+ICsNCj4+ICsgICAgZm9y ICggbiA9IDA7IG4gPCBBUlJBWV9TSVpFKG91dF9yZWdzKTsgbisrICkNCj4+ICsgICAgICAgIHNl dF91c2VyX3JlZyhyZWdzLCBuLCBvdXRfcmVnc1tuXSk7DQo+PiArDQo+PiArICAgIHJldHVybjsN Cj4+ICsNCj4+ICtvdXQ6DQo+PiArICAgIGlmICggcmV0ICkNCj4+ICsgICAgICAgIGZmYV9zZXRf cmVnc19lcnJvcihyZWdzLCByZXQpOw0KPj4gK30NCj4+ICsNCj4+IHN0YXRpYyBpbnQzMl90IGZm YV9kaXJlY3RfcmVxX3NlbmRfdm0odWludDE2X3Qgc3BfaWQsIHVpbnQxNl90IHZtX2lkLA0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50OF90IG1zZykNCj4+IHsN Cj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wcml2YXRlLmggYi94ZW4vYXJj aC9hcm0vdGVlL2ZmYV9wcml2YXRlLmgNCj4+IGluZGV4IDFhNjMyOTgzYzg2MC4uYzI5MWYzMmI1 NmZmIDEwMDY0NA0KPj4gLS0tIGEveGVuL2FyY2gvYXJtL3RlZS9mZmFfcHJpdmF0ZS5oDQo+PiAr KysgYi94ZW4vYXJjaC9hcm0vdGVlL2ZmYV9wcml2YXRlLmgNCj4+IEBAIC0yODksNyArMjg5LDcg QEANCj4+ICNkZWZpbmUgRkZBX01TR19TRU5EMiAgICAgICAgICAgICAgICAgICAweDg0MDAwMDg2 VQ0KPj4gI2RlZmluZSBGRkFfQ09OU09MRV9MT0dfMzIgICAgICAgICAgICAgIDB4ODQwMDAwOEFV DQo+PiAjZGVmaW5lIEZGQV9DT05TT0xFX0xPR182NCAgICAgICAgICAgICAgMHhDNDAwMDA4QVUN Cj4+IC0jZGVmaW5lIEZGQV9QQVJUSVRJT05fSU5GT19HRVRfUkVHUyAgICAgMHg4NDAwMDA4QlUN Cj4+ICsjZGVmaW5lIEZGQV9QQVJUSVRJT05fSU5GT19HRVRfUkVHUyAgICAgMHhDNDAwMDA4QlUN Cj4+ICNkZWZpbmUgRkZBX01TR19TRU5EX0RJUkVDVF9SRVEyICAgICAgICAweEM0MDAwMDhEVQ0K Pj4gI2RlZmluZSBGRkFfTVNHX1NFTkRfRElSRUNUX1JFU1AyICAgICAgIDB4QzQwMDAwOEVVDQo+ PiANCj4+IEBAIC00NTIsNiArNDUyLDggQEAgYm9vbCBmZmFfcGFydGluZm9faW5pdCh2b2lkKTsN Cj4+IGludDMyX3QgZmZhX3BhcnRpbmZvX2RvbWFpbl9pbml0KHN0cnVjdCBkb21haW4gKmQpOw0K Pj4gYm9vbCBmZmFfcGFydGluZm9fZG9tYWluX2Rlc3Ryb3koc3RydWN0IGRvbWFpbiAqZCk7DQo+ PiB2b2lkIGZmYV9oYW5kbGVfcGFydGl0aW9uX2luZm9fZ2V0KHN0cnVjdCBjcHVfdXNlcl9yZWdz ICpyZWdzKTsNCj4+ICt2b2lkIGZmYV9oYW5kbGVfcGFydGl0aW9uX2luZm9fZ2V0X3JlZ3Moc3Ry dWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpOw0KPj4gK3ZvaWQgZmZhX3BhcnRpbmZvX2luY190YWco dm9pZCk7DQo+PiANCj4+IGludDMyX3QgZmZhX2VuZHBvaW50X2RvbWFpbl9sb29rdXAodWludDE2 X3QgZW5kcG9pbnRfaWQsIHN0cnVjdCBkb21haW4gKipkX291dCwNCj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGZmYV9jdHggKipjdHhfb3V0KTsNCj4+IC0tDQo+ PiAyLjUyLjANCg0KDQo= From xen-devel-bounces@lists.xenproject.org Wed Mar 04 13:39:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 13:39:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245371.1544706 (Exim 4.92) (envelope-from ) id 1vxmRP-0005vi-2D; Wed, 04 Mar 2026 13:39:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245371.1544706; Wed, 04 Mar 2026 13:39:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxmRO-0005vb-Uo; Wed, 04 Mar 2026 13:39:06 +0000 Received: by outflank-mailman (input) for mailman id 1245371; Wed, 04 Mar 2026 13:39:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxmRO-0005vT-6r for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 13:39:06 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 82981ee1-17cf-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 14:39:04 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-48374014a77so83354745e9.3 for ; Wed, 04 Mar 2026 05:39:04 -0800 (PST) Received: from [10.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-48518807293sm50031755e9.11.2026.03.04.05.39.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 05:39:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 82981ee1-17cf-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772631544; x=1773236344; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=X8CtSVUJuB+yYJVb/WeTxprdobFeg8yLEY1rCMe57LE=; b=L3t+bEsRf2k7Cm9FOtMr+P7q8Jmt4Q97e/m+I5P6Tb7wCaOvZffh6C0bjawMe+YUJl cGSb2c6hlU4Za7BEZUwdDjWqBbzOdzQIOU4Szu7mtsSD+5SW7R+3BZ4+7ltALEm0AiH7 NxJuu0naz1qfA+XTkXBp8KpIxxjvZ/uaeSCTNDz4fJZ0UvHXCSnMiXNZlgZYIPQN4kYD TvrHmV/PuEUauVdculw8/xN3ktGJ4ezL5Z5mbpbz4T2+sxKHsy3fF24K3Twi9MM8wKQX LuFQi9/E7/t++cz4dBD2vljtvCB6T8q53gqCqdUoYEshO0ML9R86KwSfAz66tjGVGWzH YWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772631544; x=1773236344; h=content-transfer-encoding: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; bh=X8CtSVUJuB+yYJVb/WeTxprdobFeg8yLEY1rCMe57LE=; b=D2PB9pVAKhO5qVt7/oM8LJEHxwN23q3bddqCSCjRcAm5Zu+oWJMQcgwBydvLsvbaol 1JgcVoGUC7I7y90uAHYY+U0LVgWox02o1xEVbmauWlGH9WOT+EsURxCvcT4rntPA6/X5 48pcVkovc6yZqWAp7v9CLEIYfvpWJ4HiD5setLZnlCS/yxuAXylz40We2yIDGS9mPEsi IeIHiSb2ZLrvYIJG1Izz1uIEvpLm0HWWmo8Z/6IDevxX7lBC0oehVkuqBGcR1+90QudE zTG/m+HoF0vnHiA0IJ9JjDmWGYXgfATMSQ4uJr2X2g662NC/t8+AKSOcHr2zJ11ctWyh p4Tw== X-Gm-Message-State: AOJu0YzqwavaZSCwbOe3wOXohI0P2emPN/vHHFbMzdJ5mPK6teqTwK4C Za9T7xUA4GHEfm9MySqZfxFZsPdrtiCCbd/k5lKCN6h/Fp8Lzt3PtOQpvcMuhpPtdgWlv3BAqSn FKus= X-Gm-Gg: ATEYQzweliDychRUsTdH2tJEsCw80hel6T2Pk146Damin6qGWS0XA7WoOEap6Ysfhnz vkvmbddST1eygJWPNxq8TwTbjNVEPbEugwF3zPBQ9SitL9RmJX9FRU86IRypPHfDF3n/JPgev0w qPbXYOL4tOeGCuHIuoDkuq0/gDyZuxWt25fyrtNo3aSVYX+r4JYntaeFZtSryMJMpXQi46C5r9Z R36ztb60+qMiaF+8PdXJralyKp2OfAhQd2JmvwyFewWGxTnlOPQxOqwtkGRdhc0knfXJzONwQ01 tEcD1EATvx1dvfVoOxU6sD8VNGvfG8AYGDYoMoaDOpPNy9XySFSlWQbbuJkk4km9jQbT0vCKOHI 3LJsj/hsargqdgEGvY82n93OormL//B91t/3kjgEvCc++IrqsvzcMk9wE0Qd1g4SA/emgWuxCOi A1dcha6eVBCTUk5kVM5O7qkkh09fgy6s4VXtLTs+iSxzJU4NJC07YUm8Plo5TipPTTnI9W161Xi 2Nb25swVdrCH7M= X-Received: by 2002:a05:600c:4e8b:b0:480:1d0b:2d32 with SMTP id 5b1f17b1804b1-48519847bb7mr35003105e9.12.1772631543674; Wed, 04 Mar 2026 05:39:03 -0800 (PST) Message-ID: <12fbad10-78ad-4679-a1db-3995e34da094@suse.com> Date: Wed, 4 Mar 2026 14:39:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Marek Marczykowski From: Jan Beulich Subject: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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: 8bit MCE init for APs was broken when CPU feature re-checking was added. MTRR (re)init for the BSP looks to never have been there on the resume path. Fixes: bb502a8ca592 ("x86: check feature flags after resume") Reported-by: Marek Marczykowski-Górecki Signed-off-by: Jan Beulich --- Sadly we need to go by CPU number (zero vs non-zero) here. See the call site of recheck_cpu_features() in enter_state(). --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -642,16 +642,21 @@ void identify_cpu(struct cpuinfo_x86 *c) smp_processor_id()); } - if (system_state == SYS_STATE_resume) - return; + if (system_state == SYS_STATE_resume) { + unsigned int cpu = smp_processor_id(); + if (cpu) + mcheck_init(&cpu_data[cpu], false); + else /* Yes, the BSP needs to use the AP function here. */ + mtrr_ap_init(); + } /* * On SMP, boot_cpu_data holds the common feature set between * all CPUs; so make sure that we indicate which features are * common between the CPUs. The first time this routine gets * executed, c == &boot_cpu_data. */ - if ( c != &boot_cpu_data ) { + else if (c != &boot_cpu_data) { /* AND the already accumulated flags with these */ for ( i = 0 ; i < NCAPINTS ; i++ ) boot_cpu_data.x86_capability[i] &= c->x86_capability[i]; From xen-devel-bounces@lists.xenproject.org Wed Mar 04 13:47:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 13:47:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245383.1544715 (Exim 4.92) (envelope-from ) id 1vxmYx-0007Vn-QJ; Wed, 04 Mar 2026 13:46:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245383.1544715; Wed, 04 Mar 2026 13:46:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxmYx-0007Vg-NU; Wed, 04 Mar 2026 13:46:55 +0000 Received: by outflank-mailman (input) for mailman id 1245383; Wed, 04 Mar 2026 13:46:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxmYw-0007Ur-AI for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 13:46:54 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 97140d81-17d0-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 14:46:49 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN2PR03MB5101.namprd03.prod.outlook.com (2603:10b6:208:1b0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 13:46:44 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 13:46:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 97140d81-17d0-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VTwTDRf7O1aULMmJhJwLYyQiSK5dLU07N7Fd1VrXe82iw71RGsn/Z0U5ZYTzXcCHKIFf4JZ4gdS90GTOZBAKwVHapd0H5MG078resBQLiA3LbEAvRebHNX0oA1+qeOYAVELxT/h02rr4PIejZTI7xFoA3DIjWe9inRfKMNNY9neVGL9WOZJwTvhOY+edpbDAiU4KyihGXuuetcqETJ9B9sQlPMSnsYJ/XXu5e9boX3K/mfcRA6Fjo9Y7E4kbR8FRWfbvud3MfwIbN79RBUxG5Yoj54qxW4N4BdWYOGmTkNWJk1uzctnQgyR57s6a3hkPzqAoAaaX3K3mSfQ+Tr0C4w== 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=Hxei7N0ZENe5GUPjpfgHtnam0kPoo4xnJveyz9Th7AI=; b=hlF+GGh5ZIlBlP+/Q4QUVwhjSgNQVjp/IWM5A+vT2V90SvyPhXasYe688PQojwiSk1FMnHJKy/fTnBXw7fewXbTGHaVCDq6oGcmrdJy500xwbr6JscRNp8kyMXkx6rV6ZP5pq7mIJtbsNUcDyTmbj53x3Ij+0BhgEZnEyxu6XGmjnOm967SDi3t+UZNBOWvOa1pVrs4Xx4UkIWb1u+Bp7pRY0X6Ve5jMjOJ1zPJQR5k8hhwTZA40S4mfKZFtKGLMEa/+GPtKf8cIV4qT674/5FIbl0IsWSVv3O8H1R8UrNp6ehXGSa0ABd1P4Bp66bE1MgrVk58VT0Xs97A2+ZV8yg== 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=Hxei7N0ZENe5GUPjpfgHtnam0kPoo4xnJveyz9Th7AI=; b=TaZBl+7OthGxbZtDGYYbGaKnNBl6pTF5KRiHeqprhf56Id/7h8QKUcVdcg1npMGrvC0HkyO+GS7cHpR/Kg/hMWZ2I2UGSEPOChLKTb9GxtIt7R1sBFHLbCVdprtZVQ2tknfDuKLA/1KMVUYeLECVBTrIiDNgFaQb+eXha7aQ44w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 14:46:41 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 4/5] vPCI/ReBAR: improve cleanup Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <252e527e-dcb2-4710-8a43-070c49512e00@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <252e527e-dcb2-4710-8a43-070c49512e00@suse.com> X-ClientProxiedBy: MA3P292CA0070.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN2PR03MB5101:EE_ X-MS-Office365-Filtering-Correlation-Id: 16e62419-3e62-46fb-a17e-08de79f47946 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007; X-Microsoft-Antispam-Message-Info: i/c60Crv33QwZevC5zmRLM9uaOFQ3UlccD6dtg74LANfuH8Qqa/eYCGRrLtI7zt7fFjFShJXhsw1tdKfm1zoyEcSZNhBwNrwf7T9mxKIZTrWoNZlqvPhHPn1Ggg8gjydD+mvfvaMiaiRtLYKk8WsGc99yFve6iB5dbeymVETxLhOhTk+qyRrMqcwj8ktwz/ZDjkh7MCN8BNtZVJldUH7Tp7Kb+YiwL/0sz85IDPDAWdg0cZCZkFLb5JE2fbzRRRFupYyCpDMn/0tZPKTXdVjGL3IvtbctZkKEzabs9K0zBZMX7JmqCIy6j601PGygNFN+jHWGBICZ2E76JSDGXIh4dG86fGQoaR2ufhNSGBJPBK9ZtKoAKV0WyQf2tG3xCurIZomxPPPrYxJ7+8TVeopfkqDyWV5HnqC3XB9iGy99Z2CbyPTgPO9Nb/fh+6rC0nCsNwBpXp22E1WoR0+65oSYfhK6hkhCJP8heWPJA8g9mveNU8tp7GfEE4ZF4WIz4I68DSWyX/cDax5hthbcAEv4Prr7hdOyLY4oTQ0uvBOdqABBHXCMLM/MVtWipYuWv9YKC2Q8ce921gF4K/deoXwW/pJR6Sqy4fybAPnL38WopsLQp/oh7yEQbShlUSvk3SId4hRZyyfeXB9Y61T+5dH1cLklOJA4/gR0pU3HyiwVnvQxML0Cer3ojkbBHqVvs310yuYP9M0X2bq3ynnof/R8khUd7FL6sWrnsBiwBxwC/0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cXZQYk04T0hiMFdxcWNHNlQ3a3dhRGFwL3luSU52bXJWRWk0NHBOaEJ5Wmt1?= =?utf-8?B?NkpLOWxuQVFuc1dibXFCaWVocENoZjBERkFFOWRDclUrVFB4cEZ4aThmRkVx?= =?utf-8?B?Z0tlYjA1M3gyU25YaDJjUitqYjNaZ3pSRnJTU2hDMDRmMkZENmkzVjVId3Ez?= =?utf-8?B?Yk1iQU5hTFAwd3pPbGRiL0ZyKy85VUlDZ0pKbklQYVFXUmZlVGxTTFFDbVds?= =?utf-8?B?Y0V2eGtyOGNUVnFWSVhUc1RBbGgyVkpkRVZnOFhEVkNoQUxOSEpaVGQrdnVJ?= =?utf-8?B?SmJKcTFUT2ZvVFJlRUNGZkhIZlYvUjdTeFlnUE5kVUxDcXBLNDhFWktiM0Vk?= =?utf-8?B?Q0NYS1JkQmNXR3lmNnZDMVRyR0dJdHI0Z0c5MElSNkdidlNXWFluallwZ0Ez?= =?utf-8?B?OEhvWWNzbzVIM0ZPSlRtbHZRUUh6cTVwTGY3YXQ2REJ2VWMzeXNGby9mSkJD?= =?utf-8?B?S2I5OEdmbUVoTVNWeE5HUld3bFRDL2VhTXNZY3dDZzlEUjRRNFRnNG9wQ0pT?= =?utf-8?B?Ykl4UW5tV2RpaFJGMVM3bXcyek12QTh2MlQyTEo5S3ErdW5IZFJRMVFhKzgr?= =?utf-8?B?UW93QlgrdHJJR1lxMVV5UDJBM1hwYzJzNEFjeVpsYUVQbjNaQzN6WTByNERH?= =?utf-8?B?ZW1qaFpUcTUwRVgvdXBQOVhiZ1ZRNGdzR0tyTUlHc256b1hkMGdsSW5NRDVO?= =?utf-8?B?V1hmbjd2V2Z4OGFiQzFqM3pQeFZYaS80b2JOYVhvUVJxeldhZFM3Qi9kb211?= =?utf-8?B?VVE2czJsMHIwZzFqSW9qclE1ZFNSZnBKYjR5VXpYa0IxdHp1YlRpdFhHaWxm?= =?utf-8?B?WVZaVEI4Y1Racy9ZZ3ZySC83OWZLZ2szVXBydHRDK0E1UTVuWHZnbVNIcW9H?= =?utf-8?B?R3BoTEFBS1JPU1ZjdEpYdGpLQ1ZPRC9RVm8rWkk3VlgrN2Q4TG8raEtDbE5Y?= =?utf-8?B?SDFabUtMdWdUdi85UGg0V3hxVGdNbG1jUFhUYjZLOUNvakNucE1DaGhHTUEr?= =?utf-8?B?WWVpUWdreEdNNXFkWGczZVJVQmUwNWFpNXg1VmtvQjRkQ0xISUhvOGp0eWNJ?= =?utf-8?B?TFJCODVDd24yOFJ2RU41MXIvVm5RTWdTQlV6QmVwRlErOFBqVjd2R1VndmVo?= =?utf-8?B?c0daR3FHYWxrdWJ1aWNKSnFlTnNQRDluWThhK2tHVWErUjZRQU9MK3hHQ3o0?= =?utf-8?B?a1QxYSs5QWZLak1PeW5TNGpFdjFqM3ZVRUlnbzlpU00yaHBOQmI3d2llR2tO?= =?utf-8?B?V3ZYVjFKVGpTUnFVRmM3cEhGb1RvcTJTbEw3MlMraEM1a1VYWTM4b21EQUNQ?= =?utf-8?B?VlV1MXRpam9NYXhZSDRxblprckVQcWxSeCtsY2lHbURJWjMyczZrZ1RLMG1l?= =?utf-8?B?aHFOUEpCVGhnKzlORy8zOFZpZkxOc0dLRUVsekQraFN6Z3ZMZnRRNElJemt4?= =?utf-8?B?WVI4SjRlbEdySnZ4WklEQkRlQ1BxektuNEpmMVJ2UmlPWCtiZjhjRXE0MTIv?= =?utf-8?B?R09hbzN3aDc2ZVRwdGZnZXBJMVAzakV6MzJ0UVc4Vml1R0czWEhVVHhiLzJ0?= =?utf-8?B?KzRVSDBPN2RoQzdya3hEZnZXQUJxdWZaUlRnUzdIY2NCUjhtbnFyeWg0bElj?= =?utf-8?B?VGJhZHBtYVdkQlVhZE9IczlmQzljZnJwZ0M0QlZvT1M3Y0cxNkhGbEdoWm1l?= =?utf-8?B?T1BXL21JTWQ4blpTUVpwUkI1NkE3QXhsL3Vtci9wNlRlejhyUHlGRkJ2a3M2?= =?utf-8?B?QjhMV2JRaDB2QldjdWU0aC9BOTZxSFI0N09OSVpaM3VrOGt0WlFEQnlwZngx?= =?utf-8?B?eURkdGM2aTJJUjlhQXl1dUMxaDRGNXBrTVBHa3U1bWRkWCtoa0VKa3F0eHNY?= =?utf-8?B?czdVeFVMbHhVMTJxRkdqR25RdE9vWlU4UlpSL2pkTW5lTTBuRlZFUFEvbWQw?= =?utf-8?B?ejJkZi9LNU1jMzM4bWhreVZ2bTVybGlIaUIrSTdsdnNTb1VOOWRPMldGaE5B?= =?utf-8?B?UUU0MzRTQU01cUV1MGVEMzlXVU9lZ1llZzVnTG85T25Ya0NVVkVRaXRJUndn?= =?utf-8?B?Wk14QUxYbCsrS3B0ZUhLZzE0RUNnUWtydFRLNnRiMG4xOTczVlpma2JCeW95?= =?utf-8?B?ckJOSTdsZ2tDSlVsLy9IZkcvVXlmQnVOUm9JYTgrWU1uYWJOdlRDWVE5N1ZP?= =?utf-8?B?UFozMFpYQ3NvZUxrZHBxWEQ2U1diMS9aUVpPMmVvYUZyMmhrRDhGV1AxdWky?= =?utf-8?B?NERrWHVLNkRYQlNvSGp3L1pBdmVzOVNRc28zbUJsbFZLa0J5cVovWEJvWUJu?= =?utf-8?B?VmE4ajkzYk5oelFBR0VNdktONklCRW0zZ1NENFdObEMvYXNXQmhJUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16e62419-3e62-46fb-a17e-08de79f47946 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 13:46:44.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: 2RXcfnpwwdHmp+/0L1kutZ5Q2tCOCtjH943xffEq2uI/VrGRYC47yt85AVKuLfm+wYdTQF0dOLIrGnBVcH4XTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5101 On Wed, Feb 25, 2026 at 12:44:22PM +0100, Jan Beulich wrote: > We cannot assume extended config space to (still) be accessible when > cleaning up. Necessary value need caching instead. In fact, as the caller > also cannot look up extended capabilities, the cleanup function needs to > cope with being called when there's no ReBAR capability at all. I see that you adjust the code in vpci_cleanup_capabilities() in the next patch, so that it also doesn't check for extended capability presence as part of cleanup. > As kind of a side effect nbars being 0 (which init_rebar() doesn't > explicitly reject) no longer results in a bogus call to > vpci_remove_registers(). > > Fixes: ee459aeac096 ("vpci/rebar: Implement cleanup function for Rebar") > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:16:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:16:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245441.1544808 (Exim 4.92) (envelope-from ) id 1vxn1P-0003we-Qn; Wed, 04 Mar 2026 14:16:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245441.1544808; Wed, 04 Mar 2026 14: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 ) id 1vxn1P-0003wX-Nz; Wed, 04 Mar 2026 14:16:19 +0000 Received: by outflank-mailman (input) for mailman id 1245441; Wed, 04 Mar 2026 14:16:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxn1P-0003wR-8W for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:16:19 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b5aab99d-17d4-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:16:17 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4806cc07ce7so78664095e9.1 for ; Wed, 04 Mar 2026 06:16:17 -0800 (PST) Received: from [10.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-4851a8ea6c1sm12343105e9.11.2026.03.04.06.16.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:16:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b5aab99d-17d4-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772633777; x=1773238577; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=iWAMMFhGSYsl003M4aG2kfxFpIIqe0C5XbSQwJju3C0=; b=FAx7rUggOkD6Q2XR/zsLAHMraWORCQv1xo3G2FK5Rr1Zq+nxdGQclZ7SwAIVY5fSHz HXraC1VYmJR+KPeJGi3iPmlevYIjayQ9X3yYRqTOnYd0glx33/UZwPOUv2mO3JsZscU/ sdxT1+3yyftPoXu4kzJjUmjM8lhdkQMtbGcynAVfZqhDJtlvEddlcqBBkMoGp8RWCjw3 /rVRAmhmNjXXMjvdKHe9LZskgkQaXRTc2UhwvEe0lS0LhApuGgKxFq9kcZ1g4+Acuhce ba1hOnQlteQz9u23bVh+1YIcbcS8eWRWut0xt/d6YgE6OCiCwV3P0qDY/3kfWDjufqEX HCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772633777; x=1773238577; h=content-transfer-encoding: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; bh=iWAMMFhGSYsl003M4aG2kfxFpIIqe0C5XbSQwJju3C0=; b=ZyFRBY2AlXUyghiWCoONpKhjxREveDo8CGaohyOvTcIloX9GN9puM8eC07ezyUrKqj EZZJe60IlZyOXFbogUJ3nri2MPMe3Ih/0xPTphFk+0xlkUzn+lKq1VMZ7QRFK0FpoaDE KsDlVcUN8q+8s7SMT5sY+k9LbFuDHdzZAv0FoWrxBsN8kap8cFBM9zLTOUETNfM7RHME 59jaZHB94HRCiEQvs356yfLpAdfPkzfsvOJ7JO/fRoTCwNFBL+Zrzh1lnDBdqby+v9US clmNBR9PC7PCSOhekTpYDpWwX4iUjgSjPB+/akPDxds3cPWjEg4JWkZS7uctt5v2+lZE DVdw== X-Gm-Message-State: AOJu0Yxl/8qTOLRN+zWPXf2S/kiGPd+hyu9laOgWWuCgqoNIq7PE2q90 LZaQ3Td8a4FM/MKHK0QOYQQqsz9S2eOPEMYHfGhr9n90M4b0Wz74gTQMa6R7U98hvroQGVFrSQV ZnRw= X-Gm-Gg: ATEYQzwUL85+xSzkwp+cjTD91x5cfeokA88M1xKMlPd10OulBT9ssFqdvps0nKEDUvH 23FDgOH7EHWOo7Mf+AoSQW1VEmPO6UtAwg9dDG8FBqL/xy/H7Pu8/FW5nRoZFHkckKXuuuF2q0n k7wpAPFrPFWzIq5/C3C2J//1pxig8WA6DlXoTGfan/Xbfyd4vfey6EmePYes06TjtIUhjY1TrDO PMfbgb3pe2Gql/YeIo7HkqSFTD96+0hveOikhHPfwpUeXrOpZFzhTdi+6hkUFt1wzEDED5s6Vr9 QHKXyCjDYFDkKMqnc0WUHeZzNhSYcjK3ExhDu08oYKDIGJcwvJb0jfDWNA81NIUWxDKaeQhqKs/ RB8Q9GeJvwD5/mNL9uoVWm2Lr+XiW/I/NCAeTlyt9kg0jVkBLjxuYCVmO3O/E/TH4OH62h+rJ7y GsA2ARnQ5iZrlf470s59Po1tjBHehMbuUB9SDY8jsttITf8h0haXp2JMP8pQvWan1o4KKcBOC10 JA2gFwzN+2wqzr4X3+UJKnFUw== X-Received: by 2002:a05:600c:1e2a:b0:465:a51d:d4 with SMTP id 5b1f17b1804b1-48519848388mr31960925e9.6.1772633776800; Wed, 04 Mar 2026 06:16:16 -0800 (PST) Message-ID: <573bebfd-af24-48ef-934a-74142c7139ee@suse.com> Date: Wed, 4 Mar 2026 15:16:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: preparations for 4.21.1, 4.20.3, and 4.19.5 To: "xen-devel@lists.xenproject.org" Cc: Stefano Stabellini , Julien Grall , Anthony PERARD , "community.manager@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 All, the releases are due in about two weeks. Please point out backport candidates you find missing from the respective staging branches, but which you consider relevant. Toolstack backport requests please go to Anthony PERARD . I have already queued (in addition to what went in today) 878a9cfa4518 x86/ucode: Support discrete modules being CPIO archives a934a600c454 x86/pv: Don't assume that INT $imm8 instructions are two bytes long Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:21:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:21:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245448.1544822 (Exim 4.92) (envelope-from ) id 1vxn6e-0005ZT-I0; Wed, 04 Mar 2026 14:21:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245448.1544822; Wed, 04 Mar 2026 14:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxn6e-0005ZM-D7; Wed, 04 Mar 2026 14:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1245448; Wed, 04 Mar 2026 14:17:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxn2M-0004Pj-8n for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:17:18 +0000 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [2607:f8b0:4864:20::52d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d8a99161-17d4-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:17:17 +0100 (CET) Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-c70bfef17a4so4076246a12.2 for ; Wed, 04 Mar 2026 06:17:17 -0800 (PST) Received: from localhost.localdomain ([2409:40e5:116b:88d4:1c32:f854:c933:d139]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae3d1b2c51sm128138145ad.19.2026.03.04.06.17.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 06:17:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d8a99161-17d4-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772633835; x=1773238635; 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; bh=2HHesXUFzgL5YUe0UTlW0VJee6vfQ7EH/6Wc6oNHvRQ=; b=nMjgPhRWUKxGrzQT5Qp9yNEplTHI/0csGHlezhLeCJx0XV81ps7sWHcF1bTW+8ynWw ndv9spFEiIiqnNKloVkr/iKjSCbE0J4CQB4b6q9Trg8o4nZ4gNUrQ/gjiDkVhbhVj/5K T4WVXejGW193IJP3yPmmGe+L2Kp4b/jPzU5IKZuGN8Wz+HKdVGacRXh/lmoNZzWskE9U OIegLwgu1ZCYAlWqPKxUitjnZo2aVomHkvMztdzuenxzV49ze3n3eGfstdu4e5oxGVtf L673IEgqyTGpy9hi87jyQBsQDqIlgNfLS7pNQhCulffDaMHPEXyAaFgzvwwUtyJB46LW n88w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772633835; x=1773238635; 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; bh=2HHesXUFzgL5YUe0UTlW0VJee6vfQ7EH/6Wc6oNHvRQ=; b=QrhmaCSWG5X/lpUZri0y5SxLxgkiwvQ6Z+jVblwqWu/dr6k1+7Qq2Qv9rmybY1sZwu 6Lhp//IIQSz7W2gyxaK9VdYNXTfcOBM+7dT2T8z+jG4rTWSB/XnZV1orW0uTNlj75bFk bo0c1I3tok2UUFsygbyD2Fdt0rK6Qwp8zMrrBiQ2TJCC9cu8yuTWUVa+wJl2PU3aBPHb kJ2ASKXxfako0Ia+9SiHKwLqWwphCrvTb1eKTUJx30UFnl5HV+3MMjijrdutZi7F4WDR ryhoih89FuDVdQ68XcD2VH3c7MS6SHUqhr8djJbDvZK24NVSy42VRyUQkKzvsjxIOLBO 9MBQ== X-Forwarded-Encrypted: i=1; AJvYcCUCqle0CJuIKOKa7HNFKJWjRRUwzdAkuFDZHBB4zHESekeTwDs8+IuOcy2GijCU7j8GSUZK5FrlZWM=@lists.xenproject.org X-Gm-Message-State: AOJu0YxaL4ffy7lQohwwjImd81LzuJw51cFSjup4xJwcFvCnw/l8gMRj JuxNNi6/2VODHCheq8ca/Vx2VUqqkevpJVaD4bTmrVNoX1GxNJ0G1NoD X-Gm-Gg: ATEYQzwnsl1AGSHnQaZFav+BZdUqvbFeQ6Yw029lqZHVlqBUJtxt10XLN3b9PYni0e0 Wx7oaIeI0KzeoD/vryvjDnHIPigrTMOiMqHsOsPNAyYULp8ygXAKJoTR66anbnHpl62GFT4ezcD nSW1v9xUeO7haJLuUq6LTv3EORtUw322PJKG0McoRCGuVLpkqrn3wSV9uSsnGmUbz/SyCoGwMA7 FPmwwVNmwJi9v5WosZGh3ENzkT0ZIiY9CHSj8DWawOKBxIA4god3Jp20ImZYegmo+cwLYq/zFzt vISBt7ScOU+9tMWAMjTQL5/8wp/HNjCeEM6X9B3YZvl6R2H/+BwzV6YHTzgv8SHQHurbSW/l8lt Bi0KrLFGiBPIUZDHFHmPKPGADFg8cC5LvWMFe+cv4N0kgTWFZv2zAEZeOVFYsogGLB041c+/zhU PKrSJtlmoVBJTSz2kV3NLMgzuxuHniW3U7mLCG2emP5WM2/ma1MZjJ X-Received: by 2002:a17:902:e5c6:b0:2ae:50ec:fa35 with SMTP id d9443c01a7336-2ae6aa36151mr22864825ad.24.1772633835197; Wed, 04 Mar 2026 06:17:15 -0800 (PST) From: Shubham Chakraborty To: corbet@lwn.net, jgross@suse.com Cc: sstabellini@kernel.org, boris.ostrovsky@oracle.com, linux-doc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Shubham Chakraborty Subject: [PATCH] docs: sysctl: Add documentation for /proc/sys/xen/ Date: Wed, 4 Mar 2026 19:46:44 +0530 Message-Id: <20260304141644.28777-1-chakrabortyshubham66@gmail.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add documentation for the Xen hypervisor sysctl controls in /proc/sys/xen/balloon/. Documents the hotplug_unpopulated tunable (available when CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled) which controls whether unpopulated memory regions are automatically hotplugged when the Xen balloon driver needs to reclaim memory. The documentation is based on source code analysis of drivers/xen/balloon.c. Signed-off-by: Shubham Chakraborty --- Documentation/admin-guide/sysctl/index.rst | 3 +- Documentation/admin-guide/sysctl/xen.rst | 33 ++++++++++++++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 Documentation/admin-guide/sysctl/xen.rst diff --git a/Documentation/admin-guide/sysctl/index.rst b/Documentation/admin-guide/sysctl/index.rst index 4dd2c9b5d752..aae68373902f 100644 --- a/Documentation/admin-guide/sysctl/index.rst +++ b/Documentation/admin-guide/sysctl/index.rst @@ -84,7 +84,7 @@ sunrpc/ SUN Remote Procedure Call (NFS) user/ Per user namespace limits vm/ memory management tuning buffer and cache management -xen/ +xen/ Xen hypervisor controls =============== =============================================================== These are the subdirs I have on my system or have been discovered by @@ -102,3 +102,4 @@ it :-) sunrpc user vm + xen diff --git a/Documentation/admin-guide/sysctl/xen.rst b/Documentation/admin-guide/sysctl/xen.rst new file mode 100644 index 000000000000..957febd6bab9 --- /dev/null +++ b/Documentation/admin-guide/sysctl/xen.rst @@ -0,0 +1,33 @@ +=============== +/proc/sys/xen/ +=============== + +These files show up in ``/proc/sys/xen/``, depending on the +kernel configuration: + +.. contents:: :local: + +balloon/hotplug_unpopulated +=========================== + +This flag controls whether unpopulated memory ranges are automatically +hotplugged as system RAM. + +- ``0``: Unpopulated ranges are not hotplugged (default). +- ``1``: Unpopulated ranges are automatically hotplugged. + +When enabled, the Xen balloon driver will add memory regions that are +marked as unpopulated in the Xen memory map to the system as usable RAM. +This allows for dynamic memory expansion in Xen guest domains. + +This option is only available when the kernel is built with +``CONFIG_XEN_BALLOON_MEMORY_HOTPLUG`` enabled. + +Copyright (c) 2026, Shubham Chakraborty + +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. + +.. See scripts/check-sysctl-docs to keep this up to date: +.. scripts/check-sysctl-docs -vtable="xen" \ +.. $(git grep -l register_sysctl_) -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:27:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:27:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245467.1544831 (Exim 4.92) (envelope-from ) id 1vxnC4-0006Dt-63; Wed, 04 Mar 2026 14:27:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245467.1544831; Wed, 04 Mar 2026 14:27:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnC4-0006Dm-3Q; Wed, 04 Mar 2026 14:27:20 +0000 Received: by outflank-mailman (input) for mailman id 1245467; Wed, 04 Mar 2026 14:27:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnC2-0006Db-Vl for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:27:18 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3eb3ad6e-17d6-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:27:17 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 224B160097; Wed, 4 Mar 2026 14:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC9DDC4CEF7; Wed, 4 Mar 2026 14:27:13 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3eb3ad6e-17d6-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772634435; bh=Es80wMpp1atjNoZqqiG8/9SjgOPQJW7TW/Pe4UalxUc=; h=Date:From:To:Cc:Subject:From; b=Akq6zWMimN7VrH4OZdRxecT0Lxvp/xOfecJM39rkSUx++qr4NDHCuEeJg3Srdg5D3 7vwz2iiLwsbTMznc66KNIdpHnMiGFxZO6aeqKN5/868rFfDWzyX81o+foR1g65W0SO T+DarO/9H6bEA7gPnnrUS6bfDToMrBH3a7Xj6VAc7481Z56Kh4XtI60XN1pQY2czX5 twJVsqr5HEDWZMb4D9IYzLGBjPohVsHoAUoSfX/DdAzmM68iLe6YbffMySI+7GvHhd /J11FwFWSy8YDj9Aoco8jHYDqE/cSBhz23K5jAaiEiTz6TjEU6cBgIcoesU7DcoVS4 e/T11An8Mb2ow== Date: Wed, 4 Mar 2026 14:27:11 +0000 From: Mark Brown To: Juergen Gross , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Xen Devel , Hou Wenlong , Alex Deucher Cc: Linux Kernel Mailing List , Linux Next Mailing List Subject: linux-next: build failure after merge of the xen-tip tree Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vafmZqH34VLuiaf8" Content-Disposition: inline --vafmZqH34VLuiaf8 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: In file included from /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:38, from /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30, from /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26, from /tmp/next/build/drivers/gpu/drm/amd/amdgpu/amdgpu.h:56, from /tmp/next/build/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c:29: /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../display/dc/dc_hw_types.h:221:6: error: 'pixel_format' defined as wrong kind of tag 221 | enum pixel_format { | ^~~~~~~~~~~~ Caused (I think) by commit 4e05a08c6f3f3 (ACPI, x86/boot: Remove {set|get}_root_pointer() ACPI callbacks) which changes the inclusions and I think triggers namespace clashes with the unnamespaced pixel_format. I've used the tree from next-20260303 instead but really the fix here is that amdgpu and other things defining a pixel_format should namespace things, I'll consider if a revert is more sensible. --vafmZqH34VLuiaf8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmmoQT4ACgkQJNaLcl1U h9BXbwf+NMgzm+EwZ+oRef+uo7RxieWsON/heDAaLQf7kj0S1+EUF48sTw++m2Xp iS4EtFT0QNZCVTgH5JbbpxFkv7J9Z+Cycf9M6l9aZTsof8zzGWE1aYvrxXOo3Fw0 0ZXJlPOrxwmJldcQsf3F+rZEVY74BCL24XbQD5qHje5nqKKmlGA+XkjaZXW9KqHL /icsEcg+PbZR226vH2nrrTcAUj6nX3WVcZw294QDas+N1Un/P7vDr2HOqxAiBzvO 9bzg8mUBf2fcCFQl+rNP88wa6ODwqeN0/w9twk33EVXqcJR86FfMZRvrrdcEc1gZ Q4CM6t//I3zUfNNsrbV5tb/x3uu4zg== =c3Fj -----END PGP SIGNATURE----- --vafmZqH34VLuiaf8-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:29:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:29:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245476.1544840 (Exim 4.92) (envelope-from ) id 1vxnEA-0006qk-Gw; Wed, 04 Mar 2026 14:29:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245476.1544840; Wed, 04 Mar 2026 14:29:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnEA-0006qd-EM; Wed, 04 Mar 2026 14:29:30 +0000 Received: by outflank-mailman (input) for mailman id 1245476; Wed, 04 Mar 2026 14:29:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnE8-0006qV-E1 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:29:28 +0000 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [2a00:1450:4864:20::62a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8c5c4384-17d6-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:29:27 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b935cd1c6f3so1064496066b.3 for ; Wed, 04 Mar 2026 06:29:27 -0800 (PST) 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-b935afe7d28sm730129466b.67.2026.03.04.06.29.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:29:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8c5c4384-17d6-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772634566; x=1773239366; darn=lists.xenproject.org; h=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; bh=2W6PqjJjkvvzM4jill6dW7owJPHBge6fWDwErSN3/M4=; b=C4Bu1RGaz4qxsFb8KrlB6aJBRb2lwAE+yy1i/f3FguLcqgUtUrokEVKe1vvI4Zt91H KoFBKMWK5zPyAfflBH2rgaDuxjIr1Vn9plml1X30JS+CTb4I7vPfi2ELQWeCzb1IhOd9 K07loIuRQ5LIEpRLaefMmbZLGkcZ6usy92VtZefW40KPzSs6x0c0bztNQ14eaJJ5w4yE Yv4VS4zKV1Tsvu5+YsZpv410HVmsPxFTDHf/erKzS+ICsgRu0q29q5/pejjfank+8yLg S3/B0GvdRNh5EZGxkw37H1h5gXdUX6eg/6lte6ZFmocH1NXArghnc4OGRyA2V7omiaI6 Qhhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772634566; x=1773239366; h=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; bh=2W6PqjJjkvvzM4jill6dW7owJPHBge6fWDwErSN3/M4=; b=dZ9IBbKyQLHRMAHkGKSFbp9ypDiexkE744zATe9x5nzF9t1cT9J/N6xmb2I+SFrrvw TgCcZb/tEvnZUhMd13w7/LwwcC6yn40lBLYtoYojRzK9vZ8dXalfOyQaEIx+ElS/gDUb O4Ecs8ecFVlJmaitwMFggY60Rp2tII32b9yBRvSKoMKb9JuDgOVe92XT6PjaK+PgG4hi Mbpv02SWzLfrtmuFwfrvoZcABquOXZOM4kzMmxqR7TSYuYsJLSI1H5YbYLxX0tEgqVHp yHsBFG6xhsZFWcgpegj2LH7SA80VWHdavKCd2ZQ6HcugBv0kFtzpZLYe4YG5fTB65sqK /mag== X-Forwarded-Encrypted: i=1; AJvYcCW7nPBzlhi7wMurcF2MyMVKUEikGLhf3WnMpiCnFS+aZOABd90KrNRSNPNFEOjqybcQb2e+C9WjMGc=@lists.xenproject.org X-Gm-Message-State: AOJu0YzWcqsmsMK3pF6FuDAxor89iqSpQBvnWy0hKXQsBmO9Hm2Jbm2q Gra2KpmsFAdqq0jaNlgToSzJvBsbKbA07Bp/zFfzmwWB31WiEyqBMRzDkralwZ3cpztkTXFnmwQ O939Uaxs= X-Gm-Gg: ATEYQzxQV9GyxGHriYOM84ZkK1lzuaCsi4UVEZIJJ5RrYMh+hH6RgMVwBgr+Vgm/qZi otKLoP2JXSAKZolYZhlDLbwvgQh2RM6BTP9tkBohhOoibLc8SkV/apXE2KmRsRE1JGwi5rZCiwn hCiXyLzdcV3qdYBNCEKzWKbdsOTrHHg8FIrtjB/+IrW2pzM+rjeQiuc5Rnls16AmwWB/vzFu9Mn 5h3l09ykLVPO+HxXW6aDcFZJtuWYtZXv67Zyqdeb6sJN7NYm0DeBMAoY5U+K/cQBcvGrTASDyEd 7qpVn30YqUThA5qo9abNoiLJk1xViXBRHc+Pi7o2j78mlH91Oa5uyvOx2eW58eXMds8lO8vCoUi RlOYlxbB7lMDj4mPkzJHKuJFpHhGNlhtkHIslcgzpdY+xa+GceTZHRjydWHYVtZAu6SOljT/G3K IoOu+QjSXq/BBYAbWSart2xuLaDAKXfuDWt6a/2F5T73QSqtUUOGyuJvqmub2PVBkp8ZseygBRn HWn+CX1+pdQhXQlp0C0W8XvdkM+apngRTOpV0K+iziqRoXv1DJviA== X-Received: by 2002:a17:907:2d94:b0:b93:8d6a:7ec8 with SMTP id a640c23a62f3a-b93f137125bmr121052566b.24.1772634566483; Wed, 04 Mar 2026 06:29:26 -0800 (PST) Message-ID: <0a99e49b-ee8f-4331-9395-f5889cfe14a1@suse.com> Date: Wed, 4 Mar 2026 15:29:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] docs: sysctl: Add documentation for /proc/sys/xen/ To: Shubham Chakraborty , corbet@lwn.net Cc: sstabellini@kernel.org, boris.ostrovsky@oracle.com, linux-doc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org References: <20260304141644.28777-1-chakrabortyshubham66@gmail.com> Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 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: <20260304141644.28777-1-chakrabortyshubham66@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------YsdEc1OjNF18WtOMj3B7oZX0" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------YsdEc1OjNF18WtOMj3B7oZX0 Content-Type: multipart/mixed; boundary="------------ipVnQz6wlUAsuL6nf6BAvEEV"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Shubham Chakraborty , corbet@lwn.net Cc: sstabellini@kernel.org, boris.ostrovsky@oracle.com, linux-doc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Message-ID: <0a99e49b-ee8f-4331-9395-f5889cfe14a1@suse.com> Subject: Re: [PATCH] docs: sysctl: Add documentation for /proc/sys/xen/ References: <20260304141644.28777-1-chakrabortyshubham66@gmail.com> In-Reply-To: <20260304141644.28777-1-chakrabortyshubham66@gmail.com> --------------ipVnQz6wlUAsuL6nf6BAvEEV Content-Type: multipart/mixed; boundary="------------nMOGoNb04DKiVnZSjGOmOkQ9" --------------nMOGoNb04DKiVnZSjGOmOkQ9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMDMuMjYgMTU6MTYsIFNodWJoYW0gQ2hha3JhYm9ydHkgd3JvdGU6DQo+IEFkZCBk b2N1bWVudGF0aW9uIGZvciB0aGUgWGVuIGh5cGVydmlzb3Igc3lzY3RsIGNvbnRyb2xzIGlu DQo+IC9wcm9jL3N5cy94ZW4vYmFsbG9vbi8uDQo+IA0KPiBEb2N1bWVudHMgdGhlIGhvdHBs dWdfdW5wb3B1bGF0ZWQgdHVuYWJsZSAoYXZhaWxhYmxlIHdoZW4NCj4gQ09ORklHX1hFTl9C QUxMT09OX01FTU9SWV9IT1RQTFVHIGlzIGVuYWJsZWQpIHdoaWNoIGNvbnRyb2xzDQo+IHdo ZXRoZXIgdW5wb3B1bGF0ZWQgbWVtb3J5IHJlZ2lvbnMgYXJlIGF1dG9tYXRpY2FsbHkgaG90 cGx1Z2dlZA0KPiB3aGVuIHRoZSBYZW4gYmFsbG9vbiBkcml2ZXIgbmVlZHMgdG8gcmVjbGFp bSBtZW1vcnkuDQo+IA0KPiBUaGUgZG9jdW1lbnRhdGlvbiBpcyBiYXNlZCBvbiBzb3VyY2Ug Y29kZSBhbmFseXNpcyBvZg0KPiBkcml2ZXJzL3hlbi9iYWxsb29uLmMuDQo+IA0KPiBTaWdu ZWQtb2ZmLWJ5OiBTaHViaGFtIENoYWtyYWJvcnR5IDxjaGFrcmFib3J0eXNodWJoYW02NkBn bWFpbC5jb20+DQo+IC0tLQ0KPiAgIERvY3VtZW50YXRpb24vYWRtaW4tZ3VpZGUvc3lzY3Rs L2luZGV4LnJzdCB8ICAzICstDQo+ICAgRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9zeXNj dGwveGVuLnJzdCAgIHwgMzMgKysrKysrKysrKysrKysrKysrKysrKw0KPiAgIDIgZmlsZXMg Y2hhbmdlZCwgMzUgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KPiAgIGNyZWF0ZSBt b2RlIDEwMDY0NCBEb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL3N5c2N0bC94ZW4ucnN0DQo+ IA0KPiBkaWZmIC0tZ2l0IGEvRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9zeXNjdGwvaW5k ZXgucnN0IGIvRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9zeXNjdGwvaW5kZXgucnN0DQo+ IGluZGV4IDRkZDJjOWI1ZDc1Mi4uYWFlNjgzNzM5MDJmIDEwMDY0NA0KPiAtLS0gYS9Eb2N1 bWVudGF0aW9uL2FkbWluLWd1aWRlL3N5c2N0bC9pbmRleC5yc3QNCj4gKysrIGIvRG9jdW1l bnRhdGlvbi9hZG1pbi1ndWlkZS9zeXNjdGwvaW5kZXgucnN0DQo+IEBAIC04NCw3ICs4NCw3 IEBAIHN1bnJwYy8JCVNVTiBSZW1vdGUgUHJvY2VkdXJlIENhbGwgKE5GUykNCj4gICB1c2Vy LwkJUGVyIHVzZXIgbmFtZXNwYWNlIGxpbWl0cw0KPiAgIHZtLwkJbWVtb3J5IG1hbmFnZW1l bnQgdHVuaW5nDQo+ICAgCQlidWZmZXIgYW5kIGNhY2hlIG1hbmFnZW1lbnQNCj4gLXhlbi8J CTx1bmRvY3VtZW50ZWQ+DQo+ICt4ZW4vCQlYZW4gaHlwZXJ2aXNvciBjb250cm9scw0KPiAg ID09PT09PT09PT09PT09PSA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gICANCj4gICBUaGVzZSBhcmUgdGhlIHN1 YmRpcnMgSSBoYXZlIG9uIG15IHN5c3RlbSBvciBoYXZlIGJlZW4gZGlzY292ZXJlZCBieQ0K PiBAQCAtMTAyLDMgKzEwMiw0IEBAIGl0IDotKQ0KDQpJIHRoaW5rIHlvdSBlZGl0ZWQgdGhl IHBhdGNoIGZpbGUsIGJ1dCB0aGlzIHdhc24ndCBpbXByb3ZpbmcgaXQuIDotKQ0KDQpQbGVh c2UgcmVzZW5kIHdpdGhvdXQgYWRkaXRpb25zIG1ha2luZyBpdCBtYWxmb3JtZWQuDQoNCj4g ICAgICBzdW5ycGMNCj4gICAgICB1c2VyDQo+ICAgICAgdm0NCj4gKyAgIHhlbg0KPiBkaWZm IC0tZ2l0IGEvRG9jdW1lbnRhdGlvbi9hZG1pbi1ndWlkZS9zeXNjdGwveGVuLnJzdCBiL0Rv Y3VtZW50YXRpb24vYWRtaW4tZ3VpZGUvc3lzY3RsL3hlbi5yc3QNCj4gbmV3IGZpbGUgbW9k ZSAxMDA2NDQNCj4gaW5kZXggMDAwMDAwMDAwMDAwLi45NTdmZWJkNmJhYjkNCj4gLS0tIC9k ZXYvbnVsbA0KPiArKysgYi9Eb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL3N5c2N0bC94ZW4u cnN0DQo+IEBAIC0wLDAgKzEsMzMgQEANCj4gKz09PT09PT09PT09PT09PQ0KPiArL3Byb2Mv c3lzL3hlbi8NCj4gKz09PT09PT09PT09PT09PQ0KPiArDQo+ICtUaGVzZSBmaWxlcyBzaG93 IHVwIGluIGBgL3Byb2Mvc3lzL3hlbi9gYCwgZGVwZW5kaW5nIG9uIHRoZQ0KPiAra2VybmVs IGNvbmZpZ3VyYXRpb246DQo+ICsNCj4gKy4uIGNvbnRlbnRzOjogOmxvY2FsOg0KPiArDQo+ ICtiYWxsb29uL2hvdHBsdWdfdW5wb3B1bGF0ZWQNCj4gKz09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiArDQo+ICtUaGlzIGZsYWcgY29udHJvbHMgd2hldGhlciB1bnBvcHVsYXRl ZCBtZW1vcnkgcmFuZ2VzIGFyZSBhdXRvbWF0aWNhbGx5DQo+ICtob3RwbHVnZ2VkIGFzIHN5 c3RlbSBSQU0uDQo+ICsNCj4gKy0gYGAwYGA6IFVucG9wdWxhdGVkIHJhbmdlcyBhcmUgbm90 IGhvdHBsdWdnZWQgKGRlZmF1bHQpLg0KPiArLSBgYDFgYDogVW5wb3B1bGF0ZWQgcmFuZ2Vz IGFyZSBhdXRvbWF0aWNhbGx5IGhvdHBsdWdnZWQuDQo+ICsNCj4gK1doZW4gZW5hYmxlZCwg dGhlIFhlbiBiYWxsb29uIGRyaXZlciB3aWxsIGFkZCBtZW1vcnkgcmVnaW9ucyB0aGF0IGFy ZQ0KPiArbWFya2VkIGFzIHVucG9wdWxhdGVkIGluIHRoZSBYZW4gbWVtb3J5IG1hcCB0byB0 aGUgc3lzdGVtIGFzIHVzYWJsZSBSQU0uDQo+ICtUaGlzIGFsbG93cyBmb3IgZHluYW1pYyBt ZW1vcnkgZXhwYW5zaW9uIGluIFhlbiBndWVzdCBkb21haW5zLg0KPiArDQo+ICtUaGlzIG9w dGlvbiBpcyBvbmx5IGF2YWlsYWJsZSB3aGVuIHRoZSBrZXJuZWwgaXMgYnVpbHQgd2l0aA0K PiArYGBDT05GSUdfWEVOX0JBTExPT05fTUVNT1JZX0hPVFBMVUdgYCBlbmFibGVkLg0KDQpU aGUgc3R1ZmYgYmVsb3cgZG9lc24ndCBzZWVtIGFwcHJvcHJpYXRlIGhlcmUsIHRvby4gSSB0 aGluayBpdCBjYW4gYmUNCmVpdGhlciBkcm9wcGVkLCBvciBzaG91bGQgbW92ZSB1cCBpbiB0 aGUgZmlsZS4NCg0KPiArDQo+ICtDb3B5cmlnaHQgKGMpIDIwMjYsIFNodWJoYW0gQ2hha3Jh Ym9ydHkgPGNoYWtyYWJvcnR5c2h1YmhhbTY2QGdtYWlsLmNvbT4NCj4gKw0KPiArRm9yIGdl bmVyYWwgaW5mbyBhbmQgbGVnYWwgYmx1cmIsIHBsZWFzZSBsb29rIGluDQo+ICtEb2N1bWVu dGF0aW9uL2FkbWluLWd1aWRlL3N5c2N0bC9pbmRleC5yc3QuDQo+ICsNCj4gKy4uIFNlZSBz Y3JpcHRzL2NoZWNrLXN5c2N0bC1kb2NzIHRvIGtlZXAgdGhpcyB1cCB0byBkYXRlOg0KPiAr Li4gc2NyaXB0cy9jaGVjay1zeXNjdGwtZG9jcyAtdnRhYmxlPSJ4ZW4iIFwNCj4gKy4uICAg ICAgICAgJChnaXQgZ3JlcCAtbCByZWdpc3Rlcl9zeXNjdGxfKQ0KDQoNCkp1ZXJnZW4NCg== --------------nMOGoNb04DKiVnZSjGOmOkQ9 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----- --------------nMOGoNb04DKiVnZSjGOmOkQ9-- --------------ipVnQz6wlUAsuL6nf6BAvEEV-- --------------YsdEc1OjNF18WtOMj3B7oZX0 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/Ey8FAmmoQcUFAwAAAAAACgkQsN6d1ii/Ey8a ZQf/XKRD+RhbXO8yP1VcD826s2hbtRV5APomaGy7gKV5MxiWYXCCSFkrTa79+5W1ksakw/opvZR1 us7FZ4o0UoDqyhg71R/1aiHOydoG9iwjfItfITC/acH6kBFn6w/ColiJVP+lOH3I15l52b3xRHBT YSsl/hwO6BjPBS0SMiCD8kyhmVqDvs1pX5cemZOQD+YjULs4d7zIQJ3hRx76t6OyHK/SH9PvIrPt 5HvRxWgc1f3bKTUb3M2VOIaBAFcuwoIusfsxBcSOUifNoD7ae3xPfYEraYyY34ZFD6PsHnUNt0k8 UZBrYqhXYBAvuZhSzLt96FTSospy5XQFe/t5VjlzbQ== =g24M -----END PGP SIGNATURE----- --------------YsdEc1OjNF18WtOMj3B7oZX0-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:36:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:36:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245487.1544850 (Exim 4.92) (envelope-from ) id 1vxnKr-0008QM-6l; Wed, 04 Mar 2026 14:36:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245487.1544850; Wed, 04 Mar 2026 14: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 ) id 1vxnKr-0008QF-3d; Wed, 04 Mar 2026 14:36:25 +0000 Received: by outflank-mailman (input) for mailman id 1245487; Wed, 04 Mar 2026 14:36:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnKp-0008Q8-Ed for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:36:23 +0000 Received: from fhigh-b6-smtp.messagingengine.com (fhigh-b6-smtp.messagingengine.com [202.12.124.157]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 82af1929-17d7-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 15:36:21 +0100 (CET) Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 538267A0160; Wed, 4 Mar 2026 09:36:19 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 04 Mar 2026 09:36:19 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Mar 2026 09:36:17 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 82af1929-17d7-11f1-9ccf-f158ae23cfc8 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=1772634979; x=1772721379; bh=v1w24rbHzHrF54HJz/xGTwDUsrsyFlbqLfRT/0XgJAY=; b= dXQdqMylUa09SSFdONySWSh1VUXJcb2hxDdKm+rS/aqMJSEZqTcphuLeI/z+027l sgEwew3hYmHMbq8KfCIi49Sft8s8UUh2115n60+eVTRvoXDpMZfZXZ6nlqw91KW9 kURoRdImSaZZyrlseXLgW+nIQvQW/1tF37PadkMaK/EE60kYeggeCf0M4gbIKXGu q9oI8XWRwTAkmfFsSqLV7A/y47gt0Djg/fKDThd9Aoxb5TOIIPrr3JrmcRi8IL+K 6REbG/FdltNwQ0FlzqG5wstozhRHmwRyUv0mBCEukwO9OI+GgRi4IdJSVVJp0Pxy F5RZIUwg95rWV0fT1B/LjQ== 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=fm1; t= 1772634979; x=1772721379; bh=v1w24rbHzHrF54HJz/xGTwDUsrsyFlbqLfR T/0XgJAY=; b=1M/hBxkz5F5/0nMVIE2C6IWbZhebdxbst18HAIVlqUEYyBwO5Kj bxfOFFktvt+ryWHSsRRzpsco/1U6Ka9cB0LhpfniLM3R8tw+TfJVVybI2BCCXEKx pIJSIug3mL+/fFNUIqdHPpLJPwv4qncclYoYh6KkU3PM4q5nbdUmq5ezdCk3KlhD u0fkh1mERSS+KfFvVAxAF4dvHL380NmLziIvdJhPC/5CjEgA+/NlJCVZNaxPnG/5 FJTzW7PR5b4K2TxIbI7t/LAp6U75d1sObC2UaN+ysA6eP8/LYRvOI/Em9ZtfnHTr iR6v8AEHsfa2mntFiHQfqRymKNd2nRdb7Ig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvieefjeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhih hnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfekuddtffettefhieeuheff keeuffelvdffuddtteetledtveekfeekleehjefgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgv thhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthho peigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtph htthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthht oheprhhoghgvrhdrphgruhestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 4 Mar 2026 15:36:15 +0100 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init Message-ID: References: <12fbad10-78ad-4679-a1db-3995e34da094@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3wsJeamIeufwQU0A" Content-Disposition: inline In-Reply-To: <12fbad10-78ad-4679-a1db-3995e34da094@suse.com> --3wsJeamIeufwQU0A Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2026 15:36:15 +0100 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init On Wed, Mar 04, 2026 at 02:39:01PM +0100, Jan Beulich wrote: > MCE init for APs was broken when CPU feature re-checking was added. MTRR > (re)init for the BSP looks to never have been there on the resume path. >=20 > Fixes: bb502a8ca592 ("x86: check feature flags after resume") > Reported-by: Marek Marczykowski-G=C3=B3recki > Signed-off-by: Jan Beulich > --- > Sadly we need to go by CPU number (zero vs non-zero) here. See the call > site of recheck_cpu_features() in enter_state(). With this patch, I now see the "Thermal monitoring enabled" on resume also for AP. And then, the "Temperature above threshold" + "Running in modulated clock mode" for AP too. But, I don't see matching "Temperature/speed normal" for any of them... My simple performance test says it's okay for now, though. I'll see how it looks in a few hours... --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --3wsJeamIeufwQU0A Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmoQ18ACgkQ24/THMrX 1ywLzAf/bqO07wqXpUQrXgrCBoXHfuZyqb/i/Blg+Z2GItiRrSuQq33VEKJSZPLV sEfL9HBpM2AZZxCLn9mPbwIpf1zRnHG+bIDucJC/4cBn9YKyslZ72DxdipqL/pMn vc5FgcYuyTKwdnpX2F4XRBRaJSXeY4XmRaNqOHQfp1o24EZHgHmGfbx8nvlyeQOt eJyU54hvbYGes21NbRb/x2LWSewjXtUHO1ObL3D80IcJD/ZgBlf8e0ZIwo7X+w8U WYM4zmP9WbfHMHzA2EX3lRiZP0AFMOMWgGSGJlFHgyDehI3jX2CxxGEqVmtlba/e SpE9LqxbiHWQRypVj8taNB5FHhcxMQ== =rsdm -----END PGP SIGNATURE----- --3wsJeamIeufwQU0A-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:37:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:37:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245494.1544860 (Exim 4.92) (envelope-from ) id 1vxnLu-0000ZM-Fc; Wed, 04 Mar 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 1245494.1544860; Wed, 04 Mar 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 ) id 1vxnLu-0000ZF-Cs; Wed, 04 Mar 2026 14:37:30 +0000 Received: by outflank-mailman (input) for mailman id 1245494; Wed, 04 Mar 2026 14:37:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnLt-0000VJ-Ir for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:37:29 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aae12be4-17d7-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:37:28 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439b6d9c981so2327488f8f.1 for ; Wed, 04 Mar 2026 06:37:28 -0800 (PST) Received: from [10.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-439b503424fsm28047245f8f.22.2026.03.04.06.37.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:37:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aae12be4-17d7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772635047; x=1773239847; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=ixD03YAwPbqTVrVB8LuXCa5+sDpUh7SDQBZiiZDsct4=; b=cyedKOU+uLOqRa9NydOM/ng1Wz2ZA9lQSU+wNpYjIb9AjNhHNkFpQmWl3VRg79U/Cg HHEG+jVJAOCYqGOUiABZNoNxyPdfgEJOYddBjB2Y+FMIXZ6DtK8bhXshB2aEEkfCfSkZ xXrW8utv90Z6+8XauaUTqmO8ztLRQe708nooxrBFZZxRLrzePpprok+0lBRbc2LuN9p7 I+0KW+4ZsWdn6QPMShohDZVJ8aRS6cXr2cpCMCjo7h9sPyVWa8SBfd6JY/Uxpi2HvrSp n3wCWi7vBDwUyr4R8zDEDivP5ZJgfnz+UhMSlPYXZYofasVD0Lerbi7z35Ih9N9Ai4oU SGYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772635047; x=1773239847; h=content-transfer-encoding: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; bh=ixD03YAwPbqTVrVB8LuXCa5+sDpUh7SDQBZiiZDsct4=; b=rnU+HiGK2ZyCUohpU+pw36D8oQN/XSAlxskmeM+u1ngXt1Hs36cVpoWmxPB8kRo7hm IPlzMsJS9LGglVE7ZZHcLgigQxSotFM7h6CLncjh7Rogr4lRObZIyCdjRX86Q5rF8Phu md+FDie6u74w+MRoQUgJNOMonPA8qe6YUjJwoLrdhyW6cmYrCo4jzbbkMy/nwJk6B0Hg aen7YWxXMLZ7i/+6JX0oRBLqbUZjr5WUgGuhxLPidzWHFJhst9e0Jlo5AYmlLZkhDdrY kBeDyVW7QYIWaNJ2Aavva07zg//bJErMAQFa11ZVvE84aMKXpe6jWO8ZY8UxaMegfW7s OBDw== X-Gm-Message-State: AOJu0YzpLjmAYv/AHJshCQpwfQCLWtZdLw/A/0A+EFDrpzC4GDIcI0Vq +b5GqemYFK1wKiCBlT9bXyLQO6ZmEpjymmKPv/SU2ahe5ly7FnyJjmvnP7Y78CVIGVkbcJ1mJl2 dn+A= X-Gm-Gg: ATEYQzwnYtdi+4YKRgLxu4cDCUHENnLwBoFb0EAFUBZBfCTD2WCSOU7Q6Kaqa52n4vd MzKUdNasW+mBZjlFJYlfPICxLJgZwGOweLIGivTAOniuXXo0ClyLzWeKsRl3bShAfr2f4NkFt+/ L4M7rn9tLu1tqNdl/GdEycMpoxnmSp+xgdzvVX5EIM7hs0ZifoLxxwFYfQg/sA8f1rXHhbYhQvA ndP1v/AiPU6bAj2Qx6R564QYk9JofQb6sDUquBSX+o3Ede83hK3/OpQnjK4DVP5kQikjinSWVi+ cRSSCv71QNqWqZdLZEsh+okbk8NsazYirRuenK9kuFK73QGqKItugU0D69QhF6AkCaTjetfRL74 P6Z3QK1E8ftqua6dO4jwgYYEE0E8vzkOIp8sg4qSOUYrGmtzBfoEREL6zy9FdAeTqmlSgVjzZID JGNdgAi0NQVAVQpLm4+LenJRbuRqqXysDC8SqDmt2tCX4cv/1ALnvD7FUc8436cKKaNBxhqu7Ob y3MSqLStOjPSnM= X-Received: by 2002:a5d:588a:0:b0:439:b79d:b9a6 with SMTP id ffacd0b85a97d-439c10adc38mr11817885f8f.11.1772635047019; Wed, 04 Mar 2026 06:37:27 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 15:37:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Penny Zheng From: Jan Beulich Subject: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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: 8bit The treatment of ACPI_PDC_CPPC_NATIVE_INTR should follow that of other P- state related bits. Add the bit to ACPI_PDC_P_MASK and apply "mask" in arch_acpi_set_pdc_bits() when setting that bit. Move this next to the other P-state related logic. Further apply ACPI_PDC_P_MASK also when the amd-cppc driver is in use. Also leave a comment regarding the clearing of bits and add a couple of blank lines. Signed-off-by: Jan Beulich --- Including XEN_PROCESSOR_PM_CPPC may need accompanying with some change to arch_acpi_set_pdc_bits(), but it's entirely unclear to me what to do there. I'm unaware of an AMD counterpart of Intel's "Intel® Processor Vendor-Specific ACPI". Plus even when the powernow driver is in use, we never set any bits, as EIST is an Intel-only feature. acpi_set_pdc_bits() having moved to the cpufreq driver looks to have been a mistake. It covers not only P-state related bits, but also C-state and T-state ones. (This is only a latent issue as long as https://lists.xen.org/archives/html/xen-devel/2026-02/msg00875.html wouldn't land.) --- a/xen/arch/x86/acpi/lib.c +++ b/xen/arch/x86/acpi/lib.c @@ -124,6 +124,9 @@ int arch_acpi_set_pdc_bits(u32 acpi_id, if (cpu_has(c, X86_FEATURE_EIST)) pdc[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP & mask; + if (hwp_active()) + pdc[2] |= ACPI_PDC_CPPC_NATIVE_INTR & mask; + if (cpu_has(c, X86_FEATURE_ACPI)) pdc[2] |= ACPI_PDC_T_FFH & mask; @@ -142,8 +145,5 @@ int arch_acpi_set_pdc_bits(u32 acpi_id, !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) pdc[2] &= ~(ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH); - if (hwp_active()) - pdc[2] |= ACPI_PDC_CPPC_NATIVE_INTR; - return 0; } --- a/xen/drivers/cpufreq/cpufreq.c +++ b/xen/drivers/cpufreq/cpufreq.c @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ { uint32_t mask = 0; + /* + * Accumulate all the bits under Xen's control, to mask them off, for + * arch_acpi_set_pdc_bits() to then set those we want set. + */ if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) + + if ( xen_processor_pmbits & + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) mask |= ACPI_PDC_P_MASK | ACPI_PDC_SMP_C1PT; + if ( xen_processor_pmbits & XEN_PROCESSOR_PM_TX ) mask |= ACPI_PDC_T_MASK | ACPI_PDC_SMP_C1PT; + bits[2] &= (ACPI_PDC_C_MASK | ACPI_PDC_P_MASK | ACPI_PDC_T_MASK | ACPI_PDC_SMP_C1PT) & ~mask; + ret = arch_acpi_set_pdc_bits(acpi_id, bits, mask); } if ( !ret && __copy_to_guest_offset(pdc, 2, bits + 2, 1) ) --- a/xen/include/acpi/pdc_intel.h +++ b/xen/include/acpi/pdc_intel.h @@ -43,7 +43,8 @@ #define ACPI_PDC_P_MASK (ACPI_PDC_P_FFH | \ ACPI_PDC_SMP_P_SWCOORD | \ - ACPI_PDC_SMP_P_HWCOORD) + ACPI_PDC_SMP_P_HWCOORD | \ + ACPI_PDC_CPPC_NATIVE_INTR) #define ACPI_PDC_T_MASK (ACPI_PDC_T_FFH | \ ACPI_PDC_SMP_T_SWCOORD) From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:38:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:38:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245500.1544871 (Exim 4.92) (envelope-from ) id 1vxnMP-00015E-TI; Wed, 04 Mar 2026 14:38:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245500.1544871; Wed, 04 Mar 2026 14:38:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnMP-000157-QR; Wed, 04 Mar 2026 14:38:01 +0000 Received: by outflank-mailman (input) for mailman id 1245500; Wed, 04 Mar 2026 14:38:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnMO-0000VJ-L3 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:38:00 +0000 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [2a00:1450:4864:20::235]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bdd922b6-17d7-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:37:59 +0100 (CET) Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-3870df2331aso53206541fa.1 for ; Wed, 04 Mar 2026 06:37:59 -0800 (PST) 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 2adb3069b0e04-5a12356fe34sm1311356e87.90.2026.03.04.06.37.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:37:58 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bdd922b6-17d7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772635079; x=1773239879; darn=lists.xenproject.org; h=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; bh=SPBavIlOJuGgmLzdF/KYwcRkviDTPiwIMqjlJYlICSI=; b=Kc19yjP34vtkkHcjjDok4PefWeuKxZKk7yuPtph/pfizD3UNTgr7/XeHrM8V71Wd2H LNaH57/pxe+z6hZPuXOn8tNT43nAxils9FWTqWftYIL6QqyVhsx6sOIPi7FOg/UxFLiB LVSyVBD6L25t3wcIDwa6OGm+JcxRzJsDBvOkKtqqpnR3rWBCHEe9BA2jVWsr1qtwtgjq sAl13gx6ymGpq1miqJZbu9mmRTn0kplxwvoPI4dJ8lack12xSk0sb81W8iirRVKAVWyG xEfOsyshSfF27pzyNSU0cf1dTNbg5ZEyxaBp67Wnmxik810eS3BRGKxZ+Oxhfvv5ewoX HPKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772635079; x=1773239879; h=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; bh=SPBavIlOJuGgmLzdF/KYwcRkviDTPiwIMqjlJYlICSI=; b=uH+PygF3Hb0Xl1KseNEp+DgNZumPgaJ7pOwCFsN/eIAwb5iGdFaqIiQlGN9ZX5XTgR o/A+aAoY/U0TIwJZN3TNlQ5H7A3MP9+oHF3eyUG0jwTsjM05B+opa1+TX+vyGy0Naczq Edr1ayWz7xlUchlZL+4IJ9Qz3q0jwCVc2p8ECOPbxVpQsr33MbzS88QhbjQciYeyHQqk 4GI4be1ZELQn4FOL0JZ3D3d49PJ/+abMtbv3O7RGtuSrPGun6UNTGeXeHeTiPg1AZ1JH vmnxcqjxfMDXYT+mpsfjEqzCloTws3Cc7aaEP7f0Dtv+kMO8nYRdvDSJEtZnqqQ3iG4n jAbQ== X-Forwarded-Encrypted: i=1; AJvYcCUqQEElXuTd7esJAbWHCXuCkvcwueJxdI25yMnJOjOm6cfuOmbIBtqmfG7L4bMRHogK7714s06G2cc=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx1a1o23K2rDos4EYK8vvGsx7sI0BZm6MEUNZZMuC9/ZffnMfRx H8vW5xLgczCqzb8USWnGEbKEpfCnHxT64/v7aT2DoZFtruasE4VRHWLMikIeYRyW8OQ= X-Gm-Gg: ATEYQzz/usv4E2cezLH+cWgZYIwvc8JgzgrBW6csAdCZvZFNjQ0UuiSfL+szU5/nIzX imuSmyyn9K/3vRiF9UXvUeuzWr550eJkFq/1JKkn/HYheurFYZyQqFkVIh28/HqQOXsaIA5IGNE Jwn42BLXpfXvc7HvywWyuuy6KvuqIHyn3ibCY7HfOt9OCQt+ofDQBwgj5X6sZgjsQ48yI/Fvdyo V+puMDLA9vlsdnogpXF2VDP3QyvoSgOG0pvzrnk6CmV63p4P8z4M3Mddmsnscz8NVhbaqjkzkFd RT0xIXbqaE3e39tAQJ9IuaBONM0mlDXaQHSyB2us0xszga4S89B13m5W4UIvq9Zab57aJSS+ea2 jx6d07vTSLpfs4Viyv+p8gExMj0nxMZ3vND+oy3QHAcW6qjXkWevWJCb1wTuk783elY8KuaUn6R p/qU5qjSBKUUWXLcxe4S3q4sSw2Rn8EYn0Ldh3NlivlJ32vBuUX9KLWc1Ea7TcUKiCGoL/xDBCU ECR2DARv+XKtbbH3o8RoHM2NBgEBEITQDWYsrsWLVgVeKzsKWDTfA== X-Received: by 2002:a05:651c:1a0e:b0:385:bb35:8e45 with SMTP id 38308e7fff4ca-38a1c396502mr54586441fa.6.1772635078965; Wed, 04 Mar 2026 06:37:58 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 15:37:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: linux-next: build failure after merge of the xen-tip tree To: Mark Brown , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Xen Devel , Hou Wenlong , Alex Deucher Cc: Linux Kernel Mailing List , Linux Next Mailing List References: Content-Language: en-US From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------MR3f0SlHc2G7IOdpGbtDawDC" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------MR3f0SlHc2G7IOdpGbtDawDC Content-Type: multipart/mixed; boundary="------------spju9nddGZXaQtmFSclTQWb0"; protected-headers="v1" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= To: Mark Brown , Konrad Rzeszutek Wilk , Stefano Stabellini , Boris Ostrovsky , Xen Devel , Hou Wenlong , Alex Deucher Cc: Linux Kernel Mailing List , Linux Next Mailing List Message-ID: Subject: Re: linux-next: build failure after merge of the xen-tip tree References: In-Reply-To: --------------spju9nddGZXaQtmFSclTQWb0 Content-Type: multipart/mixed; boundary="------------uhsS8v2VuZHBS4FiEW6X2uyo" --------------uhsS8v2VuZHBS4FiEW6X2uyo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDQuMDMuMjYgMTU6MjcsIE1hcmsgQnJvd24gd3JvdGU6DQo+IEhpIGFsbCwNCj4gDQo+ IEFmdGVyIG1lcmdpbmcgdGhlIHhlbi10aXAgdHJlZSwgdG9kYXkncyBsaW51eC1uZXh0IGJ1 aWxkICh4ODZfNjQNCj4gYWxsbW9kY29uZmlnKSBmYWlsZWQgbGlrZSB0aGlzOg0KPiANCj4g SW4gZmlsZSBpbmNsdWRlZCBmcm9tIC90bXAvbmV4dC9idWlsZC9kcml2ZXJzL2dwdS9kcm0v YW1kL2FtZGdwdS8uLi9kaXNwbGF5L2RjL2RjX3R5cGVzLmg6MzgsDQo+ICAgICAgICAgICAg ICAgICAgIGZyb20gL3RtcC9uZXh0L2J1aWxkL2RyaXZlcnMvZ3B1L2RybS9hbWQvYW1kZ3B1 Ly4uL2Rpc3BsYXkvZGMvZG1fc2VydmljZXNfdHlwZXMuaDozMCwNCj4gICAgICAgICAgICAg ICAgICAgZnJvbSAvdG1wL25leHQvYnVpbGQvZHJpdmVycy9ncHUvZHJtL2FtZC9hbWRncHUv Li4vaW5jbHVkZS9kbV9wcF9pbnRlcmZhY2UuaDoyNiwNCj4gICAgICAgICAgICAgICAgICAg ZnJvbSAvdG1wL25leHQvYnVpbGQvZHJpdmVycy9ncHUvZHJtL2FtZC9hbWRncHUvYW1kZ3B1 Lmg6NTYsDQo+ICAgICAgICAgICAgICAgICAgIGZyb20gL3RtcC9uZXh0L2J1aWxkL2RyaXZl cnMvZ3B1L2RybS9hbWQvYW1kZ3B1L2F0b21iaW9zX2NydGMuYzoyOToNCj4gL3RtcC9uZXh0 L2J1aWxkL2RyaXZlcnMvZ3B1L2RybS9hbWQvYW1kZ3B1Ly4uL2Rpc3BsYXkvZGMvZGNfaHdf dHlwZXMuaDoyMjE6NjogZXJyb3I6ICdwaXhlbF9mb3JtYXQnIGRlZmluZWQgYXMgd3Jvbmcg a2luZCBvZiB0YWcNCj4gICAgMjIxIHwgZW51bSBwaXhlbF9mb3JtYXQgew0KPiAgICAgICAg fCAgICAgIF5+fn5+fn5+fn5+fg0KPiANCj4gQ2F1c2VkIChJIHRoaW5rKSBieSBjb21taXQN Cj4gDQo+ICAgIDRlMDVhMDhjNmYzZjMgKEFDUEksIHg4Ni9ib290OiBSZW1vdmUge3NldHxn ZXR9X3Jvb3RfcG9pbnRlcigpIEFDUEkgY2FsbGJhY2tzKQ0KPiANCj4gd2hpY2ggY2hhbmdl cyB0aGUgaW5jbHVzaW9ucyBhbmQgSSB0aGluayB0cmlnZ2VycyBuYW1lc3BhY2UgY2xhc2hl cyB3aXRoDQo+IHRoZSB1bm5hbWVzcGFjZWQgcGl4ZWxfZm9ybWF0LiAgSSd2ZSB1c2VkIHRo ZSB0cmVlIGZyb20gbmV4dC0yMDI2MDMwMw0KPiBpbnN0ZWFkIGJ1dCByZWFsbHkgdGhlIGZp eCBoZXJlIGlzIHRoYXQgYW1kZ3B1IGFuZCBvdGhlciB0aGluZ3MgZGVmaW5pbmcNCj4gYSBw aXhlbF9mb3JtYXQgc2hvdWxkIG5hbWVzcGFjZSB0aGluZ3MsIEknbGwgY29uc2lkZXIgaWYg YSByZXZlcnQgaXMNCj4gbW9yZSBzZW5zaWJsZS4NCg0KRm9yIG5vdyBJIGhhdmUgcmVtb3Zl ZCA0ZTA1YTA4YzZmM2YzIGZyb20gdGhlIFhlbiB0cmVlLg0KDQoNCkp1ZXJnZW4NCg== --------------uhsS8v2VuZHBS4FiEW6X2uyo 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----- --------------uhsS8v2VuZHBS4FiEW6X2uyo-- --------------spju9nddGZXaQtmFSclTQWb0-- --------------MR3f0SlHc2G7IOdpGbtDawDC 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/Ey8FAmmoQ8UFAwAAAAAACgkQsN6d1ii/Ey8j iwf9EhHkYnpCpah7/uRgLGp3oAC4dlcgZZesNEP3m5ECqYFxJnenRr1suZlRqubQ+2Mz2v1GoIxc kUwiAVyXVfY7TrGVYMKyxQ+fCRgE/3Rew+dRA4HCsntCjhvhs5tfAGnX79PgW8+MNOFu5PA3ybrX lycczmMT1aQ4zztc5S23Oo+lTxrzkCzNxNN2mbrUfOxcWkjUdGlX3arhr6b/n/LXFH1+vIYXRPdl oMQgcnPKTPVsYveeMNXgwpGw8cPvnnlH74L2of/Iqrnzn3pkl+iVVDrIbs/Tuyu3U/H40A7vTAzw OHb7e+Q3608DDzV7QujMddqPT5k6xrFTp0uIMFxsZw== =rAvw -----END PGP SIGNATURE----- --------------MR3f0SlHc2G7IOdpGbtDawDC-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:47:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:47:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245521.1544880 (Exim 4.92) (envelope-from ) id 1vxnVP-0002tF-Ny; Wed, 04 Mar 2026 14:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245521.1544880; Wed, 04 Mar 2026 14:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnVP-0002t8-LQ; Wed, 04 Mar 2026 14:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1245521; Wed, 04 Mar 2026 14:47:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnVO-0002t0-Kx for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:47:18 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0a1c5de4-17d9-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 15:47:17 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4836f4cbe0bso58650255e9.3 for ; Wed, 04 Mar 2026 06:47:17 -0800 (PST) Received: from [10.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-485188080edsm55771475e9.10.2026.03.04.06.47.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:47:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a1c5de4-17d9-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772635636; x=1773240436; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=fHFllxepf7SsU5yefoF7bkEmFMQtnjkUXCRHke/7Er4=; b=B/K4aEKv3Ul/uy/a3AAmZ2bg5tk4byq4NdmJDAIi27e4Bw5oKZVO1vurgWmp3U5Yop ldR/7WBnbdLYQB0I3kFHoRaoc54JO726HaaDrh8TFFzkfj5IeHi//nPxr5q0cMKP5FNL UYJIeVudmiYfGW+s270lHoQa8LQyZ3EuP3g0R4BphvrEFF+DdnckuSTY2zbzMGnahDhn hlJCDAH8iGZ2VDUyM1+k/IY88t1ykpNoBrNnogfc8fspDC0ENxhFq44QPb8CYjEo4QR3 AS0pCu6pBw5K57FW5L/jB0HLtE3pKsnJcSd6CNhyE6YnSec2DS/BvntGJuIk/8dvTs9a cfHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772635636; x=1773240436; h=content-transfer-encoding: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; bh=fHFllxepf7SsU5yefoF7bkEmFMQtnjkUXCRHke/7Er4=; b=GJU35aWxFG5yQ/+4jGxSu/GCuU0DZVDRBt15Z4fAYaHLk1wPVgIArdeAkU0WzJjGg5 +BA992UZba47vUZU4jWmNHLKEn264xtAcsxoJOrFnQRVHYchxYKCGT2orqKAcC6nmnRe pFTevD0fl2QFHKaaiQOr/mWf3axCUn1t9cMZwL5sN8uQmR2fvy05Hd85AZmV8B35qlcy W5udLm2UATo8YfFtB/yPrB+f7SWo3aLnr+cPGawgfvMyNow4dPPsJCm/RgjFHxuQDRwx Byt7qCsljz5g0unAPV4FZOP9lt4ZQMQeFFcqeZ1yo41+1XRNrkEIlLosSy7/m6UDCUEr qDMA== X-Gm-Message-State: AOJu0YzBe10vOKoefYtZSsjuTEAalhhUBJgFQP+YPnlqPdaQZmHjCaOT 7dHsq+YWGBT8O7e5NbqUnJDWTukianXochjlM3mb7HBHRzJ+bbUSy0RurCL0yKeNOw== X-Gm-Gg: ATEYQzzAZpjObc95C8q18ZAvL8FZicWFHgAf71GjrL/+aWJ1hyUUcFiGHSawdiQ2TAj 0meKhgxhdfUJRJ1YHaXGf42kr+ULGlV4cDCJbcdW06NwPsj7tigjOIxvgK41079NYzTzMVnBKSY MGfiqr3y1xT4WotKTGYtBmFzPVQbQzrDebCAP/7PrFF65TH7f35hLwOvHgy/VYbF1umCwmLh9Zm hSRVzosqfCy/BZKbC25RibAbIKUeHLdDi1fCVZxGXFmIceVW70jHLybX/Zw404xPwZ1BrCLXKCS iUsdyxBRvhhuJGDoH6KPpgF/BRJGso2V6gCyUusn/IVK7Kaw/N0RGs4D5WI2PJbjaQ3aWKqyBNJ ONsxv3G7wvk4h5A+l9glCs6Xg0LR1lhS9fU7Dsd4BMq679QcCXvvqZ/3y3xld7ctgOV67nQi6ZZ /nZE8BzqtiJn8mSLS1H6VNg9KnWAz+oipQH0vPzioEevvtraVZTYvpOw4W89Lx7VJb7xSftpqfe 2VTU588iBpWra/mUIGQNnR6gQ== X-Received: by 2002:a05:600c:c4a6:b0:483:6d4e:9811 with SMTP id 5b1f17b1804b1-485198c1c17mr36809295e9.31.1772635636490; Wed, 04 Mar 2026 06:47:16 -0800 (PST) Message-ID: <0c556f7c-6567-43ec-a9cd-eb542fc970b3@suse.com> Date: Wed, 4 Mar 2026 15:47:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init To: Marek Marczykowski Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= References: <12fbad10-78ad-4679-a1db-3995e34da094@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 15:36, Marek Marczykowski wrote: > On Wed, Mar 04, 2026 at 02:39:01PM +0100, Jan Beulich wrote: >> MCE init for APs was broken when CPU feature re-checking was added. MTRR >> (re)init for the BSP looks to never have been there on the resume path. >> >> Fixes: bb502a8ca592 ("x86: check feature flags after resume") >> Reported-by: Marek Marczykowski-Górecki >> Signed-off-by: Jan Beulich >> --- >> Sadly we need to go by CPU number (zero vs non-zero) here. See the call >> site of recheck_cpu_features() in enter_state(). > > With this patch, I now see the "Thermal monitoring enabled" on resume > also for AP. > And then, the "Temperature above threshold" + "Running in modulated > clock mode" for AP too. But, I don't see matching "Temperature/speed > normal" for any of them... Which would imply that for each CPU you see at most one such message after resume. Can you confirm this? (Generally for every CPU they should be alternating, but appear no more frequently than every 5 seconds. Albeit I can't help the impression that it is possible for the current state to not be reflected by the most recently seen message, for a potentially indefinite period of time.) > My simple performance test says it's okay for now, though. I'll see how > it looks in a few hours... I actually don't expect the change here to make a difference in that regard. intel_thermal_interrupt() exists only for reporting purposes. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 14:55:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 14:55:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245536.1544894 (Exim 4.92) (envelope-from ) id 1vxncq-0004o9-GA; Wed, 04 Mar 2026 14:55:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245536.1544894; Wed, 04 Mar 2026 14:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxncq-0004o2-Db; Wed, 04 Mar 2026 14:55:00 +0000 Received: by outflank-mailman (input) for mailman id 1245536; Wed, 04 Mar 2026 14:54:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnco-0004nu-K5 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 14:54:58 +0000 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [2a00:1450:4864:20::531]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1bbdc2b8-17da-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 15:54:56 +0100 (CET) Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-65baa72399fso9195521a12.0 for ; Wed, 04 Mar 2026 06:54:56 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b935ae94441sm749234866b.50.2026.03.04.06.54.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 06:54:55 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1bbdc2b8-17da-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772636096; x=1773240896; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=b8TcMBZ3yGouGfj8M+MDoejSezqgCzwzBRxv90RmjcY=; b=lk3lKjuqUCeIqKHZpbwXj/QQaDchhRUEVaigvCR/DW0lAH5bpKOj/+b0vli3zutbLQ VwIWzYDL24cJcI7SmAe1ZsGcmdaytkeHFhJu15MBhqDF+KOrsk/jGF22EStLkkHXJ28P CFYgDlp112llOMSehRZVHe42t5tKT6pSZvGYbVY8LRFqVYr40WwSWHANd2M1LnOzIUZ5 MjFXW41IoKusjKpak7Jd24U5W1XGWGd7SnBt46jdiv9/Wy9pcS3vOWxW8XOXTLjEekU7 mi2AJQ3UCbH+iOVn2Z3JOFo+eN4DUmAM5ZVgnWDAm6yHfIwMmofbdjLmVIf3v9eZccr5 +vEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772636096; x=1773240896; h=content-transfer-encoding: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; bh=b8TcMBZ3yGouGfj8M+MDoejSezqgCzwzBRxv90RmjcY=; b=Fwn50ocwpyMUndjsiz7AJsQtEY/sc/OzKGm1Koxf4bp8lz0KjNkBxKHgZorkSuE4jj X0A+ZgQBB3bxp3PHCMsnDSts+DQM9dcxe9D2N+1pfJn7R0BYwpL/OgzkNSfd3qtQniXK oeRj1+Dd8ud+IVnJaQGqRcn4zKGaW72+dDG8+kh2Mo6ijp+aqhM0jdahxB5QUtnje36A m/SMThNlEinFRlpQNt5JyVLQzroDbhnokDTnFHowDmZutiJspxdCg9kRhJUZLaco+aHf RBONRSF2TrLHtu5Ji7KZRJEpxTA9szk0LOhbxG64pjFMQZn3nZNLCr0T6aDdJg3MTaLN E5Lw== X-Forwarded-Encrypted: i=1; AJvYcCUldcjMvR9eOMUS2Gppqdm9XYPJnrJeZ2t4tSXFihkyDAuyNjJT3HCt9+KMsILO5//U1jW1Edatd2A=@lists.xenproject.org X-Gm-Message-State: AOJu0YxR20TmprZhnFm+hSBQ4sBKZh1iT1a8WRy0Q/J369Ra6kB6H4ha WIXMiCj5FFnutrS6yWmgZgOJiAkpdcVEePEwrnpMShs7/daiTIVGakAS X-Gm-Gg: ATEYQzwXUPysakK8lmPqCuijmPWKctRjNl45LX79+qXGMs0cdBXoR9q+pXNdPYOpVQu 6nJ+ED8uHnOFFL+5SASz/7PvWbA4hDGIVQKbMw9TBL+HNL7o2zpnRgfO74wU8Hp6Rm/S8BoLg2t k45Z+HuTMgmGzIqQHE7RR20LCY7fc17B+e06Iv+EairDHh1KICPa/h69IFMI3duZ9nEr85gzj20 QtMf7bsmxtWLEJqJ51KXHXAZ0ZChb80S1xB/IclbQ+Yojil2jcmruLaL3wVF2tMmVij3b+5+c/F +jbpu0f5BdrSgJd7cM2s9Mm4BPOQhHk3SC/W7tdG1ZY1FZicCCW8yfWj3rFVu97EcfR92vq1oHV 6SPymO9hLwyz90iDxEZrorfya/G+m9lfIduPH8fK4kjQPdDK9dnM4ZlYNJcqxpagVOqVRdvjBa0 +hEVEbwUR3esN9+WFBRh0b97A3Oy6P6nrk4mmoM6aGbhQq8Tab/YKKtTMZ57sME354Fb2cPlqzb c9dwEPyr/XcPw== X-Received: by 2002:a17:907:6d28:b0:b88:47b4:7626 with SMTP id a640c23a62f3a-b93f11c65e4mr135595666b.27.1772636095424; Wed, 04 Mar 2026 06:54:55 -0800 (PST) Message-ID: <7e1f3962-2dd0-4843-8976-40452437a52a@gmail.com> Date: Wed, 4 Mar 2026 15:54:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4b67f8cb-43d4-4f18-b2b6-156e21330887@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <4b67f8cb-43d4-4f18-b2b6-156e21330887@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/3/26 1:23 PM, Jan Beulich wrote: > On 26.02.2026 12:51, Oleksii Kurochko wrote: >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -2,9 +2,56 @@ >> >> #include >> #include >> +#include >> #include >> #include >> >> +#include >> +#include >> + >> +struct csr_masks { >> + register_t hedeleg; >> + register_t henvcfg; >> + register_t hideleg; >> + register_t hstateen0; >> + >> + struct { >> + register_t hstateen0; >> + } ro_one; >> +}; >> + >> +static struct csr_masks __ro_after_init csr_masks; >> + >> +void __init init_csr_masks(void) >> +{ >> + /* >> + * The mask specifies the bits that may be safely modified without >> + * causing side effects. >> + * >> + * For example, registers such as henvcfg or hstateen0 contain WPRI >> + * fields that must be preserved. Any write to the full register must >> + * therefore retain the original values of those fields. >> + */ >> +#define INIT_CSR_MASK(csr, field, mask) do { \ >> + old = csr_read(CSR_##csr); \ >> + csr_write(CSR_##csr, (old & ~(mask)) | (mask)); \ > I (now) agree csr_swap() can't be used here, but isn't the above > > old = csr_read_set(CSR_##csr, mask); > > ? Agree, csr_read_set() could be used. > >> + csr_masks.field = csr_swap(CSR_##csr, old); \ >> + } while (0) >> + >> + register_t old; > Since the macro uses the variable, this decl may better move up. > >> + INIT_CSR_MASK(HEDELEG, hedeleg, ULONG_MAX); >> + INIT_CSR_MASK(HIDELEG, hideleg, ULONG_MAX); >> + >> + INIT_CSR_MASK(HENVCFG, henvcfg, _UL(0xE0000003000000FF)); > This raw hex number (also the other one below) isn't quite nice. Can we have > a #define for this, please? It doesn't need to live in a header file if it's > not going to be used anywhere else. Sure, would it be okay to define them inside this init_csr_masks() or at the top of the file would be better? > >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + { >> + INIT_CSR_MASK(HSTATEEN0, hstateen0, _UL(0xDE00000000000007)); >> + csr_masks.ro_one.hstateen0 = old; > What guarantees that only r/o-one bits are set in the incoming hstateen0? I > can't help thinking that to determine those bits you want to use > csr_read_clear() (or csr_clear()). Good point, then after INIT_CSR_MASK() it will be needed to do: csr_masks.ro_one.hstateen0 = csr_read_clear(CSR_HSTATEEN0, _UL(0xDE00000000000007)); csr_swap(CSR_HSTATEEN0, old); Probably, csr_swap() isn't needed as it would be good to have all writable bits by default 0. Of course, except r/o-one bits. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:01:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:01:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245550.1544905 (Exim 4.92) (envelope-from ) id 1vxnig-0006jE-5x; Wed, 04 Mar 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 1245550.1544905; Wed, 04 Mar 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 ) id 1vxnig-0006j7-39; Wed, 04 Mar 2026 15:01:02 +0000 Received: by outflank-mailman (input) for mailman id 1245550; Wed, 04 Mar 2026 15:01:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnie-0006j0-Sa for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:01:00 +0000 Received: from fout-b3-smtp.messagingengine.com (fout-b3-smtp.messagingengine.com [202.12.124.146]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f33ae674-17da-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:00:58 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id B1EAE1D001ED; Wed, 4 Mar 2026 10:00:56 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Wed, 04 Mar 2026 10:00:56 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Mar 2026 10:00:55 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f33ae674-17da-11f1-9ccf-f158ae23cfc8 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=1772636456; x=1772722856; bh=/6mPn7+MSTQcX7GlpvXaiJVSgeglXAhuRBMxkvRDAGo=; b= Wq6xNLYp5ttwVnmeARhr5LgJx0+UAllepmNk/ASQHg8PRE81APuaJDOI5XaAUnZj PxRCppxbDK79V+D70mnHUQUP90D+SRR6rJFqd8D2CsnwjXgYtswdQ7NQudGb47dx NRueRb72av3pBSt8mPPUi4XvCbYNKedC1CeGOmJ2SEwcRzxOy93Iot/69LSN9rxK 1vaWtWokBpGv+jI/6lKH6y17DuD/Y7l6gc1spDL/glaFofR7opXB0iFSmfkpPzcs tV4CZivlGkQx9N6rzGSyWSNxDXkHIDnX+Yr1eWDIykgtv6Ec+1LsFtKfpFOvWtmf JcWs58EZf46TqhO0EchisQ== 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=fm1; t= 1772636456; x=1772722856; bh=/6mPn7+MSTQcX7GlpvXaiJVSgeglXAhuRBM xkvRDAGo=; b=aWRNyu7AIUjkUzmOj03aqWQPu1ixaCzD+shJsMGX+spq4T80YGb pa+Ofv3XwBu7aKExRExozXCO/K6KIiWWBpiDGw3rllosy1tBKUyo4R8ROgxfgSDW OyVfWT66V+vTKPi6982zK4C23G8B8SpmJPqD5YapwT77UupjJ5YraaDSFqJmEzaB ZulLVmgz/0i/0DmfzV8QzOsLxj170zIXJLB2TNFDfAY36rnUsQ4O9VBZZFCS5/QS uMUkGUR4QGtzom/mIWK4jqmVMjSEpXpZDekmLolnY75CkSGbfyBs1Fu5pnaaBre3 v8rGP8t2NVvJWuSAfxZz3uRjBN6WFmT/d1A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvieefjeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiuceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhih hnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfekuddtffettefhieeuheff keeuffelvdffuddtteetledtveekfeekleehjefgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgv thhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtghomhdprhgtphhtthho peigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtph htthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhmpdhrtghpthht oheprhhoghgvrhdrphgruhestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Wed, 4 Mar 2026 16:00:53 +0100 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init Message-ID: References: <12fbad10-78ad-4679-a1db-3995e34da094@suse.com> <0c556f7c-6567-43ec-a9cd-eb542fc970b3@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fOaXe1B5sBHN0ltu" Content-Disposition: inline In-Reply-To: <0c556f7c-6567-43ec-a9cd-eb542fc970b3@suse.com> --fOaXe1B5sBHN0ltu Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2026 16:00:53 +0100 From: Marek Marczykowski To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Roger Pau =?utf-8?B?TW9ubsOp?= Subject: Re: [PATCH] x86/S3: restore MCE (APs) and add MTRR (BSP) init On Wed, Mar 04, 2026 at 03:47:14PM +0100, Jan Beulich wrote: > On 04.03.2026 15:36, Marek Marczykowski wrote: > > On Wed, Mar 04, 2026 at 02:39:01PM +0100, Jan Beulich wrote: > >> MCE init for APs was broken when CPU feature re-checking was added. MT= RR > >> (re)init for the BSP looks to never have been there on the resume path. > >> > >> Fixes: bb502a8ca592 ("x86: check feature flags after resume") > >> Reported-by: Marek Marczykowski-G=C3=B3recki > >> Signed-off-by: Jan Beulich > >> --- > >> Sadly we need to go by CPU number (zero vs non-zero) here. See the call > >> site of recheck_cpu_features() in enter_state(). > >=20 > > With this patch, I now see the "Thermal monitoring enabled" on resume > > also for AP. > > And then, the "Temperature above threshold" + "Running in modulated > > clock mode" for AP too. But, I don't see matching "Temperature/speed > > normal" for any of them... >=20 > Which would imply that for each CPU you see at most one such message after > resume. Can you confirm this?=20 For the current test, yes. I got the messages for CPUs 16, 6, 18, 4, 2 - in this order. Not for 0, 8-15 or 20-21. Not sure about CPU0, but for others it kinda looks like I got it for P cores, but not E cores? But I'm not sure how to reliably distinguish them - I base it on the holes in numbering due to smt=3Doff. Specifically I have online CPUs: 0,2,4,6,8-16,18,20-21 (yeah, weird ordering...). > (Generally for every CPU they should be > alternating, but appear no more frequently than every 5 seconds. Albeit I > can't help the impression that it is possible for the current state to not > be reflected by the most recently seen message, for a potentially > indefinite period of time.) >=20 > > My simple performance test says it's okay for now, though. I'll see how > > it looks in a few hours... >=20 > I actually don't expect the change here to make a difference in that > regard. intel_thermal_interrupt() exists only for reporting purposes. Yeah, it's too soon to say definitely, but just after resume test said stable 6ms, and now (~30min later) later it's at 12-14ms. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --fOaXe1B5sBHN0ltu Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmoSSUACgkQ24/THMrX 1yyUUQf9G3qyWkVM9gFdWcbsyo/0WTGqS3d2lW8xdRYF33d29PRe54WTOOFhAQXG 3vHXNfWWme5N4YeFM/P8CH0rLuO8Zj8LKZk8lEvpFmQUXreA0RzvNwPJGa67Ogp+ o4MRZbsYNWXyKkFRfZK0CV+27qmWCv2Aw2j5iIBYhCM6ylrzXUGl6Ojxzs/TrfRF gM/FzHPDYhkoqys57qwaDKuTfbxhrd9Txlo4xEj/yoeoLZijmnDU766JI2ObIlKb y7aNrh4GYpSM1GmNML0RoK9zIeokLCJ1E4qWSt24yIStwgcgSRDHBk9AuWKLFEsn SrsXH6um9QmJEsIQtSIdw1e61KQMzA== =lMYs -----END PGP SIGNATURE----- --fOaXe1B5sBHN0ltu-- From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:05:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:05:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245560.1544914 (Exim 4.92) (envelope-from ) id 1vxnmb-0007IW-L4; Wed, 04 Mar 2026 15:05:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245560.1544914; Wed, 04 Mar 2026 15:05:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnmb-0007IP-IT; Wed, 04 Mar 2026 15:05:05 +0000 Received: by outflank-mailman (input) for mailman id 1245560; Wed, 04 Mar 2026 15:05:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnma-0007IH-F0 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:05:04 +0000 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [2607:f8b0:4864:20::1030]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 84f786a4-17db-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:05:03 +0100 (CET) Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-358ed696623so2866382a91.0 for ; Wed, 04 Mar 2026 07:05:03 -0800 (PST) Received: from localhost.localdomain ([47.30.254.178]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-359aa3eb916sm516439a91.11.2026.03.04.07.04.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 07:05:00 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 84f786a4-17db-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772636701; x=1773241501; 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; bh=fqTYOMIsNClRzqswixiS8WEm00nS5ICygdS6xEi4uwI=; b=VASiVr9TJfSCmlBbui+D2U8h3fGQRVLqUznS5XuKhKnVc7e1YCX149X15UkWBHz6DI L4sh5bQ0lMBiEQ5JLtXuTxGz/8fcvSdTmEdaoqs/215PGAlkUkdrZzyyHV1AHlX1U+/T n/VJX5qbrQm1y3NoXkO1DfFHrlqTYsbmkWQwdhOHMEP0VD726Bffj1e8IGVZSgMZ+8Rl StLS2+y8+cbJeZ/YoeJU2FM+59KQVMPrTtNTTT1nwbJJSbeRgwq3LyCylpQVsq415p1C ix2WAEikNCX6nHFj49+cIKYnYBFTMyFqa1JiP8M69sze7qI5Nm716UzEjIImtIdjHmrr SSkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772636701; x=1773241501; 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; bh=fqTYOMIsNClRzqswixiS8WEm00nS5ICygdS6xEi4uwI=; b=RnlhaKopr+ItG4uZAc+JogYxzaorAXaHwmsHb9VG1+851gebQQ4585pgB3ebfE8UnA FeaiyRyJE8rbgaIPBWwE6oPNrj6WHkVRinMVt3hpFHXDpD6XkiqmRpfE7j/fLR/4KL06 qDT17z87GW7yJJ9rEJVesiO6A1P7FnwI/NOcjejaRldDAqwLpcL5700rrI0UQLi/si5Y bqA/JCdXJkz/5mRRmwSVkNtQKrgoDe1aLdmZPy71GEmdIh3BrCJl7i5QV9cVfjKrU8iV wkLGSmprPFKac/Vmf8ZxP0MX7p2pYSj5z2pATbWGNBiOtsYyFV8JggoWSeLl/BDfvKEM AF4g== X-Forwarded-Encrypted: i=1; AJvYcCUvGnnzrt7xPsJdIsdDiISWKyiS45W0FjNALRQhtZ7rDPYzXi2nMlSEDnAJckAfZpTRa5t5tDiPTMA=@lists.xenproject.org X-Gm-Message-State: AOJu0YxYyvhvmhFbqoqpVM79XbqZGs2Wfo6ukEhwCPgNlCnXF98EsZIr ZxU3hWYT6Yk6WVjk03+qfh4zJORiURUoH6xy+l+2ok7N3sgXrwzLENFI X-Gm-Gg: ATEYQzzJLBiBYf6/qls/40d6Bpst28G8afoGIPXMdCwQK60I/LUjgg6XmMxLxGm8Kgu wqfONbSnvRHNBJn/DEJaJdydgV579LoP/fKa7z+fmN+eibjmeeL6YBoUaBNttFTFJ6GEV+24yaP bmw5qOkcY3lbedefe7ki0Xc+Tae6VpwTV1HTOT41jXvZ/llhYJkjYk9n4Ob6d95yWk40VWZQg1v hJ52C9G5P0PzTAoaVtSnf+l7AZQs2YQo7C1n97PGajd6jQ0Fm242WMzfVECoRV7nt/Pi2wiM/3G J1DjZMerZmp9r4V2LnW8bu1GEcIYUan8RsvO5k2/bR9azqSiUxX+xKQyU9P58U4JVafaJOvd5/L c3ocN8DQRGfeUuWf8ACH8KpGqRJPvCOYlpYq/i3J5PpY5d1Lye46dAjn+kD/ihFmLy/1ps7LwMD tGh9/Y9zj/b4IELsLR5clfeJTaH7Gj+GVrcXyPdCAKHrATx2KRl4819x7b5M1vtA== X-Received: by 2002:a17:90b:48cd:b0:34a:8c77:d37b with SMTP id 98e67ed59e1d1-359a6a21536mr2121281a91.16.1772636701366; Wed, 04 Mar 2026 07:05:01 -0800 (PST) From: Shubham Chakraborty To: corbet@lwn.net, jgross@suse.com Cc: sstabellini@kernel.org, boris.ostrovsky@oracle.com, linux-doc@vger.kernel.org, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Shubham Chakraborty Subject: [PATCH v2] docs: sysctl: Add documentation for /proc/sys/xen/ Date: Wed, 4 Mar 2026 20:34:19 +0530 Message-Id: <20260304150419.16738-1-chakrabortyshubham66@gmail.com> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add documentation for the Xen hypervisor sysctl controls in /proc/sys/xen/balloon/. Documents the hotplug_unpopulated tunable (available when CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is enabled) which controls whether unpopulated memory regions are automatically hotplugged when the Xen balloon driver needs to reclaim memory. The documentation is based on source code analysis of drivers/xen/balloon.c. Signed-off-by: Shubham Chakraborty --- Documentation/admin-guide/sysctl/index.rst | 3 ++- Documentation/admin-guide/sysctl/xen.rst | 31 ++++++++++++++++++++++ 2 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 Documentation/admin-guide/sysctl/xen.rst diff --git a/Documentation/admin-guide/sysctl/index.rst b/Documentation/admin-guide/sysctl/index.rst index 4dd2c9b5d752..aae68373902f 100644 --- a/Documentation/admin-guide/sysctl/index.rst +++ b/Documentation/admin-guide/sysctl/index.rst @@ -84,7 +84,7 @@ sunrpc/ SUN Remote Procedure Call (NFS) user/ Per user namespace limits vm/ memory management tuning buffer and cache management -xen/ +xen/ Xen hypervisor controls =============== =============================================================== These are the subdirs I have on my system or have been discovered by @@ -102,3 +102,4 @@ it :-) sunrpc user vm + xen diff --git a/Documentation/admin-guide/sysctl/xen.rst b/Documentation/admin-guide/sysctl/xen.rst new file mode 100644 index 000000000000..6c5edc3e5e4c --- /dev/null +++ b/Documentation/admin-guide/sysctl/xen.rst @@ -0,0 +1,31 @@ +=============== +/proc/sys/xen/ +=============== + +Copyright (c) 2026, Shubham Chakraborty + +For general info and legal blurb, please look in +Documentation/admin-guide/sysctl/index.rst. + +------------------------------------------------------------------------------ + +These files show up in ``/proc/sys/xen/``, depending on the +kernel configuration: + +.. contents:: :local: + +balloon/hotplug_unpopulated +=========================== + +This flag controls whether unpopulated memory ranges are automatically +hotplugged as system RAM. + +- ``0``: Unpopulated ranges are not hotplugged (default). +- ``1``: Unpopulated ranges are automatically hotplugged. + +When enabled, the Xen balloon driver will add memory regions that are +marked as unpopulated in the Xen memory map to the system as usable RAM. +This allows for dynamic memory expansion in Xen guest domains. + +This option is only available when the kernel is built with +``CONFIG_XEN_BALLOON_MEMORY_HOTPLUG`` enabled. -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:07:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:07:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245568.1544925 (Exim 4.92) (envelope-from ) id 1vxnog-0007oO-0Q; Wed, 04 Mar 2026 15:07:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245568.1544925; Wed, 04 Mar 2026 15:07:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnof-0007oH-TX; Wed, 04 Mar 2026 15:07:13 +0000 Received: by outflank-mailman (input) for mailman id 1245568; Wed, 04 Mar 2026 15:07:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnof-0007oB-2g for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:07:13 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ceefa75a-17db-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:07:07 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB5907.namprd03.prod.outlook.com (2603:10b6:303:6e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 15:07:01 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:07:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ceefa75a-17db-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cTSsdKySWC6+lF+heAi56WpZltXcvfwjYCwZEWdxiUfgpbiSRlJjhh+eZzYt0USZ7h1P9CIlMxBWKmWgvzLY/IJdQULJcNPDfTn2hjlvN0r9pcevBJKrXKAsxhOW73iK0P4NVdyNMd6ugaCRbWvGaTTKTLUEJWy/MkJZz30JMqlB2iUGchkty41Hcg/M+t/BEple0DGb0cPROqrGuJHS0a8JWULmB5JG8RhB4TKGb7P35DeCYihAR/Dun/vkeM9xGab+3Fldiz0SpwceeXVvrqYFfF7RulgyI49NdsdrzYOH/gp8K9Mj9kETjK2giI/03n1i+orItgyHtsUWQ7dK6Q== 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=maYv6YMM0hf8D0RaHXdIXUzwWjEs/blJ6dpfrYIT3xM=; b=hNpHLNTcr60W0kiPOhziPX0C8lQK5VVEBctY/twYHCDL3+UB5wfS+qlnmTrs4lHthJ5jRH3AH0IeH0tNTnu4FhG3oBS9LpLWCaRTOVhFDLuzS5CMd2cv7EFdMPYkHZBGJV8Kh+8U3Hh/5pV/r/JZDEBrySJ65XxJKkezmBgwZWBARsUMrEQrg9pDN8sFxM8lvvkDTT1ALLkjYZ0MdAQBWn6P3S5zPDf0E5uVL9FLIAG4f4Ac8K/y3afrzTF9xBN4gX3kmO2XySQzx6tyNERgfmq8wLodUMbiEsN3E2vVNdnqgBnv7gp8PpreVjPYZ7Th792AaVzPTdlhkKLuBtX/5A== 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=maYv6YMM0hf8D0RaHXdIXUzwWjEs/blJ6dpfrYIT3xM=; b=XWBn2QcQIxOKxDT9VD2tT2YYvordUZCBkqbt8LU2MkXtcaHg7UBHVb9ZM2pGkQ3oqEvkSAt179Ws8zK3e8QRHBD++vWdifFsPboZ+i4NPvSA/rUfKjJbJyOXcktf6bHqBcIPLTn7hGlZh2itHULVXT3rl73JxqooyWJt6XK8/TU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:06:57 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> X-ClientProxiedBy: MR1P264CA0192.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:57::8) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB5907:EE_ X-MS-Office365-Filtering-Correlation-Id: b6a9bcdc-ea74-4573-41d1-08de79ffb003 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: lzXGMbW3nyY85Gg2XW9D6Xq5FVh8OYdd8YPR4vtfidRBWNsiTc4/eAJtqBNk7PeLX7zcJPuJ5wLLH23AeQ8SQBQGh6WgEVQXu5PcVkeVxnv9R12TNMhmEk+Urwj5w+ytJM7nRGh1LHfMhRjUoVFdEO9dIALatn9z9Zij4CIODyYNyOB8xlRYHsRSUlkERd7ydcKwJLNzQjwR+SuT8tRwW6C0BWMxg4wFMpefRIpJboYkA5TDYAPM0bFC8W/AYmlr/bJdEzu2MicW4ePlCHS9jfKoGFm3sCZNtsXrTzN96xLahLL6QRxgMoKl/qHGyhdtYFMLV5obUt2uox3GciEMg75efeKHNQlovORxuGpwZnVcP59D1sK7eB4CU46PYM9+ff1JpVp6XoKFrKJpS3EDyY5uTCeLCj+iBrnUQ0yfbbtaJER7oFsaA9Ws9kuzI3HaFN6bNDfUw4dAzPScVnolp0UZhPqNAkdvX7Uh0UFzmLW5HWO8kiJI3+L04y3807apKizb1vIIKMRUpKGeIbv5UigwPsArZSQRwYTA4QXRwTNAtUleYfPrTmfDSI8VW0LhO0wlIMDZWNThJbEaSybKzUMXPUucPZc7aJrNKEmnVKHuk8Yshay2cSdxvVVs/Vcy5SkKW+IXD72/xQLLmOMF1g+JcvBhbTw3WuSh33wDJNvUaNa7/cGKKh/BWWS8nMpdxlweDs+glGbJOkSTrlXwOPJ0ktCMYmr9uIken+i6PTI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z2FHWGloTjZUQ0FGMUpMT3p6Z21kV3RqQkRrWmVibHd4Q3RpNVM1TGhqRkUy?= =?utf-8?B?a0ZaNVg2NlprZUN1TjVMNmF3c2g2UC9KeXRvaXhJOCs2cGpDTGMwbXNpck9m?= =?utf-8?B?bld4Z1JTZUpoay9ZYzZ5WEoyajl3Q011SWp6cHlrVEViYWl3UnVTcDJ0MXQv?= =?utf-8?B?ZGVtY3Q3eHQzNkxqVVBJS0d2czJTQ3pDTGJjYmJqdy9xQXNnMDI3Z0NtQndi?= =?utf-8?B?Y0d4NXBtWkdkVjJxcnJXek1VRUNwMU1pSzA4Z0NsdUFWcEh3YjN5Z0FLUHQ2?= =?utf-8?B?T29DSmtrTW5YRndyeDR5clhmZ000ajVCUEoyOHR6Qy9MTXFOSG5GWkxHWmdF?= =?utf-8?B?S2hFc0lHS0ZOdjBKa0J3Z243bVZucW9ucFZ5TDF4aTNyNWtqYkVWWjZFRjEx?= =?utf-8?B?aGp0Q2t4YnVKZGcrMnRHT3h4amg5eXlGZnQ4RmszejZuL3F5eVBvMVE1ZmJt?= =?utf-8?B?bnorUWlia2N3aGh0V010RVJrNXR3U2w2K2V2b1ZWMUJiNkZxQXRKY3ZhaVA4?= =?utf-8?B?a3cvbDAyMlBmS0lJQUJQQzlvd2hpM3FiYU5YUGhtcEhxY2EwRFNncG9WbVNr?= =?utf-8?B?WmNTb0pBbFpCU0ZFcU9Ha056cjlnU0tmRWNubWJXTzRvWkdrTjVqaExEZ0U4?= =?utf-8?B?OHJnS1dYSE16dEVkNUJGeVNrU0x0VDZnNDlGNXNFUHRjYThtUXlqK3pSNldv?= =?utf-8?B?KzdxNXNlcEVUNWRuTVZQMHBmUWVzSUh0cENyd3gwSU0yMllFS0hhSmJobnl2?= =?utf-8?B?QTJQTXNXMFRBYWZyNDkxRDdvQ09lZmdFMnR1ZzNLWGg1TFZna085OWdlcU5o?= =?utf-8?B?N0FVc1ZDeGR6NUlqS1JTU2x2VEJ5TjR0Rytxdm85MGh4bDRCMFNoUXE1dVZp?= =?utf-8?B?UUh4V1krSGtNd21xTVA2ZGVYVE5Yd3FkL3NiWEkxMWpMeUVOdGsvV1JEdkVZ?= =?utf-8?B?T3BhQWhLSGNRQ2E0TnFWZkpqN1FERHVuSUsrUDVLTXpIcmxaV21pcXR3SHJy?= =?utf-8?B?cTZPaWtKSUNXQWJSdUhrR2V5RVVqNzc2WkJiVmljclliZnVBZFNoZStQMHJX?= =?utf-8?B?RWtxNEtXcm5FbGpYaTE1am1wRFV0a0VGbXJ5QUs3aCtiRkphL0xOdnJJM3Nz?= =?utf-8?B?aFFNaVNwVlVIcjNERnYvTytjemlwQU9LeVR4VEtEMFE1UDQwdkQyTmpZMDdz?= =?utf-8?B?Q2FQSlowcUFLVnViWFFLODRPR1ZaV1grcnNqSFQva2c0Q2g4YmkrUDNyNVl2?= =?utf-8?B?YWhWNWxFdEZaSk1BWS9lU0xYQVF0d0J3ZTlMS2tMR1dOYnVBcytrMFViMHpw?= =?utf-8?B?NmNkUE8zeTdSSy8ySnlLZkNPbVQ5bExReUxXd3ZJVlQwd25mWlhUSGxDQlk4?= =?utf-8?B?ZFV2NEl4RmdxNDUwZ0plZjJYTkc2WGlEd3crcGpvdmdyTFo4Y1M3am5hWS9R?= =?utf-8?B?d3kxSGRuWGlRYXJtZnEvdGpXWHpRTzQyYTdjVUFrZkx6WGdKVFBLN1UwVW54?= =?utf-8?B?cXlHWDN5TkdqOGs3YWxFdXBqOFFUV1BIRitHRmlNL2tHYkFodmtHQTkrNGhq?= =?utf-8?B?U2FkTEpleitHZGt0bjZzaTdGaDFIMFlTUngvQzExNEx3NXNsRktvdG9lKzBu?= =?utf-8?B?Z1pHaHpjWiswTmxNU3lYTmpnSmpURG13Vi9jZ21VdER0eG9SQ1ZhSWthVFI2?= =?utf-8?B?SHBHLzRpRGJhT2dOOHdlbkRwZjNrYXhkS0tlU1Z2cG12MXUxUHVQZkxpZVV5?= =?utf-8?B?eFdEYldRa1k4S2YvcW42MmIzZ2p1cFY4bDNpUEs5Zi9RdDMrWk1QOTRORzhP?= =?utf-8?B?VHhlQTVYbEQxa3NqdFFtcHVITTVLclhsbE5aT2dtT2IwK29lNnBrZDNXd1RK?= =?utf-8?B?c0tYUUFzREFGcy9PSUFBNVRGbFhDQU9na2VZU3A4YmRkTjM2UHBWc1FYUUl2?= =?utf-8?B?M0hpZXFHTWU1a3VXVGV6Q1VHTlREYmxacjc1bUw5QnA5ZGN5ZkI4U01PL1ZZ?= =?utf-8?B?cnpyTmVmOEtpeEdrTldjN1VOQW1haFR5TXdQLzFITXZLNTNHUFVuZzdZUm5p?= =?utf-8?B?bCtpVEE4S20rQTdRQ3hxZTlVNU8zMVU1QTIrNFcrdlJONTFSUDE5TXlCeVFX?= =?utf-8?B?ZmhjdUplSmxvN09zNnltZXp6bTMzeUlWTkUxK0FnOEpWNFZJejRlRlZIc1dr?= =?utf-8?B?SGJOak5TdDlObHRseDA1QlFLZFBVOXlFcmtSSkdZMDlxMFg0ZGgrTTA1T0c1?= =?utf-8?B?NThiSnNxRFJLeDMrSDRHRW5FWUh1OUdCUFdFa3JyQTRHMnl4enlUTGdmaDkz?= =?utf-8?B?WEFaQWhwVXQyY0tGa1JLTmJScEh5QXVmWGM2WERWZ1h3dHU1ZWJBdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b6a9bcdc-ea74-4573-41d1-08de79ffb003 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:07:01.2455 (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: RnCOOEyqtK3nwJjLN0/C0TeVODocJmMeOZe1373ye39oNVUm0KP7lh+ETkI+zaWzrI+cXAMdGMlZrTMjWdSflw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB5907 On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: > When Dom0 informs us about MMCFG usability, this may change whether > extended capabilities are available (accessible) for devices. Zap what > might be on record, and re-initialize things. > > No synchronization is added for the case where devices may already be in > use. That'll need sorting when (a) DomU support was added and (b) DomU-s > may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > > vpci_cleanup_capabilities() also shouldn't have used > pci_find_ext_capability(), as already when the function was introduced > extended config space may not have been (properly) accessible anymore, > no matter whether it was during init. Extended capability cleanup hooks > need to cope with being called when the respective capability doesn't > exist (and hence the corresponding ->init() hook was never called). > > Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") > Signed-off-by: Jan Beulich > --- > vpci_reinit_ext_capabilities()'es return value is checked only to log an > error; it doesn't feel quite right to fail the hypercall because of this. > Roger brought up the idea of de-assigning the device in such a case, but > if a driver doesn't use extended capabilities the device would likely > continue to work fine, for Dom0 this probably wouldn't be quite right > anyway, and it's also unclear whether calling deassign_device() could be > done from this context. Something like what pci_check_disable_device() > does may be an option, if we really think we need to "break" the device. We may want to add a note there, stating that we have considered all possible options, and hiding the capability and hoping the owner domain would continue to work as expected seems the less bad of all of them? > The use of is_hardware_domain() in vpci_cleanup_capabilities() was > uncommented and hence is left so. Shouldn't there be a DomU-related TODO > or FIXME? Hm, yes, possibly. I think limiting extended space availability to the hardware domain only has been done "just" because we have no extended capabilities to expose to domUs so far, and I don't think we even setup the extended capability list in the domU case. > --- > v5: Don't use pci_find_ext_capability() in vpci_cleanup_capabilities(). > Add assertion in vpci_reinit_ext_capabilities(). > v4: Make sure ->cleanup() and ->init() are invoked. > v3: New. > > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -8,6 +8,8 @@ > #include > #include > #include > +#include > + > #include > #include > #include > @@ -169,8 +171,17 @@ int cf_check physdev_check_pci_extcfg(st > > ASSERT(pdev->seg == info->segment); > if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) > + { > + int rc; > + > pci_check_extcfg(pdev); > > + rc = vpci_reinit_ext_capabilities(pdev); > + if ( rc ) > + gprintk(XENLOG_ERR, "%pp(%pd): vPCI extcap reinit failed: %d\n", > + &pdev->sbdf, pdev->domain, rc); > + } > + > return 0; > } > #endif /* COMPAT */ > --- a/xen/drivers/vpci/cap.c > +++ b/xen/drivers/vpci/cap.c > @@ -285,13 +285,16 @@ static int vpci_init_ext_capability_list > return 0; > } > > -int vpci_init_capabilities(struct pci_dev *pdev) > +int vpci_init_capabilities(struct pci_dev *pdev, bool ext_only) > { > int rc; > > - rc = vpci_init_capability_list(pdev); > - if ( rc ) > - return rc; > + if ( !ext_only ) > + { > + rc = vpci_init_capability_list(pdev); > + if ( rc ) > + return rc; > + } > > rc = vpci_init_ext_capability_list(pdev); > if ( rc ) > @@ -305,7 +308,7 @@ int vpci_init_capabilities(struct pci_de > unsigned int pos = 0; > > if ( !is_ext ) > - pos = pci_find_cap_offset(pdev->sbdf, cap); > + pos = !ext_only ? pci_find_cap_offset(pdev->sbdf, cap) : 0; > else if ( is_hardware_domain(pdev->domain) ) > pos = pci_find_ext_capability(pdev, cap); > > @@ -349,22 +352,23 @@ int vpci_init_capabilities(struct pci_de > return 0; > } > > -void vpci_cleanup_capabilities(struct pci_dev *pdev) > +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) > { You could short-circuit the function here, ie: if ( ext_only && !is_hardware_domain(pdev->domain) ) return; But I'm not sure that would simplify the code of the function much? Likewise for vpci_init_capabilities(). > for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ ) > { > const vpci_capability_t *capability = &__start_vpci_array[i]; > const unsigned int cap = capability->id; > - unsigned int pos = 0; > > if ( !capability->cleanup ) > continue; > > - if ( !capability->is_ext ) > - pos = pci_find_cap_offset(pdev->sbdf, cap); > - else if ( is_hardware_domain(pdev->domain) ) > - pos = pci_find_ext_capability(pdev, cap); > - if ( pos ) > + /* > + * Cannot call pci_find_ext_capability() here, as extended config > + * space may (no longer) be accessible. > + */ > + if ( capability->is_ext > + ? is_hardware_domain(pdev->domain) > + : !ext_only && pci_find_cap_offset(pdev->sbdf, cap) ) Given the changes you have done to the reBAR cleanup function, we could even call capability->cleanup() on domUs, as the handler has to deal with uninitialized capabilities either way? > { > int rc = capability->cleanup(pdev, false); > > @@ -376,6 +380,28 @@ void vpci_cleanup_capabilities(struct pc > } > } > > +int vpci_reinit_ext_capabilities(struct pci_dev *pdev) > +{ > + if ( !pdev->vpci ) > + return 0; > + > + /* > + * FIXME: DomU support is missing. For already running domains we may > + * need to pause them around the entire re-evaluation of extended config > + * space accessibility. > + */ > + if ( pdev->domain ) > + ASSERT(pdev->domain == hardware_domain || pdev->domain == dom_io); Is this to cope around races? I don't think it's a valid state to have pdev->vpci != NULL and pdev->domain == NULL? Neither you can have pdev->domain == dom_io and pdev->vpci != NULL? > + > + vpci_cleanup_capabilities(pdev, true); > + > + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, > + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) > + ASSERT_UNREACHABLE(); Ideally this would better be done the other way around. We first remove the handlers, and the cleanup the capabilities. Just to ensure no stray handler could end up having cached references to data that's been freed by vpci_cleanup_capabilities(). And we should take the write_lock(&pdev->domain->pci_lock). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:08:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:08:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245577.1544934 (Exim 4.92) (envelope-from ) id 1vxnpW-00005W-Ao; Wed, 04 Mar 2026 15:08:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245577.1544934; Wed, 04 Mar 2026 15: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 ) id 1vxnpW-00005P-8B; Wed, 04 Mar 2026 15:08:06 +0000 Received: by outflank-mailman (input) for mailman id 1245577; Wed, 04 Mar 2026 15:08:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnpU-0007oB-N2 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:08:04 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f0975a6e-17db-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:08:02 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48336a6e932so43019485e9.3 for ; Wed, 04 Mar 2026 07:08:02 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439b0549600sm29368404f8f.35.2026.03.04.07.08.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 07:08:01 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0975a6e-17db-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772636882; x=1773241682; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=n72m+QEc/gPGrAZ2170RYO1NvK3dfHMFAijzDzbtdbY=; b=iFXu8W6vTKrE4/Kv5A02HcHRfNzr5UafP6i/zP16o+m7Uy5DxUkQ8UXEfPnz3rkyFt 9QHxrEokUzcHHfSBO/r0kyCHQIN1z/PCLLI+MwYtx0tbyTYhUjdknIxxFgkNeJKZM/8O UaoZOQOSVcqYtREZiFFWJb1xNMuuyXnoniUHGsTr0BvWgGSTAyjMDpudpw/ygvjs0tOm 4W6IWK74S5vg8Aa027j4W3CX8kYEdK6zqgO0Z9KyDjEbxBMr8ZlNzBiDGzk/P8oGormd 9glSoz30qNg6IOF8YFgcJHplQQgV6NmrX8rvhVeTDxMQKAdmJa0UdrD5SfRmcm9duaC9 F0/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772636882; x=1773241682; h=content-transfer-encoding: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; bh=n72m+QEc/gPGrAZ2170RYO1NvK3dfHMFAijzDzbtdbY=; b=bWxHaas0bjsX60TyQpeFVfc0WsXcfD2QLriHcJlHEhQxb2eTm54T/fkyYYZyXZkxMk 1bqJCswfUnu9ZR/E+TubteQMSZx96hWxDwsOXc+d2/AddAGWfUEFAWGHt4G76yohhvCS XHtVZueevHkNRDdGxeg6pGW7+q63tGkWNAsKMKt7JJKwQ9fm5dTSnv+0DYEeA/IysNi7 XoqxoJvNpd4FW+cxCQP9GWBto6p69hN514RSLoyRWv0WSW03WHqDco+YmntkbQI92c6a zP5IiXuf6+NdGVQIzvC3H4fYhQBKId8pzeS3UsaFugB5jhv62OSFioaEy82PXMWEoipl tKDw== X-Forwarded-Encrypted: i=1; AJvYcCXe4yOnbwQfEjyjtQCkt4vB1hmfDJ9PB8hknUMv8THtpxW+rx53jE7pFDsdFI1jDNwfgujWnrBZkhw=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyh8Wi1jp+PBltbgZSTaBOs59lXb4aladp2oBujuRWNvBvBwLGg bhv/9M83AyhW2+tAwXIv1MsfMDFqZ9cpoBVGVxNXtVUlFSFZvAacLdrY X-Gm-Gg: ATEYQzyZC2ICB035B3ljaK2X2XaWDu6QfL2UwCjYAHGx1TPb7DRI9e/DWZ9dAkyqbye gJRWJXol99hH5xKJf+LqpIPJPb67huictciJrSmSFD7D9N/zS74NR+J7sSCvDiAcF5jNOdtxiIf vMM9MLtbnyqpXEQyk2i/vLXmVI318v2CZ30JScQq7YaGymD4hWyZdPCx7o9lHMed8Li5jwv4CK0 +7+z2rSHnEcmr2t4K/7jOngMIFMJL+3cdN6mjdjsGZeG84r/IVB2K9RkJDqborIAdCkk259CUbp eUpnCGQPRQTF6VE+Wh9G15hsaDCGApU6MJkFIZud3qjiZDObZlOx0+EbrSTaAz0S2fQE20EYmBI /VsY/0gJHNng/4eUWPAdCjMdEhQjj6PUOkD4xuyxFU3IIraG6BqlHYozUc475Uot0qEWN+al/iL gYrEKCnBwn3kbElON+EObikFu82hnnlRQ74rzP9DtuGYOSC/GdyKM/Pl98wgD4SJHh1wEbeCPyh NM= X-Received: by 2002:a05:600c:4e8b:b0:480:4a4f:c363 with SMTP id 5b1f17b1804b1-485198480d8mr41405255e9.9.1772636881929; Wed, 04 Mar 2026 07:08:01 -0800 (PST) Message-ID: <32bd2cc9-86ee-4470-af7c-f52838e0c4e1@gmail.com> Date: Wed, 4 Mar 2026 16:07:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <6357ad3f-85c8-4fe4-a2c8-8b0a0a97f1b3@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <6357ad3f-85c8-4fe4-a2c8-8b0a0a97f1b3@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/3/26 2:35 PM, Jan Beulich wrote: > On 26.02.2026 12:51, Oleksii Kurochko wrote: >> Based on Linux kernel v6.16.0. >> Note that smp_wmb() is used instead of smp_mb__before_atomic() as what >> we want to guarantee that if a bit in irqs_pending_mask is obversable >> that the correspondent bit in irqs_pending is observable too. >> >> Add lockless tracking of pending vCPU interrupts using atomic bitops. >> Two bitmaps are introduced: >> - irqs_pending — interrupts currently pending for the vCPU >> - irqs_pending_mask — bits that have changed in irqs_pending >> >> The design follows a multi-producer, single-consumer model, where the >> consumer is the vCPU itself. Producers may set bits in >> irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is >> performed only by the consumer via xchg(). The consumer must not write >> to irqs_pending and must not act on bits that are not set in the mask. >> Otherwise, extra synchronization should be provided. >> >> On RISC-V interrupts are not injected via guest registers, so pending >> interrupts must be recorded in irqs_pending (using the new >> vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating >> HVIP before returning control to the guest. The consumer side is >> implemented in a follow-up patch. >> >> A barrier between updating irqs_pending and setting the corresponding >> mask bit in vcpu_set_interrupt()/vcpu_unset_interrupt() guarantees >> that if the consumer observes a mask bit set, the corresponding pending >> bit is also visible. This prevents missed interrupts during the flush. >> >> It is possible that a guest could have pending bit in the hardware >> register without being marked pending in irq_pending bitmap as: >> According to the RISC-V ISA specification: >> Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and >> interrupt-enable bits for VS-level software interrupts. VSSIP in hip >> is an alias (writable) of the same bit in hvip. >> Additionally: >> When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only >> zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and >> hie.VSSIE. >> This means the guest may modify vsip.SSIP, which implicitly updates >> hip.VSSIP and the bit being written with 1 would also trigger an interrupt >> as according to the RISC-V spec: >> These conditions for an interrupt trap to occur must be evaluated in a >> bounded amount of time from when an interrupt becomes, or ceases to be, >> pending in sip, and must also be evaluated immediately following the >> execution of an SRET instruction or an explicit write to a CSR on which >> these interrupt trap conditions expressly depend (including sip, sie and >> sstatus). >> What means that IRQ_VS_SOFT must be synchronized separately, what is done >> in vcpu_sync_interrupts(). Note, also, that IRQ_PMU_OVF would want to be >> synced for the similar reason as IRQ_VS_SOFT, but isn't sync-ed now as >> PMU isn't supported now. >> >> For the remaining VS-level interrupt types (IRQ_VS_TIMER and >> IRQ_VS_EXT), the specification states they cannot be modified by the guest >> and are read-only because of: >> Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable >> bits for VS-level external interrupts. VSEIP is read-only in hip, and is >> the logical-OR of these interrupt sources: >> • bit VSEIP of hvip; >> • the bit of hgeip selected by hstatus.VGEIN; and >> • any other platform-specific external interrupt signal directed to >> VS-level. >> Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable >> bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the >> logical-OR of hvip.VSTIP and any other platform-specific timer interrupt >> signal directed to VS-level. >> and >> When bit 10 of hideleg is zero, vsip.SEIP and vsie.SEIE are read-only zeros. >> Else, vsip.SEIP and vsie.SEIE are aliases of hip.VSEIP and hie.VSEIE. >> >> When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. >> Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE. >> and also, >> Bits sip.SEIP and sie.SEIE are the interrupt-pending and interrupt-enable >> bits for supervisor-level external interrupts. If implemented, SEIP is >> read-only in sip, and is set and cleared by the execution environment, >> typically through a platform-specific interrupt controller. >> >> Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable >> bits for supervisor-level timer interrupts. If implemented, STIP is >> read-only in sip, and is set and cleared by the execution environment >> Thus, for these interrupt types, it is sufficient to use vcpu_set_interrupt() >> and vcpu_unset_interrupt(), and flush them during the call of >> vcpu_flush_interrupts() (which is introduced in follow up patch). >> >> vcpu_sync_interrupts(), which is called just before entering the VM, >> slightly bends the rule that the irqs_pending bit must be written >> first, followed by updating the corresponding bit in irqs_pending_mask. >> However, it still respects the core guarantee that the producer never >> clears the mask and only writes to irqs_pending if it is the one that >> flipped the corresponding mask bit from 0 to 1. >> Moreover, since the consumer won't run concurrently because >> vcpu_sync_interrupts() and the consumer path are going to be invoked >> sequentially immediately before VM entry, it is safe to slightly relax >> this ordering rule in vcpu_sync_interrupts(). >> >> Signed-off-by: Oleksii Kurochko >> --- >> Changes in v6: >> - Drop for the moment: >> /* Read current HVIP and VSIE CSRs */ >> v->arch.vsie = csr_read(CSR_VSIE); >> from vcpu_sync_interrupts() as it isn't used at the moment and will >> be introduced when a usage will be more clear. > With this, shouldn't the RV32 related #ifdef in vcpu_sync_interrupts() also > go away? It could be done in this way. It's just a hint for a person who will add RV32 not to miss to update vcpu_sync_interrupts() properly. Lets drop that for now too and deal with that during review if a person will miss to make correspondent update of vcpu_sync_interrupts() for RV32. > >> +void vcpu_sync_interrupts(struct vcpu *v) > The sole caller passes "current". Are other uses of this function planned? > If not either "current" wants directly using here, or minimally the parameter > wants renaming to "curr". In fact ... > >> +{ >> + unsigned long hvip = csr_read(CSR_HVIP); > ... this suggests it's unlikely for the function to be valid to call with > other than "current". Agree, I will drop v argument and use current inside vcpu_sync_interrupts(). Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:15:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:15:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245592.1544945 (Exim 4.92) (envelope-from ) id 1vxnwS-0001jI-0w; Wed, 04 Mar 2026 15:15:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245592.1544945; Wed, 04 Mar 2026 15:15:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnwR-0001jB-UH; Wed, 04 Mar 2026 15:15:15 +0000 Received: by outflank-mailman (input) for mailman id 1245592; Wed, 04 Mar 2026 15:15:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnwQ-0001j5-H3 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:15:14 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id eebe7bf4-17dc-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:15:09 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4838c15e3cbso63626675e9.3 for ; Wed, 04 Mar 2026 07:15:09 -0800 (PST) Received: from [10.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-4851a82cdf7sm24196915e9.0.2026.03.04.07.15.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 07:15:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eebe7bf4-17dc-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772637309; x=1773242109; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=yX3yE1gNgEZzFEo3P5s6U8ni5U3DyiFcDvDdauRDwkk=; b=eDW2DyMwwwppWw6Zmd/bNxJNBa26id0+YSxvR8CAVX9mZuomP4uY/RY4XaEoNqbQ9d fFqsm6y9JCCwtyM1M0cWompjbH+FOieOnvzC5AQepHxWzmTUPOgrodB3VJkaUNkkpD9m zzt/07HrksGY/Uv67M0ajhdSQKJi9cphmId0KsNnxyDQiIQGJGpad3ZuJ7Tq37UkhpwS IwhIcOXr/Nf/U82JWL2UJuOTRapltT0zY1yg3BAlilLBnL+adwDB+6cL71SX+gbz+Fs9 i49pluSLx0KctcGaKx5V2vDprx+ItRWp2WiU5nTpNSO9xvPqFd8k6y1I3UZIFI3zM331 xoTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772637309; x=1773242109; h=content-transfer-encoding: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; bh=yX3yE1gNgEZzFEo3P5s6U8ni5U3DyiFcDvDdauRDwkk=; b=s+XUctOhz15bH/Tqam3FcMMmGPKGJy6SEM6twnPdNBUlQq0ahxO2uhrC1S4psGGBkk EYwa+T+ghKpPMH3kW2uVtYNFTzUdQ1tKnqdGQ2IeHHlTShAg2HZGgnALw1Czeyg5UVCV 8go9JU3P1EE5AVoT1YR7mMuEb+tQnkhbXaA9hybKRCj4MpXBDb1DQXchEOZaPf0vjqKM ZUA5oIS7o8iK9NxCjBASF2nCn5YGNJTfLPSJy48W+pPKTxlneuQrNdDr6EyzBk/YRPK3 DzyJc0A6GapAlGWinfspKNMVZRfPjn7HotWaT+ioX6u5UxB0ey5/onwkeqhvHgpk6w8c 4aaQ== X-Forwarded-Encrypted: i=1; AJvYcCXWjpgSat+Yak9wL92RsYFPOCI92yMclAdhKH3lGodG3uYnb4GMGz40HQWG2xNzZUYEkJ9qwPCGz3I=@lists.xenproject.org X-Gm-Message-State: AOJu0YxPEVdSkQ6n2OyY96Za+h35yPPvj5GVv3bH+SNtcaNnihQEzwS8 pF7c+/IHtpYXD9H/aT2GDSMnCOag2vWD/d8MkBdKuUg+2ngts4q8JUnPY+f4gTm5FA== X-Gm-Gg: ATEYQzyHaUKe25NzBo4TEpBfOCt+PfDEovEG2b8zxNPw+Kec8xgtY644d5MaJXO62nn RV5XDg+upccJgWqAeMuF4lnDcUoY9qZIPk4KdHVTquWv4AWT4Mye6+kSDK1364uLxBHnvH4ruat vFZKEZ2J1rFUUP2VSS6F7jLxPfUG7h2ILEjYD/mYprXVF7c9XBJCqiR44rJP2NTxTQdWaEmiIfI 3hCeOQ8ErU2oZgZfSLq6moLzn+sKehtwnrdtDhD012k6opA1VB9XvTix1E99EyhZsLd/+YqnOSE rdISlwd/pqJh1ijbm2mfmhYuBxgvT7BvQxqMKMaN43w77Num/n1Knrj+a5wu74u7MRUutNErxgh rLFYuruu2f7q9ZhHc/M5r9uwzsQKB6zzftPO/L94Xr42LSdPO28SGsCfKIP9z5MoxQ/D7UEtY5b lxM//ggi2MW0Xr2Ms9iKWBea+sHEGnWxePrp3jsG1CNgtS3r90UaoDU09uLt+1i2P/3xnKZfHGs mbuTefpBSWh2jo= X-Received: by 2002:a05:600c:46cf:b0:475:de12:d3b5 with SMTP id 5b1f17b1804b1-485198cb8d3mr36295325e9.34.1772637308574; Wed, 04 Mar 2026 07:15:08 -0800 (PST) Message-ID: <675ae59f-52fa-41a9-b15e-b889313a88ae@suse.com> Date: Wed, 4 Mar 2026 16:15:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4b67f8cb-43d4-4f18-b2b6-156e21330887@suse.com> <7e1f3962-2dd0-4843-8976-40452437a52a@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7e1f3962-2dd0-4843-8976-40452437a52a@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 15:54, Oleksii Kurochko wrote: > On 3/3/26 1:23 PM, Jan Beulich wrote: >> On 26.02.2026 12:51, Oleksii Kurochko wrote: >>> +void __init init_csr_masks(void) >>> +{ >>> + /* >>> + * The mask specifies the bits that may be safely modified without >>> + * causing side effects. >>> + * >>> + * For example, registers such as henvcfg or hstateen0 contain WPRI >>> + * fields that must be preserved. Any write to the full register must >>> + * therefore retain the original values of those fields. >>> + */ >>> +#define INIT_CSR_MASK(csr, field, mask) do { \ >>> + old = csr_read(CSR_##csr); \ >>> + csr_write(CSR_##csr, (old & ~(mask)) | (mask)); \ >> I (now) agree csr_swap() can't be used here, but isn't the above >> >> old = csr_read_set(CSR_##csr, mask); >> >> ? > > Agree, csr_read_set() could be used. > >>> + csr_masks.field = csr_swap(CSR_##csr, old); \ >>> + } while (0) >>> + >>> + register_t old; >> Since the macro uses the variable, this decl may better move up. >> >>> + INIT_CSR_MASK(HEDELEG, hedeleg, ULONG_MAX); >>> + INIT_CSR_MASK(HIDELEG, hideleg, ULONG_MAX); >>> + >>> + INIT_CSR_MASK(HENVCFG, henvcfg, _UL(0xE0000003000000FF)); >> This raw hex number (also the other one below) isn't quite nice. Can we have >> a #define for this, please? It doesn't need to live in a header file if it's >> not going to be used anywhere else. > > Sure, would it be okay to define them inside this init_csr_masks() or at the top > of the file would be better? Either would work imo, as long as you don't expect other uses of these constants. Personally I'd likely put them not at the top of the file, but immediately ahead of the function. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:17:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:17:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245601.1544955 (Exim 4.92) (envelope-from ) id 1vxnyC-0002Ev-Cw; Wed, 04 Mar 2026 15:17:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245601.1544955; Wed, 04 Mar 2026 15:17:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnyC-0002Eo-9f; Wed, 04 Mar 2026 15:17:04 +0000 Received: by outflank-mailman (input) for mailman id 1245601; Wed, 04 Mar 2026 15:17:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxnyB-0002Ei-5D for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:17:03 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 317854a6-17dd-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:17:02 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM4PR03MB5984.namprd03.prod.outlook.com (2603:10b6:5:38b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 15:16:57 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 317854a6-17dd-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DyL6cD1gVsx1x77O4iM6efS1qcqQcLg9FHTBEt3lnuaY4ii1+SU/LzOm/37ifSim7fJaHxzYQMqululll9xn8Yb08D5W2u2Ila4rB1/sZfp5JQtmYsqN57J0yhReO6Xqf0+eEstknp0TBuKx1KYri4YxEYKcJPBtJV/SE5eX3Sfqg5Es+iqjzEB+s5GU/1sMEmySspyq38WGdpp8dq1hSWtIbcLfGkkhZ4mv8Io2q9Pbtgmr9m93GoS0//ntcGCCfSvWUV2heVfAB6xKKjh892IvLGBcJWP0eJBNKJ1BdHZ0JubX9/l1xddv05JTXJcScT4bBxlMDZ5MY2NXTrKerQ== 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=8zWOvi79uAiRZPeyvtUEvGOvoBJzCu4sYVQ/d/Gt9Ms=; b=GW7pE1GLaYPBeEaKY1ft2SZqoOh/RAr/eHvAQVsoacPat5rhBQwv+V0BGIOFOAWtt38P1FBwEdP6J23V+iuZrUu36iVRFINpRl5w8kP/msWRm0P1JkVzyWad3w7zbPuixC7edffnSdTJKli6/c4ePfllhe/dlCPTPr2131zE0Hu5Xs1FoCCf66JF0qgEPMzp8UljlRgwiA4pdoKrt1TXoPhSMWLhb2vA17jlMqXsdefE+oTunPHwZ0dDaOeL2AlHm0+Jt+EWX9LbREj+1WmnvDeQJ1Qf6kxCy49uLEEiXjLnqr8g530iVEWu4idGNuFKvrcDDPfGU2QfkYan2Jrmbw== 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=8zWOvi79uAiRZPeyvtUEvGOvoBJzCu4sYVQ/d/Gt9Ms=; b=p5ZeOkTHfh5Eb3JRtVm/klTBrhzRVgXKf0n8qp+UJGm4ncn21qD9R3ICjTrqOJjouXu6hY/FLZjOM2dfZ54l3x/kw5K6PG5mJRboLldg6OqLvEMyqBrUA1HgRike06nzZkY+Lg13T9iWbJPn3kus0W54eS5ru1upEOXRu7QYZG8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:16:53 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Mykyta Poturai Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v1 4/6] vpci: add SR-IOV support for PVH Dom0 Message-ID: References: <8da9f137-a897-4438-9524-85836e0170a1@epam.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8da9f137-a897-4438-9524-85836e0170a1@epam.com> X-ClientProxiedBy: MR1P264CA0172.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:55::20) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM4PR03MB5984:EE_ X-MS-Office365-Filtering-Correlation-Id: 25d98dbe-6d64-421c-2959-08de7a011314 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|7053199007; X-Microsoft-Antispam-Message-Info: MiMhN0wxm3dEgsHMqp6hsMr0iuHx65QwoCVsJ2A+emSYPbQIjLYjHoOXEA/SYJnW1xavbAF83Aym/ADr12lHKK468cY+NIDlHRrt612GYWKae2Mw7mcIarc3awbqSh61k+qIwerj9ggma9VDlS7QHV6AQwevN5/5HZDntvGYJG/Zdk88TIdPMUNVYj7U9wVVCKaH8GLo5ya73kg3ro4xgD7xLMrg28LezgU7z7RqAw0lz1X3LJ3LAdpdE+EA6+lAUQKdsSAikO84XeCvcQLK3t/mN2Bk/FCsGsnnfTLp1XhxRkz3sGzEj5HWC6JaNInKmAPzUtnhWMWoPo6+0gqRx8f0RAiuRg5PJ8yq3cljKx6aicq8JyA8QLHtinnDQ/HUEVWBv0MpzQtjrgxDN3OD6jeZQzOrXX6KgoMiHGgqX3LRtflqfNKa9nzOjYVnqnV3khnVN04CoYmpffZrupGIf6zlz3JzPl1HwHSXMWFK3kYqE8/TTwby7y72hPHRcDfXLKubY+ke3MIuABt+3dT764nv4jsy90s35z8bpHTLzxKQyZiSHn2baXpu3fkCV2RMCbJfAhoWw89Bo6SoeqgyxBV7rPPYSbm1WFieewK2oJoYddF/hLqss7mEQ52y4wfJYMNhPu0nZ8HQAAslN8PW8lE7IDsjdkFE5TezLsZ39qMJ1uCOO8OZxZNxN/x1ZGbs X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UjBQenhtekpvQUkyWTRFbmFzL0lYbjRyZ3QxZnNKSkVUSWNLUVExL2FpcU1R?= =?utf-8?B?dkpsSlBzMUNIZGN1QlpVSXgwMzFQS2dQa0RyU09rTHFzQnpnb29zdEptVXlY?= =?utf-8?B?NS82b3VKa0s2dkYyUXB2QytPVDMraUljekg1MnlkakFJWWJRdUVsVXd3enBR?= =?utf-8?B?NUcvZGFYTW9HdHBMTkF3UDNrbnFScmM2aUVmNHQrYkxnR2pqQzNNc3JJVWZ0?= =?utf-8?B?RjYzb2RRVjBhN2hXL3o4UTZ3bkpDWDNHRldzU0xGd2MvYWFSQzZBUjJVWUQ4?= =?utf-8?B?amZDYktxeUNkTFlncysxRnVRNmJhSWNLaW1lcVBXb3gzMUp5SitkQVlvSGQ2?= =?utf-8?B?R2ZUYkZ1eWlVUzg3d0lnQ2lQdHo3SmY4UFBxRDhHVnFibWhGb3g4OGFvMWFv?= =?utf-8?B?N3JJTTVxbmE2dkNQeUFjeUxYdUhuMW5HcHhSaG5DOG91b3kyL3piYWxNV1dy?= =?utf-8?B?TDNoVWsxMXNodHdmVkIxWTlIVUdTbzVXaWkxOWxGWnRoVEJJMTNQTjRZd3ps?= =?utf-8?B?VWorRENZRE85SEp5cG5uU0lkcnAwcURBTXl3VlVNZjBxc1RBeWhGMlAwcTlr?= =?utf-8?B?YzZEWlgrb0k2SEZibk1Ga240M1VGK0tScUYvT1BCS0hUK2ZQOHY5RkdnRkUv?= =?utf-8?B?VThEcWw5NlZBakhKM3dLMjZuY1hlNkREdjVDV2YrSHpsMTloL0luTnd3Qk5E?= =?utf-8?B?Z1JuYitNRE5kTkhueG1janJZNWRqYjk0cjRZU1ZJV1c5bldNV1U5Zyt5QXdK?= =?utf-8?B?dUliY1EvWUpjV1pXbkV4c1d2RzVUTlZQMXpnYmZtTjNwaytIV3l2azQ1bXh5?= =?utf-8?B?NVNkVXFuRXVFK09DUUd5eUlMbGxkNkJZUVI0T3dGQ1g4ODgxcTkxQVhlNWs3?= =?utf-8?B?MzMybWdPRDhlRGExcnA5Uk40ZnFYUk9Bc0lSREI1SWpjdk4wOXp1TitUWDdo?= =?utf-8?B?aFhiWmVLSlVtNTJTblZmVE5BczZQQ2g3MVB5RHpiTDBVRndVdU1pMWxwem5l?= =?utf-8?B?akNNTGJrak5zalVHaUlpa2tBZG5XellkZXRHc2xGYlM0OFh4SDNSMlZWdEVi?= =?utf-8?B?cWZRRWhBcHpvdnNDcjV0QTR1Y2dWc2xOT2JXR1FKaUVySG9ERDJSWjNlRFVS?= =?utf-8?B?Y2lqWGQzRXRjVEt3SDZ4ZlVLeVZ2Vm1Lait6YlgwTlRSOFMzdE03TGgrSFJK?= =?utf-8?B?ellvOVBqakUva1VxcGZGd3N3ZHRuNXRkeElSdVpjd3cyUFU1Mkk5bFFoSlNB?= =?utf-8?B?NVZXRWVlemw1SmpFcWU4NU9tTndvbzJIQk1vZnFra0ZneCtEZU01am5KblRl?= =?utf-8?B?Vi9ZdGk5eEloUXFhZkdrSTNScS9razRsSkxWRGc4VWxjM09vN2NUbUUwWG5B?= =?utf-8?B?ZERLdXl4U0dMU0xaZXNUY0M5WlcwYjFKbVlQek1rNERvQUlWWnMyKzV0SXBQ?= =?utf-8?B?R2JCV2ZHNndLdUNCVWdwY3FZcVVEZDR0VVpWUTJkOWYzYkxyNGJzdDdSSVdZ?= =?utf-8?B?enVvK3VNa3hyWjhNdEswcUxFNnhvOTdpQTEwVUhpZUhuY0JTMW1TYTFDTmZl?= =?utf-8?B?VzJKY3Y0aVRQSXVINWc5SThmMDdvWVZLaThVQVlyeDZsa3Z2M2xYRVpiMmJs?= =?utf-8?B?UFppNHQyRTNhWktoaU12ZDBaMkJYNzVHWGxMTW5EQmZHZ2tnblFqZ3ZDc2Rx?= =?utf-8?B?Z3YxZExqSWRCb1FhMUlweHlFRG5nQVBlY2FYcTYxVjNHVXVUTUpWMFdTc1JH?= =?utf-8?B?VjVTczlkcysxMXBLM1NmeHdUSnQxbXl5MHJxQWFFV1VYdlZqMm0zVk9QYmJz?= =?utf-8?B?T3hVNlRhK1AzZ0FWRmxXTnpUV2xWejl6UW00M3Rtb0c4cXVjZ2E0R0pORmNy?= =?utf-8?B?TFFSMWUxOWFZLzdoOGFDeHpQL3dvaTBnZUVzWGRYbVFURmdZN2VlYmVma0pk?= =?utf-8?B?T05pWGI3M014czd4cTJReWJmbUFOa3FsOWRhUDlzQ2RGbDR6YXdUODE4Q2hP?= =?utf-8?B?MUNucURGK0E2NmxYR2N5a3RWY0N2N0JHMVV3QkVmcmlXQVhrTDdOZWlKV0FK?= =?utf-8?B?c0RUQ2Y0RFArbWFIa0U3VGlDMVBTcHlUQ0hPRjdLZFp4T0dldytWZ2ZVOFZh?= =?utf-8?B?SmNsdlJYM1ZkaEMyMEtaSlI5SGJSMVpON0tuNzZrQi9aQnRvdG4rejhWcVpD?= =?utf-8?B?THlYUXFyNUpCb0dpTHpvY3BjZmRUU2lVNnUvOHhYL01jdnc4MkpWcmszODlS?= =?utf-8?B?WVNEWGUyV3lUY3hhTjhqR29oenRUdldGTEJPUkFuWXdzeW5wNDVxTFlKZFE1?= =?utf-8?B?bytWMExjS0pMTVF0aHg5YUx2Tms3WkgzeGQzTXI4dm9ET2EyOVgxUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25d98dbe-6d64-421c-2959-08de7a011314 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:16:56.8664 (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: BbGTQJUF4LqetCMCp1BuM9x+OHJZTWv8avzxBI56UDPEUWarvZjjxm/JJnKb7BSlSEo/5BKV/KIieKv5GwBUgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB5984 On Wed, Mar 04, 2026 at 08:43:17AM +0000, Mykyta Poturai wrote: > On 7/28/25 14:33, Roger Pau Monné wrote: > > On Fri, Jul 25, 2025 at 02:24:33PM +0000, Mykyta Poturai wrote: > >> From: Stewart Hildebrand > >> > >> This code is expected to only be used by privileged domains, > >> unprivileged domains should not get access to the SR-IOV capability. > >> > >> Implement RW handlers for PCI_SRIOV_CTRL register to dynamically > >> map/unmap VF BARS. Recalculate BAR sizes before mapping VFs to account > >> for possible changes in the system page size register. > >> > >> Relies on dom0 to enable SR-IOV and PHYSDEVOP to inform Xen about > >> addition/removal of VFs. > > > > Why I'm not opposed to allowing registration of devices using > > PHYSDEVOP, can't Xen detect the addition of the VFs and add them > > itself? > > > > When I worked on this long time ago, the version of the series that I > > posted had registration of the VFs done by Xen also: > > > > https://lore.kernel.org/xen-devel/20180717094830.54806-12-roger.pau@citrix.com/ > > > >> > >> Signed-off-by: Stewart Hildebrand > >> Signed-off-by: Mykyta Poturai > >> --- > >> CHANGELOG.md | 3 +- > >> SUPPORT.md | 2 - > >> xen/drivers/vpci/Makefile | 2 +- > >> xen/drivers/vpci/header.c | 3 + > >> xen/drivers/vpci/sriov.c | 235 ++++++++++++++++++++++++++++++++++++++ > >> xen/drivers/vpci/vpci.c | 1 + > >> xen/include/xen/vpci.h | 7 +- > >> 7 files changed, 247 insertions(+), 6 deletions(-) > >> create mode 100644 xen/drivers/vpci/sriov.c > >> > >> diff --git a/CHANGELOG.md b/CHANGELOG.md > >> index 5f31ca08fe..7b0e8beb76 100644 > >> --- a/CHANGELOG.md > >> +++ b/CHANGELOG.md > >> @@ -23,8 +23,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/ > >> - On x86: > >> - Option to attempt to fixup p2m page-faults on PVH dom0. > >> - Resizable BARs is supported for PVH dom0. > >> - - Support PCI passthrough for HVM domUs when dom0 is PVH (note SR-IOV > >> - capability usage is not yet supported on PVH dom0). > >> + - Support PCI passthrough for HVM domUs when dom0 is PVH. > > > > Don't you need to move this out of the x86 specific section? > > > > According to the cover letter you are testing on an ARM board, so this > > probably needs to be put in a non-arch part of CHANGELOG? > > > >> - Smoke tests for the FreeBSD Xen builds in Cirrus CI. > >> > >> - On Arm: > >> diff --git a/SUPPORT.md b/SUPPORT.md > >> index 6a82a92189..830b598714 100644 > >> --- a/SUPPORT.md > >> +++ b/SUPPORT.md > >> @@ -170,8 +170,6 @@ unexpected behavior or issues on some hardware. > >> > >> At least the following features are missing on a PVH dom0: > >> > >> - * PCI SR-IOV. > >> - > >> * Native NMI forwarding (nmi=dom0 command line option). > >> > >> * MCE handling. > >> diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile > >> index a7c8a30a89..fe1e57b64d 100644 > >> --- a/xen/drivers/vpci/Makefile > >> +++ b/xen/drivers/vpci/Makefile > >> @@ -1,2 +1,2 @@ > >> -obj-y += vpci.o header.o rebar.o > >> +obj-y += vpci.o header.o rebar.o sriov.o > >> obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o > >> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c > >> index f947f652cd..0a840c6dcc 100644 > >> --- a/xen/drivers/vpci/header.c > >> +++ b/xen/drivers/vpci/header.c > >> @@ -839,6 +839,9 @@ static int cf_check init_header(struct pci_dev *pdev) > >> > >> ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); > >> > >> + if ( pdev->info.is_virtfn ) > >> + return 0; > >> + > >> switch ( pci_conf_read8(pdev->sbdf, PCI_HEADER_TYPE) & 0x7f ) > >> { > >> case PCI_HEADER_TYPE_NORMAL: > >> diff --git a/xen/drivers/vpci/sriov.c b/xen/drivers/vpci/sriov.c > >> new file mode 100644 > >> index 0000000000..640430e3e9 > >> --- /dev/null > >> +++ b/xen/drivers/vpci/sriov.c > >> @@ -0,0 +1,235 @@ > >> +/* SPDX-License-Identifier: GPL-2.0-only */ > >> +/* > >> + * Handlers for accesses to the SR-IOV capability structure. > >> + * > >> + * Copyright (C) 2018 Citrix Systems R&D > > > > If there's a Citrix copyright header here, shouldn't there be a > > matching Signed-off-by from someone at Citrix (I think that's likely > > me)? > > > > Otherwise if there's no content authored by a Citrix employee the > > copyright notice must be removed. We need to be careful with > > copyright and attribution. > > > > And in any case the date should be updated. > > > > Can I add your SOB or is it better to remove the copyright? Looking at > the patches you provided, I think this ones were definitely based on > them, but there are also a lot of changes since then. If it's based on the patches that I sent many years ago (2018), then yes, you likely need to add my SoB. Look like that way from the copyright notice. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:23:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:23:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245613.1544964 (Exim 4.92) (envelope-from ) id 1vxo4m-00046T-5u; Wed, 04 Mar 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 1245613.1544964; Wed, 04 Mar 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 ) id 1vxo4m-00046M-34; Wed, 04 Mar 2026 15:23:52 +0000 Received: by outflank-mailman (input) for mailman id 1245613; Wed, 04 Mar 2026 15:23:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxo4l-00046D-DI for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:23:51 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 221c5a84-17de-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:23:46 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6576.namprd03.prod.outlook.com (2603:10b6:510:bd::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 15:23:41 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:23:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 221c5a84-17de-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VbkyTNPSRCM52UNnz/RrbYSaHcfDseT0h4UVDzqlBeLiE/jRvGIUjzi3W4AB/bej9pARRsrn85qk2yt65wUv8bNDxoxUU4BN7sRkRpb3uSSQBmjnLrHZZjibddaUw+ndnJiOrcR0fk+1L9YG/3VQ19ZV08+q//CRKOGn0lT/ifMkqeFldgYg5iCRcxpWU0g6C+Yf+A29MncbCbzvdCKG8Zk8t3Wcy0WEZ0f/Uaj0ovXllJ2EMGHz8qcgx7kMGmBMPsdJSaIK5zmbwGrzFG825u5u7IQ7WYsz7psqVmQP+sfdG4bACByn1PaNZQgnfZ5J4+SMOK6JMQ6v4+5LsHpVwQ== 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=7eDQGeM3BN14L0eXKMI26nHxKJwZ35+HWJqpeczVuNs=; b=F9gLIdhDtwfUT1Uzge/WVHuqwEeHmKhKOPVTI3hwF33jyNzL8sRDYS2MGyA7mY7hbIpw9Gnc+Wb1EGfHcM1XsKurKZ5jDAl+DEl3XmBjzwqZn5dYoXGj4/SRhAMwP7z7cYRgYCDgcDZbgHCptdRZ/VeyWlcf9X44OKEk9NJp9YZ+xYTFblhUzVoxalGhIE722ICPCoEg3xIhtG1u9/iMVMDA6U9UNkqs/XkeLzq0wqRDnetYQcxGSPxV5hgYuNCTwTtETIbmFDFsFdjUJQ36GbpXjpaC7rjMTuNqppoKZMEAgIXSqwsF0t/FgFkyg1wNCUyc6UMOAsmQzsl4FHHr0g== 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=7eDQGeM3BN14L0eXKMI26nHxKJwZ35+HWJqpeczVuNs=; b=k+OmL9sv/Y42pP11/v3Fkzx1hmhM/oDEelTnRPN2Y8YS0rAva7+lFatbEcBhI0q3f7PznsAv9nYmwpGtf1K+tNrSr6LPGAH2CUt9N/2vuCGTRvVFOAQYnI48QBmfLmpbESFrcXy5alX76BeccttiB/mms00DeOhzQZ/TEQoQGds= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:23:37 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stewart Hildebrand Cc: xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v3] vpci/msix: check for BARs enabled in vpci_make_msix_hole Message-ID: References: <20260226025740.71673-1-stewart.hildebrand@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260226025740.71673-1-stewart.hildebrand@amd.com> X-ClientProxiedBy: MR1P264CA0018.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::23) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6576:EE_ X-MS-Office365-Filtering-Correlation-Id: 4e1e8f29-b2ac-4667-ab49-08de7a020447 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: abt1ytA/XxOt+FKuA/79G7jI3yUXFQzuyu4/JSK8ID+FYI+bX7vGw0jhdIxiwr5vV9GXSf9nySGlKJnH04pO+IQe9revmIUqmnm/bxZsgvAIfxjCWWEZFhFUsbeqMWpMdplTEpMibIvAYhEoCtpCT2215zm06zzfUIkbL5j64ZwivtdpUKUt3jdRXSkTUGNhuXw3B7R47rKrWuqDuTWymlbagJY4HGjnHDq/dufOS793WhDccjy3AyX8xoz64A5WlRpm3xbaH/mOehzsp6WUXrkVVIUUY+1LmTKOlTv7oPieVI55xATnmt2zgx8BaS1npUxM60+YkE0y2VEI9A6BMC9hv/joE7TKgyz8hHkjqmzIlPDJHEvIwSI/eLhH5yJE5Ew93fvjwTJ33zxqoqxL5YM68+MJJp1ld0mU8JAWEN2KS1HE8yHxzmNT61sWuj1ySolVjHEwjA1tZ7NbdAuj+0TdVgx1/RvjLg2nzcduaNrDJL0GYrKTpki8vxnsbqYWfCfu4q5FEXuO7TZpuYn2WG5ioUDpLFfp4vydiGMRPpmZ/F8tOjXJq2quNkgBLfSPS7aRSqNNXY5xIOx2xt4ewWW//VZ24gQ3EgwUn5FzyGWiyzgaZ7x0g1bVYVVm/TTL58AQOGNThpS4awiIdQTdMkBLKWwWgiceR+608fpSaXP/0Hi75oR4Q0B6BJSNtNRVxl4vB/rCevZl7UOOiFh5upfcIVA0QScglnruha/m6JM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a3lmb2ZhOFRkRUJPMWlCTUJsS1k0YUE2K1BYajh3Vk9zVlVsRk1sYVVscWo1?= =?utf-8?B?ckFkWitxc3loblFmTWFEeXZNTXBHYm5SZDVMSEpkVWNET3grMFYxNHNXUWNl?= =?utf-8?B?S2RwQWppTW9yZGNGcmhDWTVwSUlndzdxZ1RXUUYyOWtQZGhoNi85VFBOLzIw?= =?utf-8?B?TENVWEhJYytYcnhVNEhSQzA5NXVVY3RkRS9yUC9jQU9PRm1TbFkvRE1kL1BH?= =?utf-8?B?cGxtS2Q5ZzdPdXVRNXFVTWo1ZjMwZDI4bmpFL1JxTlplRjdHV1h3VXBUcXpm?= =?utf-8?B?K3UwU1o5Rk8rMExGNGJLMm1POTliSUJGVWdKWG1vdFdSWDFnaytYOE5Ib0xZ?= =?utf-8?B?WFU3aEdnaWFobTNxeGtRSHVKRXc4MGY4emtxM2xyUUxtZlJvQngweWpIb0kw?= =?utf-8?B?OWpPQVh3NW4xTW5oS0Irb0doZVQ5NTFtZDFUeXFobVUwcWFnSXVjSTZuMG5v?= =?utf-8?B?dDAwdEhlc3dTZitKa3p3TlliZDljR1pDUVJSSlV2cFVyK2cxaUwyOEo0R1ZD?= =?utf-8?B?bktKWDZYRzZMSnA3NWtIZG1LMWM1LzRiK0k2UkFDSFE3YnlSaE5YWUFqbkdt?= =?utf-8?B?MEplUFppQS9RUUFZbjV4bk8rWndiT1JMaHEzbmhUQ3Q4RVBqM3llNmFpZkxn?= =?utf-8?B?MFBBeGZQK2xudTl3NVM0eTRrdC91WFNUcnl5UHN1bjBVS3IyeW1jL2g2dVFM?= =?utf-8?B?QThCUWRTOFhxL3BHbTRIM1prVmxwZ2FlUFRLVUVSVUMvOXNVZFc2WEQxcUFV?= =?utf-8?B?L0RPRG1Uck1OclU0dmVBdVUxcFlVR25RVm9NeDBwR3ErR0RCU3FORXdSd0Jh?= =?utf-8?B?WG00bU45ZkJ2WG5XSzVYbUZXQzZmWm1PVGRkN2FibTJUK3ZpMTJYWEpSbTkx?= =?utf-8?B?QUhXeXgzVHY4d0w3U2c3L0x6aHZOdXN5akx0cDJvTTAvLzdOZEhaSXBDY056?= =?utf-8?B?bTY3NWY4V2REN0QyYnhXOUhKRHhLZ3ZCZUJWdERORjhSMFVuZmowQXNJTG9l?= =?utf-8?B?ejhHNmdzZWtmL1NMV1BxSFVyVnFQaTMxMVV2QTJTcmF1ODM3NlRBaXFZMlk5?= =?utf-8?B?aWx0dHhWelpvcGVWU2llQkJYZU5INnJnVTBXblRYdGtyWUk1T1F4S2ZQVDhW?= =?utf-8?B?QkZycTR3WlpGZWRxY29JUWxsRy8xTEcrei9aREY1M0tmTXhMajB2US9meHJ1?= =?utf-8?B?VHoxazVWRkFNaUpZc0haREFaSFVxT0pkR2NTWVI2ckNwYXFnUlpVU0tDS0pW?= =?utf-8?B?SEEvM2hxT0tJbEpjeVkybmI1MEdNZnVWN0lkUTNBcUlmODh4V3NrTHQ2MlVQ?= =?utf-8?B?ZW1xQWJuZlV5ZFl1OTRMSHpwNFJlS1lQOE5Wa3dUYmpmT0VUNzBneUpROUNK?= =?utf-8?B?VG1VTzFDdFpFRkhXZDNrb1F6Zys0RjZCLzZ6SDE0TXZGOWo0QkZjK1BlQmVy?= =?utf-8?B?V3djWThSNnVuRm5JRksxWlFKQWFOVEhiL0JCOTloZzBhSFpnbXErNzMxT2wv?= =?utf-8?B?MkV1UmRsbXhQbTRCT2h3RXBZZWNBRlJlemNaS3BrRXNEbWFTSllBVU9qTDQr?= =?utf-8?B?UVh3SlFUYWxWT3FWR3FyTUc4bXdzNlJQOGtCVWFrYngxVll0OFh3cHgraVFh?= =?utf-8?B?dnlHaVJqQzVXN3dRWUR1K3QyV0Qza3N4RjVWTFVoY0NoS3VpR1YzcW1hQnhl?= =?utf-8?B?amZPbG8wV2F6TnM5WmdZeXlmRXJEN0lOMUtSL1RIY0Rka1l1elpZbG9iQjIr?= =?utf-8?B?NXJNdkI4VDNMREMwSnVQZ0Q1d3ltUi82endiblhJMnFPY2Z0ZHZwNFVpRFdM?= =?utf-8?B?T3Nvc0NqbXJ0aXFYV1ROUXFGcElSTUpIbGwrbkl3ZGJrZUhQazd4S1Yyem9L?= =?utf-8?B?OWtySkF3Tzh5b2VaZ2xDOG9jYWRDM0tjRE9tTWlQdUMyLzArQ2p0SjJEQUsr?= =?utf-8?B?aElKNnF2MEpoVjZCcWFqeUJwNnZPUnZ4VVpLMC9HYjZudSs3SnQ1T1RHRG9L?= =?utf-8?B?K1M2NE9NU2RKWEV2c2JCNjlPeHpCOTFXQU9DQXo3Z3F0Y0RBOHJrSkNqek5n?= =?utf-8?B?OVp2NWlPWjBuRGpOd3R2eXZKdFdkOVB3Q0x1dTdNcGVFeUdpL3VHbmxJa3J4?= =?utf-8?B?Ykc0Z3BuL1JiN1FEbmNGdDA1OENBWkRtOURRLzVRdHpXSzBaYjQwN0JUeDhR?= =?utf-8?B?cko4dzV3dzhVK0JjeW1UK2VNK0hJaEh6clQwdGhIRDc4eWlkblE5eHRYWmE4?= =?utf-8?B?cTZsZ3d3MkpHS0VaajZmbnQ2WXo3Mk5RZmt2SmFHcWR5dmZ3M3IwVTYwMnA4?= =?utf-8?B?NFkwTHltUEZmZU43WnY2QVJEblNDRWc3bGxIYXJMd21BOUdMb3RXZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e1e8f29-b2ac-4667-ab49-08de7a020447 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:23:41.4612 (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: 7Sj5o31KoHTkf1GQQM3ipVJuuVuQr7ScFd8NIBv72ejXP+IAOeV61AJ9LvxdZXEYZMVKxnb2KI47iNkoSvfwWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6576 On Wed, Feb 25, 2026 at 09:57:38PM -0500, Stewart Hildebrand wrote: > A hotplugged PCI device may be added uninitialized. In particular, > memory decoding might be disabled and the BARs might be zeroed. In this > case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole() > unconditionally attempts to punch holes in p2m, leading to init_msix() > failing: > > (XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area > (XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it > > vpci_make_msix_hole() should only attempt to punch holes if the BARs > containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper > for checking if a BAR is enabled, and add a check for the situation > inside vpci_make_msix_hole(). > > As a result of the newly introduced checks in vpci_make_msix_hole(), > move the call to vpci_make_msix_hole() within modify_decoding() to after > setting ->enabled. > > Fixes: ee2eb6849d50 ("vpci: Refactor REGISTER_VPCI_INIT") > Signed-off-by: Stewart Hildebrand Reviewed-by: Roger Pau Monné Thanks. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:32:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:32:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245631.1544975 (Exim 4.92) (envelope-from ) id 1vxoD0-0005zP-3G; Wed, 04 Mar 2026 15:32:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245631.1544975; Wed, 04 Mar 2026 15:32:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoCz-0005zI-Vk; Wed, 04 Mar 2026 15:32:21 +0000 Received: by outflank-mailman (input) for mailman id 1245631; Wed, 04 Mar 2026 15:32:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoCy-0005yS-8s for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:32:20 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 53aca5bd-17df-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:32:18 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by LV8PR03MB7325.namprd03.prod.outlook.com (2603:10b6:408:188::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 15:32:14 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:32:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 53aca5bd-17df-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VWAJIsLcxWvypx2GnfaeE8md8UzmTA1ILTpWTutYwf86HGTvhyky2ehCnpUSn91mHx3v/lEX/HgzQGx2tTFVbi3k0vIw/PTX9pgwsuo5Z+HN6Ifa08W1ELFocHQXYfE9bDO3BMR0SgnG3AdlMUq0KEQJzzFTsHKIy0RT5yVLGDx3RGDaqEIlqPRTjRK7ukWtevro5hCTkkyhpzUWQAvZsTBNwp7rHUffkYPL2pdd5rqFeGk1ips2mqJFHOrPeciR7YA6KOusSsNWAmyMUXrotZ+g6xD57pyBccw2CT8x5/2D7AF2zVGJkeedM2U1fjH9uUIpjpDYJYZiyq9S9TXUgA== 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=+vZjbpBAy9Snmo62R0tvM+zuvAYrogOKQcidS+/0Y9o=; b=p7gyEIdr8MIKQ9wiHC3VGSW6yuHeCakormIljCA4huyR9dFTVjrHkLOju0A3i5G7sGFkdahaLqZuuQHXeC47jm2n+AbWk84QupY0rACqgGJ4oSL0dHjzTm8rnmKELZXDGBXJbg6hq8jQ9IGY8aLmMugnsbZQ2k2xw9mosaf43kPvUO6pkmZm9spCzh80yXqZMsI4TPOQ3hWoSmv/YmeVcyjnYlDix+QakMxzelTnOt+7FSTT8TmtcRkeTo18xFJmFCHGEwsMdv2jsRwaMu/s/8ncNXZ3yr0cMUo4dHAd0bZbsqk9DAp7L5C4vjrS0tQ+GuoMRpyYC4XgiAwJ+ugOAQ== 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=+vZjbpBAy9Snmo62R0tvM+zuvAYrogOKQcidS+/0Y9o=; b=hIWnuMpE6s0fiXmhqF0VgFLeYgkTvWilE5DHm0I4HcEVUzI5H844GA0/Zu3wxhbymvIdyzTNndzhKbdQfFRnVSFKDJFcbc+keAxBHKpGYHAO+qy1IcG2UWCvuJLIv7lbVeU+J3vsaySjCcROsoLINMyKSqAS9BYW817OavXz99Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:32:11 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Ariadne Conill , Stewart Hildebrand , Steven Noonan , xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/vpci: do not use pci_sanitize_bar_memory for domU Message-ID: References: <20260224231235.6277-1-ariadne@ariadne.space> <1d832f36-d22e-42c6-996c-d09c06376b8b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1d832f36-d22e-42c6-996c-d09c06376b8b@suse.com> X-ClientProxiedBy: MA4P292CA0011.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|LV8PR03MB7325:EE_ X-MS-Office365-Filtering-Correlation-Id: b4b1599a-6006-43e7-cd82-08de7a03360d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: k0byp1qlmkHNUWfjfLZOtUl+qPw2n+SgFALBiMsDzp+bWS7QIKSfXVLWeLp6v4wzgPzla4UNt7khqgVEvtqqea/YIaR9Wx5uFdLRZCyT0c0uSDn3pH8vzfAB8YzXKSMSOb0CAvUs9c0hRwiLkYFm/SF18kWmqFxH0pKXKAjLgUPVGBpriXUREpeQjbsXiKPv4QmAkLydrRPUXDzTvEctY94n8wUxdcfsxAqVWdOB/gxAOOxDqxfKLOCd1lZjjmDaN+NeEWWPKfhLDxvGRF7uhCwTpGUaAtVIynj7rH83bpCGZiy/bnPDcnRsjpNvhHQvCMYuWHLbjoLRT0yosEH4KjIvROsQp7HiHyKmJp4q7xr33osF16y9ASx0QdK7wYaChtcwY/UW3RXbhKi87bG8mEykerwOk+Kz7OGVrz0hWTBRpX2b2FWlDFGUFDAvxusTUkycR5VtQ5BD3ZiXlNgl7c4KzIzOILsgpR6hYppPnUL+jXnlsk9H5sCS9wjP7p4HsIF6umS4HPuQusoppo+KnDYfSikanSWAy3BRKJxBw1ZhlRf1CuYR613Uf8wLNizbSf6iCopg25fR1Dx156q0T55YN1xrQ6iiaYcXUNKnWbID6E2fx6Ikd2BrA1qy1Nn1n9WnUXQ+P02IzleAdcV7kIZ3XMQzibCy8KrOccqczMMCHQGTyJKYz58jiJww2N1hkIc003BCUvnLz020l6+RSkBojjCVZ3Ghalx+OKMFcWU= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aFREcW1uQ2xiaWxrU3I4TDgzSEo2amVZbGYxbjZHK3BvSzNBUVBrK1Fzc3Uw?= =?utf-8?B?TWJIVjRMZGVOTmc0bStjNEdZRHUvR1doZGJIbnFrU2tGWVRDWTd6YlJUeUp1?= =?utf-8?B?TXRpZmhQc0hHUUJIQVhjUmlFYW9lR2xZMFFiaWhKS05qYUg5U0JWYmRIbThy?= =?utf-8?B?djdIbG9zaVhud0dQRkRkZGUybE9PM1pFWk5QZVF5cEJsT1NiRGJIbGJqMjJh?= =?utf-8?B?bUxoYmJha200OHM2cThINE4vR2dhRWpQU3pLQjVSVzR1Z1lvTUcxS3Vhdktp?= =?utf-8?B?Y0ZvUVJGczE0NERKZ1ppM2IwdlVUQnQrY3k5WUtwL0F4aXlaWUdBNlAya3Jm?= =?utf-8?B?VC9qblNLSElYU2MyQ1dGenFldTg5WUNGcllKMGVobG9wZXo1YkVJbWNKMEF1?= =?utf-8?B?UUJXUklCYkJkdnlhVlJVUVd1VVpwZ2VmRHQzTnNlN2ZGWDRmakFVRU80Z0dx?= =?utf-8?B?QnRVaGt4YnhrRnNGNlhiWlU1NGlsaG1GbnRSckNDdElRVVZuKy9sd1JRbEdw?= =?utf-8?B?a0lFWEtlamZpOXR5MEE4MnF2SjFCTXh5Rk5lN0dOdW5FQlJEbFRQQnhjcHlp?= =?utf-8?B?Nmt4MDBua0pvdEY3UEpVWDZ1bHEzQWtDNVZlaGczQWFoNGpwSStkdGZhRlNk?= =?utf-8?B?QWRFSmYySXlVeEJCMTNkanpld1ZhYjk3bDI4eVZlTVByV1JhWTR1RG1RYzJj?= =?utf-8?B?d1hwcTFqeXNJOENlcUZ1Rzd1NlJTdnEvOGZTRmNmZGF1emtjdU1RaEFGNzUr?= =?utf-8?B?aGk3VTZVQ0JiaVNLYmlhR0JLcDhtcDFFbzBGUEZuL1JsdkZ1K0IvWUNUTWF5?= =?utf-8?B?cnhyaWlnN3hOM2FXRHcwMTRhNE5vS1dHUFp3VndDMVlYM2lsci9mZFAzK3Nq?= =?utf-8?B?NFhyV0NSVnM5aTk2d2pOSUV6U21DY1hlbHp4ZVVXN0VVSmdmSnp3cm9NdFpD?= =?utf-8?B?KzJJbDFLcXlsSGwrdDF3UUo4RVJuVVAwRmw1dmJzMkgwSUF6ZFhZY0dJMkxo?= =?utf-8?B?MXJMNHVzRXNOWHI3NHlqbGdYdkJyQUx4UXhIUXpzTzVnQ0FlWmgvVG1TK2FZ?= =?utf-8?B?YlRWK2FSczd3MDMrVjNFWjFtQVdDVG5QVVFOOHZxRWpwVmI0THhZbHU5ajVM?= =?utf-8?B?eFZ3cGhDOFVHWXFIMU84U0tNSndDZ3A4WmNla2lWTE1MVXczZVN3QWd5cnJT?= =?utf-8?B?QWNWZmlhakhwWWY0Z1h4TG5lRXhxUUwvT0J5UjBLK2xEcTg5T3czd0FCWHZn?= =?utf-8?B?R3JjTUxOOTg5ZkVzREtxQmlqVXNzVTY4M045QmEzYVZSLzFPTHZYNW81eHJ4?= =?utf-8?B?d0wvNXM5d2RBZTg0ZXpPVmRvdjFrenczTzd4cHcreGE2TlZ6VXpRSjYzdG91?= =?utf-8?B?bEdxbTdRRnV5aVBzTDhTVW9kR3VKcTlTbHlqRU1MVERFeXFjVDJYTTQyYmFp?= =?utf-8?B?OFA0VnoyREN3TC9BWHI0eXpnUWw1dEMwZm1LOUllS3lqcGJtMkxMM01Cc0lV?= =?utf-8?B?NGRYczNiVndETkU4ZndHWnFHbFJ6bVpRR3dMOXptaHBZdDlmT0hTL0tnb3FJ?= =?utf-8?B?ajBXOGdKUEUzZ3k0MngzZUV3YWpnaHJuSkxDRjFoTnNJaVZiVUdXNUVBSHVP?= =?utf-8?B?SnBQZVNNZEdQRzhLSHJVMktEdWtjbUNwV0JXaFZrNmtsakkvQXhMQ245TkVD?= =?utf-8?B?cWRqNDFXMWFsWWRoNGFPUEg5SzRMTVYyZ1p2OTJSaWJYaHdhM0hBQ3N3TVdM?= =?utf-8?B?akV1eEdNSTVreXphZEZNNUd6S293R2NPU050eXpPRjN3V3A1N3dJaG1OZk5p?= =?utf-8?B?MTQwQVVPRnlkdEJ4L1h3azlCRWxjMllqMkc4dW1VdlkyNWZEYml5T2k2UEJN?= =?utf-8?B?dS92cGZRVzFRNTNZdVduQXExd01PWXJKMWFHWEpQckNPNU51d1Vmb2VpN3Vh?= =?utf-8?B?OVptNzY5T0JGaitIM3VhTHA2L3pUTWtoVXBaTmV5djUvNXhvamZFUkRBcXpG?= =?utf-8?B?T3c1RnFLRlRsVlQyb2xFNW11NHhwVE5keGExTFdHMEtHSmpZNDFZSElsMG1s?= =?utf-8?B?cFYzamx0NUlRWGdnTUh4OUFaWW1KV0UvL1NnS0RxV1kzMUNTMnYwSUs4MHBZ?= =?utf-8?B?dWt6UzRWN2VQbTc1MkJxZFdUN2dpLzIvUmN3YlFzRG4rcjBLK3c3c3I2NjM3?= =?utf-8?B?ODNQMC9TNmViN0xRMWtSS2VFNmJuMVFpYWk0RUh5cTljd2ZtTkNlTFptZzJy?= =?utf-8?B?WTZ5eEZpdElwRlNJQU9sdlpqdlBwZ2M3RGo3aVlQNlVWSXB0eGg5T0E1RDI5?= =?utf-8?B?R1Q3Ym5ESHpOWDJSOUtqcFlXQi9BZXhzK3oveUlJTXFrKzZXQ29HZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4b1599a-6006-43e7-cd82-08de7a03360d X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:32:14.5856 (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: hbIgkKscqeK990mSJlZPbSIL5dPH8QIO/54a65SBn1yF1pqOoEsrp0zef5aHAkRwql+ONcQLqMUtQZaXi50EsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR03MB7325 On Wed, Feb 25, 2026 at 04:44:09PM +0100, Jan Beulich wrote: > On 25.02.2026 00:12, Ariadne Conill wrote: > > From: Steven Noonan > > > > This function should only be used for the hardware domain, because it > > compares addresses against the host e820 map. > > The same is true for its sibling function, pci_check_bar(). For both the > question is whether skipping is the right thing, or whether for DomU-s > checking against their memory map is what is needed instead. Well, the usage of pci_check_bar() from modify_bars() is slightly different: it does get called with the BAR host addresses (not the guest ones). So the check will work as expected, albeit given a domU cannot change the BAR host addresses the check is likely redundant, but not strictly wrong. Checking against the memory map for domUs would be complicated, as the guest can play many games with that memory map. > > --- a/xen/drivers/vpci/header.c > > +++ b/xen/drivers/vpci/header.c > > @@ -394,13 +394,15 @@ static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only) > > } > > } > > > > - rc = pci_sanitize_bar_memory(bar->mem); > > - if ( rc ) > > - { > > - gprintk(XENLOG_WARNING, > > - "%pp: failed to sanitize BAR#%u memory: %d\n", > > - &pdev->sbdf, i, rc); > > - return rc; > > + if (is_hardware_domain(pdev->domain)) { > > Nit: Style (see surrounding code you alter). > > > + rc = pci_sanitize_bar_memory(mem); > > + if ( rc ) > > + { > > + gprintk(XENLOG_WARNING, > > + "%pp: failed to sanitize BAR#%u memory: %d\n", > > + &pdev->sbdf, i, rc); > > + return rc; > > + } > > To avoid the need for re-indentation here (reducing churn) you may want > to leverage that rc is 0 ahead of the call to pci_sanitize_bar_memory(). > I.e. you could make just the call conditional, without touching anything > else. You could also introduce an early continue, and leave the check(s) below applicable to the hardware domain only. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:35:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:35:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245640.1544985 (Exim 4.92) (envelope-from ) id 1vxoFd-0006Xt-FG; Wed, 04 Mar 2026 15:35:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245640.1544985; Wed, 04 Mar 2026 15:35:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoFd-0006Xm-C2; Wed, 04 Mar 2026 15:35:05 +0000 Received: by outflank-mailman (input) for mailman id 1245640; Wed, 04 Mar 2026 15:35:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoFb-0006Xd-SY for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:35:03 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b371d114-17df-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:35:01 +0100 (CET) Received: from BYAPR03CA0019.namprd03.prod.outlook.com (2603:10b6:a02:a8::32) by DS4PR12MB9659.namprd12.prod.outlook.com (2603:10b6:8:27f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 15:34:51 +0000 Received: from SJ5PEPF000001E8.namprd05.prod.outlook.com (2603:10b6:a02:a8:cafe::9e) by BYAPR03CA0019.outlook.office365.com (2603:10b6:a02:a8::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.23 via Frontend Transport; Wed, 4 Mar 2026 15:34:52 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SJ5PEPF000001E8.mail.protection.outlook.com (10.167.242.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 4 Mar 2026 15:34:50 +0000 Received: from SATLEXMB06.amd.com (10.181.40.147) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Wed, 4 Mar 2026 09:34:50 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB06.amd.com (10.181.40.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Wed, 4 Mar 2026 09:34:50 -0600 Received: from [172.30.142.83] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 4 Mar 2026 09:34:48 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b371d114-17df-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=R/7Y7+GAyHDyHGdEBQPPGKjbDif470GR7YRyk+oo2rK3aO9Ztc37t+3VcxqtEruoQKwciyrCNBEjaukdzoXWuNODooPL5FzZgiEMGjTea+ax/aKTukqoankG2zRsyUhBxV1ckiIKfXzrJxwieqN0A5TKPR0Y08w4Q3cLi/kDcUjOLs9iMh9PJfFlfCsuT4vXRWoYwGgQdfoIriPZ72OuKH87DuMeLJRAqoXo0go7RzmjyX1RFlhBQMaCoaVvkOK3qteCnbr55C8luqeePGVUC8GyIwEEJG6UoCadmiiE1ChTCjFIP/XTODuqvhtKZyCZ0CvSl7CtAe/tEnoOL9e0Vw== 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=2qnyNU8K9XOSeW8hicrLiTi+a+m+bbxwcRWJIQliUBo=; b=cI6Kw/VFNvpGMJsGTL59tmEBenhbtXrcuicRGSUPePdac8ljRLj0EYHZTzTydWgdXW+V444htlPeJ/6tSSxgQElkzZdzryXx/H1yenDzH9jISl75ZXXzn5LWJ25I4G5x7xo43salDOSVMMR40YRCDmXVV/NoKdRV/gqTYIq7Q3dmYQD3M2XoZ01BRF56KcNqsDWQUg38/U5laM1Dg+cRjsmx+aTD7FF41oFPIQ9ShmJc2lyHcRvuwj+6hZd4Xb/Ux+UBkECYTTqJ89QBR+WA+ECY5kcaN3BKBjR8g0LCWqGoPY8EwoSDZYHLwPP6zn20g13a+96Gfoydrv/5oNOFsw== 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=2qnyNU8K9XOSeW8hicrLiTi+a+m+bbxwcRWJIQliUBo=; b=u2tW3IJMB01mjigaiarvP2rxD4QQpdxd+IbqulsROEJge2wPP3bknGikMWGd4gU2ezgCyCpEQVGS7w5cO8bnQV+qTfAalJh/ZnPPTYwjBIAkUFFjxYHTudUHxwQOfkzagIvJNP+Xc+VcrYTS3W2Txf6yM6FI1UuZQe3EgpacTZo= 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: <726e088f-0090-4e00-a511-465d88b1e3ad@amd.com> Date: Wed, 4 Mar 2026 10:34:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 4/6] vpci: add SR-IOV support for PVH Dom0 To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Mykyta Poturai CC: "xen-devel@lists.xenproject.org" , Oleksii Kurochko , Community Manager , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , "Julien Grall" , Stefano Stabellini References: <8da9f137-a897-4438-9524-85836e0170a1@epam.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ5PEPF000001E8:EE_|DS4PR12MB9659:EE_ X-MS-Office365-Filtering-Correlation-Id: f04a01ae-ee66-4839-d3e5-08de7a039368 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|7416014|36860700016|13003099007|7053199007; X-Microsoft-Antispam-Message-Info: rze3z7YJNsWKnBT93vxuR9/TVlLFAV31UcjPw9jCF0fvEDj7m4jwyFry4G+cOPxRuCZBQTZktnBBUH1sDd7IyUPaAup51ZMBwMocHqAGuuuWQPnSAay6tZD1/HPQVjjwz9aX0pO7KzY2Gw/YYYUauX4OQoCXrdDX4pTdTE7PrF+ybznHdl+wTLEEY05dhG3nskf2+EtUB2aBwnFOevSOqqXkDvPgrdQmxt5D6UJ2iBnaW5o+ygyr8xI5Jh+Dqt+ZGEZaUv1bKhuT300N/A/RiUcIfla7X8uNgmdbn/GtROHPNDmatGPFmAK+I7C4foihFsz/dYrvNS7pJTgdU8Iq3JbiLqxJf+npMHeAhbU+mI5WVRgKoqgJMF/13ceANlN3D8y/5pQPGw3NJpsbziIpbw5SouVU2SNf38SdtS7TGVE+sKgmGY7WaetHQozu7Nn0aiPFqm9WCW2i73/6jHBpz6vkGyPLe6kmJMk4dwyHsswS5lCPnkXlxKdeIe/TrAVXakKE+uIReWDWWkDMKSk4CSnralmzK1nw8Zh+IM3HNFH4sO731PRi6yQGK0PErFkE/kqy13rjLHVEeWiDPL4qbgPnX2FJEEaSDz8C5uzbo28Hux5hlsFA+bI1bnx546v9buNj0Xy9Jbt14lKuC3kkUhSUbKSOsgxxXfYxPFQkkKOA7EInUY7RhGol0M9RRCVLDOPiupnUEARXbWpY0afhqmlhSbrLa3vt6feT/EEZ94Q= 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)(376014)(7416014)(36860700016)(13003099007)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 8AwXFBBTsLSnPVOGA+gJ7etEJCJtXqsKYh7K4HhIxCR2YG9PfKtZab1J+8yVS2j6RL75BYNAM4GaGhTbVvo9Zu+++F1JrtlOnWXkionKWxa58NSYmNQ9jRqIuLL4qYHWP+pt6EcdnukvmC83vwHhReoOw5uAJrkO8PBUkWFXyyD0PClTE/RO6tPcd7xdAuQYRLc77zHQeRgPLcPpt5kH3wQxx8cNCKwFfzlYtLqrjt48NTNfhrFFuej49ghw2DyBl8wvnyfXFarHyfejbn3DUVxMBlAtUCj6jYDcEUp5B6+fFbiSDQeCZi5D3GUEw8/94X93XKd3gwFN+tVXldE1CSlR7tTRqdhOvtq4XEcyAn1QxqQMZ8hvq6yip7RRNoKV7BQCwqoLvMz7WxI6cM710FUGUMSPb586SVF2yVVoimM+jqt0FYE2dOasvGajVp1C X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:34:50.8940 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f04a01ae-ee66-4839-d3e5-08de7a039368 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: SJ5PEPF000001E8.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS4PR12MB9659 On 3/4/26 10:16, Roger Pau Monné wrote: > On Wed, Mar 04, 2026 at 08:43:17AM +0000, Mykyta Poturai wrote: >> On 7/28/25 14:33, Roger Pau Monné wrote: >>> On Fri, Jul 25, 2025 at 02:24:33PM +0000, Mykyta Poturai wrote: >>>> From: Stewart Hildebrand >>>> >>>> This code is expected to only be used by privileged domains, >>>> unprivileged domains should not get access to the SR-IOV capability. >>>> >>>> Implement RW handlers for PCI_SRIOV_CTRL register to dynamically >>>> map/unmap VF BARS. Recalculate BAR sizes before mapping VFs to account >>>> for possible changes in the system page size register. >>>> >>>> Relies on dom0 to enable SR-IOV and PHYSDEVOP to inform Xen about >>>> addition/removal of VFs. >>> >>> Why I'm not opposed to allowing registration of devices using >>> PHYSDEVOP, can't Xen detect the addition of the VFs and add them >>> itself? >>> >>> When I worked on this long time ago, the version of the series that I >>> posted had registration of the VFs done by Xen also: >>> >>> https://lore.kernel.org/xen-devel/20180717094830.54806-12-roger.pau@citrix.com/ >>> >>>> >>>> Signed-off-by: Stewart Hildebrand >>>> Signed-off-by: Mykyta Poturai >>>> --- >>>> CHANGELOG.md | 3 +- >>>> SUPPORT.md | 2 - >>>> xen/drivers/vpci/Makefile | 2 +- >>>> xen/drivers/vpci/header.c | 3 + >>>> xen/drivers/vpci/sriov.c | 235 ++++++++++++++++++++++++++++++++++++++ >>>> xen/drivers/vpci/vpci.c | 1 + >>>> xen/include/xen/vpci.h | 7 +- >>>> 7 files changed, 247 insertions(+), 6 deletions(-) >>>> create mode 100644 xen/drivers/vpci/sriov.c >>>> >>>> diff --git a/CHANGELOG.md b/CHANGELOG.md >>>> index 5f31ca08fe..7b0e8beb76 100644 >>>> --- a/CHANGELOG.md >>>> +++ b/CHANGELOG.md >>>> @@ -23,8 +23,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/ >>>> - On x86: >>>> - Option to attempt to fixup p2m page-faults on PVH dom0. >>>> - Resizable BARs is supported for PVH dom0. >>>> - - Support PCI passthrough for HVM domUs when dom0 is PVH (note SR-IOV >>>> - capability usage is not yet supported on PVH dom0). >>>> + - Support PCI passthrough for HVM domUs when dom0 is PVH. >>> >>> Don't you need to move this out of the x86 specific section? >>> >>> According to the cover letter you are testing on an ARM board, so this >>> probably needs to be put in a non-arch part of CHANGELOG? >>> >>>> - Smoke tests for the FreeBSD Xen builds in Cirrus CI. >>>> >>>> - On Arm: >>>> diff --git a/SUPPORT.md b/SUPPORT.md >>>> index 6a82a92189..830b598714 100644 >>>> --- a/SUPPORT.md >>>> +++ b/SUPPORT.md >>>> @@ -170,8 +170,6 @@ unexpected behavior or issues on some hardware. >>>> >>>> At least the following features are missing on a PVH dom0: >>>> >>>> - * PCI SR-IOV. >>>> - >>>> * Native NMI forwarding (nmi=dom0 command line option). >>>> >>>> * MCE handling. >>>> diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile >>>> index a7c8a30a89..fe1e57b64d 100644 >>>> --- a/xen/drivers/vpci/Makefile >>>> +++ b/xen/drivers/vpci/Makefile >>>> @@ -1,2 +1,2 @@ >>>> -obj-y += vpci.o header.o rebar.o >>>> +obj-y += vpci.o header.o rebar.o sriov.o >>>> obj-$(CONFIG_HAS_PCI_MSI) += msi.o msix.o >>>> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c >>>> index f947f652cd..0a840c6dcc 100644 >>>> --- a/xen/drivers/vpci/header.c >>>> +++ b/xen/drivers/vpci/header.c >>>> @@ -839,6 +839,9 @@ static int cf_check init_header(struct pci_dev *pdev) >>>> >>>> ASSERT(rw_is_write_locked(&pdev->domain->pci_lock)); >>>> >>>> + if ( pdev->info.is_virtfn ) >>>> + return 0; >>>> + >>>> switch ( pci_conf_read8(pdev->sbdf, PCI_HEADER_TYPE) & 0x7f ) >>>> { >>>> case PCI_HEADER_TYPE_NORMAL: >>>> diff --git a/xen/drivers/vpci/sriov.c b/xen/drivers/vpci/sriov.c >>>> new file mode 100644 >>>> index 0000000000..640430e3e9 >>>> --- /dev/null >>>> +++ b/xen/drivers/vpci/sriov.c >>>> @@ -0,0 +1,235 @@ >>>> +/* SPDX-License-Identifier: GPL-2.0-only */ >>>> +/* >>>> + * Handlers for accesses to the SR-IOV capability structure. >>>> + * >>>> + * Copyright (C) 2018 Citrix Systems R&D >>> >>> If there's a Citrix copyright header here, shouldn't there be a >>> matching Signed-off-by from someone at Citrix (I think that's likely >>> me)? >>> >>> Otherwise if there's no content authored by a Citrix employee the >>> copyright notice must be removed. We need to be careful with >>> copyright and attribution. >>> >>> And in any case the date should be updated. >>> >> >> Can I add your SOB or is it better to remove the copyright? Looking at >> the patches you provided, I think this ones were definitely based on >> them, but there are also a lot of changes since then. > > If it's based on the patches that I sent many years ago (2018), > then yes, you likely need to add my SoB. Look like that way from the > copyright notice. > > Thanks, Roger. A bit of context here: When I worked on this, I used Roger's sriov.c from [1] as a starting point. Unfortunately, during my haste of development, I neglected to preserve authorship/Signed-off-by, and didn't get back to addressing it before I shared the branch with Mykyta. So yes, at minimum Roger's S-o-b should be re-added (likely as the first S-o-b), and potentially even make Roger author. [1] https://lore.kernel.org/xen-devel/20180717094830.54806-12-roger.pau@citrix.com/ From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:39:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:39:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245653.1544995 (Exim 4.92) (envelope-from ) id 1vxoJN-0007OI-2y; Wed, 04 Mar 2026 15:38:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245653.1544995; Wed, 04 Mar 2026 15:38:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoJN-0007OB-05; Wed, 04 Mar 2026 15:38:57 +0000 Received: by outflank-mailman (input) for mailman id 1245653; Wed, 04 Mar 2026 15:38:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoJL-0007O5-QT for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:38:55 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3fcf1a75-17e0-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:38:54 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA1PR03MB6354.namprd03.prod.outlook.com (2603:10b6:806:1b5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 15:38:49 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:38:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3fcf1a75-17e0-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lLRIeppK4R45mskrmzkA0YT9Sl6xcEXicRxy3vI/4veyc/DLgc+fccfcIHF5Fi6qTOU4gduBGNln4WhKcJNqo2saftxPBauzn7IYJrUhKan0oY8tjAx9uh8gfJzkl6PUPbxiSI+jhRfVD8P2Whof5PqoajcUqTZd78Duhe9nRnXyLxo4V0IA2WiEL+A0JSr+5E6ZAnuVtIni/6LtIy/rRLZCsArWuZJoVuFJj3Hge0y2RNDutaRQOyUHXDOeAREyF9fowgap+PjYh3D5SayqHd/eDpjAOPvu+gtdsocidZfogRW+YGT3kwhqjZwwnFPvmrbTyOO1zbAolRFjSGZgqQ== 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=9JXynPD0+Hi+BE1VZ+yaXhtAgc15KDOeqO9w/iTbPH8=; b=RO0oR8kkEVew0/JBy5KYFnt4c5gnubRXfDRZG+FxG/P+aDpyR1IyVNLGXu2zKg29Z0KiEucMSodeAbDQmM74FPlIysuk+xfrR5u1c3NEXTp9AUB4HsaonFKcWxGbR22y9HZbB622SQx6UXpkzfBWfw0kX3YVB9BOoTyorZ6wN49D2GwFaxtZlNZwPYAJnWuLwWGv6+tt3XLV7L+nluiQzu7a7dLwm/KhzuIEdGP19BXqdRe272ZH6c6b1JuI1mYae+s0IVff+eq3ye834FVfT4oDHZTt9Y1XQhYPvwXX5qYKIN5mEF5e9IhzJnoD6jCCwt8kEqVaiZnmrDzVPv2PlQ== 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=9JXynPD0+Hi+BE1VZ+yaXhtAgc15KDOeqO9w/iTbPH8=; b=lBDHPwThgt37ozDuAQvf/DejlxEq1rk68rFE/xRGhA3rq0fI2P4ZW4t/NYhlzPNyuE/E3SurRZLO9LXCrTw2/OZdBdzh7m6HC38ewbullETeIETIsC09ahBxNU+oh8uia/8Y1D406D7Z92sotFlUttDrNEEX4CO1wda58jrZasQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:38:46 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] domain: use unsigned loop induction variable in complete_domain_destroy() Message-ID: References: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> X-ClientProxiedBy: MR1P264CA0122.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:50::32) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA1PR03MB6354:EE_ X-MS-Office365-Filtering-Correlation-Id: 76d1fb2e-b4e6-4c5f-d603-08de7a042170 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: YL0N+R7IC9+I+ocIDRHt7jWW6icF4RrWZlD/ZnMEPFCcmYU7sc0Am0Gbsm4YG/XXqnkTodQg9jYKSRhYsfKRi3LKWIWR5KwlUzojESwipQnQ6v2eZp6g64y9DCkmA6uRaNsr8CFj1YOxF4TzUbiPpHS5aNdAOjuRxQ6Ngz7Ppq3DYk9tvN3ftHfYdJIYk3uEPqp8D2LhdwLzHeE3BoZ3kIKf/Tg2SwiVzo/0bUm+WqQl2cYCxFCQ3UHaDshAY/JPF0I06xj6mWqCdcd510QCgMV2GQeTNyA8W5IJP7K1vl/OlR2uBwxKaxKYsdmNFQvN/z8SSUE3YCIdV+kGHX3h3PsnP8b00uPIaeDZ88LukW6Nflf7utbCPOIMd5OzS4/7N1dnDapACbVZxLTYaPU6cOPQmwleyO/o60/Xk+by+KMIItAV/ev09u44Npl24LuYSKF3e7WiVX2IWIMywTickqb/tqSMxkJvLM7PkHTTOM6ATZ/kOt2kQ5ysTkqg4hGZc8BTwrh/WHcB/wNklvtuQpCUGEcKOQB+wwnVoWXIzn41EwcHmIH9Hz4KSKNBQOum03jhrTmEael1PCrQAOEBtgglPdqVTWBTldq7N92a8Vp8XULC6m33d+xV3m/73sg642Ta5782bCuI+9x9IfFDNrSUWJ3agCuLhysihoeW2FENqnxh8/Oh+6HIoXtiXkycodAVowE+gvOvwpsICxG4ed9Siaoq/TejQtkVjjopDFo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aENDbXViYWYvQXdoQXNySHNqWHZRanM3TSsvSmltRlY3WEhudHR1aUwwVVZY?= =?utf-8?B?OTN5UTJGR3RCSGlrUUk3VnJ0T0luVnFZSlBGOWNvMUpYMjZ1THltZTVPOTJ3?= =?utf-8?B?ZHNpcEEzMkpidmh2MElJM2U4ZCttTnR6Y3puQXZEZjZ0dVlkN2RkbTdkaXQ5?= =?utf-8?B?VGhQSUdqTW9rZCt6OXMveTFHcGVPQmFaZCthWmdxWjBSWkhFdzVMVnNkVWlS?= =?utf-8?B?WlZhamk1NmhwZ0NEcThRSzBFbnNSakMvTUlxNFdzdWkrR1BVc2ZvT2YrVDVn?= =?utf-8?B?RXpZL05UQzZCQ1JlZTM4K2EwTTR3LytWS0tJNHZKNjlDZi9EUjlOTUg2VjVM?= =?utf-8?B?SXBZTld5L1JyL241NUI3VlhYV1NkTm1sRngvQ2p4NmZwdnZOSUdDanB6RW8z?= =?utf-8?B?Q3BJdlEvbWRlb0hHUUVvNlBsaWR5OVZHT2xxb1RMb3k0N2RyZzdGRTVqdFFF?= =?utf-8?B?VUJPNE41emFYOE5jSUFHZzAyQ0VzLzZkcUVTcTJXdXVXR1BJYTBPb2hCdTcr?= =?utf-8?B?ek1Ub081eTZIN2hyUDQvZ3RTM1hFWmNPOG4yT1dKTmNtOHdSeDhGVVV5a3dH?= =?utf-8?B?MG1LMlRIZ002QzluOWNzM1hZd3QrQldWTXBrMUJNcVZXQS81NkVaK2NXaGxQ?= =?utf-8?B?VWxHdE9LT1JQMGc2SWJ5VXlUYzRmYm9mRGlPTDFaTkswM0VUL0svckNzUVNk?= =?utf-8?B?V1oxWmdjK1FIbkIrYjBVTklDL1ljbzMzZzRsZDUvclVzMHJPaU40YlNSNVJZ?= =?utf-8?B?T2tBMWVNSkN1OXBVTzBJVE5UOXZabEVKWWl2dzZuZnN3WTZEdlVTMUZVa2ho?= =?utf-8?B?Y3R4MUJQYWVjdUVTVWxYWXBUeFo5OTlwTitpcmcvZWg4eEJMUWI4Sk9NNU9n?= =?utf-8?B?eGtWcHF4MHVjRTFIMU84NjFLWUlqdFhXbGVBVXNYZnlwb1BkemVScThIV25n?= =?utf-8?B?QVpUK2F4cXp1RGE3YmpKaCtCYXRzZnA4bmpRMXc1bUV5OUY5OFdmYTU5QlJN?= =?utf-8?B?dXgrbjZYQjQzSHU0RjhBQXRUbXpqSmlCTlJYbXdYNjZ5TmxXSXgyN3FnanR3?= =?utf-8?B?UVoxVFZOZDlwSzRwRlR4VkFRM3BkYUlnblJkanlrUVZoT2F3MzNIajBSTnVM?= =?utf-8?B?MWhQeUoyYWl2VXIyYWRBenBHWkdhbFk2bjhmUmdHemNxOWl0RXM4OEtFVWVi?= =?utf-8?B?T1hKL0hvODdPRlN4ZWJQdXZmc0QrZzNhc3N6d1UwcnJpbCsyL2xEUTlrV01T?= =?utf-8?B?S09ISitWSjNZQUlydG81aHZkdXB4NjRQMkpBWHhkNFZaVHkzRVBkRFBWbnF5?= =?utf-8?B?OGtVSm1GK1lZM1lSV0QzQ08wZEwxTlZMZUs5bmtWeTNub1krelJLNGtRNUNV?= =?utf-8?B?bGViOTlGQ0w1RkgySGwwQ0U2d0lWYWZWK0pCaGIwQ0t3MEdFQjBwVkN4a2lP?= =?utf-8?B?c1dhcmdRd0VwS3p4SlQxSXI0RFE4THpMOGN5eTRjeXJ6YzZtVjFPSHFjTUQr?= =?utf-8?B?OEFLV1pDaFVKc081UUN0Uys5emVPZXYzTjJVelp0bVZmeFhpOW1rdzhKbURR?= =?utf-8?B?VE13VXJJUVNYVGg2bS9pbjJIN1lPOWYvajZVdGF5UldTWXM2UThDbUord05p?= =?utf-8?B?ZG1zMWhDWjdDdDBreDJQTXJ1ZHcvRmM2NStlaWJzSGVxbC94SGdvWFhFbnNy?= =?utf-8?B?Q25OamJTSmtwMkZiV3Z4eVdKZWRxUE5taG9LTGdKRHlGRkRZTWg4dTgvMm5a?= =?utf-8?B?M2lUR1lVYWlyalZOcFdkdU9NQmR1L3pTTVgyTDBuRVAwYmd5U05aNVh6ZmRr?= =?utf-8?B?ZkU5QUpsYng3TlVjTlMrSHROcWhmOVBDcy9PeDZsSHVsTnVMYTJlSjQ3ZGFW?= =?utf-8?B?SnBmRktnaUthWU1DQzdMQVljMGw0ZHpyU01nZFBDZzV3OW5ySi9GSzh0bzBI?= =?utf-8?B?OUlpK1JIZHdVQ2F6eUVTRVNmcWFMcmFwd1pOcndaS0J2WHBoRy9MTG1XSVJw?= =?utf-8?B?bVdGYVd4NkMxcXFQU1RvdHZDU2VwNG10RjVZZ3pHN2pWSlk0Y2RJeGFzbkFO?= =?utf-8?B?amZmZTV4dFRmS1JadEFhR0VDOG1QWmxtOUtLQ2VVMVY2Q0s1aUtWOXRQUjFG?= =?utf-8?B?SWNBbFhNV2NDNjR3S1JSb1B5SWV5d3FCTnFHQ2xXOVZ2NHh3TEdzRXZEckpq?= =?utf-8?B?MnBRR1dHWUxmMkFPNk1GQlpScFZkbGtXSGc5OGx6R0NJdUV4aEgyTjhpalFJ?= =?utf-8?B?TFhzZW5QZEpBdlZNYlFwdnl0UTkxclN6RXhudG1xcTVnV1dSR0M1V3EzNXFa?= =?utf-8?B?amtBUjIzbzE3Tlg3bzhsVHV0UkF2V25KVFIybVJoKzF2anpBYU9jQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 76d1fb2e-b4e6-4c5f-d603-08de7a042170 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:38:49.5400 (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: cuNxWUF2qlPOak7o0fUdxf3j29TJ07GxQSaXwfSZhAAyJ6Z3eaTLR6F5SUfi19M2N2p1E6ADJNh0/LMG8rtPVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6354 On Thu, Feb 26, 2026 at 10:01:45AM +0100, Jan Beulich wrote: > Using plain (signed) int variables as array indexes can be unhelpful on at > least x86, where the compiler may see the need to insert sign-extension > insns (strictly speaking it should be able to avoid that when the loop > continuation condition says >= 0, but that's not generally the case even > with gcc15). > > Observed effects with gcc15 (will of course vary with compiler version and > level of optimization): > - on x86, one less preserved register in use, yet due to sub-optimal > choice of register variables still a small code size increase (%r12 > isn't a good choice when it's used for base-without-index addressing, as > it requires a SIB byte which other registers wouldn't require), > - on Arm64 code size decreases, albeit that's eaten up by padding which is > being inserted ahead of a few labels, > - on Arm32 code size increases for a reason I didn't fully understand (my > ability to read Arm assembly is still somewhat limited). > > Signed-off-by: Jan Beulich > > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -1475,7 +1475,7 @@ static void cf_check complete_domain_des > { > struct domain *d = container_of(head, struct domain, rcu); > struct vcpu *v; > - int i; > + unsigned int i; > > /* > * Flush all state for the vCPU previously having run on the current CPU. > @@ -1485,7 +1485,7 @@ static void cf_check complete_domain_des > */ > sync_local_execstate(); > > - for ( i = d->max_vcpus - 1; i >= 0; i-- ) > + for ( i = d->max_vcpus; i-- > 0; ) Is there any reason we need to do those loops backwards? I would rather do: for ( i = 0; i < d->max_vcpus; i++ ) ? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:39:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:39:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245654.1545005 (Exim 4.92) (envelope-from ) id 1vxoJV-0007dt-AQ; Wed, 04 Mar 2026 15:39:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245654.1545005; Wed, 04 Mar 2026 15:39:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoJV-0007dm-6J; Wed, 04 Mar 2026 15:39:05 +0000 Received: by outflank-mailman (input) for mailman id 1245654; Wed, 04 Mar 2026 15:39:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoJU-0007O5-E0 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:39:04 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 459160dc-17e0-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:39:03 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4837584120eso52408505e9.1 for ; Wed, 04 Mar 2026 07:39:03 -0800 (PST) Received: from [10.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-439b0549600sm29576163f8f.35.2026.03.04.07.39.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 07:39:02 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 459160dc-17e0-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772638743; x=1773243543; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=QNWsCIeGZRbprrIy/0SsmSPOdGwM07nDurlIE+0tk1o=; b=fIyfA2jJhaa/XRQgIiFm68b5U9n87lbihXB3gl/BYWY61YA32rTts+VyR+ipNQw6+v 8xbwvlgOQAdUDXKW2CQbZ6I472Npq88yqvhArWT5DcPS3okF/46rbU2wMLETHG0NDEct UHKGHZJ8bWAAutNADu1boIbYfXoDkFdY32aGYzdQ3iSKIWinf8gUk3N7nukTuOIqRqJE R1vfRv+qRjvU/GRiKqgDFz6CBc6w1fn/Hx5T8+yAHMQMwJugy7Z7xE4bViZG7NqAEwoz pAb/GKwyNv9My0O8FKBdLcxget7Jh+omQeHpfs7g0LnJ1hLwfOuIaXlttR5JbFQDSWqX A7BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772638743; x=1773243543; h=content-transfer-encoding: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; bh=QNWsCIeGZRbprrIy/0SsmSPOdGwM07nDurlIE+0tk1o=; b=Gvemt4bfe8jf9glHXrPa8pSQT9GF8A/lW8CKiwHkxeiYVu4yBIstlscoHfm3ZKCx6q CIEvMxgmoyI2jMOq5ZQ5z1ThZz13WKgyoSgbxebjfsvz3FdDbHTNnXYZ/jDgw9CECbPR oyI0lwyoxggqi8Ce4rWtzQPQdilFCw5SlDvRioN3D6wnjJO5hn1XeLWhT7NUwRpzf4m6 ZM2gpQY9DGUH0YS82FlTw0YElOIWpyNvWPb5/neorR4f6wIeITZHKGa5QY6DmzCbmHNe EJ6Qs4AMMBU1NoltArvGSMXYm2Wi+B7Mit3Hu9SX/l7dDvUIYAWzx5AntApdc/04qpcG Prdg== X-Gm-Message-State: AOJu0YyxBjARIQOk8W88YNFONOQf+yCjkMuUxsOnM9ZRegudV62HXOsQ na1z2D131gH6obKEbozFwt5qseORZWyEWgA8FOzuUPAbqFRanEt87BYwbnBsV4BZ0w== X-Gm-Gg: ATEYQzz0QFNmTWu85EHqLdv0+WNR0bUN3Fs7GwKWFXdqv8v9gb6hZSbXpqNvsZWaHqQ gpAOphbc6yLRRadgv2x+/JzxM+bc5DCPbuH++bSnEgDiGuC5AT9fQ7M0I02DLN1P53F/eRcgG4X G26KWh7GjiOqvvoADHRCggcOz9x8QBXYDdobMxQpaDZOqWcsBYXf6Ik0rmRac7f2/vZ7Uusnigp qazkje/uks52wcFPy4+KabDlib5Fi0G3Bj/ZZsFxgV/Tu0DPQBO7sJfRG4kThPy3qxr8IYhaNWp upYwBYZ7gAUF9txc1wWmX6TC3XTZyqn+fnAYfN+REPo/TQjrL6rnJpkzqazpTof0UgRNMInNYyI 3ptKlWJbuklyJvOdVsdqKH+OKyS6OwU8JdBXJ0GmjOYa38rZNoAwABs69SLFyKKY7kTjuvczbNa 1LrX0l6eLIBWl395coRayQanfwkVhUq8EDTuWYA2/oLirggApMBt6vJtkhyf6QUm81iStkbxJHT Uq6C9wERSvmF8c= X-Received: by 2002:a05:600c:1c26:b0:483:71f7:2796 with SMTP id 5b1f17b1804b1-4851982e8bcmr42106625e9.10.1772638742475; Wed, 04 Mar 2026 07:39:02 -0800 (PST) Message-ID: <7d7b75b7-80c4-4c23-8678-b33f4c90132c@suse.com> Date: Wed, 4 Mar 2026 16:39:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 16:06, Roger Pau Monné wrote: > On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: >> When Dom0 informs us about MMCFG usability, this may change whether >> extended capabilities are available (accessible) for devices. Zap what >> might be on record, and re-initialize things. >> >> No synchronization is added for the case where devices may already be in >> use. That'll need sorting when (a) DomU support was added and (b) DomU-s >> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). >> >> vpci_cleanup_capabilities() also shouldn't have used >> pci_find_ext_capability(), as already when the function was introduced >> extended config space may not have been (properly) accessible anymore, >> no matter whether it was during init. Extended capability cleanup hooks >> need to cope with being called when the respective capability doesn't >> exist (and hence the corresponding ->init() hook was never called). >> >> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") >> Signed-off-by: Jan Beulich >> --- >> vpci_reinit_ext_capabilities()'es return value is checked only to log an >> error; it doesn't feel quite right to fail the hypercall because of this. >> Roger brought up the idea of de-assigning the device in such a case, but >> if a driver doesn't use extended capabilities the device would likely >> continue to work fine, for Dom0 this probably wouldn't be quite right >> anyway, and it's also unclear whether calling deassign_device() could be >> done from this context. Something like what pci_check_disable_device() >> does may be an option, if we really think we need to "break" the device. > > We may want to add a note there, stating that we have considered all > possible options, and hiding the capability and hoping the owner > domain would continue to work as expected seems the less bad of all of > them? I'll see what I can do. >> The use of is_hardware_domain() in vpci_cleanup_capabilities() was >> uncommented and hence is left so. Shouldn't there be a DomU-related TODO >> or FIXME? > > Hm, yes, possibly. I think limiting extended space availability to > the hardware domain only has been done "just" because we have no > extended capabilities to expose to domUs so far, and I don't think we > even setup the extended capability list in the domU case. Considering how many things there are to be done for DomU support, I think it would help if every place where e.g. is_hardware_domain() is used only as surrogate would be properly annotated. Or perhaps properly named predicates could be introduced right away, so one can actually go hunt for all of them. Then again is_hardware_domain() is also something one can go hunt for. >> @@ -349,22 +352,23 @@ int vpci_init_capabilities(struct pci_de >> return 0; >> } >> >> -void vpci_cleanup_capabilities(struct pci_dev *pdev) >> +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) >> { > > You could short-circuit the function here, ie: > > if ( ext_only && !is_hardware_domain(pdev->domain) ) > return; > > But I'm not sure that would simplify the code of the function much? > Likewise for vpci_init_capabilities(). Such a short-circuit would need replacing / dropping once DomU support is added. I was hoping the chosen arrangement would make for a little less churn at that time. I'll listen to your advice, though, just that the question gives the impression you're not quite sure either. >> for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ ) >> { >> const vpci_capability_t *capability = &__start_vpci_array[i]; >> const unsigned int cap = capability->id; >> - unsigned int pos = 0; >> >> if ( !capability->cleanup ) >> continue; >> >> - if ( !capability->is_ext ) >> - pos = pci_find_cap_offset(pdev->sbdf, cap); >> - else if ( is_hardware_domain(pdev->domain) ) >> - pos = pci_find_ext_capability(pdev, cap); >> - if ( pos ) >> + /* >> + * Cannot call pci_find_ext_capability() here, as extended config >> + * space may (no longer) be accessible. >> + */ >> + if ( capability->is_ext >> + ? is_hardware_domain(pdev->domain) >> + : !ext_only && pci_find_cap_offset(pdev->sbdf, cap) ) > > Given the changes you have done to the reBAR cleanup function, we > could even call capability->cleanup() on domUs, as the handler has to > deal with uninitialized capabilities either way? Hmm, yes, looks like we could. >> @@ -376,6 +380,28 @@ void vpci_cleanup_capabilities(struct pc >> } >> } >> >> +int vpci_reinit_ext_capabilities(struct pci_dev *pdev) >> +{ >> + if ( !pdev->vpci ) >> + return 0; >> + >> + /* >> + * FIXME: DomU support is missing. For already running domains we may >> + * need to pause them around the entire re-evaluation of extended config >> + * space accessibility. >> + */ >> + if ( pdev->domain ) >> + ASSERT(pdev->domain == hardware_domain || pdev->domain == dom_io); > > Is this to cope around races? I don't think it's a valid state to > have pdev->vpci != NULL and pdev->domain == NULL? Knowing that I had seen pdev-s with NULL domains, I'm perhaps overly cautious. Yes, ->vpci being non-NULL ought to demand a proper owner. > Neither you can have pdev->domain == dom_io and pdev->vpci != NULL? Same here, looks like I went too far. >> + >> + vpci_cleanup_capabilities(pdev, true); >> + >> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, >> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) >> + ASSERT_UNREACHABLE(); > > Ideally this would better be done the other way around. We first > remove the handlers, and the cleanup the capabilities. Just to ensure > no stray handler could end up having cached references to data that's > been freed by vpci_cleanup_capabilities(). And maybe not just that: For the hwdom case cleanup_rebar() adds new handlers, which we'd wrongly purge again right away. (Because we pass "false" for "hide", this isn't an active issue right now.) > And we should take the write_lock(&pdev->domain->pci_lock). Now this is a request that I'm struggling with some. I can see that callers of vpci_{init,cleanup}_capabilities() assert that the lock is being held, yet it's not quite clear to me why that's needed. Shouldn't vPCI internals all synchronize on the vPCI lock of the domain? Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:40:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:40:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245666.1545014 (Exim 4.92) (envelope-from ) id 1vxoKN-0008LZ-HT; Wed, 04 Mar 2026 15:39:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245666.1545014; Wed, 04 Mar 2026 15:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoKN-0008LS-Ez; Wed, 04 Mar 2026 15:39:59 +0000 Received: by outflank-mailman (input) for mailman id 1245666; Wed, 04 Mar 2026 15:39:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoKM-0007O5-0L for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:39:58 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 650a4211-17e0-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:39:57 +0100 (CET) Received: from BN1PR13CA0012.namprd13.prod.outlook.com (2603:10b6:408:e2::17) by PH7PR12MB6537.namprd12.prod.outlook.com (2603:10b6:510:1f2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 15:39:44 +0000 Received: from BN2PEPF000044A1.namprd02.prod.outlook.com (2603:10b6:408:e2:cafe::ba) by BN1PR13CA0012.outlook.office365.com (2603:10b6:408:e2::17) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.22 via Frontend Transport; Wed, 4 Mar 2026 15:39:44 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BN2PEPF000044A1.mail.protection.outlook.com (10.167.243.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 4 Mar 2026 15:39: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.17; Wed, 4 Mar 2026 09:39:44 -0600 Received: from [172.30.142.83] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 4 Mar 2026 09:39:43 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 650a4211-17e0-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uFdiVgCPP+aJXFZ02qJTAAqeW8c2H19VtiZJsPyI2iejWuJnVeB4LAZbOjjOBt1tk9risT2wXfw+4NXYB6K8POqueW+QYQ0DOQBeE1suhiL7SuVIsEtMdbtfM2pcip0POoZXUVWGpduaD2Gj4ebiTwr/OzRbbdPOkjgg2srJExbRRtV+EqPkVTbfxs+xuiu1aWdL0zHUfulMjvdM1H/Eh9eqMwjKK3qgc46mHJF8QcTo8NqHhwi4B3DEVDlzXpJgZvbJuLs54lDnFBwJnlLTurDbyOWbce1Uk1tDIPz5PWdcBY69bZ1h3WAQto1MGddlGVqRIsnbYKSJq0fPAoLeXA== 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=vyhb4HtPgNTNTQK78/KCtQ5UY9dl0XWdx5R5IX5sM0k=; b=d+MKV2m4MoyiZ3gDmY2vQt6khSc84sFyeFt33YUbQMhff2erIxpiHao0g92hkqDJHBvsra9p7+lHvutMzkcS9/MwiEL/sAMolhUS707pIZ5jVM8SoVtDX4I3F4iPK10sd4DKv9O1saxDmKJ8GXdtE5wLMNQUI90lwcsyjbO2wUKMHpRS95NcVTDt8Cr4GKAut2oZ9bh3aFqXVU2NwjgJ3alpspJskKhDlMv7W3w3LeKWjQX+Q45ZRnRm24CGLkey1IIgf306vXv60aiR9xeoMjw7cJPyIj4B9MLvIUP9vPLkroIS2u3j2qfjrzpjurN98kjVI+Kw4IFOSHJIXwpWLg== 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=vyhb4HtPgNTNTQK78/KCtQ5UY9dl0XWdx5R5IX5sM0k=; b=jCH8dGSjyHX5Zcqmcl49Vf/0rVEV3y3w406+bFdOMLoTlOJJgvwbaRyqdhVHE+XPfthFSNUDRm515i03CTXC3JoCOdWSNzjOiwA2eaP1gJoC95jrb1OywchU8hT1aXzio2qHyLJ/yu/zQqVSEY53D7wIa5FByRPTKPFk9ESm3Vo= 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: <1e62a5ad-f865-4477-a899-0182dec38901@amd.com> Date: Wed, 4 Mar 2026 10:39:56 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] vpci/msix: check for BARs enabled in vpci_make_msix_hole To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= CC: , Jan Beulich References: <20260226025740.71673-1-stewart.hildebrand@amd.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A1:EE_|PH7PR12MB6537:EE_ X-MS-Office365-Filtering-Correlation-Id: e4fae744-d7c8-458e-7712-08de7a04426f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: WBTAJ5+1pojhYvufmg98sWm9Mhj5Q2MtEQETyeIszx3yuBJaUOdrq/ry1hGUwxB61lmn1msm+WxuPEOqH9a2zfgMBFxCKHwyJF3z3aswhk/wmiD68o7g7q/sgKGryZ+dF0+yhzTe5nIQBX1fuzxCrtxyNO6dHGh1S98r8ZsS8o6AT93B0e0rMLEQW+Okpn6KM2USj2oIYjLhPytCSPLvJo8tWNVvvlouWwxys5lVhOJIdVstbBd60gzFA6H3q8h+yClRtNro7s1RFU14jhvvNaLlygOhmzmc8RudxIL8TH7Kk81+pxN7Ad5hd3u6enJrKKToCf+k9/3RjVQDunMuRzjhU/ypdOss8v8Ke5HOCogSD+kLZDlfGBERCUuBnZelPrTGYC1tNy85Lzc2+Bat0/pqsR3rALYq4kGUuInoqOMT/dSOOgcV+Aqylw6Yis7PmWKwoawcMcrozrKWAlMvpeAGgw9n2+SuONgw5aWtb23QqVBaZVVn0KrjTrDER3nBpb0zi2y9n3slRYZ4MhIBRTJSmqTg1PwgUe0ik+q1wfuaHza8l8nOqKBPOTx0f2CXTUGXJKXEN7k1szUEG8nhTvg8kEtGZBx08fngWk7+LKP+vyMeSQVwKjtW7U4e1lpLriMiIZskZTCqtgLVU6W4lLF5oeQhZTlDbSQNd1sd0h75XAPqC45B5gVFbF5IwGfHfG4Dr/O9H4R9kr+uOIp1tn7nBweIvcw/Ii3c0OtjtUEraf34m0tbIRMpuX7pV7EqmEnnvQfka1houfRKs6w0eg== 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: hMlB5XsJDpeXmQ7Y0emgf4yyzgUsNT7QJSjwIKv6lXJt5BnL8/BGjZytkSbaJP+IuixYg7oP9P99EoGumHwRtztasDMKkkCG9j611wTDjDWyDv+7//13dHwU33qpBCdzjjVUKWzZA6UF7z0ckYzttadS4eIFsKsKowixpXEPiZZjXh2F0nnt9Z6xDX3dGwn5hHoKLzRwwouooTpe0ytEbYfoSOMyvACXhlffJThKpRi7FPQAOrO+fhvfSBOHRYJUVUUgm7j6+++9enn01lYeAE49hox7R39phAilLvLomF9RNmO0MHlpPsFD14w/uJA8j5abbXdzn1JFjyKARQE0pIeKb0LdqfjjWWY1FXLN1keCuGRTUcqQTf76tqxrz6B0J85I3KXieMi6bS8mbzRkorbm9jWdjxYWQcNLjY3AtAXp9ReiWJGRyP0i6RZmTYoh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:39:44.5827 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e4fae744-d7c8-458e-7712-08de7a04426f 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: BN2PEPF000044A1.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6537 On 3/4/26 10:23, Roger Pau Monné wrote: > On Wed, Feb 25, 2026 at 09:57:38PM -0500, Stewart Hildebrand wrote: >> A hotplugged PCI device may be added uninitialized. In particular, >> memory decoding might be disabled and the BARs might be zeroed. In this >> case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole() >> unconditionally attempts to punch holes in p2m, leading to init_msix() >> failing: >> >> (XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area >> (XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it >> >> vpci_make_msix_hole() should only attempt to punch holes if the BARs >> containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper >> for checking if a BAR is enabled, and add a check for the situation >> inside vpci_make_msix_hole(). >> >> As a result of the newly introduced checks in vpci_make_msix_hole(), >> move the call to vpci_make_msix_hole() within modify_decoding() to after >> setting ->enabled. >> >> Fixes: ee2eb6849d50 ("vpci: Refactor REGISTER_VPCI_INIT") >> Signed-off-by: Stewart Hildebrand > > Reviewed-by: Roger Pau Monné > > Thanks. Thanks! I would like to point out that this now needs a rebase: The helper vmsix_table_bar_valid() should be moved to the new private.h. I'd be happy to send v4, assuming I can retain your R-b. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:47:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:47:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245688.1545029 (Exim 4.92) (envelope-from ) id 1vxoR9-0001fK-GH; Wed, 04 Mar 2026 15:46:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245688.1545029; Wed, 04 Mar 2026 15: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 ) id 1vxoR9-0001fD-DA; Wed, 04 Mar 2026 15:46:59 +0000 Received: by outflank-mailman (input) for mailman id 1245688; Wed, 04 Mar 2026 15:46:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoR8-0001f5-1D for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:46:58 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d4244d4-17e1-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 16:46:52 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CH3PR03MB7341.namprd03.prod.outlook.com (2603:10b6:610:1a6::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 15:46:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 15:46:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d4244d4-17e1-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HYQJ2QaT+r01EeoYFzmxo1kOSfA54ndTS+ZXsxg2WTVezoamAz4v3dp8CPLH9jPWQQkbuApTjm3nehioQyIVz7ocB31VeTLtqovxIb/nMIaTkHl+W6Ire9GML5qCJQVljzvHTZzBYTVxXjaacVSpfa5ip9xvPGaWhqGIyfyqLqBqhHYpzUIsd30Q29LKR3f+GPJ8WjrK4clFkvtz1ef7FfwxreTO7/AkHYnTuGOyKIrL+KYd2qsQ5zSqYAfADe/uE86/nJixgKwqi+0NFVqKvh//dnGwMRtvFL2eAy+TzeZqg2/s5r8rOp1I0EYX49W97U0kAbOVgsTDVX20hEN42w== 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=cow4Ee/eldGQKE8TcB2/TyGw1p+U5zfANcUH1l9/wyE=; b=QR5+Xxvp3cpAOMZ9gvJM+PMI0a1Kviq2cTVsZKksjmE4N5tzPnxby9AyZiYYKRRlPOKZOAJo6RlPli4YGW0v0xTIrXdbQIASuIoB1hCV+GMQrpJD3LyA19DHl6zQ5XWxOsJQBuahVmsBk8qjo/SqYJqw7C8eVegSlJHHn0mWLr2jnyL6Wud6SVidJ3AASUoxpORX2w0U/iiGgPqmn2BWWm9Pklx0y6hEI+ZLjWyc0pGLIqqyY5h8LPqAcvzzDn7wmW9FvG9DrTUgjOMrBIFbpwn8rWgUpasGRfuSPW3CQdJq31UMN8NkA9YXMvWddqlb3Hk9KTdseFGOV3N4f794ag== 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=cow4Ee/eldGQKE8TcB2/TyGw1p+U5zfANcUH1l9/wyE=; b=HSeMfhfFdtuuw6Ex2zaNGe2AWhTSjnb4iEgpoORg4d9d6GPc50COJz8Vxdh3DeBXqC5aLfaGKYOHKk6hTTCRY71cqv2LcM5VSjkLP9/AXkDaymECdFRQmCFTWohSuZeO8kAgHDQa1D+yyhuVVSXJviVD94GsVlHSsIvHtsedbBs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 16:46:44 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Stewart Hildebrand , Ariadne Conill , Steven Noonan , xen-devel@lists.xenproject.org Subject: Re: [PATCH] xen/vpci: zero guest-visible BAR addresses to ensure domU asssigns its own Message-ID: References: <20260224231216.6203-1-ariadne@ariadne.space> <2aef1aab-f1f4-4063-8c61-d26ae335d06f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MR1P264CA0066.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CH3PR03MB7341:EE_ X-MS-Office365-Filtering-Correlation-Id: b885b062-304b-4547-fe05-08de7a053efe X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016; X-Microsoft-Antispam-Message-Info: +EbYmSRsuSWaBMUmDyHGia1ChwqwMyJD7lTS51EBQRva0uMhEHaOMvUBued/GZCgM/N8FcHdc7xJaNoiK0VF85Sq6npJL8nrl6KyqiiQsXMFswX5vCTNt3nG2dBQzTY+pxuSSF79OLEpmp9e9qDXkBdvyZfUtx0zdEibElDTGr9UY4sCJkQUpdS/dhtLaVuaihq71YyBSgrSfTGr3D9k5nNPQZgIwLmWdg04v3bnYPgXgAOYV253tEXn7AbPBD6+RFbaPGMGsls0y0qEzomURyJs3mNyX8JwoE26+AuMO+hNI1TZ1nFxjM27H1f546GIMmrlOf97wf2XyvjET8DJb2hCPJFyM3vwmahwnO49DcWbu4IP75VsTAxo+irdXxSPmQmwKQIMRDH49LFhcauAR7Lf5kFZMFI6fLDc4Uo10vhLkpz1gyntIPEDuoE6DhVFecHw42J1eNurPEx8iKLQqEpxYdv6YCW+va4aTOmWg/j8p5630sNhi8EqGUzHWCh7aY8/CwYy7VXfTCOsXNpKJ4pcBpces7dUXFaj3uvpXREiQQUL0/9CuM6kbyekyypemyAzc2TI9YqbU9fC/venTlCkomrunWXlgloKaOHMMo7pGOiEQ88/bEEEZzEx0C03/gcUnDcUREBev25LBTOqfuA1UPSwQYqDhW3VYC79jh/LmsGk0vK1VENnIF/9DQmlonYQjETMseNIqwz89L1yd5QSzmLHlpegmiQglyRIdk8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?clRXMjBMVWYybTl3OFl4bHZsb3N5RTVnWGlCbDFNYmtCdGViTFdQVE1YTWo0?= =?utf-8?B?OUd1aWRBTXJyV1lqT2lvczJhZWdDTjlBTlNkNm4vZTdYb1N3clVDK1VsQ1hX?= =?utf-8?B?T3BIeEVXNFpDYnNEUENwblZNUXAyVDBMSXNUYTB2Zll0Z2dJYmFZeTVXUzNY?= =?utf-8?B?WVo2SEpKL2tuK2cxVVA4QUJQbDBkdnhmQXZFOEVYVS9INEtPd0hyZWxUUnhO?= =?utf-8?B?N1dhZDdjUmN6aFk1YmJyM2tDNkJ3ZlY0TnNVTE9ISFpjNGNFanRtRE10MmlX?= =?utf-8?B?LytvZnc3K1V4ZmlrV21LRW1wMGlVT1VlSkcremgzRmZ1bHNNWTRSRTdwSzcx?= =?utf-8?B?Z1U4ZytVTm9iOGd4QU5RbkZhWkV0dXpQQjlaQVl3OFVrT3kvTEhxTFNPVTIx?= =?utf-8?B?ZWZEYkZrd0dhdmwzY2lqaGc5R0Z0YkRXTEdickZYZEV2eWN4TElwK0JCLzIw?= =?utf-8?B?Zi95enEyWDgxc1RSbXFKYlNZL0xZL2h1akJBcVBwU1NSdDZqWXlpTXpycHAv?= =?utf-8?B?c1QyRkFxSCt4UDE1Mm8vTC9GMTk5QVpaL21KY3I0OC9iWkZDR2MzZG5pc3g5?= =?utf-8?B?QXVnbGdKLzhCQVpuYTh0WjJ0ZkszU3FvVTZvb2YyLzVwUjYvd0VDdTUxNmVG?= =?utf-8?B?c05ZY0pkcVptdVNwWmFYY0tkN01oZmk0d0hlVkdVaFdpOXp3UjhySmtrQW00?= =?utf-8?B?bTlqRWVWN3QyaEIrVENYMXRQUEx4aEN1T3RxSzdRbzhheGlLUFBRcTdDL3Jx?= =?utf-8?B?QytEWlJrSnlIMWtYTjJqSjU5U0sxd0JUWjV4bitnR0RLcWY2QXo1aGJaVlBu?= =?utf-8?B?YXRZN0FJcU5YRHNmSFZaelREa2JtenBLL2h5Z2NGS2xXcUJVRldwVjRmdXhG?= =?utf-8?B?QUdqNnREYnlESGtvRGFGQ0RJYVdOZC9QQ0tud241Y3M0UEZpa2JoSWVKdk5B?= =?utf-8?B?UlB4Q0lhRlpXZFk1NnpEeDRQT3ptL1NNdVFFQnduNkhIb3Roak9HOG55ejlh?= =?utf-8?B?TDJCMysxV3N2VzlQNkc4Mzl0dmtVaG9jTWZBazArM1RnMnlSLy9XSnBua3FL?= =?utf-8?B?S04xV0VOeGl0cTdWQllVcFM1RDVNZnBmRmFUZlRCWFJocEVtbG1kNG1SaHpa?= =?utf-8?B?dGNuVU0zaDZNR252SDNNaU9SRnNSdy9qYTVFZk1ValBsek5EMXViTFpTNk9m?= =?utf-8?B?bm90S25TSTRjS0ZnSDRabUxLbU5HR2UweTV2UEErdlhMMlRtUm9ldEZURHp3?= =?utf-8?B?bG5mQW1HNVAvdklIaFVnODFLSE0rMDFFN1BiUU5hVCt3S2hwdGFiSlVTbjJw?= =?utf-8?B?OWttblg1ZURZRHQ3SCtVaWtPdUNSZ0ZFZ3VudzRqdVpmb0RXUG5sNy9OYml0?= =?utf-8?B?Q2xlbVBPNWx3Q0t5SEhnVytNK01NT1dLUVBOVEw2Y3l5bkZKVi81ankwVHdP?= =?utf-8?B?YWhNQlRVRVRCZmJJWi9lcXFMNnhlVEx1NGd6cGd3QU1hTTVXL1M1QWlxZEpE?= =?utf-8?B?OXkyclM1STVWdUV1bG84U3RSeGNuSGpoL3VNUzlFOEpiR0pWUWo0YXhPdGE2?= =?utf-8?B?Yzd0M3lGczBOVWZ5Tk1LUWVPOHRIQnk0cEZzTi9Nay9jdVpxalpRU2JHK3JJ?= =?utf-8?B?QTNZTEE0T0FOWmFTblQ2MDBXS3IxODRUNC9oRy9TdGpoRXNpUFN4dVUrRUlp?= =?utf-8?B?MmErSXBndmRldXZFU3A2TEhrRlNnZkJGQ0JqQ2FsV0hsbjl1NjVqbkRkZnBY?= =?utf-8?B?bVRCUXlSMlRjNkEvYVc2NXJHMThqMThLK0l3YTgwcVJ3S0N5VHJqWjBzMmJN?= =?utf-8?B?L29YL0FWckE0Z1hlcis1dEZuMTBFR0pyVUZkY01NbWUreDZMSTNUOEgvKzd4?= =?utf-8?B?NnN6N2t5QUtteHc5bGFKdzVKaDA4bHNQZVhXc00xQ2M1ZFhYem5mR21wdzMw?= =?utf-8?B?cGRIYnNmRmIxaThtcEVJVllKNnNVNjVaQ1RjTWhVNlpFcVBjNWJLMTFXMzlJ?= =?utf-8?B?ZWNUZ3huNFlZNDF6am1BTVRHSDF0OFRZa1poTnNEK2FEZ2YvaHErd01LM1ZD?= =?utf-8?B?NHFvYUkyS0NXYUlHVUZTYkNtV0FhSjJIK0l6dG8vQ1dicFRQUWlad3R5SGcr?= =?utf-8?B?ZnFmUEZYYXRCTVprd1VPV3RXZGk3eks0YUF2WllLWGxQVDF3eXVSUitQKzRl?= =?utf-8?B?b3lnUm12VjN5NDFOWnNkOTI4WXU5eWxXSnNvWk5LZEh4MEJjYUtVdTh2b01R?= =?utf-8?B?MitRMzdLdjQ5WGxObmdCOXYweFc1SXRuMHZkNU1haldmc1JkVzJoZGhHRkdi?= =?utf-8?B?U3IwdjdLSjBBRDU1THZNOGEyREt3cEdvbng0MzRnTTVZVzNXdjBVdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b885b062-304b-4547-fe05-08de7a053efe X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 15:46:48.5781 (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: 6hSRGCRhMH2guKCJbtJi/Tda08vliCKXCr3GYmz3lrVreQ25rVtQ5XmO5Vz8yu3vgUxLk8DcglAahI0eQeprhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR03MB7341 On Thu, Feb 26, 2026 at 08:47:52AM +0100, Jan Beulich wrote: > On 26.02.2026 03:50, Stewart Hildebrand wrote: > > On 2/25/26 10:37, Jan Beulich wrote: > >> On 25.02.2026 00:12, Ariadne Conill wrote: > >>> From: Steven Noonan > >>> > >>> If we just use the host's BAR addresses, the domU might not attempt to > >>> reconfigure the BAR ranges and may never try to map them with the IOMMU. > >>> Zeroing them ensures the guest kernel knows the BARs are not configured > >>> and needs to make its own choices about where to map the BARs. > >> > >> Yet for this, don't we first need to expose a full topology to the guest, > >> i.e. at least a host bridge, and maybe further bridges? > > While we eventually do want to expose (a) virtual bridge(s) to vPCI domUs (this > > work is currently in development), I don't think it's pre-requisite for the code > > change herein: clearly, leaking host BAR addresses to domUs isn't right, and > > there's no need to wait to address that. > > > > With that said, the commit title/description don't align well with the code > > change. Assuming we want to move the code change forward, for v2 of the patch I > > suggest dropping the 2nd half of the title, and reworking the commit description > > to focus on describing the code change at hand and less on what the domU might > > do. > > That would indeed work for me. +1. The "try to map them with the IOMMU" wording is not accurate IMO, and wants replacing. It would also be nice to mention that zeroing unconditionally is fine, because for domUs the memory decoding bit is also unconditionally cleared, so there will be no attempt to map the BARs into the guest p2m by vpci_init_header(). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 15:48:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 15:48:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245697.1545039 (Exim 4.92) (envelope-from ) id 1vxoSR-0002TG-Qa; Wed, 04 Mar 2026 15:48:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245697.1545039; Wed, 04 Mar 2026 15: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 ) id 1vxoSR-0002T9-Mm; Wed, 04 Mar 2026 15:48:19 +0000 Received: by outflank-mailman (input) for mailman id 1245697; Wed, 04 Mar 2026 15:48:18 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoSQ-0002Jq-Lv for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 15:48:18 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8b3e01f8-17e1-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 16:48:09 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-48375f10628so47190585e9.1 for ; Wed, 04 Mar 2026 07:48:09 -0800 (PST) Received: from [10.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-4851c907a08sm2074985e9.0.2026.03.04.07.48.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 07:48:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b3e01f8-17e1-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772639289; x=1773244089; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=szv7ibgFC1wfNHL1X56ycFpl6qWz9laDnmraUSEN+Jo=; b=WwNAHwefR03PASbf2b7rnpLaKnxsgLzx0nkm/cmKsihnHGYfnkE/xaeNfYvc8k6kjl VdW+3WGJGqYTbgAyoGIi2yT2nHqZn5g9yChvJE5kibNye4Z0Kaa/QVlP3qYIABA0G265 En5exJtj3RQuNlucVdvBBL0v+RMp8KZBX1MwAsa0IB6mCNKIGZl2pO4QvG5C6vdNEvJB yNJiWKcima65pi0/V42Hj5v7NDPBKRJeMkwGlYH/OR9NUxjb4VijDYpyeD57vVYryyH/ xLhw6LSmBAdyccvBSfdHSPggDJzzo+bN1SQE7jYm5MOlDUbUPqk9vDKXvu2NsRoD6iSv T4ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772639289; x=1773244089; h=content-transfer-encoding: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; bh=szv7ibgFC1wfNHL1X56ycFpl6qWz9laDnmraUSEN+Jo=; b=oDEJmEPfsRhgl7e2pu6CVSOhqkOkRWvR8Ov8aBqOWa+Q+OGM7kzw4IsPa4G0T8be3w lpmV5D0zVVV/llBb2wPTOXiaKbR5AEWgwcSf0LX8Z4CwZao7R2TOBxcTp8jysVF5Yl2B rq+ImPumYM8HtRRSHj7fE97IeJM2+Rr1U+/6I4hdKFKjgSlwiPCBpNge8sBK37s46JTS 96TUAV3Guyh2l4zciAnSGoCJDDh3tuwaEjltIxmvLHrXPKM0O3o0fVMKR4SCKlr3yy0b PJAyB+kQ52Fv1laFNDop8pOmBn9suF/UqoAXwP7r2fm5qsmUB/pJ5pU91GQPPm6loF6q RLhQ== X-Gm-Message-State: AOJu0Yxjn/+0mK8YM23rW3Po0MZLX9Fns5Ss5vcO2hbBVbhZ+twOq4wp BMVs8XfKc7HPVocE23cAyMb0ClITgt1DWRmE8fNlMoKmGAHrqs/0ZNnsY8bYU6n15Q== X-Gm-Gg: ATEYQzzkg/KXM8fd5D26//D440jZ/kPec0cqa+HEXW6/x9ttCFpIt8HIFH2fa/uYuNc ZFjS5Hcta6GtxTPTjRCf2jpC2NjEi+iWHyrMAgpt30p9DBlMcVtgyqCsAoUmM4Lj0t0aE0zjCRC Ws83gLUxs3P0tW2W8pLbzqXVFpznEmQlQlzC2TWEO5lb6sXWgOFcwnINtBUP7vMPs0+HjU/sOCc /svxbmiAOW8DS5+Z26oLMMImS7k6gNdxfzuINgyaEPAku/J3X4TgoYUseheR9jgedKNDeYEHilU 1KQ/iq0zxha2zTwZuMe5JoS/quJXnIwdDedf5DcnPgQOiyyZj9i7Y7RrY1527YHSI/p93WOryJy jADoYn+3uV9B0gpXvdJFpWPviKIs/PN1MQtpS9v3ssm8Yts8/sxMIn2B+WeWom90hwehkkc4ce1 EAw/WeOVM35NbQg6ngCv0vbjSsaDYMDtonjlic1cvTEnC3kxMBInb9ntZCPXDSPgO5Py10Um6gm mtcAfss8udDSY4VyjFRovBSXQ== X-Received: by 2002:a05:600c:4e8a:b0:480:3a71:92b2 with SMTP id 5b1f17b1804b1-4851988ade2mr36628565e9.26.1772639289007; Wed, 04 Mar 2026 07:48:09 -0800 (PST) Message-ID: <80129c3a-77cb-4cb1-b3fd-128454e3db0b@suse.com> Date: Wed, 4 Mar 2026 16:48:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] domain: use unsigned loop induction variable in complete_domain_destroy() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 16:38, Roger Pau Monné wrote: > On Thu, Feb 26, 2026 at 10:01:45AM +0100, Jan Beulich wrote: >> --- a/xen/common/domain.c >> +++ b/xen/common/domain.c >> @@ -1475,7 +1475,7 @@ static void cf_check complete_domain_des >> { >> struct domain *d = container_of(head, struct domain, rcu); >> struct vcpu *v; >> - int i; >> + unsigned int i; >> >> /* >> * Flush all state for the vCPU previously having run on the current CPU. >> @@ -1485,7 +1485,7 @@ static void cf_check complete_domain_des >> */ >> sync_local_execstate(); >> >> - for ( i = d->max_vcpus - 1; i >= 0; i-- ) >> + for ( i = d->max_vcpus; i-- > 0; ) > > Is there any reason we need to do those loops backwards? > > I would rather do: > > for ( i = 0; i < d->max_vcpus; i++ ) > > ? I think it's better to keep like this. The latter of the loops would better clear d->vcpu[i] (to not leave a dangling pointer), and there may be code which assumes that for ordinary domains d->vcpu[] is populated contiguously. Hardly any code should touch the vCPU-s of a domain destructed this far, but still better safe than sorry, I guess. In no case would I like to mix both changes. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:07:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:07:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245722.1545076 (Exim 4.92) (envelope-from ) id 1vxolO-0006Le-J4; Wed, 04 Mar 2026 16:07:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245722.1545076; Wed, 04 Mar 2026 16:07:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxolO-0006LX-GM; Wed, 04 Mar 2026 16:07:54 +0000 Received: by outflank-mailman (input) for mailman id 1245722; Wed, 04 Mar 2026 16:07:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxolN-0006LR-8U for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:07:53 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4be01a62-17e4-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 17:07:51 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4836f363ad2so82580055e9.1 for ; Wed, 04 Mar 2026 08:07:51 -0800 (PST) Received: from [10.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-439b3cc2e65sm28542085f8f.2.2026.03.04.08.07.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:07:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4be01a62-17e4-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772640471; x=1773245271; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=lIanfJHGJrbMTqrVwQVmc0FAWMVR3HjKHqqvv6oPTxo=; b=dkrB8AXvUuriCg8Kkpiy2fowo77wUub/w9yr8K0csXWcwiTotG763saBxxPn6ThtJh PqUBE/87Pz39kLkpSlHErm46PNe+SAYvw0m28EmRl8a80muedP3RcNZkKam5J41NaGzK 9Qhegziu1YElVYHcdi/+HvoXGRNeQ9XbfQYRglou0c7xEKdPgUz8f5PoBT3MFAK3OaGg 4Yas/caTLiy6MFdxL234o/L7BWObNl7tnXk0saFHaamVXc8/VPAW9RcNndKa9K/3ZOvZ b//kZzycT8vsUGK4ghOn8eKdsxqU/U0V3fdY0rvPjVk4Mt2UyhXvc5WPhIDImC2F3vsL 5ZFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772640471; x=1773245271; h=content-transfer-encoding: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; bh=lIanfJHGJrbMTqrVwQVmc0FAWMVR3HjKHqqvv6oPTxo=; b=FVz88ilwiKFUT2Lq12gfYdRwJRkarB3RMXZIsPvS5e61dWbxLyEfe2Nmcr9zVcLpNA RUjawgMoPsaBuTo1NdwoTaT8ZFYov3tn+NInNpQ6tYbVEmQM6ejyWMxfm2YRKR+H5HrP pE576BfebwhSEqHofbYfZtZxmO2oSWakEV4EksP6uazUPoHH+mDGUK9RDrN3f4o02cA3 l3AG/chDoRe931mdIJVHrgTDGGAkG9QGb/bW014wsBd4WsEpnqtaYl9Ma2l6yoCtlE03 lKJOHUwEED6cHAmFYbUvh60SHrMsBX+DN7kg914q2hvvJGoLW9MSrGPmmX06lg63mgRT UE+Q== X-Forwarded-Encrypted: i=1; AJvYcCWdRiI3gntVKHtuImqxf8ZfLBqvW2/+hxhSqt5hgPjTnN0VPb7TfOEzCikTnXL952FbLAORyJUjtOo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwjJw13sjb9NynmvNKAEkKSWIswW9fodzVJyB/k5poHVjWwiaZu IIfHrDagqzzzxDuYxlzM6Skgh95/SSWeNcyDpfIMewKJyUA8lUpvvdkM+yQ03WSPzg== X-Gm-Gg: ATEYQzzisECuOHf4KmoB4hk1kM2EYfWPQbRhOAs3fujmNmABBN00NhWFjYDRrXNUaz5 fRgoEv6q5IrddNiPuLZzblspgg84lYR1ShK2rvh7EuU/Lc5C+T6Fxxr0UBYr2SZUdpInGgLD0cI Ibw+gxrfBZrmZ55NRTRdXevDGJcOkfspGTQBETsitmDDpTKGILrd1mzfAjUg5jLYY6Ojr1+luzf P903Z+cbsJBs9OIJz5dHShi1WXz66RgPTHz56JhF3to8TSMGX6s2LWG/nZPNpEu7RhIngHgrFxx MhbCepw1S4jXIm5mjPszNLbbzaRqNqEEjLznSsfKSrRfld3A6B/8ofEG5toELjs7AVBDh6XFcmd sHw8qduBpY/fhfEwa0gfhEACFSwW3FnRRhS0mCqHjZD605d+EvgvsCqruHsFzFGxqHlCoYEvCYl qviytomAF8fGJ4r5j0B3Vyy+PcqTHsjQEhRNzxikDEDWKm1ercfhfEjlGfPVophVAQCK1+A7ymU kVz7StztMVe6xs= X-Received: by 2002:a05:600c:a51:b0:47e:e20e:bbbe with SMTP id 5b1f17b1804b1-48519889928mr39855335e9.25.1772640471280; Wed, 04 Mar 2026 08:07:51 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 17:07:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/10] xen: Add NUMA-aware memory claims for domains To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , Juergen Gross , Christian Lindig , David Scott , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > Credits: > > - Alejandro Vallejo developed the initial version > - Roger Pau Monné updated the implementation and upstreamed key improvements > - Marcus Granado contributed analysis and suggestions during development Despite any of this, ... > - Bernhard Kaindl developed the new domctl API, extended tests and documentation > and developed the refactored handler for consuming claims on allocation. > > Comments and feedback welcome. > > Bernhard Kaindl (10): > xen/page_alloc: Extract code for consuming claims into inline function > xen/page_alloc: Optimize getting per-NUMA-node free page counts > xen/page_alloc: Implement NUMA-node-specific claims > xen/page_alloc: Consolidate per-node counters into avail[] array > xen/domain: Add DOMCTL handler for claiming memory with NUMA awareness > xsm/flask: Add XEN_DOMCTL_claim_memory to flask > tools/lib/ctrl/xc: Add xc_domain_claim_memory() to libxenctrl > tools/ocaml/libs/xc: add OCaml domain_claim_memory binding > tools/tests: Update the claims test to test claim_memory hypercall > docs/guest-guide: document the memory claim hypercalls ... only a single patch has an S-o-b other than yours. Is this a correct representation of authorship? Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:08:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:08:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245724.1545086 (Exim 4.92) (envelope-from ) id 1vxolc-0006gN-Q8; Wed, 04 Mar 2026 16:08:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245724.1545086; Wed, 04 Mar 2026 16: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 ) id 1vxolc-0006gG-NG; Wed, 04 Mar 2026 16:08:08 +0000 Received: by outflank-mailman (input) for mailman id 1245724; Wed, 04 Mar 2026 16:08:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxola-0006LR-Rl for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:08:06 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 544d2007-17e4-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 17:08:06 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439ac15f35fso3992643f8f.0 for ; Wed, 04 Mar 2026 08:08:06 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48518839ae7sm52908465e9.1.2026.03.04.08.08.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:08:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 544d2007-17e4-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772640485; x=1773245285; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=vqxBnM8tsYWxs4qD5MGZGFVyVPe8myeroZllsVPZb60=; b=cDu45fXFLSj4kw1Yk1WwEvpRpstRVcY+L5VJGyWS59R1mxgRvDZ38IzyVAxiiNHlzg KLHlXIjieplQUQmgGtRr/ePxNa/v8HU9yAOdW/XmrLqzp+NpgQO5iQ4feC3S/KrGFLj5 ofbh6K4W5eAbjhURlYIxz76Edo4xSu+armymDs5qRQj2y/tg3KQY731bv2QV4tFQSp7O LPf3Tsx3d8LTtbQGilbypCRe+inef8pH1OT/VimmycQhpdoHh1YQCKnSS2R91xrl2IPA +UJ8pjFm2ceGR+VOgcOa07bFRNeZUXcasXO8kbzR86sa5XHsyDw9w6Q8E96zmdgb3Jux DrWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772640485; x=1773245285; h=content-transfer-encoding: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; bh=vqxBnM8tsYWxs4qD5MGZGFVyVPe8myeroZllsVPZb60=; b=Aq6zvoA1Bg3Zc4GPgkcKFTHYfIeabU6goQzGfIFzRw/gfvNVJ21wM0oavOdLTlB63y WkWPtqmPnPwSukD7Cu/5wcyf+CMfEf/qA4ciDGhNvVe33LXc34hjPzdKLlle81ycHHWJ lrSDDIAhAwyKuyntrcMi/hNvZxAsuBKmSRWGkvl1+AnpCXx4qfZqE6NLgZfcUmqKnygh S/dF7SIaeCCRltsXM7WxWal0FTLPn76UL58TmgOX3R8dKBpGJzSVVFLIfGGE3TTTyS1r gBjv/H1FjGdpvlhga/x9paU204So37B30dNIGrOk0bxsZ+ee5q6AIWknH1Vqjh3/heFs cfOg== X-Forwarded-Encrypted: i=1; AJvYcCWPuAeZkCTTARU78peTxh86A+a495RB1lHemGTPdLbrY83wE8mUbznY8rn5YrM+Uk8Wge3hYU+hJVo=@lists.xenproject.org X-Gm-Message-State: AOJu0YxozTb7SiwRyr2zcimKfaXE4K3PqrdJnYfaNM2130HwSQ4kcrqo 3p4k+L0ZqzYSgFCnCjkUAf/VWaQ5j6cd3fxqM/AY8Sh2mciLvxgxGKnq X-Gm-Gg: ATEYQzw64VOzZ5nT2jLRWjfM1EmBkFUyznrpU3a94kQf2Y5JIMwIghZ2sreGHPWdbL8 A7GU9hSM8h+bRM0oroMF60znIYrLMZI0jNHvYCKB0BL1LV6Cma1vLskbRgf4q/00EIwJLOVYg6Z 2pEYehv3qyqFIYJHhFyTP/B0LA9oodYcGM6YFyzmNysUI4nzZYscALe/VQKg6aVTLbsh5gugG+R +aH9lxboQjRKgySn5ulGhQePv+jAkrTfGtdpTCJcZYNjPp04Z2elYQp7Bi3D4ZGAKA4sFkjPAL/ RyScjrMQiVKoARg+IqRVGEHs77ufueo85UyPu8680XqyIJ/hgpOHhH4BRhY8aEDMRTdulK5aeSH MfCRinAnRA93emBSt1NaactWINpuzTtoKUXaguHwet3CqvK1CKBnjpuqF4qsie1hobxC2r5KOqc Ylm2iabGzPAnkPqxjtiR7YdRg4uPjE8oJ7BDY7lq1+KqLO6Bbru+urITiv8SilpMIlrDZnxCR77 go= X-Received: by 2002:a05:600c:4e8a:b0:47e:e9c9:23bc with SMTP id 5b1f17b1804b1-4851989fb4cmr37601565e9.30.1772640485310; Wed, 04 Mar 2026 08:08:05 -0800 (PST) Message-ID: Date: Wed, 4 Mar 2026 17:08:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <4b67f8cb-43d4-4f18-b2b6-156e21330887@suse.com> <7e1f3962-2dd0-4843-8976-40452437a52a@gmail.com> Content-Language: en-US In-Reply-To: <7e1f3962-2dd0-4843-8976-40452437a52a@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/4/26 3:54 PM, Oleksii Kurochko wrote: >> >>> +    if ( riscv_isa_extension_available(NULL, >>> RISCV_ISA_EXT_smstateen) ) >>> +    { >>> +        INIT_CSR_MASK(HSTATEEN0, hstateen0, _UL(0xDE00000000000007)); >>> +        csr_masks.ro_one.hstateen0 = old; >> What guarantees that only r/o-one bits are set in the incoming >> hstateen0? I >> can't help thinking that to determine those bits you want to use >> csr_read_clear() (or csr_clear()). > > Good point, then after INIT_CSR_MASK() it will be needed to do: >   csr_masks.ro_one.hstateen0 = csr_read_clear(CSR_HSTATEEN0, > _UL(0xDE00000000000007)); >   csr_swap(CSR_HSTATEEN0, old); > > Probably, csr_swap() isn't needed as it would be good to have all > writable bits by > default 0. Of course, except r/o-one bits. I came up with the macros declared inside init_csr_masks(): #define INIT_RO_ONE_MASK(csr, field, mask) do { \ old = csr_read_clear(CSR_HSTATEEN0, mask); \ csr_masks.ro_one.field = csr_swap(CSR_##csr, old) & mask; \ } while (0) ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:20:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:20:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245757.1545144 (Exim 4.92) (envelope-from ) id 1vxoxc-0001q6-Fl; Wed, 04 Mar 2026 16:20:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245757.1545144; Wed, 04 Mar 2026 16:20:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoxc-0001pz-D8; Wed, 04 Mar 2026 16:20:32 +0000 Received: by outflank-mailman (input) for mailman id 1245757; Wed, 04 Mar 2026 16:20:31 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxoxb-0001pt-Oq for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:20:31 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ef72ed2-17e6-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 17:20:29 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4806ce0f97bso60915465e9.0 for ; Wed, 04 Mar 2026 08:20:29 -0800 (PST) Received: from [10.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-4851a8ae17csm13993845e9.6.2026.03.04.08.20.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:20:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ef72ed2-17e6-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772641228; x=1773246028; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=bFqecisVfpqlBVF4/cTVsR7G7jAGrW7vwDhM9nM84Ig=; b=ehX+R7OSO7gNeQpDiU/Alk8U/NuwtEArdyZ4QvJCdocr69fBrxJhmaZ9ZuX0F10ewb p3hFKUEryB6OR9OZxTgLPsq3DHA0MTXWGsS+YRWLiWWPbBfa2/mmFxbPFzsxcLU+RRck 1zjJOUzXbPMBdENt+VBC8Mf5KYVaBu1fpdlP2gGD5u8zBINaZCWc1m7xQ2NpSTkbuup5 oi/lhU3JQf+as8Jspr7IYL/KbrHqD0axxeb8mdHlxCAbunbOCJ6pku/RPRFYTJsSSG/M hQ0lQGYyGLDTPUpY/nuPM16jgSyLpsXwuD0o/Fra6jWdpH9XxnALSUNfnMPbhuvL9Exz pI8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772641228; x=1773246028; h=content-transfer-encoding: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; bh=bFqecisVfpqlBVF4/cTVsR7G7jAGrW7vwDhM9nM84Ig=; b=GSxQyy9A7dx20UQkeVciTkUOp2AxOQ8Pb60/9zhke1X3J/lxFnp4SNFD56ukTCfEqo hp1ObdGcL5nLInNAOOi7gf9YhEM9m0i/EiVX/acirPmNAvsxDUBYRNZUy3HXHKSWUdzt TeyC6JgZ5SXxW9kIeKBqoiugrdjk8YRl7CFXx7M5dMrDlmxrEryF5F49lQfBC6S3HbgQ vQ9HDt90514c8zxozhoBnnnC6AZIgNz8n/rVrQNCzE8g6TLU9bXBm0HvbSKmcl3l8b1H To68uFieJJm1pM7HxSI4RhxGeHVUOA552SKia52WS+5NYl4gFfI7zmPpCU9158KCd/nY 79vQ== X-Forwarded-Encrypted: i=1; AJvYcCVHcBazYyM75AjUBRSLcAgYG4BbWvp3DEBgF0ezt4QR4azx9snm2ahDUiRp4FPvWZpXaaQe7rrdEE0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwGc/vaLysWyexSHjjQRi9mxPnOjOS3dSBxYRJCbNeSwcObtbDn x1tnNz/fAilDn+jJAFvyGuFHIG3MI47AggLvibxyRJiojtsHeuSXBXyq4385yo9Jzw== X-Gm-Gg: ATEYQzyXkFeQYGrrVFk8ZLwIsj/an1C2hRKW8q+G8PoYtClVgrMxKfMvlnxErZdXNph 5JgqfPZzLRmNllDpQiMTbXDz3vcXqGJpFlIjC3eB3/U2zUpEYG17wyoM830WkD0YhbS37XmU7Nj eyNTZbME5Oktdl3fG89gf5x2u4d0hXW7ThnSmPML25Wq8wSCAMINTZHSWpMsLYXcGkXV2UlncM6 R7xgERPTHKcV/1I2onXFglAXY/wbgSF8StxM0vm8FedOVB4zbkCb00Qej3QsA2+LQpE9wk+n7Hy hytaUpOQuQhHUsialMlcLcKZhVduyHUZyqrSsTbDASqGdQN7Myn6d9dYWVZdUQ2JNSl8+ha1Sw/ YC0Z6fTf0dy5gWLC7kCCqZv2XpxsZAq2WlpH/a6L3UDgO91HKOziFCx4M/jgBtbeCHTIUUdxoHo mRnpkRS6rDL+gs7dZAdGZriGX2Qe7bEZC9lVPVmgHuTasKgkHV/7Khl4oUIHAzRoYFWinhrzbsX myhcMjHsX45pFQ= X-Received: by 2002:a05:600c:1d0c:b0:483:78e1:784 with SMTP id 5b1f17b1804b1-4851984a312mr40672175e9.4.1772641228106; Wed, 04 Mar 2026 08:20:28 -0800 (PST) Message-ID: <91d2bd4b-7ca8-45fe-9e60-071d2cf2d327@suse.com> Date: Wed, 4 Mar 2026 17:20:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/10] xen/page_alloc: Extract code for consuming claims into inline function To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -518,6 +518,34 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) > return d->tot_pages; > } > > +/* Release outstanding claims on the domain, host and later also node */ > +static inline Generally we prefer to avoid "inline" in .c files. This is better left to the compiler. Furthermore while we have a few examples of this kind of line split, it's clearly not the preferred form. You'll find ample well-formed static functions in this one source file alone. > +void release_outstanding_claims(struct domain *d, unsigned long release) > +{ > + ASSERT(spin_is_locked(&heap_lock)); > + BUG_ON(outstanding_claims < release); > + outstanding_claims -= release; > + d->outstanding_pages -= release; > +} > + > +/* > + * Consume outstanding claimed pages when allocating pages for a domain. > + * NB. The alloc could (in principle) fail in assign_pages() afterwards. In that > + * case, the consumption is not reversed, but as claims are used only during > + * domain build and d is destroyed if the build fails, this has no significance. > + */ > +static inline > +void consume_outstanding_claims(struct domain *d, unsigned long allocation) > +{ > + if ( !d || !d->outstanding_pages ) > + return; > + ASSERT(spin_is_locked(&heap_lock)); Why is this not the first thing in the function? > @@ -1048,29 +1075,8 @@ static struct page_info *alloc_heap_pages( > total_avail_pages -= request; > ASSERT(total_avail_pages >= 0); > > - if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) > - { > - /* > - * Adjust claims in the same locked region where total_avail_pages is > - * adjusted, not doing so would lead to a window where the amount of > - * free memory (avail - claimed) would be incorrect. > - * > - * Note that by adjusting the claimed amount here it's possible for > - * pages to fail to be assigned to the claiming domain while already > - * having been subtracted from d->outstanding_pages. Such claimed > - * amount is then lost, as the pages that fail to be assigned to the > - * domain are freed without replenishing the claim. This is fine given > - * claims are only to be used during physmap population as part of > - * domain build, and any failure in assign_pages() there will result in > - * the domain being destroyed before creation is finished. Losing part > - * of the claim makes no difference. > - */ Much of this comment is lost. Parts have been moved, but I think another part (in particular the first paragraph) wants to be retained here. Plus in general when rearranging code it is best to take the original commentary as is (typo or factual corrections of course included as necessary). Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:31:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:31:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245771.1545155 (Exim 4.92) (envelope-from ) id 1vxp8I-0003dC-FK; Wed, 04 Mar 2026 16:31:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245771.1545155; Wed, 04 Mar 2026 16: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 ) id 1vxp8I-0003d5-BY; Wed, 04 Mar 2026 16:31:34 +0000 Received: by outflank-mailman (input) for mailman id 1245771; Wed, 04 Mar 2026 16:31:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxp8H-0003cx-JE for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:31:33 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9773717d-17e7-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 17:31:27 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-439b2965d4bso3461439f8f.2 for ; Wed, 04 Mar 2026 08:31:27 -0800 (PST) Received: from [10.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-439b4e771basm30370129f8f.0.2026.03.04.08.31.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 08:31:26 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9773717d-17e7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772641886; x=1773246686; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=cho1gBbzdAzbi5aNRaJ7Aduz2iliIVIo2vn0mUgOkJo=; b=KW6nYc4xe+PeGitlnpLpnSAdwSg2ZuxwXKvBDCBZ4sAMjId5L52CaaXNRKiXwokwTc lvNR3+rXZ48Z2w3jBDCoknAFpp3APhF28PNuQQF3OBaLAoQGabWDaauqIkxkJqWOmAtL xJwBKz2/ZIHyseesKBimVZ3h9loz1fOU46ZOEt+B2uswn5dkkmbt/JplJximnoIEUJ10 U3oPMYPKd0NN1Q1adFE+2XAurXH711VdI0iaZQEWo5eL51dTp9YpZoXVBrXZaRT4LCFE ApPPn/8dNsjlYr3jwV3b1URVYGHp7Y9ry7UvH0hVE//d96LpaYqv3pMd30UE4T2rQC5Z J5pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772641886; x=1773246686; h=content-transfer-encoding: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; bh=cho1gBbzdAzbi5aNRaJ7Aduz2iliIVIo2vn0mUgOkJo=; b=vCv/L4dkih5zUrUSk2za+/1N+QqGwBXWN+Ll94GNxAiOng0voxLYAkDaJubL4YQif7 e7du5KXq2S31rOGsFRBoRb912SP6BH3UsWVy/n6zwtS5+XO1mzY7kA5W3M3HNnjc43hS 4uQ84NPDt3chrlN2nNhnOJXFrnAlxgGZdnUS2qzz1U9vUg3AjrfUP9RH7WZBTsyz8IKk q9s4eZh7Rv1CrJFhYiqUGw6UNvfeBoNJYXdOhwYmp9c9qUfZckZfMrA/7/29AYdhDI1I 0Q/bCyWx/1FHiys9GPCfIygz7RkchD0WJAezlAlRYr2mI5cvPXqlvqrf4DwYD2M81i7R xJMw== X-Forwarded-Encrypted: i=1; AJvYcCXBqsBwvoZOa/ezaA9PyGyzoWec+0K53lmwPZAiZ3kX3yqXtI2ltxsHhVXQc1YNWB8VsBCnug/SFO4=@lists.xenproject.org X-Gm-Message-State: AOJu0YxPQ02Lz0DJIsO1T+/3b0Tuh44taK1nCzi1hprfz6iCuzFc5cvp bKYdzVxoQkMcO3vGpdOSah6g9WaNt/dOATwumsBtydGZB3VTJ79tf2Zpwd0xcKBCeg== X-Gm-Gg: ATEYQzyqgejZUAvaC/9kZVb+HUo17XMwnyRJfwlfLBAGzG2ADZTfv7aEelFojjGpg39 OmyT0+WZpab1U5KgbuLi1vwYAkEHXAjcy8Fej3VclNl1764hjWcpDwlSeI94gIkHzGA+PUE75US mGYne+WOgnbAuKBdW5kIRN5qusdEojUcYiEAKhqNSZttYzbgciGuUixVKqRkl2pU+uKdP5P9yDL 04uB/wIKnn5REy6LqeJoueqb0ad4ONF3eagOTEi+rGzPKtXn+diLAPVTTr7ysWLY9hQ/eGf4I3D cuu7QDl8h2D/BFgnR/4KS95NF5qHD6KJLk+cpYK/QY7Hd8Lulioxk4Zyqm3ozX7AcCa/v16aoC1 +8zBB3lw6cgwc96DXbGnqSt9lvO7z/UIwp/jZmA5TayYHXsC+dPRT+han2xztiAol0DPOZr0O/I nC89o/R/CSo07NpCc3mAQdzIj4+Gxytk0CVGekHSkXEhz8H1dr3AGHR6v41Zp0Fe3EYq3T09Djl FuRxHbA52UtB9g= X-Received: by 2002:a05:6000:1373:b0:439:ca9b:1f61 with SMTP id ffacd0b85a97d-439ca9b1fe5mr2735480f8f.17.1772641886481; Wed, 04 Mar 2026 08:31:26 -0800 (PST) Message-ID: <5e4d4674-1e1a-4902-bcd0-a24fbd13dc8e@suse.com> Date: Wed, 4 Mar 2026 17:31:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/10] xen/page_alloc: Optimize getting per-NUMA-node free page counts To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > From: Alejandro Vallejo > > Add per-node free page counters (node_avail_pages[]), protected by > heap_lock, updated in real-time in lockstep with total_avail_pages > as pages are allocated and freed. > > This replaces the avail_heap_pages() loop over all online nodes and > zones in avail_node_heap_pages() with a direct O(1) array lookup, > making it efficient to get the total free pages for a given NUMA node. > > The per-node counts are currently provided using sysctl for NUMA > placement decisions of domain builders and monitoring, and for > debugging with the debug-key 'u' to print NUMA info to the printk buffer. > > They will also be used for checking if a NUMA node may be able to > satisfy a NUMA-node-specific allocation by comparing node availability > against node-specific claims before looking for pages in the zones > of the node. > > Also change total_avail_pages and outstanding_claims to unsigned long: > > Those never become negative (we protect that with ASSERT/BUG_ON already), > and converting them to unsigned long makes that explicit, and also > fixes signed/unsigned comparison warnings. This wants to be a separate commit. It hasn't got anything to do in here. > This only needs moving the ASSERT to before the subtraction. > See the previous commit moving the BUG_ON for outstanding_claims. Please can you avoid such statements? You won't know in which order the patches are committed: Patch 01 may go in weeks or months before patch 02. > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -483,11 +483,32 @@ static heap_by_zone_and_order_t *_heap[MAX_NUMNODES]; > > static unsigned long node_need_scrub[MAX_NUMNODES]; > > +/* avail[node][zone] is the number of free pages on that node and zone. */ > static unsigned long *avail[MAX_NUMNODES]; > -static long total_avail_pages; > +/* Global available pages, updated in real-time, protected by heap_lock */ > +static unsigned long total_avail_pages; > > +/* The global heap lock, protecting access to the heap and related structures */ > static DEFINE_SPINLOCK(heap_lock); > -static long outstanding_claims; /* total outstanding claims by all domains */ > + > +/* > + * Per-node count of available pages, protected by heap_lock, updated in > + * lockstep with total_avail_pages as pages are allocated and freed. > + * > + * Each entry holds the sum of avail[node][zone] across all zones, used for > + * efficiently checking node-local availability for allocation requests. > + * Also provided via sysctl for NUMA placement decisions of domain builders > + * and monitoring, and logged with debug-key 'u' for NUMA debugging. > + * > + * Maintaining this under heap_lock does not reduce scalability, as the > + * allocator is already serialized on it. The accessor macro abstracts the > + * storage to ease future changes (e.g. moving to per-node lock granularity). > + */ > +#define node_avail_pages(node) (node_avail_pages[node]) This isn't really needed when ... > +static unsigned long node_avail_pages[MAX_NUMNODES]; ... it's a static array anyway. Plus you may want to talk to Andrew regarding the use of such a macro as an lvalue. > +/* total outstanding claims by all domains */ > +static unsigned long outstanding_claims; As you touch it, comment style wants correcting. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:36:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:36:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245780.1545164 (Exim 4.92) (envelope-from ) id 1vxpD1-0004DF-Vw; Wed, 04 Mar 2026 16:36:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245780.1545164; Wed, 04 Mar 2026 16:36:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpD1-0004D8-St; Wed, 04 Mar 2026 16:36:27 +0000 Received: by outflank-mailman (input) for mailman id 1245780; Wed, 04 Mar 2026 16:36:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpD0-0004D2-5e for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:36:26 +0000 Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azlp170100005.outbound.protection.outlook.com [2a01:111:f403:c005::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4866cd05-17e8-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 17:36:25 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SN7PR03MB7273.namprd03.prod.outlook.com (2603:10b6:806:2dd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 16:36:19 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 16:36:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4866cd05-17e8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fKcYAA+D8JUD5AHwq7nRbGmB1s+whJBWBlhlNVSThmmzPS3bAOdj0RZhw0Zi8iG1CexOqipy1n+W4tkAD9l8FnjOBdJSxDT+qkKTssdmjJGeGBsI607C81i8gTI5jFfUD3PPwqIa/pd7MjK4tftnlgA5lcZuIIWiDgV5amuxMFAAoAO2e7kcqTs9e8IfGsgYGodNUyrgahv4wseGbs2f/pzcWW5InjyFkKHNO+qFGNY+jDc4M3LtQUqFLIPCgBQ4oWI2Dc1XTd/1JEl3KXpAqTG6Dc7kRSalHDy6cXJ1DxwC7v77v4hISizeUL5idXwNbciOROAQTCR9l3246KgQag== 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=6SWCLNezxbk11hmU1qh7DwEJLZHtpZYGIKiOyFAD5Gw=; b=UQBcuycomfcIDcbli509qePiv5soibYPov6TWs5amsW5oBlIJFi5TQA0cGIfwAYRKmAhsNR77sQ3HPFGraT6l7QD9YMpKDyI4/jeQM0E0HMkYBLGSQ3lwrJblhRcE2+OtgJ6UTLKgUZFDLa06v9Fceij2H8iC3goF4yBoL+UDxaD6mhhh2CFt+PGGaNbQsrwQa4NjuEdYw7kMKgTYreaNzUYAtJ1jZUHusVqi7l8UNG3Q7+eJXZ9UpLEku5Rywx8SnXMc1Zvgu5x3NagZtV9LIRoB1Z5odykpEbrIlDoCMp/WgKHDD5KkOFziqrxxApelloAewC9vZ/kK1VhAFbYeQ== 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=6SWCLNezxbk11hmU1qh7DwEJLZHtpZYGIKiOyFAD5Gw=; b=ZcrnmMYh4lRQEFexwn0U+HVjkh/O66Ly6nUe2yRNNEz4OL6qcItLjSSnbWjWhkPufZjdnv+aCxySWAb2uHYU/Wdq0eMfnKXmxLw/e7+BdoMNJEkY8umHBV1iKNRoveYGw8UYEs9ip6wsaCNJtUGI5fcDpU6oXJSxz1s6UKdSGqM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 17:36:16 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA3P292CA0069.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:49::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SN7PR03MB7273:EE_ X-MS-Office365-Filtering-Correlation-Id: 0e47eac8-9b1a-48a4-fef5-08de7a0c299a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: jDmISeA4FiRzJq6CFzWI+1iJ0FDPtRctmyqMbv9oSh4oJ5A77pq/OsrYgiMkwQe3UQjYVZTro8M+8g7yQ66zlcYXkzhRIzK/s2cNIGfdz2vKX81Vbj6AIS/7yaEw/PyZ8zUrequSzZao+3L+HAsJ2bblnl0mI9+Ks5MDS+btO91JLgugZbbS2xYsTFjDsvKuzlQWZqq4EOUieqI8tlq+P29eayoSAeXHPq+m9kcy/yAVLqQ3JzDGP1rA9j7vh1ngjmbFu8mP3qz8axQx5oG3FqPa6YzNtgZUOJTtO7Y4TMqK4sVzHUKPNXFpXmq3y8D/mcP3uyKWOQDnQ6Iq2XjYG2N6OoBm9zGLrkOM0tCDILDdXj2qYOhFPobUrXfyWvHlucbtotoNgFc1DJeJhKiKdtSok1gUmEauk5cgfg5TH6ZVV2fM7w4gunmMTAJ4kuHFBcyK71mBtEOYdif9Rjxk22/nxP4Pm5QJ+6lJ/VhFyNctI+BLwMdByv4mJtRyJHZn5/rZ0TxQTGgZFSXHvIhC3VifDauqzhsAU+cY57G1qYE8gqmX9B0Xo5+bZ+yxgsWaNU2g0lVQhU6Uad1SHqn2YoAQ5/5nIaU11S7Zk5bA9eJ/zZinpBowdC4ucs/5P+VjWa/ertAy109P4tnLaL1kZye/4kM03+jj7NN5ASJVUTpcdE8TCh3kjRmPZ+w3nZ4eTP9S6TrPTc9aQtTxZSkYkpBLQ78h97bJXrwUXDWzqBE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?amxUSVB3RzhxRHIyUEpRdU1nK09id21sNDBGeG1VL2NCdVluZjlGeE9QNEVL?= =?utf-8?B?ZUZRWWd5dHFoUVBsM2UwM29WZGFZWEZWS0loM1MyWHJYSmJVSUtkcGxjRkNO?= =?utf-8?B?Y2NrNFpQTENkcUUvQll2MkUxSGxYV0N6bTNEWmR0MUhTY3VvaDdRek1KQzJn?= =?utf-8?B?R0pXS0kxdzNwdk9UcWFFYnkwdEhaT1VpaGcwWVpac2I1a08zeHJJd2ovaUQ2?= =?utf-8?B?OUJyRU50dGNSOWtFeFl1NSs1MnhLd0c3YUhVanBxdmpNY2JzWC9GL1FmNGZR?= =?utf-8?B?bzNpeWJCbzBINnE5NTk1SnNSTVBvOTlWQXBRZEhtRVVlVi9pMHR3OVBGMnZL?= =?utf-8?B?eCtleTFRM0lKZ2huMWpLK3lkZVpXQnBIOWZFMzRIR0JyNUIrelRqYWJJeDdF?= =?utf-8?B?OE82YzUzaS9tU25vbG1jTGFZMXZhcGVTTDB0TnlQUTNGeEY2T1hySWJuWnlO?= =?utf-8?B?ZEtrNXp0ZWIzaFFkb25iN3owTlVTK3VTMVp2emc0cEJLR0QyZ2RqQnlZU0Ew?= =?utf-8?B?eVhGek4xUEZnNXhHblNFTGxqdS9iZ2YrbzE0NTdHbzltVzJFRU9TYmRFeDJ0?= =?utf-8?B?NzJCYm9nMTVGUEE5WmJ0MTY1VXlUL3UvWVByQ3lyS3g3c0UrSFRrMHFXRlNT?= =?utf-8?B?d015dWtIRWdEaFJXOUJQREhSdnRmeTVWeHN5Rmk0V0E5SmVCSnBORGorNkx6?= =?utf-8?B?SThvSTJ6TW5BSVNzQjZVejBhdmErNVI3RzV1ZGRXSDRvNjU3QkVhQnFJeGtN?= =?utf-8?B?NnkzZ3NZSTRhTCtRcGN4NW01em54Y3orYWxMZkpzTEZRc1hJbHNFQ2k0ZlZY?= =?utf-8?B?R29TTFBBbzVoSUhyb04zekI1RVk0SnBLL2NxaS95Qko0L2gzTklQUGE3VlJl?= =?utf-8?B?RTN2TXJPTlQ0dVFkSUtqN3pUV250YjdJN0IyUGpndFZpdGwzZi9UWUE5cjBF?= =?utf-8?B?bHY4cDVFL2xkeFQzMVhrZUtYUlBINWZXWFg3cHkxWlpCYmZITlVDK3J2NExE?= =?utf-8?B?M2VYY3ZoVTZTeXdUMTJxbk5CR0xjY2gyTFVmWlZyekVuamZWRXptYUhVV0N1?= =?utf-8?B?MFZINmNuSC8xT2xOQ1pCczNhQmFvbjZielNUTFRBZ29Ha01DaHEzMjdYRGF1?= =?utf-8?B?QzVIWisrMkN2N0tkZ2d5K1NBS29XR0t4TU1IQWpyR1doUGluK0ZpK2hGbEdr?= =?utf-8?B?SzdIcy9wRmxQK09NSEwzdmZ6Mk80T2F3ZXNPc3pWa0JrNjJ3Nm1ma2F2U2di?= =?utf-8?B?MTJieVFIeTMyeERKZ1F5WGdXcDJ0VmQ0Qlp2L2E2TEYwbE1GUFVrQzR3cnha?= =?utf-8?B?b1hhOG5odURQWGluUFAzZVE5K1F4T1FSdzk5SEJBWWg3eVNlOGkxWHArSW1k?= =?utf-8?B?OFRtMG81eVFOb2psWERWbmVFUkJZZHVzYWtyUnVaR0svbEtJRFBxTk5OQ1Ru?= =?utf-8?B?ZnNPVWNuU3NuSHdBNktaeWNDdzN5anJ6TXhic2dLMk1ueDJqREEyZjlWdjdI?= =?utf-8?B?OXBiMitoM05PajRSRzZTdlEzR1pUdzhuMWtBUzhHd3NMdVd3cllxZ2FidEwy?= =?utf-8?B?TDJDekk5SnkvdU9JTDdDN0dKZFJSMHc2WktBS2UvYmJ4dFFjUU8yRkR3Umo4?= =?utf-8?B?TzF2RHlLNEp2V1hndHRlMStiN0xFbjczT2V2ZVJ4ZTRzeEZQL3FwdXpWVTRn?= =?utf-8?B?djJsU0NWK0l4bEgrVWxycC9wUU9YanNFWXJDdmZzN0pwM0ZjZGQ5TW83MDRE?= =?utf-8?B?KzJ1Wk5jT2JCRll0RE9HclBmZUlYbFpGdlEzU0VTNDZBZ2orLzNVZWlzTS9O?= =?utf-8?B?QW9YMUNldHdQV01INitYa2piSml6UE1xaGIyd0VWMWozajJJVWhMR3I4MWNH?= =?utf-8?B?K3UwcEQyZnZETmcrWURSakpya0EvaGwvaGhtNitnZStyZnFDcUd2OGlqOUxn?= =?utf-8?B?UE9FMVU5bCtOTlJVajRKUHViNjVKZ29yMkhaRzlMSjhVRnlQeGdBTFAvTzRv?= =?utf-8?B?M3FSeVE5eCtDOWszbVFqemVkc2FqQlNmTkJUTXdsWHVqek1GbkRJSldlQjRI?= =?utf-8?B?WnpQMVV1c2g5QXR1bUFVMWtjS1pkWkdzWTcvUmJBdndpTnZDUkdWZFUrTisx?= =?utf-8?B?NDlMK0F5bXI3bC9aU0IzWDkwUU1NWDJ4YUlRcnZYYi9Sdm96MEhqbjdZY3Jj?= =?utf-8?B?NjA2RWgyVzA4Y2FQSTlpT1JLNkMyS2ZLUS9oNjkzMFFqREFmemVRZ2lhZStl?= =?utf-8?B?MTZ4dzg0bzAyYlRIQkJlb3QxQ3RRSXJ5eFI4MXBTeTNKckhoNmJUWitnQ0Fh?= =?utf-8?B?WlBHMEptakRvU3BoRmdxSEpGRWJMcFNoZHJMdGFncnpTVG5KbHBqUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e47eac8-9b1a-48a4-fef5-08de7a0c299a X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 16:36:19.1496 (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: /40Lrc5lOmIYe9Qn6kSDZcoupmzxYaAzM055FcgG+RUQubzIwAcwhEC/RgVHNkNpEt7hcni4ZuFkGP/uqACp+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR03MB7273 On Wed, Mar 04, 2026 at 03:37:25PM +0100, Jan Beulich wrote: > The treatment of ACPI_PDC_CPPC_NATIVE_INTR should follow that of other P- > state related bits. Add the bit to ACPI_PDC_P_MASK and apply "mask" in > arch_acpi_set_pdc_bits() when setting that bit. Move this next to the > other P-state related logic. > > Further apply ACPI_PDC_P_MASK also when the amd-cppc driver is in use. > > Also leave a comment regarding the clearing of bits and add a couple of > blank lines. > > Signed-off-by: Jan Beulich > --- > Including XEN_PROCESSOR_PM_CPPC may need accompanying with some change to > arch_acpi_set_pdc_bits(), but it's entirely unclear to me what to do > there. I'm unaware of an AMD counterpart of Intel's "Intel® Processor > Vendor-Specific ACPI". Plus even when the powernow driver is in use, we > never set any bits, as EIST is an Intel-only feature. We possibly never need to set any bits there for AMD, as those _PDC Processor bits are Intel specific? > acpi_set_pdc_bits() having moved to the cpufreq driver looks to have been > a mistake. It covers not only P-state related bits, but also C-state and > T-state ones. (This is only a latent issue as long as > https://lists.xen.org/archives/html/xen-devel/2026-02/msg00875.html > wouldn't land.) > > --- a/xen/arch/x86/acpi/lib.c > +++ b/xen/arch/x86/acpi/lib.c > @@ -124,6 +124,9 @@ int arch_acpi_set_pdc_bits(u32 acpi_id, > if (cpu_has(c, X86_FEATURE_EIST)) > pdc[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP & mask; > > + if (hwp_active()) > + pdc[2] |= ACPI_PDC_CPPC_NATIVE_INTR & mask; > + > if (cpu_has(c, X86_FEATURE_ACPI)) > pdc[2] |= ACPI_PDC_T_FFH & mask; > > @@ -142,8 +145,5 @@ int arch_acpi_set_pdc_bits(u32 acpi_id, > !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) > pdc[2] &= ~(ACPI_PDC_C_C1_FFH | ACPI_PDC_C_C2C3_FFH); > > - if (hwp_active()) > - pdc[2] |= ACPI_PDC_CPPC_NATIVE_INTR; > - > return 0; > } > --- a/xen/drivers/cpufreq/cpufreq.c > +++ b/xen/drivers/cpufreq/cpufreq.c > @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ > { > uint32_t mask = 0; > > + /* > + * Accumulate all the bits under Xen's control, to mask them off, for > + * arch_acpi_set_pdc_bits() to then set those we want set. > + */ > if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) > mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; > - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) > + > + if ( xen_processor_pmbits & > + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) Currently the CPPC driver is AMD only, and hence when using it we don't care about filtering the _PDC bits, because the ones Xen knows about are Intel-only? As you say, we likely need some clarification about whether there's _PDC bits AMD care about? Linux seems to unconditionally set bits in _PDC, so some of those might actually be parsed by AMD. I think we might want to split the setting of XEN_PROCESSOR_PM_CPPC here from the addition of ACPI_PDC_CPPC_NATIVE_INTR into ACPI_PDC_P_MASK. The latter we can possibly untie from the questions we have about AMD usage of _PDC. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:54:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:54:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245802.1545174 (Exim 4.92) (envelope-from ) id 1vxpU0-0007Ht-G9; Wed, 04 Mar 2026 16:54:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245802.1545174; Wed, 04 Mar 2026 16:54:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpU0-0007Hm-DK; Wed, 04 Mar 2026 16:54:00 +0000 Received: by outflank-mailman (input) for mailman id 1245802; Wed, 04 Mar 2026 16:53:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpTy-0007H9-Fx for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:53:58 +0000 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azlp170120002.outbound.protection.outlook.com [2a01:111:f403:c007::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id bbb0e46c-17ea-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 17:53:57 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA3PR03MB8476.namprd03.prod.outlook.com (2603:10b6:208:546::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 16:53:53 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 16:53:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bbb0e46c-17ea-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fdVBYAyJdRj31I0gjIBPhXd5LrJ8rVyrm3Ysj+KEE4bUCeRMMQsxlj2Ekp2rPEIKa0dP5OhsbHXyY4ctj3eKOHUrTj7SWUkkyJ9W0C2at0MpBy6OEzpZEhloZtEpwETHJ7fpQsjN1pbeyAmBpd7RWBjQ3IvXXmZwHIHYFQWodBSnjot7PSjyj12Cc4g+MpGqHciBTBijKz//UreDyn1nh3G/nQidve2SFdtDbXtkliRRie31EuCpTYCI+RY56xpj4byCb1pkW+klDBmoxUEW0XAGeypVMmvdqmD4i4LIyY5SLbNIhrI+y95n1YAnUoW9WYCX/UTQmYssAHP/DHH17A== 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=MN/AJP09JF9qcdDot8V4nIdKNZMqeXmKBDo6YqcnPAg=; b=KSFQCF2QbrC7efb/DH1kFj+9UjooyGwD7SGXQEAdRJfFYpCbxzSf8rkbCmXtVJkYSYi/yyVEnK37m+pgLsUjwMpHrY6X/1o7hZAlygQxxaxsaRwwLZhwGxzQdZZrFQf0J9W5FG0GqB1XA7nxsDzfNAXVvKQDJj1ed5+ErgVKd9ceaTTrZImcAUBBeQrwZ9J7E+5SYyyZQqkjf0tj/CR2FGuCU5mZrnj4wIYDexpsC/H0mhxIeyU109cLUf0S3a3wmopILvAiGjKp8qDAdo8eOxn2xTPi8BpsfKlCq5Rt+G7mSXgVTynzHLStlkdK97IzFm5thHMt3w3eh/8Ls1yhfg== 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=MN/AJP09JF9qcdDot8V4nIdKNZMqeXmKBDo6YqcnPAg=; b=WPc2Zb+9a7cKlyqp4Jhb/Uikym3OsE4/M2rihJr6NQqFDN5UbAbBYPK13qSbcLQ3PVgTjcmmy9UG6pJ7xX4qZ2FqFDGBTowp7UufkAb+FkZi2OlRc8c7pbkDizXbEVMfveEk3/usf1Cp17Y2WBys07nihVlNqYOE+B3NqhGxim4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 17:53:51 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <7d7b75b7-80c4-4c23-8678-b33f4c90132c@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7d7b75b7-80c4-4c23-8678-b33f4c90132c@suse.com> X-ClientProxiedBy: MA3P292CA0035.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:46::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA3PR03MB8476:EE_ X-MS-Office365-Filtering-Correlation-Id: b09f8084-0e64-4739-83eb-08de7a0e9e37 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: wgRpl+wdmujDYp24ilGJbqJrD4NhOzrlY3k75rIhJgB+4ipBsjBt8fFiHud+nXlwlEFt0X1+pKdRIq7QPU7i8LMz+10UzUhvWE/8sAQBF+b/FfPYjwoZtkgsOHs34KWl9OdeqsyWeLwPW2PSq3SoDUXWaoBfJfCSt6Zj0/fO25FEq/QSfmm7mJhnEcIcoNoM1DCLRWEeQ4mkBveLDosKtmGrbOBQ/kpNOea4W5RXIrd67MqTXuIxZiF49mVB6jtoKRstZOnL3d2VXWPoXXvtiNEBUyNi6Ibwt5HQeHa0EkoaEWE6BlJOA98+dtGNkshu4687oJOWj3heKOh6rKvlUgE/CBlJzr+liP6w3mhIlknqyAMqD/ELbsMNyO9tWGrtIWEbbEBszWG8hVCzul4TGWgRxLAlx3w8NCR9/LVkLzz5A0frI+OquE5vVbexAAg6PyOxqu9RvOVVTS5eI/ixZqhiRHwNPpqFla5pi3CNQrpfCka0gTBZ8vl8biJPHTP5lusybmPbDqZn9Cwcpj0eYE5QHHvEC4Wj5rff3Rs20uGWXSYQBprqLhTgOkMgx29Eey+bMvgxRYsb6oEpn40RT1hWeYhXACkz9KWp95ltdDrCzUpSc1ixyogkCun4ZJ9gJ1vWAXcJXug4FD93sRUEkezhO6aZYQFf+sKAyDyLjrIx9pimxHbX8DChseKw7shL7EfWqg9XburcGLEjW/a4+l7kE85dEVES6lON2Lw7MYY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RVZDUCtzd3VOS3duaW01MXdaaTBHVEpnQXpvSFpkY0hyU2lEUCsza01SSkZ3?= =?utf-8?B?eDF1bmJuR2FkQXlCbTFBRTJhRncwQ3RHNlpCdGtIUHFkSkUzektTK2plV3po?= =?utf-8?B?cW9DM1cxQ1B4VzA4SEwvQm03eHBBUkFuK1I1VnlzTnFUcFFqRlJmYTczcUFn?= =?utf-8?B?TDJvYk0wbUZSQnM5MVJzZUpNQjhzdDZzMmQ5dEd0YjRHcjBLLzZBV2FTNTFn?= =?utf-8?B?czdPYkpCRThiTlhSYXRjZk1ReTVhbEZwOExvUm90UGpPMnljNG5oM3pVWmZJ?= =?utf-8?B?UXlmYWd3ZzJENGJ1RXQ2ZUlJWXVIT2trWkVZbERPV1ZaNWVhYWM1STdrTDBK?= =?utf-8?B?YlYyWnFaTHFaaVl4V2tGUEtxanArdXZNRWwvR0EyK3QzM0tWbHk1YVNYWmlF?= =?utf-8?B?SElJQkVqTHZrREJwOVR5QkdGZUZHVEQyS3pwbHpzenBqVXJHWVRRTHdaSk5J?= =?utf-8?B?WjRIOXZ6RnY2bFd5dkhzSW9lTjN0K0xuYmxWMVZScDNDWWljZWRtOW4rZ0x3?= =?utf-8?B?RlVUczh6Ym4za0Y0Uk4rU0VNSmcvNlYwZHE3MDRUUWNjbzhpMG56akh5YWZV?= =?utf-8?B?MnpKd25wWjhZQjdScEN4ckQ1bTZsWFRLLzh3Q0ZTVFVkd1dEdjUvRWE0VlNR?= =?utf-8?B?N214RE14bXN6a1Z3Z3VpWVVPeS9ZQWV1SFl3ZkEvMjM2WjdyL3FtbWRwTVE0?= =?utf-8?B?ZlVxaDdsR2FZclRjQkNiOThQdm55TW5GaFdUMkswL2hESUJZcG1IeVBrOGkv?= =?utf-8?B?K09Sd21tZDZON1FHVFBXejNRYjFZM2lLUjAvbUl1MHhCbW5FWWV1Tk1NVTdy?= =?utf-8?B?MjFDRVpoYW9wRXJwK1MrS3NYN1hVeG8yQ2NnMStPS1ZzSlJlalN2TXhFcWxv?= =?utf-8?B?ZUEyYllKanIvK20zMjNNL1Y5RnNHYnlUWkFNQlpFZ2x5M1l6RXhSOTZ6dlZO?= =?utf-8?B?MlBFc0ZLUE9WR2hQZzlib3h0bnVVbkhZOVZUN3l3eXppbUFOby9SMlRxRWFt?= =?utf-8?B?Y0xKNlA0RUlHaEZweVVaVnhwc2FXSzZNbXZkdUdWcGdlbzhZQUxaSDY2NE1t?= =?utf-8?B?a1crc2hjNVVkaXBKeFBWb3hKQzgzM0QwbmtJR3E0SUk5SVdrQ0FQSEFpRGZm?= =?utf-8?B?Z2tKVG5HTUg1VWcveDVrSGlVWWxPb0FuRnBLc29wV1VjWDNzTnBTZGNXSGY5?= =?utf-8?B?S1dTWHZXdlNGcGJBOEdrRkx6dDRMRFhZMEdNOVRxWXlIT01lb3NNbERPL3Bn?= =?utf-8?B?dHpaQ3FBRG1TbnRmc2lGRmdPekNOVEsrZXNNakZIc1Z0eCtlZGtUSmN1RmVC?= =?utf-8?B?NlJENlIxWEhtYTNiN0QrLy8yMzNpbjJrRm4zTDlnS3JzNzlGelFQQTB4di85?= =?utf-8?B?MUczajI3UHdNYkRHM09DeXpTSSs1dSthM1ZPWnBBMGJNc1NNcHV1aDBpTE5o?= =?utf-8?B?cHZIK0F2SjRjMTFsMW14Nm9CN3dXS0dGU0lMZHNPUGdyVm9SS2dVY092N295?= =?utf-8?B?LzJmbVFac2xUWGt2SEZMYVBKOWJVWVJDMWkxMFhVelFOd1MrR0NZUFFWc2tW?= =?utf-8?B?em9Db2gyQjIrWUpOeXQyOFdIanRlQ3JZSHV1ZW1pK2NrMEFwdjgzVXJHNGxa?= =?utf-8?B?cTNrT1dQcGNhWjdvbHdrVVNiWEdhSEdwSUY4ZE81aVdJZmRGMzduTGpGdlJM?= =?utf-8?B?aXlnRW4vSlh1c2xOYkdXWm1MYStBamhFMDVzemlUTzJoQzBQc0ZyOGFUaGdK?= =?utf-8?B?MTJodVhLUEFJZlVGbFd4SnJvcklPN3hmN1JITmZwOVRiejVGTnpkRzIrYk9y?= =?utf-8?B?YTJwODVsUW00OEF2VHl4MWhyVDltT0NYVVB1RWpFTXg1QzBSam92Skx5Qmd3?= =?utf-8?B?VC83RjVYWGhzZlQ4b3J4dHA4YmZ5TmttR2Y0eUJGTG85b1loUjZlUDFqQzJp?= =?utf-8?B?eFBqVlJ4cUNUb2ZTV0s5bXFJeDhhT21HdWllY2xqREhEN2lMUGQ1OCsxMkJO?= =?utf-8?B?d0FHT1hYekxSOVNsYjZ5S3ZBNjdpaSs1L3NxM1lZWFhiU3VERm9HVk0weXYx?= =?utf-8?B?MkJDbW8zYk04RDhGYnljbDNaUjVDZ0pvdnAvSWkzUm9BOHhGMlp6UlJjNzJU?= =?utf-8?B?YmpRWVg0ZFVqelpLK2R6eGh5ODgxWkkyTUFTZXRsVkk2Q1JaRHMzaS9aRSs1?= =?utf-8?B?M0ZWSVVTZ3BPK1RDbzcyeHIyVjF4S3BpeXZ0VVZtTTIzOG9HRUJ0alJEUi9Y?= =?utf-8?B?RzAyNXJIRjVLcHU5TkF5T3h5TFdOeWFIZ3FzVno3Q29FQUcrTStnTEdhTVZF?= =?utf-8?B?SXhKNW1NL1Fib1hZOE1Rdzl6dnRuU3Y4akh4R3E1OHRXV2lLOHBQQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b09f8084-0e64-4739-83eb-08de7a0e9e37 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 16:53:53.7582 (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: +WaU6RvYQAxe/ymTzso8hUAGTGWo9j3lnrR8HVAWGZyoW9vn1QSB6gJYc/UZGxmbQ2Qj/1yLjjFkjTdWETzlGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8476 On Wed, Mar 04, 2026 at 04:39:00PM +0100, Jan Beulich wrote: > On 04.03.2026 16:06, Roger Pau Monné wrote: > > On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: > >> When Dom0 informs us about MMCFG usability, this may change whether > >> extended capabilities are available (accessible) for devices. Zap what > >> might be on record, and re-initialize things. > >> > >> No synchronization is added for the case where devices may already be in > >> use. That'll need sorting when (a) DomU support was added and (b) DomU-s > >> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > >> > >> vpci_cleanup_capabilities() also shouldn't have used > >> pci_find_ext_capability(), as already when the function was introduced > >> extended config space may not have been (properly) accessible anymore, > >> no matter whether it was during init. Extended capability cleanup hooks > >> need to cope with being called when the respective capability doesn't > >> exist (and hence the corresponding ->init() hook was never called). > >> > >> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") > >> Signed-off-by: Jan Beulich > >> --- > >> vpci_reinit_ext_capabilities()'es return value is checked only to log an > >> error; it doesn't feel quite right to fail the hypercall because of this. > >> Roger brought up the idea of de-assigning the device in such a case, but > >> if a driver doesn't use extended capabilities the device would likely > >> continue to work fine, for Dom0 this probably wouldn't be quite right > >> anyway, and it's also unclear whether calling deassign_device() could be > >> done from this context. Something like what pci_check_disable_device() > >> does may be an option, if we really think we need to "break" the device. > > > > We may want to add a note there, stating that we have considered all > > possible options, and hiding the capability and hoping the owner > > domain would continue to work as expected seems the less bad of all of > > them? > > I'll see what I can do. > > >> The use of is_hardware_domain() in vpci_cleanup_capabilities() was > >> uncommented and hence is left so. Shouldn't there be a DomU-related TODO > >> or FIXME? > > > > Hm, yes, possibly. I think limiting extended space availability to > > the hardware domain only has been done "just" because we have no > > extended capabilities to expose to domUs so far, and I don't think we > > even setup the extended capability list in the domU case. > > Considering how many things there are to be done for DomU support, I > think it would help if every place where e.g. is_hardware_domain() is > used only as surrogate would be properly annotated. Or perhaps properly > named predicates could be introduced right away, so one can actually go > hunt for all of them. Then again is_hardware_domain() is also something > one can go hunt for. I would mind having more concrete predicates, even if right now they are some kind of dummy checks. However it might be difficult to formulate those know without having the full picture of what domU support requires. > >> @@ -349,22 +352,23 @@ int vpci_init_capabilities(struct pci_de > >> return 0; > >> } > >> > >> -void vpci_cleanup_capabilities(struct pci_dev *pdev) > >> +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) > >> { > > > > You could short-circuit the function here, ie: > > > > if ( ext_only && !is_hardware_domain(pdev->domain) ) > > return; > > > > But I'm not sure that would simplify the code of the function much? > > Likewise for vpci_init_capabilities(). > > Such a short-circuit would need replacing / dropping once DomU support is > added. I was hoping the chosen arrangement would make for a little less > churn at that time. I'll listen to your advice, though, just that the > question gives the impression you're not quite sure either. Yeah, I wasn't fully sure. IT would be nice if we could add those short circuits now, and then once domU support is in place we just remove teh shortcuts and it works for domU also. But I fear more changes will be needed anyway, at which point the short-circuit is not that attractive to use. > >> + > >> + vpci_cleanup_capabilities(pdev, true); > >> + > >> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, > >> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) > >> + ASSERT_UNREACHABLE(); > > > > Ideally this would better be done the other way around. We first > > remove the handlers, and the cleanup the capabilities. Just to ensure > > no stray handler could end up having cached references to data that's > > been freed by vpci_cleanup_capabilities(). > > And maybe not just that: For the hwdom case cleanup_rebar() adds new handlers, > which we'd wrongly purge again right away. (Because we pass "false" for "hide", > this isn't an active issue right now.) > > > And we should take the write_lock(&pdev->domain->pci_lock). > > Now this is a request that I'm struggling with some. I can see that callers > of vpci_{init,cleanup}_capabilities() assert that the lock is being held, yet > it's not quite clear to me why that's needed. Shouldn't vPCI internals all > synchronize on the vPCI lock of the domain? Right, the callers of the handlers already hold the locks, and the removal of the handlers should also hold the locks. The point of taking the d->pci_lock is to avoid the device from being removed while there are vPCI accesses against it being done. The vPCI lock is fine for vPCI internals, but functions that deal with addition or removal of devices need the d->pci_lock to avoid races with possibly freeing pdev->vpci while in use. I think you are right, and for the usage here (that doesn't add or remove pdev->vpci itself), the internal vPCI lock should be enough. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 16:54:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 16:54:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245808.1545185 (Exim 4.92) (envelope-from ) id 1vxpUZ-0007hC-Oe; Wed, 04 Mar 2026 16:54:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245808.1545185; Wed, 04 Mar 2026 16:54:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpUZ-0007h5-Lg; Wed, 04 Mar 2026 16:54:35 +0000 Received: by outflank-mailman (input) for mailman id 1245808; Wed, 04 Mar 2026 16:54:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpUY-0007fV-Ba for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 16:54:34 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d08a7dca-17ea-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 17:54:32 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA3PR03MB8476.namprd03.prod.outlook.com (2603:10b6:208:546::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 16:54:29 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 16:54:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d08a7dca-17ea-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yi1nqTE2m9zIv2CAm++COvJmPlUuCsmb38rM7nyAhjF4pB5pJZyHZTwHq17iNYEyNb26X6ZCrgJ6eXRD6bOT3YZdtEPxMEVJnpii+qehbP6EXokeYxzeNyq5IziVh7OtLoD45uoTiX7CQE4A069907dnEER6sn2vPkJoHe/kWd6RtuN5vWOvOHpgPurqLSJODDxRMraKmZkkhkUkMZmDc4ADPtIk84bWgRzoo4mRxr80z3Kg6iaZOYGJqAxsua9nzeMRxoPr7MkjKINZ7vbsZXgjIUqLDveim6vbSZ8UU1pYth1hUE9lD8KGx2kB+5KCSpfN+TW3UmYCiAxRtriaKQ== 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=uC7NLkYgKm3Arkz4reuBJQX25+4AxfjyXOCHSyXKcG8=; b=EcN5WfLSWybXB7sWPqWJisrTbeIAO//SRLqTaM/q+3EWGJ2SrdAH9GbweU4B5W7wkiWCbLyHT75crXpZOiXhYMPGyLStewUGfcLv+9MtLK6ZoqzOLEf70RlMdq7Ra+rrgnFMEAaug9bKfFA1DOOlqSvvR4tfcLNpRm3xz0F3FaadpXhsrgBwP+xWrnVgiJgzDYAKGC5JnqRSjRA0mKFDCUUwIeRb9YVj1IkOJMmVr2W6Wc4cBAPUgrO29/cV3qLRJh6qcComXQVnAGY68jHHodl/BkE7vzvwDLuhlRhhPwVZo1NdZkh2gYkW2xd9rvfouaz308FHJhQYA+TbFK37pQ== 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=uC7NLkYgKm3Arkz4reuBJQX25+4AxfjyXOCHSyXKcG8=; b=FtzaX+bU8ibBaJpo4WRPm8/LrzcIAcIYZ9+3nDk+w+Iz9wX+2lfP2aTR0Cyp7FwsxR52imyiEsCyTssxJdJSFK1awsYdVdJ8OutQd8R4RbFKH2aYKBqh+m2Fk7PkEvKW0mibq0Hx5LEPDOxNTfSa+pVdkfknt3KE5S82dp+d1oo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 17:54:25 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Stewart Hildebrand Cc: xen-devel@lists.xenproject.org, Jan Beulich Subject: Re: [PATCH v3] vpci/msix: check for BARs enabled in vpci_make_msix_hole Message-ID: References: <20260226025740.71673-1-stewart.hildebrand@amd.com> <1e62a5ad-f865-4477-a899-0182dec38901@amd.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1e62a5ad-f865-4477-a899-0182dec38901@amd.com> X-ClientProxiedBy: MR1P264CA0182.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:58::18) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA3PR03MB8476:EE_ X-MS-Office365-Filtering-Correlation-Id: 634e3eea-79f0-45f3-d8ff-08de7a0eb36f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: qgxvPtIPHKhv+7Qc2ZAVDcYW53NW+IjGZnTxTpt2Nw6CqxHcdJmLDr0Bv6yabOqU5uKNlqztlAgeYu9Z11mFwzIhClFxdGALpQOfOhTqd+B0METnAQK+1peIPUroa3g4p0YaY9+U4HOqQUS0lt39Rjw5k4yikNSxBEFYrAbMIBIYxVk0tWqYzgTVhuwgyeIS7Cud8Bo97sTiuOZN/xWgRhNDt+aMNIcq5Lx4ZtdcDmo9GkoJeh6l1dT1kojwLj+0o3v9gPDD+mt36Wb9ugZR9IR82MxnP5WrCfBhXROM9DbVEf+MYoc5KXANvg9BvexX/SHFM8np/vPssWU4HgYQfCO5yhjUK3yoz+1DA0U4b2yKS4MRivRIbBhPi1rggeNq/rY6CoHCJY/2XMOv3XCbOpeGIVU9DPzv7reQGBefPfVrW6O7P2qE7NTfYYBWkxJBCAm/yrE8SiCutg3JLz5aeBI9Gr36ltqEO9pq/2lbldvTk2pufVTwL2nyysjUEJKWG3KjdioTNRuOCu84VmnkGraLTmU6Z/M2Lh3v7hLyrrM81ZGxMUF8VRJSU0Q7z90xKPROGrvce0Kc1TMExQwGCdRzDA14UsNC6uxYhid5FNiGtQfhOhhXRcIsX3oRbZI8gjJ0UInXcz+Slh5gcMXLG31BM7wNh6jz07+JlSRcts0preY3uy7WIpY28ENsFx8G1vQ5cB8aEDkw29z1UB6B+EajFNtHX57s87CRrN4UwME= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ckFDZ0QwNUdMSFRrS2QzWmc0U3JYSGpvd2crcTcvVnpGS1ZsWTNCN2ZheW9G?= =?utf-8?B?WFd6NTRveXBaVnlmY0NsNHVzenlFQTlUVXZjMzJBdzhER2xYVTdTWWJXaTF3?= =?utf-8?B?WnJqQlBVRm5nK2xFKzFUclFQZXppYm02cWxTWmdvVTA5ZjMzSkVpeTBqL25w?= =?utf-8?B?WjZibjFRRVNUUFBKS3JscjVwQ0QwSlR1V282Sy8wNy9vVFMxQURzckFkYU55?= =?utf-8?B?SU43MFVjaDZSalJIenlUYk5zMXFaWmI0ZzRGNDR1VlU4R2k2SUNlVzZoWDZo?= =?utf-8?B?ajA1dVAzYTJWVXZaelMwNnRkRGptL2RXODZGaU5hTnpvWW1qL29RUnYzNXJW?= =?utf-8?B?R1lpY3lzalU0ZFBleTEvUzR2T2pDV2VYQ2RMbVlSV05iSndGYW1FMXQ0OUln?= =?utf-8?B?MWxSRjBUSDZNcDVZRnV0ZjVFSXhWV0JqSzlLUWNaVDkvSVFQbnVFSlN6WUQr?= =?utf-8?B?WG12V1JVNzNuc1dicHRkeEsvS3Y3djlFVDRoOCttNnhkMkZhVUlRV1dlQ3FQ?= =?utf-8?B?bHZUMG1oNE9iOE9YMEJUYisxQVRzUDdzeUdSL21vVzNZUkltQWdNK3ZpaHdu?= =?utf-8?B?bjJ5VU9lYy9pQkhHVUdjUE9ITGcxOGtPc01nakVXZEVOTUpXTkEwYVlmeFph?= =?utf-8?B?ODdjNm9UVUhCaVJQcDJNMmlwcjNVK2xhenVjcFZpUXc5d1dqNC9Lbjlja0wx?= =?utf-8?B?MWwzS0VVeXhucnBwdHI1Y3RnQ3VXUitvbms4NlFqZFdxTUpxNVZKZTV0czho?= =?utf-8?B?KzkzVTJydGo5S1k0S1NTd01vTGlXc01ZNWhMcDFRdmxPaFR6SnpGd2NWL0xn?= =?utf-8?B?NW9HQkk2aUZ5QUFvMTBvK3RiNm11YlFaMllxRTZKRi9VcWZDdGJhQWZmWThs?= =?utf-8?B?TEhCYmhTUTZteUtMZ0ZXb20xTklIazREYjJ1djg5SkRFblBwUTkwNFdLUVVU?= =?utf-8?B?ODFSQ1J0b3pwRU5GeEkzclRmekxqT1AxUTR0d2VGTWNqb1dlS3llTE93SzJG?= =?utf-8?B?VnRnWlBYRE80cXFqS2JLYzZiaXpIUnVHekV0R291bTgyaVphdlZ0MlVldkN1?= =?utf-8?B?RFhnYXlOc0pSYXlTVG1wNFJMa1h5NXNQQkxlaGVQVGM2aDdaUWxqcXRPdFBT?= =?utf-8?B?T1E5aHA5OHF5Tkp3QTg1QTdHTVM0bk5sT25rT2VqMjlvYklyWmo4RVNzN2Fu?= =?utf-8?B?bXEyeTdmUy9pb0V3SnlvQjdJWHl0bmgyUGIrMTFQRHlsMWlXTm1POFZDaGhv?= =?utf-8?B?S3NFb0QvbmtRYkJMVmJrNEJzeEtWSjB2cXdzZXZxY25ORXhUdEIrcTdzSDRL?= =?utf-8?B?akxONWs1V2t1UkYvUVBmUisxcVQ2WDRFTXN5aVBJR0pPNEt5OERMd0R0VVps?= =?utf-8?B?V3JrTmJURTkvWTNxVXhZaVNWL0FXVU5sSlA0MzlOcW5CRnZ1b0JoT1EzN1o1?= =?utf-8?B?NStOc0t4NmlLVXBZUjRIalFHbUEzVC85MzJJRThoYjdJMjJEblZoMmxoWlVl?= =?utf-8?B?THlvaVdEb3h1WUw5MUt2dWJFdW9vT2lKVkc0bXRCNWZsNFhjY0dhZkFpTVRp?= =?utf-8?B?K25XZk4rVlB5Wk5tRDdLaDBpUHJqbk1wNXVvS3ExR3FvMzNZbDBWSXlZYm1q?= =?utf-8?B?VHF2TnNnVzhqem11RXptZVdSTHU5OEI3VDlCR253MHc2NUQxMkc2QmRIbXIv?= =?utf-8?B?eFREbTBYSkRkbGJ4ZS9YQTZCOEZUejluR3hyNm5TdnloYWZYb05mOGhGOFZW?= =?utf-8?B?MzRJeW1WdURDU005dE51Y1VnZThrZDhUZzMrOVN1QW5OOXc5MGcySWMwQVkx?= =?utf-8?B?NDJQMTNaUndqenVFVlZ2VGFuUVdjdU90R2lrbnM0dmdNVG9rZjd4SXlJNnVF?= =?utf-8?B?U2xDdGlLNHdva1drMmVYZk4xT0NZSER1dHR3bGVjZEx1NHNxbEovdmZNaTFL?= =?utf-8?B?RzQvZ2JkSFk4NUJCazhMR0NOOW1sV2oyVVd4dDkwQXFsMXJ6K2lhd1lyY1BD?= =?utf-8?B?WE1vZGE1ZWp4ZkNidnd0aEhpNXhaamZaVUdybWczek9tVUV1dStoazl2ZlQv?= =?utf-8?B?eXdaSkIyeUEvVGI4SC9vSjF6bzhtY0E2MlVGTnMvcWVTWlpLMFg0eVJsK3Ex?= =?utf-8?B?OTREK2YwbHhoMzM4VWtEeit4OUVvU2ZIekQ5Rkl1NHBOUnU5VWNQK0pnL013?= =?utf-8?B?b3lTUzN5bDZFTnN5Nndka25oUFhzWUh5R0hDT05vYVFMc20wVklPMGFmdVNU?= =?utf-8?B?UERVZWdpSnNVNThtMUJwZjRhRkoySXI3SzY1WWw4NVlCRkhIOVpMSnR3SWwz?= =?utf-8?B?SHg0WU9LeHhCM3p0OHBuRVhlYjN2TExFV205WVBxcFVlSDRsaWVZdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 634e3eea-79f0-45f3-d8ff-08de7a0eb36f X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 16:54:29.3799 (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: fN3mi5IG6Qp/ALGVF3RTaPgnReV0tJ+y6MX5hGmGzhTXAk/Zup3g0tQfyw1xDu9/sNPrL/tHZExxOImX3oKKGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8476 On Wed, Mar 04, 2026 at 10:39:56AM -0500, Stewart Hildebrand wrote: > On 3/4/26 10:23, Roger Pau Monné wrote: > > On Wed, Feb 25, 2026 at 09:57:38PM -0500, Stewart Hildebrand wrote: > >> A hotplugged PCI device may be added uninitialized. In particular, > >> memory decoding might be disabled and the BARs might be zeroed. In this > >> case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole() > >> unconditionally attempts to punch holes in p2m, leading to init_msix() > >> failing: > >> > >> (XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area > >> (XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it > >> > >> vpci_make_msix_hole() should only attempt to punch holes if the BARs > >> containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper > >> for checking if a BAR is enabled, and add a check for the situation > >> inside vpci_make_msix_hole(). > >> > >> As a result of the newly introduced checks in vpci_make_msix_hole(), > >> move the call to vpci_make_msix_hole() within modify_decoding() to after > >> setting ->enabled. > >> > >> Fixes: ee2eb6849d50 ("vpci: Refactor REGISTER_VPCI_INIT") > >> Signed-off-by: Stewart Hildebrand > > > > Reviewed-by: Roger Pau Monné > > > > Thanks. > > Thanks! > > I would like to point out that this now needs a rebase: > The helper vmsix_table_bar_valid() should be moved to the new private.h. > I'd be happy to send v4, assuming I can retain your R-b. Sure, please keep the RB. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 17:18:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 17:18:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245832.1545198 (Exim 4.92) (envelope-from ) id 1vxprp-0002cO-KS; Wed, 04 Mar 2026 17:18:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245832.1545198; Wed, 04 Mar 2026 17: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 ) id 1vxprp-0002cH-GV; Wed, 04 Mar 2026 17:18:37 +0000 Received: by outflank-mailman (input) for mailman id 1245832; Wed, 04 Mar 2026 17:18:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxpro-0002cB-JA for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 17:18:36 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2a7efe51-17ee-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 18:18:30 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4837907f535so63939635e9.3 for ; Wed, 04 Mar 2026 09:18:30 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851881a844sm59032745e9.15.2026.03.04.09.18.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 09:18:28 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2a7efe51-17ee-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772644710; x=1773249510; 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; bh=kLgVDDKfnR6JHrXAy+RBeThIO2uC8DuDIEkoJk6r+O8=; b=AOf3QJ5Ok3Qn99x4Tr86bdRFfMFzJIWS+pbUPQVm09kcyCxJIeJh99FygSzDmrZCwy s4Yp9nTcnxpV4dMDzzh7vj7O63IaFn0JEOLYfHeYFdgyhYRahFUuqgOGc8BQ/7XlzQ3w ah7kO7MRCBDQTtmURrmNUwHIqF+QZxrnOVroo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772644710; x=1773249510; 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; bh=kLgVDDKfnR6JHrXAy+RBeThIO2uC8DuDIEkoJk6r+O8=; b=e2XA7PovXF0dcZ1HZaQvAsq17KtTdIaeHRAHlYnNmRw+Erg7gvmMybpKRon8xow5y2 /DkUCEnVVdjc8gLBULpzui9oeeFeqJqm20YWbvzQ9PfFRYrj9n1sQP6EGf1xPeBLuhKZ nz6BxHs8U2ZCf0tKNpyr1Yeo5WwoiPRC9WsExIx0+IQLCBGcnCwZ5rGzBV6XKhED5hFt H8whgZwmJdSc64rQswDLo806NCF8uT6EQzRmTnJGhnICdH1nvOM7WCsBFhyg4mIxqp7i I2O8fvf7nZOrCvWSTqMLUWo1BIHDJ94jQHxWnMzSczpyFKXD3HBnBVd9NImB3sM5gshu j1pQ== X-Gm-Message-State: AOJu0YwHJQa2fEXzgJroymagCOxdyw1YCBcnicy3IGGnfzUa4HHDI68k ize3Uzrg7ZSJQyTNHCe4j9Z51lZFCVd/KOibuzEQYm0BGUmHW+aTQweXK7VaIF99WkBtrnGOG8U P0j6O X-Gm-Gg: ATEYQzw9TeGiK3pH1pk0rU3VKbx3kJnmlG17IFs4nKnn3ygZZ8TrkC3T1GIH1Npkhkh a9nvUzJ1xdYrvrEWShBs6nIpq+JWno1pZQQVonsRfTgPVvTLN7kwR+pVHKLndTEAv5R9PmwQ/DS sMeEBNeNA/YiWLuCstQjLZ5NoiyLVsmjEB0cIj4b8wvu29Ntcc/L1RZQdQ9oswxQ59ZV26roi8y JuHtOjd1wJEgSIW5EbVuO5NBYGeIX0zwWJ55PRPcLDWscubczJsu9MQpL7fqxWPy5Enf1GjRneP h31I8OJQEmyro1SVvdDGB/cDBjg0PA5Bo+6m5R6KpViQ9PaUMB0TLhrX7GpZy9fy7QCQiL48WMg fND0N1Ux69KuwaPz6ErFrhvpdDYBvA98mMKIdfxZKXI9eLjslwku4MQGuA5j2WQH09QFPG1kqzU FZiCQW+kTK5VzMet2BfpdT51k7ET/dGN0nGvGydSYu1GbOcFulEYDzF7QaY86yrIYHxDEKZhY= X-Received: by 2002:a05:600c:3b12:b0:47a:814c:eea1 with SMTP id 5b1f17b1804b1-485198b3304mr47230035e9.35.1772644709130; Wed, 04 Mar 2026 09:18:29 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4.1 09/14] x86/pv: Adjust GS handling for FRED mode Date: Wed, 4 Mar 2026 17:18:26 +0000 Message-Id: <20260304171826.45847-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-10-andrew.cooper3@citrix.com> References: <20260227231636.3955109-10-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When FRED is active, hardware automatically swaps GS when changing privilege, and the SWAPGS instruction is disallowed. For native OSes using GS as the thread local pointer this is a massive improvement on the pre-FRED architecture, but under Xen it makes handling PV guests more complicated. Specifically, it means that GS_BASE and GS_SHADOW are the opposite way around in FRED mode, as opposed to IDT mode. This leads to the following changes: * In load_segments(), we already load both GSes. Account for FRED in the SWAP() condition and avoid the path with SWAGS. * In save_segments(), we need to read GS_SHADOW rather than GS_BASE. * In toggle_guest_mode(), we need to emulate SWAPGS. * In {read,write}_msr() which access the live registers, GS_SHADOW and GS_BASE need swapping. * In do_set_segment_base(), merge the SEGBASE_GS_{USER,KERNEL} cases and take FRED into account when choosing which base to update. SEGBASE_GS_USER_SEL was already an LKGS invocation (decades before FRED) so under FRED needs to be just a MOV %gs. Simply skip the SWAPGSes. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné v4.1: * Extra comments v4: * Adjust GS accesses for emulated {RD,WR}MSR too. --- xen/arch/x86/domain.c | 16 +++++++++++----- xen/arch/x86/pv/domain.c | 22 ++++++++++++++++++++-- xen/arch/x86/pv/emul-priv-op.c | 26 +++++++++++++++++--------- xen/arch/x86/pv/misc-hypercalls.c | 23 +++++++++++++++-------- 4 files changed, 63 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index e658c2d647b7..9c1f6ef76d52 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1791,9 +1791,10 @@ static void load_segments(struct vcpu *n) /* * Figure out which way around gsb/gss want to be. gsb needs to be - * the active context, and gss needs to be the inactive context. + * the active context, and gss needs to be the inactive context, + * unless we're in FRED mode where they're reversed. */ - if ( !(n->arch.flags & TF_kernel_mode) ) + if ( !(n->arch.flags & TF_kernel_mode) ^ opt_fred ) SWAP(gsb, gss); if ( using_svm() && (n->arch.pv.fs | n->arch.pv.gs) <= 3 ) @@ -1814,7 +1815,9 @@ static void load_segments(struct vcpu *n) if ( !fs_gs_done && !compat ) { - if ( read_cr4() & X86_CR4_FSGSBASE ) + unsigned long cr4 = read_cr4(); + + if ( !(cr4 & X86_CR4_FRED) && (cr4 & X86_CR4_FSGSBASE) ) { __wrgsbase(gss); __wrfsbase(n->arch.pv.fs_base); @@ -1931,6 +1934,9 @@ static void load_segments(struct vcpu *n) * Guests however cannot use SWAPGS, so there is no mechanism to modify the * inactive GS base behind Xen's back. Therefore, Xen's copy of the inactive * GS base is still accurate, and doesn't need reading back from hardware. + * + * Under FRED, hardware automatically swaps GS for us, so SHADOW_GS is the + * active GS from the guest's point of view. */ static void save_segments(struct vcpu *v) { @@ -1946,12 +1952,12 @@ static void save_segments(struct vcpu *v) if ( read_cr4() & X86_CR4_FSGSBASE ) { fs_base = __rdfsbase(); - gs_base = __rdgsbase(); + gs_base = opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : __rdgsbase(); } else { fs_base = rdmsr(MSR_FS_BASE); - gs_base = rdmsr(MSR_GS_BASE); + gs_base = opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : rdmsr(MSR_GS_BASE); } v->arch.pv.fs_base = fs_base; diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index d16583a7454d..b85abb5ed903 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -14,9 +14,10 @@ #include #include #include -#include #include #include +#include +#include #ifdef CONFIG_PV32 int8_t __read_mostly opt_pv32 = -1; @@ -514,11 +515,28 @@ void toggle_guest_mode(struct vcpu *v) * subsequent context switch won't bother re-reading it. */ gs_base = read_gs_base(); + + /* + * In FRED mode, not only are the two GSes the other way around (i.e. we + * want to read GS_SHADOW here), the SWAPGS instruction is disallowed so + * we have to emulate it. + */ + if ( opt_fred ) + { + unsigned long gs_shadow = rdmsr(MSR_SHADOW_GS_BASE); + + wrmsrns(MSR_SHADOW_GS_BASE, gs_base); + write_gs_base(gs_shadow); + + gs_base = gs_shadow; + } + else + asm volatile ( "swapgs" ); + if ( v->arch.flags & TF_kernel_mode ) v->arch.pv.gs_base_kernel = gs_base; else v->arch.pv.gs_base_user = gs_base; - asm volatile ( "swapgs" ); _toggle_guest_pt(v); diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index 64d47ab677a4..53676b30219c 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -25,6 +25,7 @@ #include #include #include +#include #include @@ -926,7 +927,8 @@ static int cf_check read_msr( case MSR_GS_BASE: if ( !cp->extd.lm ) break; - *val = read_gs_base(); + /* Under FRED, GS is automatically swapped on privilege change. */ + *val = opt_fred ? rdmsr(MSR_SHADOW_GS_BASE) : read_gs_base(); return X86EMUL_OKAY; case MSR_SHADOW_GS_BASE: @@ -1066,17 +1068,23 @@ static int cf_check write_msr( if ( !cp->extd.lm || !is_canonical_address(val) ) break; - if ( reg == MSR_FS_BASE ) - write_fs_base(val); - else if ( reg == MSR_GS_BASE ) - write_gs_base(val); - else if ( reg == MSR_SHADOW_GS_BASE ) + switch ( reg ) { - write_gs_shadow(val); + case MSR_FS_BASE: + write_fs_base(val); + break; + + case MSR_SHADOW_GS_BASE: curr->arch.pv.gs_base_user = val; + fallthrough; + case MSR_GS_BASE: + /* Under FRED, GS is automatically swapped on privilege change. */ + if ( (reg == MSR_GS_BASE) ^ opt_fred ) + write_gs_base(val); + else + write_gs_shadow(val); + break; } - else - ASSERT_UNREACHABLE(); return X86EMUL_OKAY; case MSR_EFER: diff --git a/xen/arch/x86/pv/misc-hypercalls.c b/xen/arch/x86/pv/misc-hypercalls.c index 4c2abeb4add8..7e915d86b724 100644 --- a/xen/arch/x86/pv/misc-hypercalls.c +++ b/xen/arch/x86/pv/misc-hypercalls.c @@ -11,6 +11,7 @@ #include #include +#include long do_set_debugreg(int reg, unsigned long value) { @@ -192,11 +193,13 @@ long do_set_segment_base(unsigned int which, unsigned long base) case SEGBASE_GS_USER: v->arch.pv.gs_base_user = base; - write_gs_shadow(base); - break; - + fallthrough; case SEGBASE_GS_KERNEL: - write_gs_base(base); + /* Under FRED, GS is automatically swapped on privilege change. */ + if ( (which == SEGBASE_GS_KERNEL) ^ opt_fred ) + write_gs_base(base); + else + write_gs_shadow(base); break; } break; @@ -206,10 +209,13 @@ long do_set_segment_base(unsigned int which, unsigned long base) unsigned int sel = (uint16_t)base; /* - * We wish to update the user %gs from the GDT/LDT. Currently, the - * guest kernel's GS_BASE is in context. + * We wish to update the user %gs from the GDT/LDT. Currently, we are + * in guest kernel context. + * + * Under IDT, this means updating GS_SHADOW. Under FRED, plain GS. */ - asm volatile ( "swapgs" ); + if ( !opt_fred ) + asm volatile ( "swapgs" ); if ( sel > 3 ) /* Fix up RPL for non-NUL selectors. */ @@ -247,7 +253,8 @@ long do_set_segment_base(unsigned int which, unsigned long base) /* Update the cache of the inactive base, as read from the GDT/LDT. */ v->arch.pv.gs_base_user = read_gs_base(); - asm volatile ( safe_swapgs ); + if ( !opt_fred ) + asm volatile ( safe_swapgs ); break; } -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 17:28:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 17:28:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245845.1545207 (Exim 4.92) (envelope-from ) id 1vxq0z-0004Kw-Gg; Wed, 04 Mar 2026 17:28:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245845.1545207; Wed, 04 Mar 2026 17:28:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxq0z-0004Kp-E2; Wed, 04 Mar 2026 17:28:05 +0000 Received: by outflank-mailman (input) for mailman id 1245845; Wed, 04 Mar 2026 17:28:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxq0y-0004Kj-AB for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 17:28:04 +0000 Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170120001.outbound.protection.outlook.com [2a01:111:f403:c107::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f0305cd-17ef-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 18:28:03 +0100 (CET) Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by BLAPR03MB5556.namprd03.prod.outlook.com (2603:10b6:208:297::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 17:27:58 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%6]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 17:27:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f0305cd-17ef-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SqGkz8Tlx3yj8xQe6jMXVqHorv8q2/Lyw+Qd/wbxTFeOdusQHWGFu2tBzVIw6h6ki7B7t36CrNBze3lGwRMYjRtZw9489ntT1OuLfXnXxoD9uapniGkTRK/7xvNsOJBlIYb4VwAwLaDizXnBmaZ6L10gYRgg89DzPXBZx3vNBUahcuopjRJhjfbZJfISyImzSLE7Ao61oCrSMPzBaj+WjjVV5f1uCPoo8elFwHzTavqW77HUyvUEa7nOCLLJY6kVAwySLR4jg0rbzjpTCWgreq2G6FnleGRlxK4xYoBnbgnsmjyjQPAssO2jfczlK3TriedIWOAGuRU72SVjbQbpHA== 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=BTW0OIApes7ucx+QNWFjxhTP/zA1bUY3ihHkrnMnzs8=; b=JJN4qkhPgojYIgn+lFHrCAz3VmCsaPkCRhW/42IgoPCN/S/C2x46WmFqunju05T7Xy3ORfmmovnpvE512EjbjUHhRej+qzyNoNY1fwq7KR7QfcnnfM06EDYgR8s6U01FRfvw8dDJnJntg/gzjkkB2gF2FPbe0gzDR2Dw/exbjy91/jBECW/X40p9Eb6GY5TCTuluZpkBCLgwrklXblQ6rlqUyAUWPRH2T4ACU6Oak3GO3dvfJ8G1E8T2Q7Q012xEgOs0xZjkFXtbwzX6jaTQIC7skAYkUph9eqkXf78cIuG6++pWAvhrnAewZqDqpL90dTBZ69gSppDqd5Lxk9Z8qg== 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=BTW0OIApes7ucx+QNWFjxhTP/zA1bUY3ihHkrnMnzs8=; b=NOVg0tu4yXqX/1VkAvv52Rkh3I3j0a2pmfcgkkXE9jfK4wJdPPjySQYZL6nYYE3QCmVJENOB9Zy1OXtY7wtPaVaaH2XrJGqlWHJwuEro+/xs7nxzcCsFCotQ6n9li4Y+yLu426Uf7UNUDxFusT+PKsV5NpW+J0xW1Q9IHwFNvsI= From: Bernhard Kaindl To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , "Daniel P. Smith" , Juergen Gross , Christian Lindig , David Scott , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v4 0/10] xen: Add NUMA-aware memory claims for domains Thread-Topic: [PATCH v4 0/10] xen: Add NUMA-aware memory claims for domains Thread-Index: AQHcq/EQ7U0dGER6F0e0O8+l9l+UF7Wen7Sg Date: Wed, 4 Mar 2026 17:27:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: LV3PR03MB7707:EE_|BLAPR03MB5556:EE_ x-ms-office365-filtering-correlation-id: 8d1fe9c3-8b44-4898-4000-08de7a1360c1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021; x-microsoft-antispam-message-info: DMcfUBvB7RKPIzg/pfZYC9YbI1yvGxgglnmUMzYJOJ/uMmyx/pxaaRmOg16LR8kMFhZ9xZf7p2hP8kKCiLv9wkbE3r8f3HH5PtcdSZ9X535swVD08O0M7M97yOsMvkbjz/pP6FhWUrPJXd90CNCK1Ki0EpXXs4tR8Y8ekUU2Yg/yuaKC91pbeMUQ8jqxgIuVh+J8oBn0TV9xfb0rYvxKFTQgyP7uY5ZNBFDFGVOEb8fZMbYdTLgfqDiiXWW1MOst6ZJvt2I4z/7x/Dp5p6HykWW06qlzPML6FbCezkr0Cdi9xMmZzFT5OlFwVNEWneK9GtODwC4x34WgavJXpfijn04V7dRzWlP+Q99ZUTO6TK0CmhIjHNqOql3/xRdu/iZRe+/ResjlzHB9xYkLKx96PHqOWf20wQ9Woy71InV8oQVbux29gqzyGgaM65LJzoWanIbnyKXoAf3fzEXlCh7wEuptx0cHohxpvY1UQqTALCgEW1pBO3P+iA/qFGZJZGCDJ6XjvwNCyFIi8wPXaL/Seu/1xkLNsVKS1UhSE6m0zPIfUT+Jv6UiorctWQQJMQ7HCkxGfgdwufCxEfOomyeAnAcHdSDs36j62RW8c6wSy4A8q6RzqaCaMuLieFjMIXF7RqPZ6DOci8tRSGRX+A+5W1tTgKhqJZNz1nKYgkSA2oKcUfmq6kHOE3DFsCx8xVxAgcxhIlfdCvlHLTrgWYmEyKPeL1Xbx8bsZyO51oYZIEZVtiTD7FEMObcxbH8tMtjG48stszLpq8SED6NlyuM37R+6LoIe1R8Uh+vP6tXGPPs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Qi9iSmR6MWo2WHZCU1FYd0NPbk5HZTVyS0JCdVJ2amtTZXZ5MlZaU2QveGNZ?= =?utf-8?B?RXNNVHZacGtodmduUkg3Q2ZGakkvS2phSXJDSlJDV3hOVTVITjU3eHJOKyth?= =?utf-8?B?UzFzMkFOckRKL0F2K214QUROWUFQcnVaNmw5Z1dOL0RBNHA5cHZ2VEZqaG5o?= =?utf-8?B?LzA3L2xIVFNlUXJIWlNCSnNtdFFYdTlrTXpZNmVUaWR0SktFNitncUFZZE1p?= =?utf-8?B?bjh2MC83Z2daQUlla09qMnVld2tkdms3c3I5YVRzV0V4OWJod2hwUWg2cGxh?= =?utf-8?B?U1NlMmd5bjQrWXR0ekhIRnNNN29tQUFNWmR0Ty9STkFGSUxJdC94djliRDV4?= =?utf-8?B?QTc3UVpnVlJEU2lLRHhucmdqYnVhNFUrRVJQTzk3N1luMHR2SVk0cmc0NFhY?= =?utf-8?B?K2NQUFVHaFJkbVcxajlsVFB6MmdMaFk5M3dsdWplK0RrWTJ6NlF0MzdwN3Bv?= =?utf-8?B?MHU5a2FkUGhMQnFVbzd3OU5LQUZYTGlsUEhpc2F4dDNUMHNydlYrVm1aVlk5?= =?utf-8?B?SWlyeitkckZyTmJzc0dEc2JRUVJsUkIvWVlKY1JkTEZZVVdnWUhkbFR1WVJw?= =?utf-8?B?LzRyN0V5eUJ0dTkrU2I1dmtRbVFrVjU2d3YzbEEzdnVIZ2Y4dy9RaU9wNUUx?= =?utf-8?B?d0pjbUw5Z0pDOHlJWUNGZjVpSlFhT3hwcnV4VmlaZ2Q0d1pDRFZNMWtMWUgv?= =?utf-8?B?dEdaNWE0MEUzdTYxTDBiMXN0eTl1b096ZjRURmZFYVJhYnFYUnpOaWJZMHY5?= =?utf-8?B?NWUxVUNjTWNWRmFYaG1NTWh4VmFTeEJGdGgyNHdKZS9CMkRGUkxVd2NmMEtR?= =?utf-8?B?QzRDRVB3SFFPaUdILzNJVjh5NCtMM3hKUEEwMDIrRGVQT21DMFJHZm1XR3px?= =?utf-8?B?cDA3dTlPaEkxNzYvaXV4N2hCSXREaWx4YkgxZERRZSt0L0NUaHJiUWlOUUVJ?= =?utf-8?B?ZjdCbGh5RFFsQkNPWlhCeGN4bEUrci8yelh4RlM3Ny9tcTBhSndCNVgvQUxm?= =?utf-8?B?NEE1WkpFRHE4RXZnNTNjU1RUYkhGWU5zOXVzWm5iU28wVCsvRU1CYkQxSXVS?= =?utf-8?B?RDFiVEJ1dnhtbk52RERjNk5DMHoxQTlCVmZMYTAxOTZLamZYRVFrRDdIN2Ez?= =?utf-8?B?cHk5ZFBMdHd5SFJvUUduQ0JMb2lTdExYZ2c2QnYydVluenRTOHRzQXdxRjE0?= =?utf-8?B?SnFjSERPWWJNdXgzMTJhNEVYQWJxcWkrcmtwdk82NnNNbFVwOWdxYVhpL3Vv?= =?utf-8?B?aXE5blpyZEd1UTdWM25idnFFeUpsSjZoMVNYYkJhQ1ZzeXYyN1U2WUFYeXlJ?= =?utf-8?B?YVJKQm9KY2tJU0FNVGs2V0c5bnF1TUkxeGNCeER1TmQ5blZkYm5qUTdha3Nx?= =?utf-8?B?NUxuU0t2WEszbGtZMUxBUVlnNjUwL3VXV2hHK21kaUJuaGV5L1dIWFl4czM2?= =?utf-8?B?TzFWYjA2d0Vvd3NiNTFwOHV6WllpczNJa0dnQXJ1ZWRqS0hhd2R6VHUwTzVi?= =?utf-8?B?cUhvdHFBWHhaVHlJaUhpdy9IYTF2enlDL2JaUjdZQXlvRFVkOG5rRVRZRTRu?= =?utf-8?B?TlJMWHpzRmVJZ25MNDBXNkJOYytFTDFsQjdYVGJIS1Y4azYwRGFjeTZxUnpN?= =?utf-8?B?U1FwY0MwYUhBbjc4V2dVVGo5TUhwbFdaU09oUVFNdEFWRWVSdDkvSVcvTXZ5?= =?utf-8?B?NnVzSnAxaTBnalN1NkpYWHVSNy92SjhaWlJHcXVXTkVia2RUZkFKa3crU2VQ?= =?utf-8?B?VjRielptZENtS1Y2cDE1R000ZDFrOGg1aVc0Y2t2QUJ1bTBIaXpOSXl0WlpL?= =?utf-8?B?RWNmNnFkQ1E2djRJeG1oUlBRazh3bTU2T0o4RTF6c2tWWERIQWRKeTVLYW15?= =?utf-8?B?cHA1RkRkQTQ5QklWTWVVK2VmSmdzSWJOTlhQQlFuVE9RZUZSVjNJcDV0bzdF?= =?utf-8?B?Y1Jlb05jTzRSZ3pZeSs5UmZ4S0tnY2JnQ2NudnBDckd4NmZKSmtrMEdNeGFq?= =?utf-8?B?RHY4RkIyaE40enJySndWUjdXaXZac0xFa2VPSEhJV2pQOFUveG1ZdDFYSURB?= =?utf-8?B?SldGQS9zYm9QcGpEcmwraWI0aStJbEpGRkQya0lzMXV2dzNxUG11RTQyRUw2?= =?utf-8?B?bXM1K3hWWVFyb09mMGQxZWdzYjFiQmFQNjdoZGtDUk44RTR1SXYxREdWdHJP?= =?utf-8?B?MXJHTzFHWnYyb0c0Q200RFpRajNnWDRGRGM1VGsyVEdzUXdGTVlhcUxOaGY1?= =?utf-8?B?WWVMUGFaTHZjVi9YU2NaYXBFanJ5NG9nMGJ6Y2NrNTcxd2llOWRwb0ZlTUtJ?= =?utf-8?B?ZklkZ0VSSGkvT25LZ2d0ZEorWU4zTmRlbDZxMHBheDZhVTJDZGVGdz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d1fe9c3-8b44-4898-4000-08de7a1360c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2026 17:27:57.9096 (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: KWjZ+qLNuWCY0Yp10DdEmhH0pbiGpCD0MFeJezVgZm6QpuyjrwtPilwshLvdgJvgc4ZAtPGxb6eim8bxFABZLLdwCfK+S382HTDU6MWpRw8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5556 SmFuIEJldWxpY2ggd3JvdGU6DQo+ID4gLSBBbGVqYW5kcm8gVmFsbGVqbyBkZXZlbG9wZWQgdGhl IGluaXRpYWwgdmVyc2lvbg0KPiA+IC0gUm9nZXIgUGF1IE1vbm7DqSB1cGRhdGVkIHRoZSBpbXBs ZW1lbnRhdGlvbiBhbmQgdXBzdHJlYW1lZCBrZXkgaW1wcm92ZW1lbnRzDQo+ID4gLSBNYXJjdXMg R3JhbmFkbyBjb250cmlidXRlZCBhbmFseXNpcyBhbmQgc3VnZ2VzdGlvbnMgZHVyaW5nIGRldmVs b3BtZW50DQo+IA0KPiBEZXNwaXRlIGFueSBvZiB0aGlzLCAuLi4NClsuLi5dIA0KPiAuLi4gb25s eSBhIHNpbmdsZSBwYXRjaCBoYXMgYW4gUy1vLWIgb3RoZXIgdGhhbiB5b3Vycy4gSXMgdGhpcyBh IGNvcnJlY3QNCj4gcmVwcmVzZW50YXRpb24gb2YgYXV0aG9yc2hpcD8NCg0KUGF0Y2ggMyBzaG91 bGQgaGF2ZSBTLW8tYnMgYnkgUm9nZXIgYW5kIEFsZWphbmRybyBpbiB0aGUgY29tbWl0LCBJIHdp bGwgZml4IGl0Lg0KDQpUaGFua3MgZm9yIHRoZSBjYXRjaCwNCkJlcm5oYXJkDQoNClBTOiBEZXRh aWxzIG9mIHRoZSBwYXRjaGVzOg0KDQpJJ2xsIGFsc28gYWRkIFJlcXVlc3RlZC1ieTogUm9nZXIg UGF1IE1vbm7DqSB0byB0aGUgaHlwZXJjYWxsIGhlIHJlcXVlc3RlZCB0bw0KaW1wbGVtZW50IGZv ciB0aGlzIHNlcmllcy4NCg0KSGVyZSBpcyB0aGUgYnJlYWtkb3duIG9mIGNvbnRyaWJ1dGlvbnM6 DQoNCjEuIHhlbi9wYWdlX2FsbG9jOiBFeHRyYWN0IGNvZGUgZm9yIGNvbnN1bWluZyBjbGFpbXMg aW50byBpbmxpbmUgZnVuY3Rpb24NCg0KICAgLSBCeSBtZSBhcyBwcmVwYXJhdGlvbiB0byBhdm9p ZCBkdXBsaWNhdGVkIGNvZGUuDQoNCjIuIHhlbi9wYWdlX2FsbG9jOiBPcHRpbWl6ZSBnZXR0aW5n IHBlci1OVU1BLW5vZGUgZnJlZSBwYWdlIGNvdW50cw0KDQogICAtIEhhcyBTLW8tYiBieSBBbGVq YW5kcm8sDQogICAgIC0gRXh0cmFjdGVkIGludG8gYSBzZXBhcmF0ZSBwYXRjaCBmb3IgbW9yZSBm b2N1c3NlZCByZXZpZXcNCiAgICAgLSBVc2Ugbm9kZV9hdmFpbF9wYWdlc1tub2RlXSBhbHNvIGZv ciBhdmFpbF9ub2RlX2hlYXBfcGFnZXMobm9kZSkNCiAgICAgLSBVc2UgdW5zaWduZWQgKHRvIGJl IGZhY3RvcmVkIGludG8gYSBzZXBhcmF0ZSBjb21taXQgcGVyIHlvdXIgcmV2aWV3KQ0KDQozLiB4 ZW4vcGFnZV9hbGxvYzogSW1wbGVtZW50IE5VTUEtbm9kZS1zcGVjaWZpYyBjbGFpbXMNCg0KICAg LSBUaGFua3MgZm9yIHRoZSBjYXRjaCwgSSB3aWxsIHRoZSBmaXggU3VnZ2VzdGVkLWJ5IHRvIFMt by1iJ3MuDQoNCjQuIHhlbi9wYWdlX2FsbG9jOiBDb25zb2xpZGF0ZSBwZXItbm9kZSBjb3VudGVy cyBpbnRvIGF2YWlsW10gYXJyYXkNCg0KICAgLSBJJ2xsIHJlbW92ZSBpdCBmcm9tIHRoZSBzZXJp ZXMsIHNraXAgaXRzIHJldmlldy4NCiAgICAgTm90IG5lZWRlZCwgYW5kIGl0IG1pc3NlZCBpbml0 aWFsaXppbmcgbm9kZXMgd2l0aG91dCBhbnkgbWVtb3J5Lg0KDQo1LiB4ZW4vZG9tYWluOiBBZGQg RE9NQ1RMIGhhbmRsZXIgZm9yIGNsYWltaW5nIG1lbW9yeSB3aXRoIE5VTUEgYXdhcmVuZXNzDQo2 LiB4c20vZmxhc2s6IEFkZCBYRU5fRE9NQ1RMX2NsYWltX21lbW9yeSB0byBmbGFzaw0KNy4gdG9v bHMvbGliL2N0cmwveGM6IEFkZCB4Y19kb21haW5fY2xhaW1fbWVtb3J5KCkgdG8gbGlieGVuY3Ry bA0KOC4gdG9vbHMvb2NhbWwvbGlicy94YzogYWRkIE9DYW1sIGRvbWFpbl9jbGFpbV9tZW1vcnkg YmluZGluZw0KOS4gdG9vbHMvdGVzdHM6IFVwZGF0ZSB0aGUgY2xhaW1zIHRlc3QgdG8gdGVzdCBj bGFpbV9tZW1vcnkgaHlwZXJjYWxsDQoxMC4gZG9jcy9ndWVzdC1ndWlkZTogZG9jdW1lbnQgdGhl IG1lbW9yeSBjbGFpbSBoeXBlcmNhbGxzDQoNCiAgIC0gVGhlc2UgYXJlIHRoZSBwYXRjaGVzIGZv ciB0aGUgbmV3IGh5cGVyY2FsbCBpbnRlcmZhY2UgcmVxdWVzdGVkIGJ5IFJvZ2VyLA0KICAgICBJ J2xsIGFkZCBhIFJlcXVlc3RlZC1ieTogUm9nZXIgUGF1IE1vbm7DqSB0byB0aGUgQVBJIGludGVy ZmFjZSBwYXRjaGVzLg0KICAgICBUaGV5IGFyZSBvZiBjb3Vyc2UgYmFzZWQgWGVuIGNvZGUsIGJ1 dCBub3Qgb24gcGF0Y2hlcyBvZiBzb21lYm9keSBlbHNlLg0KDQpCZXJuaGFyZA0K From xen-devel-bounces@lists.xenproject.org Wed Mar 04 17:37:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 17:37:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245860.1545217 (Exim 4.92) (envelope-from ) id 1vxq9i-0005uk-9y; Wed, 04 Mar 2026 17:37:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245860.1545217; Wed, 04 Mar 2026 17:37:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxq9i-0005ud-7F; Wed, 04 Mar 2026 17:37:06 +0000 Received: by outflank-mailman (input) for mailman id 1245860; Wed, 04 Mar 2026 17:37:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxq9g-0005uL-E1 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 17:37:04 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c1c1dffc-17f0-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 18:37:03 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by CO1PR03MB7963.namprd03.prod.outlook.com (2603:10b6:303:270::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Wed, 4 Mar 2026 17:36:59 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 17:36:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c1c1dffc-17f0-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L3kf0YcMg7PPQ1M4XhDPFfUO7xubTg+qUIzhFOFYiYfS6S92cnkjMET69eSnq7tZAIDYJ1ie1dyE9Cy3gxsasWkqmGhKZXW71TtUmFSLLjveXWGzd4S3PFcDZvDM39i0VsDpxhsiNvFmAlem2QwQbrLkSxfV6e5OrRlNlIfc+0JzyynJ8lglk9dURJ/MTgkPXOpnoFSd4aZxY9d7sXLnN55OXfFB7vQSd6RwQloqrsaoTRKv0zsKKPnLbm/rAWrG0kYktg02SzM+x6PDJ9r3/7rVRRX9ch8QNESv0H6mY6wTe/OHadmC1NIFZQN7WCDrzHZr1rtYdqaNgNNlSBV1DA== 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=tYj4Aq4H/z18cpo/OR/vwiWEXB53aTYcBr5skHnHH2g=; b=cCGCZIDC9hCq5/uQcOHGd94PIUlE9wS9sfKGpIOJd5qvOtqdbCuxLGOwy2ce91ySukKQZFKf4AIWS0Vs63jis2NWudhQ25LWLvOAIjy3SlqJFZxuGPUl1PRYlHWbUJIiiDOuScMwJzJFcPww3cfkZZ2MYPATlnlgGDmBcHBUITbm+FOy2YQwnpXuii/GthUfA/5B7aNvmmyd7LQE62fnQEQW3QX76CMGXzRHijNAOp9HysGgiC4a3x+Ik/sI+tuoqMOYGbG75lB0PJwHggIfv+qeZRgjEqEFXL1TNvoOEBlT7OtxbPTMXPHDpPNekYRZJLX79LtRJaFvhDMy7o3q2Q== 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=tYj4Aq4H/z18cpo/OR/vwiWEXB53aTYcBr5skHnHH2g=; b=JOLoIB8tJtm5cbGHjKafIC+lyMdGnwiRhSDd8jbVli87sA9cwaSUVaEul76Q7tpoPYhxOqTsiHsvZuzi+JhlO91uojKwxUpA7rcg73+FQjZtHbqnvxNXAAmU1xSypJ1jO+KrsIBv3Q1GhOy4pjxUQzgrqgjCIH61J86+C3dqx3k= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 4 Mar 2026 18:36:55 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] domain: use unsigned loop induction variable in complete_domain_destroy() Message-ID: References: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> <80129c3a-77cb-4cb1-b3fd-128454e3db0b@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <80129c3a-77cb-4cb1-b3fd-128454e3db0b@suse.com> X-ClientProxiedBy: MA3P292CA0053.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:48::6) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|CO1PR03MB7963:EE_ X-MS-Office365-Filtering-Correlation-Id: 934d6cfd-2c7d-408e-5bb2-08de7a14a280 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: cSj44eIUBwT3yyjxQ8vDTTeTFmFarL2IzGYRM8+z88lE3urk5ReUmAr701BLSwOhQ/2OeE2f7b82puZ9uOM4fdWZ1lZXJ9I5lpJeXXPOGCxULsTR5HPqNMiINScbEAUZxON0TnLWmhizbEe4sqmgHo8IDXDIWVkXFHOVtkWeupy/pyZTOV0Zbh8Iozh6BBx7IVLwDn5KDFBQ0wveiHT8V/9QXZDW8wZ0J54I4UxplvQI2bk7iHrUcg1p4EMTGPpKM63kZpRzRRuRGezLulNEz7aqvvTbRM7Q1Y3qDbYIYUdcWSI/H2y/5j4uz90NVPM31RyOZ3KbkQgecxumzXIhwnBCLHZlHOJLAO+UAIImpBy4bb/DEVx+pk0lHUNyPs1a/deX+Gq63d3VA9bsWgMeFl7y3brvKvZC54TNplMMydq/6Z9udLQDKUN+I+xOYFqb4uhuDXdRL/JDgoYP8762NOyxf9cDL+LgSKJizlQxD8ESGn74T4Q/Ie03KnJEn7RDmXha/9nkavCoSxADoWdcTc9jVOexr+aBcaXME81EpPA6ywdwFuxNDGehGGP4tLBIfMkaO/bbRpVRbvo540JLGOltOaaA7DUWMHg4SdPQFkXyeH/5Pz6xUEJKkY47w3URwL0IwMFQ4sDpaF8mEChc/CXB5vtTrackZhtbFlGgiW6ye6rjGl4fhl7OrGO5BQLmD2ujjsCWwN2XXbgCfuQdP1C96z/d40EgGNvnRY7tHNs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aGZGT2M3QTFXald1ZFRXbm1WNXFpQk5ESWJjVzA4TGpIZnZHY0NNS3BlWTZj?= =?utf-8?B?MitnSnVVNTR6WmZJN3ZHSzc2Qm5BSGFTOFJQTTlVSldLNWdLVldDb1MzTW0r?= =?utf-8?B?WHJvMXgySlV3M1QvV1ZueVFkK0JmdFQ0bmxTcEw2c0llVllGRjNKakQ2ME9Q?= =?utf-8?B?MG1Ud0ZkWmxzOHVvWnJmOFBhNkhhTU0yK01uQllZWmhDR01tU2ZzNGFUOEx5?= =?utf-8?B?K1FOd2x1OUE1dGlwQ2ZOeDNvQmxZUXgwNVhtTnhrak5aUmZRUEN0QnBKeVYw?= =?utf-8?B?K3pLdU1EUHRpMjV5MUxzOUxPMEhJcmtPVmFRcEJqbVVBVW0rakVrY0NWMkls?= =?utf-8?B?UFBKYVIrQ1BNaHVTZTlkQkhmQzV6elUzcjlPb0s5OXoyNHo0bnpEd2JrNEd5?= =?utf-8?B?bGpnY3BuckIrV2dGTUM3VWxlUnVDZzhJOE1rcFFlVkVwOGxVK0lWR25EVzlk?= =?utf-8?B?ekp0ZFVFaXg5NTZvTFhNZ2FlSGRCMWJBNlA4UWpqeU16VWM0TnFrRzV6QUJj?= =?utf-8?B?WDhIOU9uYUdqVElaTzB1VlR6ZENpbUxQc3pVV0pFUEhXMTR1VG00M2xQRzJl?= =?utf-8?B?K240UWhCL1hQRGJuK0drWUo4dDJwKzJMTHV4ZGRaTW1NbDkyNVVsRXp3NkVl?= =?utf-8?B?Vjg4VEU3TGIzVURaSDI1Z0EzOW1tTmd3SFJzcnhPOS90QlNKb2RHRlhTOXQ2?= =?utf-8?B?eGYrbmxueEYwYUM5VVR3czY5TnVuenQzanYyS0dFTlRmQlBJczRCNFNzbVhL?= =?utf-8?B?RUZFeWluanZSbWJHQUJOeVVJY3NxK0tiRTNqaUVITnd3MFRzdTdoYnpFYjFH?= =?utf-8?B?cjlIeEFEQkhjMkU4NFlYQ2w5NFJZTmxzeXQ2U2pRTnhFR0phc0w0eVVXRzZM?= =?utf-8?B?Z2JXN2JXZFlRajBTMFlQaDJLa0dKdHJRZFhPRGcrM1dhN1hXazF3KzB1MlhO?= =?utf-8?B?N0t2M1VROGQ0NVdLcEpQRFRGSkVicFRGamN2THRBcWZkbWdzTVEwUWQweEZr?= =?utf-8?B?eEJCNzZmOVpRZTh0YjhLM25VZ0E1c2VLekhXZ3JQYkJpaGptWkticWJPcXJZ?= =?utf-8?B?MU5rbGFqSVlXSFA2aThJVnd3R21EaHlPYnRvRHR3UGRaV1orMnY5WmZGYWZB?= =?utf-8?B?VURZUlVHWkpmSHRLN3hxd0xmTnRNKzVlMUdIL0E0TWk2aDBIcDUrZ09GbnNH?= =?utf-8?B?Sk1UTWgrL01POXZjYWVjM20xN2tMdHdqYmNVT01CTmRmU2F1WGFQcWRxbW92?= =?utf-8?B?THNEajlubi9ja29JYVBkck1SMDdldlZEeVdwYXFVbGpIWW8zZFZHWXhWUE5w?= =?utf-8?B?S2o0cFhGUUtqTGVMR1g4SFoxRVFIUWpEVmxvcGVKamFRQ1JnUlFRbExqYnVS?= =?utf-8?B?bDFPcmtzNmNwSmk3NC93WkpmdUwwSXZ0YUhPRHZWV0k3MzRWc3oyTXkvTTNQ?= =?utf-8?B?Nm44b3NrWVlKSE83Z1lkdjl6NVVKL3poV2QwQ1JTbnFvcFRDbmc1VjVkT2pp?= =?utf-8?B?WUFqaG9pdmIxZFp1NVFLNG9DcUIxc2ZDajdXTEM5UmEzMVA5MHpwdUpFcFUy?= =?utf-8?B?M1RnUmxUUThMeENUMkZLdnR5R1Q3a1A1RjlNRnIwN1Nucm4wc2hWQnlua1ZP?= =?utf-8?B?Ty9BUkp3S0toYWVpalVaR2QwWUlubEkxZWhOT2MwZlJ5Z3V5TG9KVUYwTThH?= =?utf-8?B?SDQ3bXRyUGZWcW8yVzk4eG5Cck93Vk9tL0R6ZCtDY0ZaOWlrSWd1WHhTS0lz?= =?utf-8?B?Y2lrTTlqWEkzUWl6T2U4bS9BQUdzSXBOdU51K1FyT0dyVjh1UU9tRVdVTGxy?= =?utf-8?B?L2NHYXFVTGFmTUw2c1dRazgvejE5RFJZUWx6TGdhRStOZUI5cTA2REp2MDUy?= =?utf-8?B?ekt5b09nczdxcGloRjc0S2xnZDkwZjF1VVdOd0UrTkVCR1dKcHlXNksreE0v?= =?utf-8?B?RGxKTFh6c2w1ZTUwSVFKK3dvRWxOcDdoSXFYUHJQUkdzbHYwUDc2Q0MxOE4x?= =?utf-8?B?TEI4cVluTGFla0l5NWdXMXNrYjNWZmZQRnhzaFU2R1hlSzY0b21oenJ3TnRC?= =?utf-8?B?bDhTdGhmd3drY3RTV3NnSW5QZXJzNFRZRjVUdVpKS3JCZXBJWEVUZWY2Mndx?= =?utf-8?B?dVMyWnlOeEJnRXhueTA3U2JFbW1Nd0FpSGI0UnZ4ZGVsdTk5OW5UWlZ0SmZQ?= =?utf-8?B?UEJTN2RVR0t3UjJiN2FoM0d2Vk9wdDZKLzdPemtNcHU2QjVRV0FKbUVLaVJv?= =?utf-8?B?UWhGTHlSazduMlJQa2dyckowSkg3UHlIVG1WTTNWMzVoOFY1NTE2eXZJRmlJ?= =?utf-8?B?azF1K3dZbWdONTVaZ1ExeFYzeDVWbVVrOHVBUGNZLzQ1emFnYmpKQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 934d6cfd-2c7d-408e-5bb2-08de7a14a280 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 17:36:57.9722 (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: jjnCk8NaK9wW1h5rdOpI6MEgSspme8QVo4qOaf9Zgk6d7NxOCr5caPD3lYPwuY7W4hSLCAokkUGPpy/83ot2rg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7963 On Wed, Mar 04, 2026 at 04:48:07PM +0100, Jan Beulich wrote: > On 04.03.2026 16:38, Roger Pau Monné wrote: > > On Thu, Feb 26, 2026 at 10:01:45AM +0100, Jan Beulich wrote: > >> --- a/xen/common/domain.c > >> +++ b/xen/common/domain.c > >> @@ -1475,7 +1475,7 @@ static void cf_check complete_domain_des > >> { > >> struct domain *d = container_of(head, struct domain, rcu); > >> struct vcpu *v; > >> - int i; > >> + unsigned int i; > >> > >> /* > >> * Flush all state for the vCPU previously having run on the current CPU. > >> @@ -1485,7 +1485,7 @@ static void cf_check complete_domain_des > >> */ > >> sync_local_execstate(); > >> > >> - for ( i = d->max_vcpus - 1; i >= 0; i-- ) > >> + for ( i = d->max_vcpus; i-- > 0; ) > > > > Is there any reason we need to do those loops backwards? > > > > I would rather do: > > > > for ( i = 0; i < d->max_vcpus; i++ ) > > > > ? > > I think it's better to keep like this. The latter of the loops would better > clear d->vcpu[i] (to not leave a dangling pointer), and there may be code > which assumes that for ordinary domains d->vcpu[] is populated contiguously. > Hardly any code should touch the vCPU-s of a domain destructed this far, but > still better safe than sorry, I guess. Yes, you are right. sched_destroy_vcpu() relies on this specific top-down calling. Since you are adjusting the code anyway, it might be worth writing down that some functions (like sched_destroy_vcpu()) expect to be called with a top-down order of vCPUs. For the change itself: Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 04 18:04:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 18:04:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245883.1545228 (Exim 4.92) (envelope-from ) id 1vxqa6-0001a6-C0; Wed, 04 Mar 2026 18:04:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245883.1545228; Wed, 04 Mar 2026 18:04:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxqa6-0001Zz-96; Wed, 04 Mar 2026 18:04:22 +0000 Received: by outflank-mailman (input) for mailman id 1245883; Wed, 04 Mar 2026 18:04:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxqa4-0001Zt-JW for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 18:04:20 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8ec204cf-17f4-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 19:04:17 +0100 (CET) Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by BY1PR03MB7309.namprd03.prod.outlook.com (2603:10b6:a03:52e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 18:04:11 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%6]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 18:04:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8ec204cf-17f4-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ymcZB7avWz+upqpYod/pq+fsiZAHbbvaCVTsEpDhT5cqoR471dzK7HLSQLP1uujj+TEXkrvwifq93ExuqTI+FEUjiHBhwVP8CxtXysxjr+HpvohW4fG1DAg3uTb9um2wQr2UuK8aehW2PHZwlOWhYaFafwyTytU3/hotGOEFPD1KCCVBkjgMphhjRjafDS9EevXpUyB1JbgAih1SOMC31t88cFRB0iC49Ren5U94oEq87K5VplOMRRfsqbCdCEyHxwCj9k4s/WKxnAwztgEUwvyVlsL4znRJsAgjRu53BGkEq8ue+GrJBUS0XQtJzsca7BqK3LjkLQ2E7rJ+K6g1WQ== 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=7dJQeHs9cvZ6btZc71IPUR3teyBS83Ug9Xkx1pLIiw8=; b=S2qZFIgmpWqJLigarlfN0L4nDIkuMBqrqEqwFRdnjgD28wUrDZTE0T4GZ5FGHup6DxTzvg7S4eUbHr4sEZqyrk6iGJlJdVv5W64dw/ZEtjXf5tsAQnkyamvVjNX5X+zYlz1Jm5Ikghtdof6JE7DWd2qbh1YYiXENYnNj/hipn9NCHCsEqkox9hPRbkIiiCzg8K8jWHWqvljDfORArFjoE6RXV7cwFGbSM54ZERKHyKTXziTphy7D49QyezvdNoIm7DUCGve7Bo0/Ou9ssHMLUoKzn16IaSckKEv3vdJClhMRPf+h4/Tbv3Jz0haykEItoAqWHFoTK6Xj3Iy4U/N05Q== 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=7dJQeHs9cvZ6btZc71IPUR3teyBS83Ug9Xkx1pLIiw8=; b=xr3I0daXpgNT/0J6/z6cm8j171ODuFaJDF9gKiWBBqaLPgkEvVVLHFSVM/PTkz/SJQ8abCZY3tzMFNFE9oYMebeOhr2VjZfq6CpnjVDziAjKrzIkKXlh9iaz13t/s5taRmfyG5BQXO7osS3kEw2UjH/Cm10esbM0Xv7G68CV6bU= From: Bernhard Kaindl To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v4 01/10] xen/page_alloc: Extract code for consuming claims into inline function Thread-Topic: [PATCH v4 01/10] xen/page_alloc: Extract code for consuming claims into inline function Thread-Index: AQHcq/LTrNW7h1OyYkqbdUVMe4OBY7Weji2g Date: Wed, 4 Mar 2026 18:04:10 +0000 Message-ID: References: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> <91d2bd4b-7ca8-45fe-9e60-071d2cf2d327@suse.com> In-Reply-To: <91d2bd4b-7ca8-45fe-9e60-071d2cf2d327@suse.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: LV3PR03MB7707:EE_|BY1PR03MB7309:EE_ x-ms-office365-filtering-correlation-id: 34ce544f-516d-4bb7-1cdc-08de7a186ff5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021; x-microsoft-antispam-message-info: D5or6y0hpUL/bObyAQK5z815Dbb0YvWxfSwFu5vJn5gl+a4tS4un3oR3hNfEF8h1/LfYA17E71XA8aRuusdWiqGX7ehoQIF2qOdbXoPvYZK9fbllLqIcPz7+5yne6Gfu83eTbQeruccn0Q7tzWLj6ZbX6X88/oqgx9ZrDDLlJTZYhWhH6TUSilrRVTNfUs9TCNL1yi4vKWH9r5v5dI401fkxOar+JlzyZqveScfc3TjGFpzgoze0LBfCvzuEGIkI15A8mnn3HA+/wxFp1kamgKAczeCxkq8FkJ+7Gr6dmu8b0O1PKkrRXggFFFgEYP4fGksC3wcgzrq2vrlVoF9fhOkM68jTBT5eTDPlfeDH2kEAE+CKuSddkXC9JNJCBnTed6eadxlHSSgGpxkefnzpM4VnbW96Z0uQWyYa79ffsHr6Og9fGjM8Ge9baqrmS9e2S3R0UqL3RrebR7rQnXuqfD5LdUfMuO+dqg7ruHlA8bjEDlo8W8Fe571vN/ZMP8fb8uuo5EiIk0qNeApS6cBd4QiSN6lFSpjZ2SAf8wwrNaGDz55enQTdjjhTOlMq0QuE3z9sosE+CWS5fR+FmqqwPeuGoSpvNSD6uaMMiufG7VEe3BhVC5wmUJWL+Bp9igG3yaDX8zNugKkUJfgmbcxtSQpQd0YCDxitr02zuprVStYUnHjlNn6bMJL3QyQt7ui3Uf3asgH+VK/vG6Ij/LmDG7y7ZO+a0HnFfBgmEh+s6xSTJhjht2hoJ4R6Bxp9cuGwBKLVxo7NVtUULKAhYFzKIHONu2PQU5Dcmudmi9IagV0= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NDNDditqUENmQmR4MlhlSmFyMXJNb3BORzV2RkhOWHFzRnpRTTljVWd2RUpJ?= =?utf-8?B?bzdncVNRSkNac3JJdEtwUGlURSsvaU5lVEs5empHY3FOeFRFQ1hheWxHdTVx?= =?utf-8?B?NlBWMFhBSVY3c3V5UTRJTE9IZWVFVUNycHJ2UlZwT1BsYWJjUkNiczJPZElR?= =?utf-8?B?akFrK2tHQmVUTzJ4MCtNRGQ2bzNFZUZMOUNmV0hlZUxwVG1DSXFaZXg0Nzhq?= =?utf-8?B?YW9TTjIvbUFKc0hncEZ5enp1cWQrcy9rbjRZQVVlYU9GNTZNMHY2WHViSWZu?= =?utf-8?B?YjBBNExWYnpVVjFWQ3VWb0FIYjZmaW9EWmkxeENLN0RsdHJxeXhGZGhqQjJU?= =?utf-8?B?NVlHV1dadGFCVENXUEZQTnI0bm5aeGlPWVBsV0hmcnhwTjRXYzFIQ29KQUUv?= =?utf-8?B?NFlvRFFMT25qMGYxUEI2R1J3cVJPUm5USFNKU2h4ckdaMFRDekYzNzltOE0r?= =?utf-8?B?SWJlb3IvNWY0cmhzVjkyU0F4V3ZnY3pDY0lKeDVNMS92RzNPcVRTOEtvR3Rv?= =?utf-8?B?emtlQ0t5anJsY1EwZlhrWEZrTzRZUnFHa2JndDFGZnNNR2V5YU5vOFlmME5V?= =?utf-8?B?cWhNTXZxcmQyR3YrVXpBQll4QzhTc01FMmltTEIzQkpnWEtCRG9ZVXpKQjNo?= =?utf-8?B?Z3VBWU4wWlhGY283NlhxRXltVHdqVGsyc2VQc044VVR4NWtPT3JyTTUybDJi?= =?utf-8?B?ZDJxS2VnSFpqSVRxMzF4SWoxNDZqWUh4V0FlUmJOYjFpWDVmb3IvVlBUNzFV?= =?utf-8?B?anN1VXdRUmd2elVucmdFeVpZdkZSRnZxdzk4MWhPMER6QUg4bGFhY2xoTFBz?= =?utf-8?B?S1A0V1E3QlF6SzFHVU54N2hBazBWRjJrbmhYRFpMYXQ4Y25seTJ5YW55VW8v?= =?utf-8?B?cUtmKy9vSGozOHRmUXJwbEFIUHpGYko3b1N6Q1JZZW4wMzE4UUJZOFlwbjgx?= =?utf-8?B?UmNQekdDZ2lxeTFmSTNKSHc1MTUzbzVhYkxLM0JSV1FaWmhSV2toSTBkVmw4?= =?utf-8?B?T1M4TTNlYVp0OFFvaUJyU1M2OEVNNDRkamNiSU1JN1gxWlJEdk96a3ltcngw?= =?utf-8?B?aEc1emIyNGh0ZlNLVDBtTlh2QUcwNHhMS2NZUEtETDZ0TmRKTnd0bi9JTFg3?= =?utf-8?B?b0M0UzR1OEJoMmJDSE5HcGxmRG5lcko4Uy8wdUFhdFFmaWRsS0I5QkMrWTlZ?= =?utf-8?B?cjNQRFBBZWJKTDZvTUVjS3dudndDVS92OFYwOE0zQ1YwTXZWVUk3R0lndEJ1?= =?utf-8?B?cVMzVU9RbW43SDdvckJ5NStlR29BV3NJRjExNUpxTjZicFBSaGRHUG8wa1Rr?= =?utf-8?B?c3FCalptVjNzMjg4NHlacXVBTjNkQ2lzK0k3NFhTYjZwTlljV0ptZ0NDRWND?= =?utf-8?B?VEdncElMMGRyZGlPTEk1Unc2RnBZUkJ2T2tKZ3ZyTDZ2cTUvTG42R1J3bmxK?= =?utf-8?B?eGZmTnVDV2FFdVk1SnVzdm9lQk9OWlVvUGFST1o1d0FYRzZ5Y05iZEZtbUhs?= =?utf-8?B?b1NIeStQWDgwOXJqWWN2RmxVL1NPSnZscVJqa3c2VjF6VC9NVXJvdlZIQzAx?= =?utf-8?B?YVFCUVBvalZ5cUJlb3RqTTdMbmV5dSs5bmxWMmVTWFhUV1N3bXBFQ01OVHZa?= =?utf-8?B?YWJJUFZxdFdMbkhZbmR3ZnZJVllaM042Nk0vSytYSVZtSEFTZ0diVUlaWU5q?= =?utf-8?B?bngyMkEyQmlsajc4RWlTZ3NQNzBjQUhTbnBSSXhySEtrRnlBd3J4QTVUeTdL?= =?utf-8?B?QkVNL3hVZW0ycCszZmY0emw3TG9lNmZxVzVWWVhuMkl4aUdKUmpmY3EyZmI2?= =?utf-8?B?M3VPSG51YllFVGZhRDVEeFpZaEF1UkV1RFR5eDNkZWF6MXcrRnpnZEh3U2g0?= =?utf-8?B?MjNEQzFNWVNEMmkvS1IrV1NHN1JhZmVocTRaVUpNOTBNOGxYY2RXaVE5cDFv?= =?utf-8?B?d01hNWFYNDVubkNaVmdKVy9ZODF6a2NwdUllNUM5M1o5bitMUXR4S2FVRHRQ?= =?utf-8?B?TE5JOFU1akxSK1VSR3hlMHhnWVJoaStGcTV6RlFrWmI5NkpHWWR1TGROekFU?= =?utf-8?B?VzZGT3Ftc09VckEvY3paek8rWVhNZWRZcFAralZjUWZBMW1qU3RNZ1hEczA3?= =?utf-8?B?TGhxcEdjRGlNWUs1OVJxSndOeE9yRGZIQi9vaVRFVmNkZklBeWJSVlp0ZGtp?= =?utf-8?B?MlUyVWlBTnduckhCamRXRnVzVU1wUkpOdGtwKzh0ejgvNFdiakV6SklaVldP?= =?utf-8?B?RElpeHVyOWZEUEVVNE0vS29ubjBJa3pTNkZabktDNWViajNEcU5wK01zbUJX?= =?utf-8?B?ZHJBWDFyS2ZSRFowdGp3bGF6dzNkRWswdEVWREgvTzBBZnpiaStKQT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34ce544f-516d-4bb7-1cdc-08de7a186ff5 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2026 18:04:10.8717 (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: tZ3jdcgUSdYjJfxaAjYBkZZFa5KDc3HXsH8osrov1n5J0/fmh+02NHRWp9RpsaBoudC+4yyfSjvRjVqnuCXoyvyD1xJTliwusmT6RpuweCQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7309 PiA+ICtzdGF0aWMgaW5saW5lDQo+IA0KPiBHZW5lcmFsbHkgd2UgcHJlZmVyIHRvIGF2b2lkICJp bmxpbmUiIGluIC5jIGZpbGVzLiBUaGlzIGlzIGJldHRlciBsZWZ0IHRvIHRoZQ0KPiBjb21waWxl ci4gRnVydGhlcm1vcmUgd2hpbGUgd2UgaGF2ZSBhIGZldyBleGFtcGxlcyBvZiB0aGlzIGtpbmQg b2YgbGluZSBzcGxpdCwNCj4gaXQncyBjbGVhcmx5IG5vdCB0aGUgcHJlZmVycmVkIGZvcm0uIFlv dSdsbCBmaW5kIGFtcGxlIHdlbGwtZm9ybWVkIHN0YXRpYw0KPiBmdW5jdGlvbnMgaW4gdGhpcyBv bmUgc291cmNlIGZpbGUgYWxvbmUuDQoNCk9rLCBJIHdpbGwgbG9vayBmb3IgdGhlIHByZWZlcnJl ZCBmb3JtLg0KDQo+ID4gK3ZvaWQgY29uc3VtZV9vdXRzdGFuZGluZ19jbGFpbXMoc3RydWN0IGRv bWFpbiAqZCwgdW5zaWduZWQgbG9uZyBhbGxvY2F0aW9uKQ0KPiA+ICt7DQo+ID4gKyAgICBpZiAo ICFkIHx8ICFkLT5vdXRzdGFuZGluZ19wYWdlcyApDQo+ID4gKyAgICAgICAgcmV0dXJuOw0KPiA+ ICsgICAgQVNTRVJUKHNwaW5faXNfbG9ja2VkKCZoZWFwX2xvY2spKTsNCj4gDQo+IFdoeSBpcyB0 aGlzIG5vdCB0aGUgZmlyc3QgdGhpbmcgaW4gdGhlIGZ1bmN0aW9uPw0KDQpUaGFua3MsIHdpbGwg bW92ZSBpdCB1cC4NCg0KPiA+IEBAIC0xMDQ4LDI5ICsxMDc1LDggQEAgc3RhdGljIHN0cnVjdCBw YWdlX2luZm8gKmFsbG9jX2hlYXBfcGFnZXMoDQo+ID4gICAgICB0b3RhbF9hdmFpbF9wYWdlcyAt PSByZXF1ZXN0Ow0KPiA+ICAgICAgQVNTRVJUKHRvdGFsX2F2YWlsX3BhZ2VzID49IDApOw0KPiA+ DQo+ID4gLSAgICBpZiAoIGQgJiYgZC0+b3V0c3RhbmRpbmdfcGFnZXMgJiYgIShtZW1mbGFncyAm IE1FTUZfbm9fcmVmY291bnQpICkNCj4gPiAtICAgIHsNCj4gPiAtICAgICAgICAvKg0KPiA+IC0g ICAgICAgICAqIEFkanVzdCBjbGFpbXMgaW4gdGhlIHNhbWUgbG9ja2VkIHJlZ2lvbiB3aGVyZSB0 b3RhbF9hdmFpbF9wYWdlcw0KWy4uLl0NCj4gDQo+IE11Y2ggb2YgdGhpcyBjb21tZW50IGlzIGxv c3QuIFBhcnRzIGhhdmUgYmVlbiBtb3ZlZCwgYnV0IEkgdGhpbmsgYW5vdGhlciBwYXJ0DQo+IChp biBwYXJ0aWN1bGFyIHRoZSBmaXJzdCBwYXJhZ3JhcGgpIHdhbnRzIHRvIGJlIHJldGFpbmVkIGhl cmUuIFBsdXMgaW4gZ2VuZXJhbA0KPiB3aGVuIHJlYXJyYW5naW5nIGNvZGUgaXQgaXMgYmVzdCB0 byB0YWtlIHRoZSBvcmlnaW5hbCBjb21tZW50YXJ5IGFzIGlzICh0eXBvDQo+IG9yIGZhY3R1YWwg Y29ycmVjdGlvbnMgb2YgY291cnNlIGluY2x1ZGVkIGFzIG5lY2Vzc2FyeSkuDQoNCkFjaywgdGhh bmtzLCBpbmRlZWQsIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGtlZXAgdGhpcyBpbiBwbGFjZSB0byBp bmZvcm0gcmVhZGVycw0Kb2YgdGhlIGltcG9ydGFuY2Ugb2YgaGF2aW5nIGNsYWltcyByZWxlYXNl IGFuZCBhdmFpbCBjb3VudGVyIHVwZGF0ZXMgaW4gdGhlDQpzYW1lIGxvY2tlZCByZWdpb24uIEkn bGwgcmV0YWluIHRoZSBmaXN0IHBhcmFncmFwaCBoZXJlIGFuZCBtYXliZSBvbmx5IG1vdmUNCnRo ZSAybmQgcGFydCBvZiB0aGUgY29tbWVudCBvdXQgb2YgdGhlIGFsbG9jX2hlYXBfcGFnZXMgY29k ZSBmbG93Lg0KDQpCZXJuaGFyZA0K From xen-devel-bounces@lists.xenproject.org Wed Mar 04 18:21:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 18:21:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245900.1545238 (Exim 4.92) (envelope-from ) id 1vxqqy-0004Od-Qm; Wed, 04 Mar 2026 18:21:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245900.1545238; Wed, 04 Mar 2026 18:21:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxqqy-0004OW-NZ; Wed, 04 Mar 2026 18:21:48 +0000 Received: by outflank-mailman (input) for mailman id 1245900; Wed, 04 Mar 2026 18:21:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxqqy-0004O7-Ck for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 18:21:48 +0000 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azlp170120002.outbound.protection.outlook.com [2a01:111:f403:c007::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 009cef6a-17f7-11f1-b164-2bf370ae4941; Wed, 04 Mar 2026 19:21:47 +0100 (CET) Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by LV3PR03MB7611.namprd03.prod.outlook.com (2603:10b6:408:290::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Wed, 4 Mar 2026 18:21:42 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%6]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 18:21:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 009cef6a-17f7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sLOxQA3bUqKpeA0RY8nfFo1TqVEPEyR/LNFQR8qYKUHSIz1FnDSnETWcEqeNLrUgAvlX3qluQE/b6w37ya8c7j/UEezT6BIgu9U9LVHzC88kEddBu6hsyYzSuT+ubFNlkVKpE8j4tSP2oeX3N8ph7gT/pQPTZf17QOTTHz98eOvC9rsPvJ3xlTpEamCBgVDmckop6mERLzWeLsSDwkhksMhRQB330v9+aqOYzWkbgA2CvM0GVV5FmLheabWUCLkwl67PPu70XKqXk2nCe4gHg8IYdW1zQxvWJavdxuFPzVSpr7F4M0rQOZMFKed/WT00AXGYYoOH/Na82oAf9flm6g== 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=HT8S73pF0AdY20RHfdnN8wYSfqur/qUxBePSwcJeCFA=; b=Yx7oP7WNziXcjxkN7+1gu8n6iUtLmqjnNY5RJJVR9S0r1T6r/S+DF/jtezQggNhUfn3xKHO+efqa95qGj4tIXeAPf0T0x73zHppwgGuQkWRhdrly9zufkAkN3DIj6rcCOidq6qm3RTX0kRwMDDTKl95zMIFi2GNlw06zReJwKUtqTOahVIOzarA9rFuNlDO9ytpYmHoehnV3yeVp3s4u8Z4ud/SjsT9TdS2JVR24Yx90Ij326EOyjNbDcGDXBfOEztwf00nYrhr5cjr7V3ZywG3RxAksvoD+6qMU84IkQ0K4oYI2J58qXo1NX7JbrSzj1cr/R47d80MYp7V38DmXdw== 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=HT8S73pF0AdY20RHfdnN8wYSfqur/qUxBePSwcJeCFA=; b=ibQKt7Pg1pqtfMB7xayAa/EMXFL+A4MHjxyH0VvJz8pMkTDkOdmT6ozt74SGOSX4SxVKWmx5GEmHEVHvLTq7/0iGEYw7v9CQfsGs96WQBatWKux8rq8Jgy5RLrFS+s4eCKYEuhJMZO3itX3nm2A0lJBn7bD/emeWd898o5TLOMQ= From: Bernhard Kaindl To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v4 02/10] xen/page_alloc: Optimize getting per-NUMA-node free page counts Thread-Topic: [PATCH v4 02/10] xen/page_alloc: Optimize getting per-NUMA-node free page counts Thread-Index: AQHcpy3M66O7r2QZuEav6YZwQwz7ULWemlMAgAAa8BA= Date: Wed, 4 Mar 2026 18:21:42 +0000 Message-ID: References: <5e4d4674-1e1a-4902-bcd0-a24fbd13dc8e@suse.com> In-Reply-To: <5e4d4674-1e1a-4902-bcd0-a24fbd13dc8e@suse.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: LV3PR03MB7707:EE_|LV3PR03MB7611:EE_ x-ms-office365-filtering-correlation-id: 21b1d24b-6ffd-4fb9-aaa1-08de7a1ae2c5 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021; x-microsoft-antispam-message-info: eoJN6BKC1GVZw7rZfMmYCYfOQ2L9Ccp1bkjRTqOkv8KgLS4SUsUpKn1KHPDPB3XOcpr9Mvtfu5ZZnj9TY2DnX1IuAcQXJ8R1QWgwGJgZZAvRBg4lsvFEj2SusDP3JpppKZzifu8eGu09BkBmmFxYXbWHh3szcInjim7VrRGB/TUp9aOvAqIT8+OShO3CUw12BsLhiLApzAF1u0OSqFdMgE8olvwiyBDZvabbe1G7bd1AtyGYAZsyXgTOKNS9r+7vH4v00P69gsbrlv5X8lwJap3Hm58ZgvBxV0HjCK+rIJ2jERg1nn9RijRKpTzBW9aAx+/EbUG3CqjyFK5TOfydlRH/m35D35UbaanVubSOY+UHmBDWQ5so9zsQqI9FvF9yGLeJRfQPySBIlEU/nmi/hX2xQsVvk0j192Pqd4gIGumO0vmpB+M/xSLRb6ECpO3llE1G7A5jjNrm4Taa4jq9QlRJkSEYSehiwGaNZKW2V5EMtIVLZisaP1ad0K/62++zjhWyFNbS8Ibt1JoqEVzgqbE2id/XzVHH41tqL9zvCNm69pIa5o3FIVUDaoesV3Mo/2gDzBbSrbLrFwwIgDZw+eKqjIgVMd26jrwK7QGdAIRK6CkOot1Hj20qlLGnUn2Uiz21mIvLXobhsxjX6kFN/7KWr4U90A5S93p4b1sf2wWpttn0A+TY7P2yZQ4tQmKE98W+TwfXKnC5CBm3TojvAoelRbBsBTAhHNUc6bqQBy0EKGx6dZvCvi1C33A/t8zLrsnB5CSKkE3xX/qFgyKLCdM6wJEu5ckkoPFgpm1vgTg= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dTl0RHF1MURtLzFOM3RqNTZyNE5PK0d3ajRTSFFBZFNJNjJDRWVaRFAyczg3?= =?utf-8?B?M1U2cVRFUE9EbG54cmZBNjFzS1k5dGh6dG0yWkFJODZHZDJsK0RlUWQxNW9w?= =?utf-8?B?YU5oa2J3WlcvWXU0dkNlQlY3aklXWHJqeWh0VHRwOW9SZzFDZzdsbFV6QW1T?= =?utf-8?B?UUhwNi9RMTQvRmMzOHQ3dTZFY1lnOU54dWJFTXdKNENTeElER1Y5SXp5L3g0?= =?utf-8?B?R2VTbWpuQWFPb0xXaTFEUHk2Y2dieXdNQWREVi9QcG1MYUpCQUxQYlZ4bjRr?= =?utf-8?B?cnFuRFdSdmdKU2NpY0IzZzh5cDVVMjdwR0pEMEd5THV3cXdPbkJCcEtZVmFx?= =?utf-8?B?Q1JqbTVPeU9DenFTeXpHSmRrZUxKNjJMNVU1ZDNkYlh0cXBHdkJ4SDV2dmNw?= =?utf-8?B?anpzNUpxc2xiQ2QxNWZCUGd3elRuSCtvUlQvaGdtRzFVQk1ZQTVxSnVWTWxQ?= =?utf-8?B?UXhOWm1FTGpJb3RUVDJoTnVHK1Z3dGlaMWZhazNIN2FDQ0xpb2NSNHdnTzBs?= =?utf-8?B?a2x5VHd2YVBuMzRqbWJKZHZiTGtSL3VRby8xd1VVVFhoSjdVc3dzdjdsTlp0?= =?utf-8?B?VUdMK0tmSEROTDBWTjczOVczdFNXM1dnbG1oVVR0eHE0ZzNtbXF1YVliYzRG?= =?utf-8?B?NEZBc3NESjZDSzIvWlFNUG5KQTRtZkxJUE5KdUN2SDdQTTc1ZnN0cUZnVlJU?= =?utf-8?B?RmpFck9STTZ1THY4Z0NRTUY4N3pVWTBJaURIcXozWE9RQjdTM050QkQ2WWZm?= =?utf-8?B?ZXpnc2ZDUjZPUHlSMG9SeG9kdVBXMWVtK09Ebk1Zd0dRRGdGWS9kTW5JR3VW?= =?utf-8?B?Rlp0aThmcG1yUmUrbHRZRm0yYkxRUytDTmhSaHQwc01BamJtb0Q5Y3c3UGpB?= =?utf-8?B?OTdnb2tzMis2dHBCeVgxMlYyQ1JnTXlJNzBwWktMZ0ZTaHpsMHMyRDdzaFBY?= =?utf-8?B?YjQreW1hOGdUS0FibVhhVm1xbVJzYXJOT0E4YkVFWGlOY3RhY2VPQlkyVUZy?= =?utf-8?B?WDR4V0d6U3ZMWkFmMkZqc2w5WHBWQkZDS0pNdmd0TmlGMzhuZ2ZXQXlGbWcv?= =?utf-8?B?bEtkYUFBcGFmdWVaaHVKS0hUdlN0aDdoYm9YQWNybXk0VVhQUDJDNVgwT1lI?= =?utf-8?B?K3U1ZUdTM3NTTkhBL0xmVUcvSjVVY2k3NnNHS3lhVVJybVJ1MDBjRzMybEVp?= =?utf-8?B?WnFRemZuOW0vMzVucHkyNXZvalVNaEh3SU9QZnlWY3lGNlUvdk5TSGVZbER6?= =?utf-8?B?Q2VXdmNUaE8rT0lIbGdiRTBZWlViM25TZG1LTjZnODBuZi80NVBlUGNRS1Zl?= =?utf-8?B?VjVQdWsxVWlaNk1BeXVVS3FuaVR3S2xOOForZ0FIYW5kS2Fwa2FlemJOUkJt?= =?utf-8?B?Q1B1dWs3aisxTmdFNFVzNTZkcUd6M0NVT1k4TVJvZVdtT3BWcXZVM2QybW5F?= =?utf-8?B?eDA1WmxxR3FSR2lkRStuN2JWdU9zOFFVVDdIdHhRRUtQdVk1ekpBd0VqZEht?= =?utf-8?B?TUZ1Z2Mxb0xFbmZUTi93cm9heU13UXVydWJVQWFkam11ck9xZVlQa2QwWUZN?= =?utf-8?B?MTVCTmxCY1BRSzMvOU8yR0NpZ2Q2c213NGhIcjFuSnBTY2llT0FldjlkTzhR?= =?utf-8?B?b0I0UC9rM2lRNHI0MzkrQzV5emFNWEdFWEtRMVZ3SjB6SUZiTjNWUmhxM1c0?= =?utf-8?B?TExHK1lLV20xQUMvSGlBS25qMmZ5SjBuaGtNVENwU0FmUWdqVUl4M3BMS0I3?= =?utf-8?B?QzN3L2dqajlYWTUzT1lTWWlYbUROWGI3SkVOdzFkSlJNOVVkU3dmLytjMkJJ?= =?utf-8?B?WldXeEQ2a05sdEc5NGV0YjdDQklVeTNUaHk1cmVURWxhS0hoMktsWWNVeVEx?= =?utf-8?B?blUrWjRoTEZFbHlDa09xZDdqWk92cm9GSE5WN2wyZzR6UzVoenRQRGYzd0tE?= =?utf-8?B?c2lJUVN1WEE4YXhqV2taN1RFZTl3WVh2VEYwMFB0dzVpUXdKZnFrTUQyR25s?= =?utf-8?B?NTR4N0xYb0xqalE3Y21WUHFpcytYaEp0YmtROFBhTU83OEFKVTdvOXh4WHhZ?= =?utf-8?B?ZGYyVTVISmZWTlpqcWZoTGZpVG9NazhlL0pwRk9ZQnJrdkQ5ZnJpODk0RGhD?= =?utf-8?B?QndheDZVTElxclEzR3hZWi9WMFJETHl0UkE2Qm9JNHZxT0s1NW9hOTVBSHdW?= =?utf-8?B?V0ZFSmxINTRWQkY1N0ZtcTIvdWxjSk9XRkJMR2tNNU8zU1RLTUpBckpYcHpp?= =?utf-8?B?SzFYOVpoY2syNlZEOEd2NTIxcE5XZ2lXeEdmdXNxZVM4NVNXZlNLYnd3NHV0?= =?utf-8?B?MUNwMnpNV2o2dy9RNjdleDRrTEtTVmVYVmIxNUpCNWFtNU55UXpydz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21b1d24b-6ffd-4fb9-aaa1-08de7a1ae2c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2026 18:21:42.4602 (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: UpiDrc0kw0Qp7yMDyoB6QGo7BFY1Bzn1+V2J0eoE0uRIa3s5YoeMb3DX4x2bOCLLM6mXrLrU753gHDgqCpoy23bPuv0CJ/rZhwgr2wTa5jE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7611 SmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPiB3cm90ZToNCj4gT24gMjYuMDIuMjAyNiAx NToyOSwgQmVybmhhcmQgS2FpbmRsIHdyb3RlOg0KPiA+DQo+ID4gQWxzbyBjaGFuZ2UgdG90YWxf YXZhaWxfcGFnZXMgYW5kIG91dHN0YW5kaW5nX2NsYWltcyB0byB1bnNpZ25lZCBsb25nOg0KPiA+ DQo+ID4gVGhvc2UgbmV2ZXIgYmVjb21lIG5lZ2F0aXZlICh3ZSBwcm90ZWN0IHRoYXQgd2l0aCBB U1NFUlQvQlVHX09OIGFscmVhZHkpLA0KPiA+IGFuZCBjb252ZXJ0aW5nIHRoZW0gdG8gdW5zaWdu ZWQgbG9uZyBtYWtlcyB0aGF0IGV4cGxpY2l0LCBhbmQgYWxzbw0KPiA+IGZpeGVzIHNpZ25lZC91 bnNpZ25lZCBjb21wYXJpc29uIHdhcm5pbmdzLg0KPiANCj4gVGhpcyB3YW50cyB0byBiZSBhIHNl cGFyYXRlIGNvbW1pdC4gSXQgaGFzbid0IGdvdCBhbnl0aGluZyB0byBkbyBpbiBoZXJlLg0KDQpP ay4NCg0KPiA+IFRoaXMgb25seSBuZWVkcyBtb3ZpbmcgdGhlIEFTU0VSVCB0byBiZWZvcmUgdGhl IHN1YnRyYWN0aW9uLg0KPiA+IFNlZSB0aGUgcHJldmlvdXMgY29tbWl0IG1vdmluZyB0aGUgQlVH X09OIGZvciBvdXRzdGFuZGluZ19jbGFpbXMuDQo+IA0KPiBQbGVhc2UgY2FuIHlvdSBhdm9pZCBz dWNoIHN0YXRlbWVudHM/IFlvdSB3b24ndCBrbm93IGluIHdoaWNoIG9yZGVyIHRoZQ0KPiBwYXRj aGVzIGFyZSBjb21taXR0ZWQ6IFBhdGNoIDAxIG1heSBnbyBpbiB3ZWVrcyBvciBtb250aHMgYmVm b3JlIHBhdGNoDQo+IDAyLg0KDQpUaGFua3MsIG9rLCB3aWxsIHJlbW92ZS4NCg0KLSBOQi4gSSBk byB0aGluayB0aGUgZmlyc3QgMyBjb21taXRzIHNob3VsZCBiZXN0IGJlIGFwcGxpZWQgaW4gb25l IGdvLg0KIA0KPiA+ICsjZGVmaW5lIG5vZGVfYXZhaWxfcGFnZXMobm9kZSkgKG5vZGVfYXZhaWxf cGFnZXNbbm9kZV0pDQo+IA0KPiBUaGlzIGlzbid0IHJlYWxseSBuZWVkZWQgd2hlbiAuLi4NCj4g DQo+ID4gK3N0YXRpYyB1bnNpZ25lZCBsb25nIG5vZGVfYXZhaWxfcGFnZXNbTUFYX05VTU5PREVT XTsNCj4gDQo+IC4uLiBpdCdzIGEgc3RhdGljIGFycmF5IGFueXdheS4gUGx1cyB5b3UgbWF5IHdh bnQgdG8gdGFsayB0byBBbmRyZXcgcmVnYXJkaW5nDQo+IHRoZSB1c2Ugb2Ygc3VjaCBhIG1hY3Jv IGFzIGFuIGx2YWx1ZS4NCg0KT2suIEl0IHdhcyBvbmx5IGEgY29udHJvbGxlZCwgbG9jYWwgYWNj ZXNzb3IgaW4gdGhpcyBmaWxlIHRvIHN1cHBvcnQgbW92aW5nDQppdCB0byBhbm90aGVyIHN0b3Jh Z2UgdmFyaWFibGUsIGJ1dCBJJ2xsIG9taXQgdGhlIGFjY2Vzc29yIG1hY3JvKHMpIHRoZW4uDQoN Cj4gPiArLyogdG90YWwgb3V0c3RhbmRpbmcgY2xhaW1zIGJ5IGFsbCBkb21haW5zICovDQo+ID4g K3N0YXRpYyB1bnNpZ25lZCBsb25nIG91dHN0YW5kaW5nX2NsYWltczsNCj4gDQo+IEFzIHlvdSB0 b3VjaCBpdCwgY29tbWVudCBzdHlsZSB3YW50cyBjb3JyZWN0aW5nLg0KDQpJIGd1ZXNzIHlvdSBt ZWFuIHRvIHVwcGVyY2FzZSB0aGUgMXN0IGxldHRlciBvZiB0aGUgY29tbWVudC4gV2lsbCBkby4N Cg0KQmVybmhhcmQNCg== From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:10:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:10:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245918.1545247 (Exim 4.92) (envelope-from ) id 1vxrcG-00026Y-9f; Wed, 04 Mar 2026 19:10:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245918.1545247; Wed, 04 Mar 2026 19:10:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxrcG-00026R-6M; Wed, 04 Mar 2026 19:10:40 +0000 Received: by outflank-mailman (input) for mailman id 1245918; Wed, 04 Mar 2026 19:10:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxrcE-00026L-TH for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:10:38 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cb3245de-17fd-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:10:24 +0100 (CET) Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-457-2ohN0X8qP3CPSqcLgNxD4A-1; Wed, 04 Mar 2026 14:10:21 -0500 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-89a0013d87bso47755046d6.2 for ; Wed, 04 Mar 2026 11:10:21 -0800 (PST) Received: from x1.local ([174.91.117.149]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-899ff659b75sm73282246d6.34.2026.03.04.11.10.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 11:10:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb3245de-17fd-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772651422; 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: in-reply-to:in-reply-to:references:references; bh=D0fD55fcz8KZ4PtgIiEuNTP5Fw4Mwe9/ywY1K2zb/Kg=; b=Mcs7K6eSl8NqmMgN0kc4AFD8Xk9fogUDrFYoykk3bzwpIOTHV+HDC1OYCCFRNikQZd5FXV fzRdlw9YSQ/JAwncZXWrp9M1/+oPXC1gj767Qs1i0wyk8KU8c/Ujbo413qY+zRS99GIO3J LLgSvjEKikGhL5tgt0MiWKqS8eUtZ6A= X-MC-Unique: 2ohN0X8qP3CPSqcLgNxD4A-1 X-Mimecast-MFC-AGG-ID: 2ohN0X8qP3CPSqcLgNxD4A_1772651421 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772651421; x=1773256221; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D0fD55fcz8KZ4PtgIiEuNTP5Fw4Mwe9/ywY1K2zb/Kg=; b=MVmYcF3JxpEiGGf/J2EKajOkiHh1+9SI8DTRVWrLkdVGzFHhnuKJeLO0MFKGhTGmrn iLYowj+PviHTPso0uj0haGbxK3Y1zjBAkIcDAmL2miMg5kSgEzZjiqKz5pMFYOhuvtg3 avEuXX/iWVb3+Wi9iangQI8dnJXrP9NEe+3J6LrL6xNpF5kc2acydsC2kt/Twr5JzuCS pY4AKakcjQSKs9j0q5wf8IHPcc4lZmXczevrbt1tjD6RVIHZD5ivjdVVIt7peFzcCprk /9N3CObBnAWbS5SaPP4GgNjQHeHtnAYJHuobRT7xW9a8+H2Lplh/tqyNvwW2b0CtIHeM UH8g== X-Forwarded-Encrypted: i=1; AJvYcCXcdCCXguHsUbrDcfTvn36AMOr0AZaCk6z3gbKxM9fUYlaWSp0WvsFC7eq96wr8LjaNF2UlcGbWYP4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwHq1EW8LLHFJIB1JL4EG3A0+jiPzVCkl2lTgZLp13treCJlIld cYx0zgH4uWT5ku3dQgDo2Cv5Fo8h/qfuA/+nkbZrikAcouA+q/OI9RtB63mB2tLYSDDr1IW+RSe 1dVXLhEWyGoFSa84rxhSzfA2yt0wFk6amICU20J71PUlrMwbmaNBfJo5LlRcHebtN7cOH X-Gm-Gg: ATEYQzydTI0xZUfhf7dvNioUvyjmXTKZTchZrE810KflxDULfirqGg+PS6PuWYpu0J9 7zDQMiicdGBHxhEWOl3uANdzsbj1C8hovrl0XbterQPPv4zbKl9D2sIEBFmGON8LZp4t3+kyiJc nQnL84w73vShDIP4j5I+o4vii9fwNtnS3DXPncX7t4zuDr3SMpqpWljiJ0lLfHYebHWn87Bg0nq uXhFGGedV+DXChVUl8fyqVC4oQpV7/pPzdtFQ0n+w30hv/PoIW3xmwLymBQRtbkH81ineilJh5T F5SjpeCla5yty2Q32vacD9Fge286tK8lHq5hei1eTzSHxq8Vhso0CukwRc+t83eBgOpcBPZQjtG Q++d8HtWmmnchFA== X-Received: by 2002:a05:6214:dcb:b0:89a:1116:b55f with SMTP id 6a1803df08f44-89a1998b398mr41124746d6.7.1772651420624; Wed, 04 Mar 2026 11:10:20 -0800 (PST) X-Received: by 2002:a05:6214:dcb:b0:89a:1116:b55f with SMTP id 6a1803df08f44-89a1998b398mr41124166d6.7.1772651419928; Wed, 04 Mar 2026 11:10:19 -0800 (PST) Date: Wed, 4 Mar 2026 14:10:08 -0500 From: Peter Xu To: "Edgar E. Iglesias" Cc: qemu-devel@nongnu.org, Paolo Bonzini , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 3/5] physmem: xen: Conditionalize use of the mapcache Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-4-edgar.iglesias@gmail.com> MIME-Version: 1.0 In-Reply-To: <20260304015222.979224-4-edgar.iglesias@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: uMkzWZmE2PEkuc7Si-0yoeR3GHkKaIlXRP8-1G8CuKY_1772651421 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Wed, Mar 04, 2026 at 02:52:19AM +0100, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Conditionalize use of the mapcache. This is in preparation > to optionally disable the mapcache at runtime. > > Signed-off-by: Edgar E. Iglesias Acked-by: Peter Xu -- Peter Xu From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:29:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:29:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245939.1545257 (Exim 4.92) (envelope-from ) id 1vxrur-0003ti-Ob; Wed, 04 Mar 2026 19:29:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245939.1545257; Wed, 04 Mar 2026 19: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 ) id 1vxrur-0003tb-Lv; Wed, 04 Mar 2026 19:29:53 +0000 Received: by outflank-mailman (input) for mailman id 1245939; Wed, 04 Mar 2026 19:29:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxruq-0003tT-M5 for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:29:52 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 82ee16b5-1800-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:29:50 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48371bb515eso107980745e9.1 for ; Wed, 04 Mar 2026 11:29:50 -0800 (PST) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439c6129017sm9129316f8f.31.2026.03.04.11.29.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 11:29:49 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 82ee16b5-1800-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772652590; x=1773257390; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=Br0owAO4cMjtqobqDOXI/vXhN4+464FEXKnA6CShxks=; b=S5m1wfypIvX+2AgjELH0YxqqVPhqQrGs10M1SP5faNctMBHjMICoON36rf2gh8Ad3S xbNucnj43Cv0tkXeMHktlqlE4Q0iuWZgGipNfA2dDkFnXGt2g7/t+mWavMcVa2mSFXX7 sRxO+J+VcufczGefnNehxp/UtDxjFgLO1ec0muKBsaXRLdqOQKWkQkIUGtAmUqJOL8h/ UVhC8FfMM5RIU8TEfbEPilzAMIwhdFZdaj84STF/LAkPRbv/E0qaRrUm+Iji4p24uqDE sOL0bM4f8RDSAkI9FPxEfQwdQhdafnSdlNArTj159lomMpOdf4u2Q7q0VAdW8IlEUkGr KTCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772652590; x=1773257390; h=content-transfer-encoding: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; bh=Br0owAO4cMjtqobqDOXI/vXhN4+464FEXKnA6CShxks=; b=VQfvFjC4NDQ3J7oSEU8F+lDLkIUkyqBnIC1kJb06Y44PLK/bXmGZHw9e6RBRT7CjV0 +JcudgtwzJ7SnuRtoUQqWJl3uMrup1e3+WfhDwTegNWcxBlgrqttqtO/YQHtxYhUCgaN vqoad9wz4TEPa7g0PbWRhSpD7xCkdmZqWg/WChs0cxHXJLPeP1IAYSvKb8YLJo89k6vn wZ/2+TKQ5a6HFXj/axnNXoFvvl0/9QKbvEsamopVGdyLC3CZwDY6i9Hz6Fwrt9CvlJVz UKx2y15Vu7CYl1J1kMUoeoktyR+GuuUMlfr1gvgKXn3yCcGL1frmhDI31Nl5ntncTKih VpMw== X-Forwarded-Encrypted: i=1; AJvYcCWw2YbZd908UFvdkGNSYj55LgTkecU9USmtdp6JdqvJRy/QPYbIEZ/0TAp7dz3JwpvevwJpNduzpTQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YwUT1DSfA2tG9NxHIxDPYuIKYoO3pBMBYE4eTCHk5gbTy17+SeQ 6mGwZeuqpKUvcbVo86JOxB7LgPfgeDJi5vvK0qe8WeJOr9yBQeiLAAzl X-Gm-Gg: ATEYQzwqDvAhwkU+vRw79JWwxrC7Nyc4T2SebbUDgKNOf9zVXClzgVhP7Nm+azgXY7A OKk1Dei3ETH7zprRfzvLzQhySdzDhw9B9Drb3ivWVFG3KLCArBPYHbdw2pAlnIqPbM/TTZNqmkB f8kKMPM5BpZCrDGs7E1Wt6swIOjKkUeHEneWZebdT3oYaTiiizZM63dQbx7USsXIeEFbKcS9y7k xyDPiZjcZwoS4J1GyxjO2iFFX15icnRiTQ+gKNcSw9dE6mdEuuM0GHdZBOD0pmuqtfhtwarrcCH mN3EZqjG5ZvEpmYqYzB+YtNPuitfXemiLQCFZDJzCJfR3ocEMc8TVe6ilfP2pzhS81tTZKZ3RvY zx29R1Re5Xb5nMwlaQ0HsPquDjdNenjqIJKzER6TwkpKr3PkUcZ2qcOVzZYt+3vDZpIVd2Ry6yq f1LVJ8jzMmhm9Z3d+ydzMrckomiHXF7QxgYy/mH/f1Fa4O22RYF/h+NJo15z9G/2xD1T9lY81ls Mwytn6dPb8bBg== X-Received: by 2002:a05:600c:1986:b0:477:af8d:203a with SMTP id 5b1f17b1804b1-48519897aa6mr51546315e9.27.1772652589413; Wed, 04 Mar 2026 11:29:49 -0800 (PST) Message-ID: <23b77208-5321-4dad-8974-f943b38ef104@gmail.com> Date: Wed, 4 Mar 2026 20:29:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <6357ad3f-85c8-4fe4-a2c8-8b0a0a97f1b3@suse.com> <32bd2cc9-86ee-4470-af7c-f52838e0c4e1@gmail.com> Content-Language: en-US In-Reply-To: <32bd2cc9-86ee-4470-af7c-f52838e0c4e1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/4/26 4:07 PM, Oleksii Kurochko wrote: >> >>> +void vcpu_sync_interrupts(struct vcpu *v) >> The sole caller passes "current". Are other uses of this function >> planned? >> If not either "current" wants directly using here, or minimally the >> parameter >> wants renaming to "curr". In fact ... >> >>> +{ >>> +    unsigned long hvip = csr_read(CSR_HVIP); >> ... this suggests it's unlikely for the function to be valid to call >> with >> other than "current". > > Agree, I will drop v argument and use current inside > vcpu_sync_interrupts(). Then would you be okay with using current instead of v argument inside vcpu_update_hvip() and vcpu_flush_interrupts() introduced in the next patch? ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245950.1545278 (Exim 4.92) (envelope-from ) id 1vxsHT-0007wQ-S5; Wed, 04 Mar 2026 19:53:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245950.1545278; Wed, 04 Mar 2026 19:53:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHT-0007wJ-Ow; Wed, 04 Mar 2026 19:53:15 +0000 Received: by outflank-mailman (input) for mailman id 1245950; Wed, 04 Mar 2026 19:53:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHR-0007ik-Oe for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:13 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c65a2e74-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:11 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:09 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c65a2e74-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=G9fgIzB/esvZOYKPhZQWNtvoztOjx++wKfgZiuk+ZcatPg6UNquY1Ihx7kzv3QWbquXKQK8yPDH1ZUTFg7op9GTkmJIHJUuC/1xJ8AZ1kkzavCGEF54vv5K0z3w71YF7Ru3kr2DX5RfMDi9wgnwnHsZ4LgTvrIO5tU9DKV1MATeQ/YP/xMpZr0UtA4C+BLfO/yLZGpdYg1IAwX0f38OyOySv+HkSE6jZmnVbwAsn+KFDj6w9rrkvaF/OwKkestXDf0VZ1IQWcBi3kxR1QaKuKqt20eR91f3jOtdL0l7dQicbUPxSD0pQRIJnAFt5qU9bnNvc8drRqobevuafbKJ1AA== 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=73HOYRSmCsvCAcjUm4czWHv5BB3usADT9uJVL/8SOJE=; b=hIsh3GN7R5izIMeVwRyCVbpdTyOJeSNfN5nMsm+FqC09MwDugJHaLrc/zQANJ6VUsBCNYEOV04WvwEOjuoK/xHH0kBDp3NIh7OdMyzg9fwDcQOpYUoBicKCuMr9kzNYERERHKmkOY3AjKGV35tHEXeOJ88O/L5h0V4JIdGZpoQl+XP5N7fok3FWRp/QU0qMTlOgA802MgyzUVMs59jSi9h31xal9z/tN8i6xW5Ei9rwZEn6J+T4s8CoRcPBBmFH+GmlAo43/ktHxwDP+gtsEZdZads46RPAXL+l8JCQ/B9NcZIKcDgXE1iptlHAhHkXg23uiE9mxhzNRntlf2S72Jg== 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=73HOYRSmCsvCAcjUm4czWHv5BB3usADT9uJVL/8SOJE=; b=morUedH0F8U4pnk4+KxPwlawkoMZILwTY/vX1AyQaGaUDmD86g7jXwXaVkBffpoibwgSSd8hu1t2GgH/oaXQYuGhKayvXWZiB8MFyrEFsqpbgxFE5wD1uDicnmA4WsoIg4Ns8rUXbElJ062kjRg38ZrMcc/dQiYAeEyFiob1YDs= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 1/6] x86: Remove x86 prefixed names from mcheck code Date: Wed, 4 Mar 2026 19:53:45 +0000 Message-ID: <20260304195350.837593-2-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P123CA0319.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:197::18) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: ed0d4de5-ee03-4d7b-5808-08de7a27a8d4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: grE54Vd8OFvw+XYt82Qh7eRl3EDyPMsFe9mAfNMsBg+knKNZVstr7rjs4wdKxBATqgjjj4KnxUgcLKWLXVzcGQdAFkEU7y27mlhGS69JvFqyloOS7EoEo9+Xiso2mQMtqoMnkrNyP7kuz88FijqOxcIdtpjPxxYACJErJOH5TqA7CDsJAXxMnzREmf8H/6SpRs2jhbC8QUYjhWNvR5n6UHAx135qzNkTVUK5NSWGdyHB9pJYeHbIUANFe04BCduNXS4qokKVJdqQbfZKGjwlKGKRQpYRGfJgy9CUwNNQEI5oCyQ09xw4z9Rxzrm5BUhtFReYRa352YqnmdmpgMVZ1Q9fCqMmlf47DxSY5t24Whs//DyTenFSv+p4qWLhMZBOKzYjgHmwKlSakscBZ+oQTmTK9Bs5DaGkJx0TWT5W2794s8qqeq0RYcYOxTaAnfbw24tiPVzqeFIQAbNd2dmRW4P8lwt5jm2wRbnoYIA+p5jo3gwJ63i4qlKQ1Nr/uIywXOSrZyLFH2novtpa1I7uPoU4gXau0focgzSYHcK2FWGPT6t32LKIftHr6mQc/dq29q5EokOoJEj0XpyjI5CDY9Bbb1Nx/+yKCRh0dSzeQpkmL/tDpKXo3JhuDPUOxRi6UdI4w1cf+iM6Z+s3XThrUxSPqLhQN5mY4IIuFvp42cNTssGMrEXw6old1tGknohLvi74C26YkoBPHlUtZ4yIMuZXEtH9CrO8zjBA6ZA7iIA= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wR482VTOFudGC0BRMmzFZcbUkpHydyCRq9a9EO3/ZERGxVVIFxVgEkTESgFB?= =?us-ascii?Q?ghFzuy9/78NT5poDipGtXmXy5hJVSvXh1lQs8l+7y/bIxKnv5HdjS+oJJ2A9?= =?us-ascii?Q?wIPnyWOBudRqUzgSxhX8QoDBMoAa+cmvD08k5OMECkwBe9MQSc3laXKnr4sj?= =?us-ascii?Q?hSWkulRLScfZFCGtx+vdk2YDNmqWS5iA3MjkNEFpXXWXWKugM9FTAQ9Rub4F?= =?us-ascii?Q?JMo0LUgkRsfrMGFUiQYNMARPa5jpRuWQ8RUj82/AzwFUgW4HTemxSvK1KCmo?= =?us-ascii?Q?VmesYasX4scF15OjFSgkaGYPIcivILyc689cvppyRypXoUSyUKu4oMSOutRl?= =?us-ascii?Q?Tx4Hyx2pkbImYfymqQAWgm0ksU/uEZsH1BRGQsgArT6WyXMHacLIrva9seLD?= =?us-ascii?Q?+m8z4droblB1y3V/4RdUo1GlnWEQxRsZtSWukgDlle3IUdE+W80cmSnAhQoR?= =?us-ascii?Q?QgjoIvj+X9cNWVvGU/j6y3noEPlrdZZ/Xjb+DFHq8JY6+9fxi4MwOCEHg7el?= =?us-ascii?Q?yRvxC3xhTblRl5DfVY2DzJaksm4uwdDJiBrTt6YVWs7vlqcCJvTtNRaFnpkM?= =?us-ascii?Q?fyWe1G7MmRJL6UAsq0xLg1WEOQid+ZNWGk++5wdyEU8Cf7u5SzERlqYDZ9rW?= =?us-ascii?Q?9rxdBX2pxkPykVJxTZShqmrhiERs1QLoLa958zcA8Ml2Eamo85JiJfiuutVo?= =?us-ascii?Q?GwrlQOkv5JZe6rA4+t7m8Rytd/mmv9B04DEMhDL+UxrtnUS1Ss7HZO26FCRY?= =?us-ascii?Q?/2K7I+1e46Ag+nzf/mwn1SITU1tYEfU4MbUNXNHpGfph6i2YzUoHbs/0OTBX?= =?us-ascii?Q?N2/+BY4JHceFKn6FpKmCIGFitS++S+IAN/4akPIt+184nn1j/dxl5QStUvgt?= =?us-ascii?Q?q7PTK9CpEIjx/7LclT5HI/vjsOQTogtlaZzxwHiHONa46j8IHBYcmyz+13Ip?= =?us-ascii?Q?PS7gyjjJyXTPCRmw1BCaPVy9MfjK4Vx3TsfUmE9m9d/1IvgmyYE6aw3Nuus2?= =?us-ascii?Q?jZULDMHwQM+Q+JfYqy39t6WkSZk9sSD04QsD5XFJdWs89qcraiqSgTFLC4YM?= =?us-ascii?Q?Agm8Qjx/60EMkb6g2d5mBTtmKlxPjWQz9wWpnvT/xT7LApODZub+fW7fGkto?= =?us-ascii?Q?YCMn8PQPGsHi4A2nuF6/aj/EXv5d+fI4HOtsK/OvTXiiJntZXUe+wXv3ds1x?= =?us-ascii?Q?X01hI02oRlh9jmS/PGg5bdFL5f526tYdRwswvskWvTZbnTko4v498KqjNroz?= =?us-ascii?Q?2UrJYIcqrHkfxeFeAqeMSDaFV8XDrxXiM/WfZAlnPBURFXUouv26/hBfnDry?= =?us-ascii?Q?rmUENwcEOKMDEA3M4iZgU5stRvpp/eJFQCBgbmNbsSgvAXxLu8Lb6ZAAF5HM?= =?us-ascii?Q?OX6g9Jd4pEo/o04yhvvC+DltdHZj2idPQCrUKsC53XTqd0E6ogWHyJX0PMnG?= =?us-ascii?Q?SNVSUxzVul7l/cZaVpuc3/o892R1NwV6qFm3gCI97pIV4X3+gvkRgEBFuyTZ?= =?us-ascii?Q?782Ui98qgcZFm5aoHUWzZQOk88UThJ9dkiBJTDosZWh9mvvbceLd620llLT8?= =?us-ascii?Q?PcOMxPVoykLjm/nVpnR90y35d5vAYOjie9K3MjRfWWNKGrG6yJbXGrNd9xwS?= =?us-ascii?Q?sLgZDtlYrPu9VVkLCaJrEJviRreHAmD7vsg7tgwSwxHHwaMQtb5fpM81rLmD?= =?us-ascii?Q?5+/50IzBinJmK8gOyzkkoEQzVTQKmGpoIfoqrB4MMSBSgYUppF9d7Xe69ePX?= =?us-ascii?Q?jN2raAIE/Q=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed0d4de5-ee03-4d7b-5808-08de7a27a8d4 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:08.8986 (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: X78UOGanNrXjtInCwGmhQ8SVpo1ZPn2HtSGws8z3OGxF8DxKbpVeoXwunNZ+oXUk8o1dFXv70MrFFLFiSVVKVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- Changes since v1: - mcheck_init() check for family != 5 instead of 6 and 15 - mce_firstbank() match vfm range - mce_is_broadcast() add vendor check as well as >= INTEL_CORE_YONAH This supersedes the individual posting https://lore.kernel.org/xen-devel/20260302191900.672460-1-kevin.lampis@citrix.com/ --- xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 2 +- xen/arch/x86/cpu/mcheck/mcaction.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 35 +++++++++++--------------- xen/arch/x86/cpu/mcheck/mce.h | 2 +- xen/arch/x86/cpu/mcheck/mce_amd.c | 16 ++++++------ xen/arch/x86/cpu/mcheck/mce_intel.c | 5 +--- xen/arch/x86/cpu/mcheck/non-fatal.c | 2 +- xen/arch/x86/cpu/mcheck/vmce.c | 8 +++--- 8 files changed, 32 insertions(+), 40 deletions(-) diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c index 7d48c9ab5f..fb52639e13 100644 --- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c +++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c @@ -191,7 +191,7 @@ static void cf_check mce_amd_work_fn(void *data) void __init amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c) { - if (!(c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) + if (!(c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON))) return; /* Assume we are on K8 or newer AMD or Hygon CPU here */ diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c b/xen/arch/x86/cpu/mcheck/mcaction.c index bf7a0de965..236424569a 100644 --- a/xen/arch/x86/cpu/mcheck/mcaction.c +++ b/xen/arch/x86/cpu/mcheck/mcaction.c @@ -101,7 +101,7 @@ mc_memerr_dhandler(struct mca_binfo *binfo, * not always precise. In that case, fallback to broadcast. */ global->mc_domid != bank->mc_domid || - (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + (boot_cpu_data.vendor == X86_VENDOR_INTEL && (!(global->mc_gstatus & MCG_STATUS_LMCE) || !(d->vcpu[mc_vcpuid]->arch.vmce.mcg_ext_ctl & MCG_EXT_CTL_LMCE_EN))) ) diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c index 9a91807cfb..901a71157a 100644 --- a/xen/arch/x86/cpu/mcheck/mce.c +++ b/xen/arch/x86/cpu/mcheck/mce.c @@ -23,6 +23,7 @@ #include #include #include +#include #include "mce.h" #include "barrier.h" @@ -334,7 +335,7 @@ mcheck_mca_logout(enum mca_source who, struct mca_banks *bankmask, mca_init_global(mc_flags, mig); /* A hook here to get global extended msrs */ if ( IS_ENABLED(CONFIG_INTEL) && - boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + boot_cpu_data.vendor == X86_VENDOR_INTEL ) intel_get_extended_msrs(mig, mci); } } @@ -564,8 +565,7 @@ bool mce_available(const struct cpuinfo_x86 *c) */ unsigned int mce_firstbank(struct cpuinfo_x86 *c) { - return c->x86 == 6 && - c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a; + return c->vfm >= INTEL_PENTIUM_PRO && c->vfm < INTEL_NEHALEM_EP; } static int show_mca_info(int inited, struct cpuinfo_x86 *c) @@ -596,7 +596,7 @@ static int show_mca_info(int inited, struct cpuinfo_x86 *c) case mcheck_amd_famXX: case mcheck_hygon: printk("%s%s Fam%xh machine check reporting enabled\n", - prefix, type_str[inited], c->x86); + prefix, type_str[inited], c->family); break; case mcheck_none: @@ -766,7 +766,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp) else if ( cpu_bank_alloc(cpu) ) panic("Insufficient memory for MCE bank allocations\n"); - switch ( c->x86_vendor ) + switch ( c->vendor ) { #ifdef CONFIG_AMD case X86_VENDOR_AMD: @@ -777,13 +777,8 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp) #ifdef CONFIG_INTEL case X86_VENDOR_INTEL: - switch ( c->x86 ) - { - case 6: - case 15: + if ( c->family != 5 ) inited = intel_mcheck_init(c, bsp); - break; - } break; #endif @@ -882,7 +877,7 @@ static void x86_mcinfo_apei_save( memset(&m, 0, sizeof(struct mce)); m.cpu = mc_global->mc_coreid; - m.cpuvendor = xen2linux_vendor(boot_cpu_data.x86_vendor); + m.cpuvendor = xen2linux_vendor(boot_cpu_data.vendor); m.cpuid = cpuid_eax(1); m.socketid = mc_global->mc_socketid; m.apicid = mc_global->mc_apicid; @@ -983,10 +978,10 @@ static void cf_check __maybe_unused do_mc_get_cpu_info(void *v) &xcp->mc_apicid, &xcp->mc_ncores, &xcp->mc_ncores_active, &xcp->mc_nthreads); xcp->mc_cpuid_level = c->cpuid_level; - xcp->mc_family = c->x86; - xcp->mc_vendor = xen2linux_vendor(c->x86_vendor); - xcp->mc_model = c->x86_model; - xcp->mc_step = c->x86_mask; + xcp->mc_family = c->family; + xcp->mc_vendor = xen2linux_vendor(c->vendor); + xcp->mc_model = c->model; + xcp->mc_step = c->stepping; xcp->mc_cache_size = c->x86_cache_size; xcp->mc_cache_alignment = c->x86_cache_alignment; memcpy(xcp->mc_vendorid, c->x86_vendor_id, sizeof xcp->mc_vendorid); @@ -1142,7 +1137,7 @@ static bool __maybe_unused x86_mc_msrinject_verify(struct xen_mc_msrinject *mci) if ( IS_MCA_BANKREG(reg, mci->mcinj_cpunr) ) { - if ( c->x86_vendor == X86_VENDOR_AMD ) + if ( c->vendor == X86_VENDOR_AMD ) { /* * On AMD we can set MCi_STATUS_WREN in the @@ -1177,15 +1172,15 @@ static bool __maybe_unused x86_mc_msrinject_verify(struct xen_mc_msrinject *mci) case MSR_F10_MC4_MISC1: case MSR_F10_MC4_MISC2: case MSR_F10_MC4_MISC3: - if ( c->x86_vendor != X86_VENDOR_AMD ) + if ( c->vendor != X86_VENDOR_AMD ) reason = "only supported on AMD"; - else if ( c->x86 < 0x10 ) + else if ( c->family < 0x10 ) reason = "only supported on AMD Fam10h+"; break; /* MSRs that the HV will take care of */ case MSR_K8_HWCR: - if ( c->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) + if ( c->vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) reason = "HV will operate HWCR"; else reason = "only supported on AMD or Hygon"; diff --git a/xen/arch/x86/cpu/mcheck/mce.h b/xen/arch/x86/cpu/mcheck/mce.h index 920b075355..3b61b12487 100644 --- a/xen/arch/x86/cpu/mcheck/mce.h +++ b/xen/arch/x86/cpu/mcheck/mce.h @@ -137,7 +137,7 @@ void x86_mcinfo_dump(struct mc_info *mi); static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr) { - switch (boot_cpu_data.x86_vendor) { + switch (boot_cpu_data.vendor) { case X86_VENDOR_INTEL: if (msr >= MSR_IA32_MC0_CTL2 && msr < MSR_IA32_MCx_CTL2(v->arch.vmce.mcg_cap & MCG_CAP_COUNT) ) diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c b/xen/arch/x86/cpu/mcheck/mce_amd.c index 25c29eb3d2..2d17832d9c 100644 --- a/xen/arch/x86/cpu/mcheck/mce_amd.c +++ b/xen/arch/x86/cpu/mcheck/mce_amd.c @@ -160,17 +160,17 @@ mcequirk_lookup_amd_quirkdata(const struct cpuinfo_x86 *c) { unsigned int i; - BUG_ON(c->x86_vendor != X86_VENDOR_AMD); + BUG_ON(c->vendor != X86_VENDOR_AMD); for ( i = 0; i < ARRAY_SIZE(mce_amd_quirks); i++ ) { - if ( c->x86 != mce_amd_quirks[i].cpu_family ) + if ( c->family != mce_amd_quirks[i].cpu_family ) continue; if ( (mce_amd_quirks[i].cpu_model != ANY) && - (mce_amd_quirks[i].cpu_model != c->x86_model) ) + (mce_amd_quirks[i].cpu_model != c->model) ) continue; if ( (mce_amd_quirks[i].cpu_stepping != ANY) && - (mce_amd_quirks[i].cpu_stepping != c->x86_mask) ) + (mce_amd_quirks[i].cpu_stepping != c->stepping) ) continue; return mce_amd_quirks[i].quirk; } @@ -291,13 +291,13 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) uint32_t i; enum mcequirk_amd_flags quirkflag = 0; - if ( c->x86_vendor != X86_VENDOR_HYGON ) + if ( c->vendor != X86_VENDOR_HYGON ) quirkflag = mcequirk_lookup_amd_quirkdata(c); /* Assume that machine check support is available. * The minimum provided support is at least the K8. */ if ( bsp ) - mce_handler_init(c->x86 == 0xf ? &k8_callbacks : &k10_callbacks); + mce_handler_init(c->family == 0xf ? &k8_callbacks : &k10_callbacks); for ( i = 0; i < this_cpu(nr_mce_banks); i++ ) { @@ -311,7 +311,7 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) } } - if ( c->x86 == 0xf ) + if ( c->family == 0xf ) return mcheck_amd_k8; if ( quirkflag == MCEQUIRK_F10_GART ) @@ -337,6 +337,6 @@ amd_mcheck_init(const struct cpuinfo_x86 *c, bool bsp) ppin_msr = MSR_AMD_PPIN; } - return c->x86_vendor == X86_VENDOR_HYGON ? + return c->vendor == X86_VENDOR_HYGON ? mcheck_hygon : mcheck_amd_famXX; } diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c index 839a0e5ba9..4d6b7d588e 100644 --- a/xen/arch/x86/cpu/mcheck/mce_intel.c +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c @@ -711,10 +711,7 @@ static bool mce_is_broadcast(struct cpuinfo_x86 *c) * DisplayFamily_DisplayModel encoding of 06H_EH and above, * a MCA signal is broadcast to all logical processors in the system */ - if ( c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && - c->x86_model >= 0xe ) - return true; - return false; + return c->vendor == X86_VENDOR_INTEL && c->vfm >= INTEL_CORE_YONAH; } static bool intel_enable_lmce(void) diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c index a9ee9bb94f..4e7c64abef 100644 --- a/xen/arch/x86/cpu/mcheck/non-fatal.c +++ b/xen/arch/x86/cpu/mcheck/non-fatal.c @@ -23,7 +23,7 @@ static int __init cf_check init_nonfatal_mce_checker(void) /* * Check for non-fatal errors every MCE_RATE s */ - switch (c->x86_vendor) { + switch (c->vendor) { #ifdef CONFIG_AMD case X86_VENDOR_AMD: case X86_VENDOR_HYGON: diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c index 1a7e92506a..84776aeec8 100644 --- a/xen/arch/x86/cpu/mcheck/vmce.c +++ b/xen/arch/x86/cpu/mcheck/vmce.c @@ -45,7 +45,7 @@ void vmce_init_vcpu(struct vcpu *v) int i; /* global MCA MSRs init */ - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) v->arch.vmce.mcg_cap = INTEL_GUEST_MCG_CAP; else v->arch.vmce.mcg_cap = AMD_GUEST_MCG_CAP; @@ -63,7 +63,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct hvm_vmce_vcpu *ctxt) { unsigned long guest_mcg_cap; - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) guest_mcg_cap = INTEL_GUEST_MCG_CAP | MCG_LMCE_P; else guest_mcg_cap = AMD_GUEST_MCG_CAP; @@ -136,7 +136,7 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val) break; default: - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { #ifdef CONFIG_INTEL case X86_VENDOR_CENTAUR: @@ -273,7 +273,7 @@ static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val) break; default: - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { #ifdef CONFIG_INTEL case X86_VENDOR_INTEL: -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245949.1545267 (Exim 4.92) (envelope-from ) id 1vxsHR-0007ix-Gp; Wed, 04 Mar 2026 19:53:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245949.1545267; Wed, 04 Mar 2026 19: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 ) id 1vxsHR-0007iq-Dw; Wed, 04 Mar 2026 19:53:13 +0000 Received: by outflank-mailman (input) for mailman id 1245949; Wed, 04 Mar 2026 19:53:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHP-0007ik-JT for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:11 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c3f07a98-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:08 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53: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%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c3f07a98-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SwlM8fkYyZc2IBVBN97fo9+Pca06are4U/czKvcFokNBd1c1LeGWSMy4bz2vzoET2B+CXcRd0uANhWP3RlkWmXt3dSEiC4zARdqUyJhOZSX1vw9LRkvTzAbP3EP7SLHSFbf5X7SQuySvUl/wdQJ0zauK4tKduNkWitlYPQL2l4iZimnZ0B7KZFN+RI6MFA5lL86VixlS1juRdLNnUsCAe/mI8xT+IReI828DP7ODoQe+FqFBqvCWYfdwmIlUDiS21fryeeRm3BfeQ8g1QtBgu8zpKZh73g8tNREEcGNZHLKdYRwywX3+Bs0WVQ90cMllxs8msZ04p6ThySLtFZZF4Q== 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=8qU7HXOlN7etxGerDCTpK0kCfqtMybHf5pJHx9bkqsw=; b=VDgWjVweVbZTK5fcoJHvP4M+OxzzQQYUlgkHJgb5ull/4Lzm3KkWSuSHQUAzd0vNgYlEKlgIWhEgq2Pypl92Id/cba50Lr6IGwK+9n1TLFIg4bKhpE7aEXsaeN7k9DCbHnSPbMhgCUgviMWb1A0dNu2aTmylRJYNYJ3GPx8sSCmgCIWe/MzT4j0ftqSG9Os0BZmQPfJXl6rRTSoDbJNMUNWqeOYKULryLqkIFF2JYibTujfI5Bvk2YTUkXcnndMQdFVqfKLpPGa376OmbrrvCV7y8eJtxCG/R1yWJCUxN/Xthq6lE+hIW+DLSu2urMhFQNua6pk7qB66kjF5cT8VDw== 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=8qU7HXOlN7etxGerDCTpK0kCfqtMybHf5pJHx9bkqsw=; b=H13+FjIgNiqsIKug56LSbBaN4G0li3MXdY2+oTPI5UEPo3PCQ3wAGNlisZR8N6HoaeYNBopdfe0bqPp/BO3R4gEW7ZPriluXzntTMVANZEgzsPcOmrn+z3AlnEJ6mVb+WoaeNqBvziHX2YIUigXdINEhCVRJy41ll0Pfq7N0wNA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 0/6] Remove x86 prefixed names from cpuinfo Date: Wed, 4 Mar 2026 19:53:44 +0000 Message-ID: <20260304195350.837593-1-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P302CA0014.GBRP302.PROD.OUTLOOK.COM (2603:10a6:600:2c2::15) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: ee5b279b-923a-4dcb-8985-08de7a27a58d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: it8/i0ti6jF0IMkAujxTuPyJgBdrP7kPL6npcV3fPBepm8mgy4vthNEdMdCzQHidhBK1LgUo/cMm9vn8Vz2LxHC4KQRc+iOavkx2IjFaN2rPGvYBglkOjFKTjvMC8Z8RtDzOVR5KgiWtN838TAHWGYDoIyOjXHCbuZyTn/KKrzGD2LkgKuSTlsW0/QLvB3/IKWrofc7f/PDfDMmqf2g3y2QYbNxcidv/FWtyYrhAjEHyDInCWPXe22JAxihCaLsjNezbAeBjEsWVdYvjbKDEqkFzr1DAziAS4O2LtrFOfxVnLVpI/Y0a52uAEpTzWcGbUSlfBx3etShk5UVNU/DJy3IOk9SOGGHwL2NWFf7laD8UPyLzaIAcdGkvyTI8d5yK17RtEL8iNQRr0IF10fVyx9jMq+nwzPiZ6YldM+m0akMVvNlOR6qnAw3oI3xHc25V8Ir+7NnTkqL/7uu+u4v0OGw0673f1IGWw40jUOr7/iu4H0c0GG0QtwM+jT0jQMql0hz/irYCf66X8kS9B05U1PrQJnWCQ77pblS+twUz4Js4PSotW2Bu/6wAF+GPRm3/B399WCqj2WIRa9R3RwWJdXHRGriA2P2RGNOvaQi5c2CfMCLrVTUxDTvoTg/oWp4PGQS+XCv1Z5Dix4qupo2z50tBHGgvELoQQP5BUwJ5TMfHGHq1j/N/DM3WJvzh6Qmh1Wox6D4xR/rHqnB8LWnK9Q4qHr/hfGrrpDr3xwsreSU= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?aJzOLNC6zakfOM6cCnkVRVtrgDHEC9AOf5662YI8mmGn+mFF+CLk0a2WfyXH?= =?us-ascii?Q?Y2smm1s4/yCLb1R27VFdLnz49rFsQ5O6V/MaXCmF3bc4+94QXpBEMqdkULNN?= =?us-ascii?Q?tKIJCokFwn2hb7+Q78BzG6uCMc4h7WVZtq2PgwqdJXNdNoV05HyEx6+l1Il3?= =?us-ascii?Q?vXUCHwEenCvF6iU9h8580+T7OwSIqaIfcN2IHtej0eu4qoJyggzAm/N4IyUa?= =?us-ascii?Q?QWdIsegIwHj6L5IofikpwSJcfMSRRh00oyduUhs3MN8NMbwIDMwYxcG/7hUE?= =?us-ascii?Q?cgTO3tiGxd0rNG/LGx7Ug5HOls3CNRi+tWtty/dHvsc3lrz66e8lPEiuCp6Q?= =?us-ascii?Q?Vgq/jSX7ehzFMbTlz1NKsLYTZRQZkSFAAX95stKVm9m7YGKwDXmZglauWb7K?= =?us-ascii?Q?zGBZJxpzZos2PVRL4mK4nl8KpHwPqLydEEXuGSqiW5biIOstXJSKE8i9QxoR?= =?us-ascii?Q?91pzP3wTNmvN3ysqksEGLq3AoY/qYcTE2V9DlB9H4bcnlN3LyQpFxE3Cf8Dv?= =?us-ascii?Q?DbIlblgqjnLlqKVcUZ37M/qHfnD5GTmy96O0ttSegfbFOGMUxh4RNH3u/Q2Y?= =?us-ascii?Q?puaWyz9PsXaUTRw5OZE7aSsZhPQxks7DkMufLi6DKlFoXb4t/sRaNP5sKnEO?= =?us-ascii?Q?xass3kcoqX+XXULkCFr4FgFNuULDOKOmCbiqINQ8rOPyOaRqLoYBurqXwQLc?= =?us-ascii?Q?r/5red9ILbJUtYOvItrDy6AVv6i2Ja3iw85mzr8az8bbB/k9QjYRMLq3dI4m?= =?us-ascii?Q?lApIpc+be6YcWTJyK75SVso0cdIXp9pmVtvwNdP/362WJIptPXNmkKHhXgYc?= =?us-ascii?Q?UT68r3+tzkoBY0QUMEz/aHlhLiRvuHqrOKguG7wTlWH66ODxo72Ux4Lyx0SE?= =?us-ascii?Q?OXYZWCrSFrFrtoqMUQRXgBo6XHWXJZy8Up+o9JzRJuua2iQIYdFsbegCu8ee?= =?us-ascii?Q?ALyHRwWRkXhECxoMVKxl97OC1/TYWKlygwNkabYBus6K6245Oqkmv6pWkKIu?= =?us-ascii?Q?jdQqcwtyZSiYA5+76c/ABN8G+FkdkQwHJ+R3cbqOtAcf5bVMMZzcQy0XLLiA?= =?us-ascii?Q?UzPVJmEOY5jwZMqlbBlW8LL9p1+h4d9bWVfnhMceZ7oGUyBscoFbHM2UwyCk?= =?us-ascii?Q?838Ihqel+mODsd4xVbEIS6RciVwh2Zv5Tg/UF9ksNMQ+Xyr30m0ypLt8w5hg?= =?us-ascii?Q?h8gkSa5iU8pJh0wxJiydiuiawsJe9f1lS3n7HWdm0gVGDrp4LTQY0JDdvd9i?= =?us-ascii?Q?tb82VXuq/39f7Kt2kexsCJFPTIPrGTh59ORqjzWogIb+lmD5RNCfkzlQk3lJ?= =?us-ascii?Q?zs3RNHhnsuVMrt4pipbVFojSMG1Ttw47jsyl8wjC3d4FCF/V+SeX54EtV3f5?= =?us-ascii?Q?Jjgw9M+Hr6WCde4Xg1zs/YSWnhRF/O1LR//fJUk6ywnmcud98n/K+UipB09i?= =?us-ascii?Q?CmJIuquaH2Ly1pEDWM9HXAF/P6jI9HWvy7s6uLGlosIFZOdQ+uFNPO9LN75v?= =?us-ascii?Q?j6hIZRiK+h+ReaZ/jA5tuxqNYzN8hNcvPtgBFXKFCwX0BwF8wohjcNrEOKLu?= =?us-ascii?Q?aIL9Szsjg1Mrj62m5fm4ZOC7zchr94yIMCci9xKS8NdJB4zmzYk5gkLYuaoJ?= =?us-ascii?Q?lz0e9+DjeKqRoazhQNvhojQxwSzoq1c0EtLI07aoYcbh4fhoppIJV72mEcx8?= =?us-ascii?Q?yr71tWZDKICu908Dd/Onivepn9TuML6eNRHDySn2bP/z5KPTpHNd2W/iUOJ9?= =?us-ascii?Q?Xc7GCo94hA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee5b279b-923a-4dcb-8985-08de7a27a58d X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:03.4042 (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: Y4ioeZ2MOb9G5x6KgLRkIYrDZexDVz44MvVkjaFhTDHLpeQPx1foYXTOOK2/yv8y4iqCA1nb3QqQxtM2lbeCXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 Remove x86 prefixed names from cpuinfo and all the places it is used. This work is part of making Xen safe for Intel family 18/19. Kevin Lampis (6): x86: Remove x86 prefixed names from mcheck code x86: Remove x86 prefixed names from acpi code x86: Remove x86 prefixed names from hvm code x86: Remove x86 prefixed names from x86/cpu/ files x86: Remove x86 prefixed names misc x86: Remove x86 prefixed names from cpuinfo xen/arch/x86/acpi/cpu_idle.c | 20 +- xen/arch/x86/acpi/cpufreq/acpi.c | 2 +- xen/arch/x86/acpi/cpufreq/cpufreq.c | 4 +- xen/arch/x86/acpi/cpufreq/powernow.c | 4 +- xen/arch/x86/alternative.c | 8 +- xen/arch/x86/apic.c | 2 +- xen/arch/x86/cpu/centaur.c | 4 +- xen/arch/x86/cpu/hygon.c | 4 +- xen/arch/x86/cpu/intel_cacheinfo.c | 6 +- xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 2 +- xen/arch/x86/cpu/mcheck/mcaction.c | 2 +- xen/arch/x86/cpu/mcheck/mce.c | 35 ++- xen/arch/x86/cpu/mcheck/mce.h | 2 +- xen/arch/x86/cpu/mcheck/mce_amd.c | 16 +- xen/arch/x86/cpu/mcheck/mce_intel.c | 5 +- xen/arch/x86/cpu/mcheck/non-fatal.c | 2 +- xen/arch/x86/cpu/mcheck/vmce.c | 8 +- xen/arch/x86/cpu/mtrr/generic.c | 6 +- xen/arch/x86/cpu/mwait-idle.c | 4 +- xen/arch/x86/cpu/vpmu.c | 4 +- xen/arch/x86/cpu/vpmu_amd.c | 6 +- xen/arch/x86/cpu/vpmu_intel.c | 6 +- xen/arch/x86/cpuid.c | 2 +- xen/arch/x86/dom0_build.c | 4 +- xen/arch/x86/domain.c | 12 +- xen/arch/x86/e820.c | 2 +- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 6 +- xen/arch/x86/hvm/vmx/vmcs.c | 4 +- xen/arch/x86/hvm/vmx/vmx.c | 278 +++++++++++------------ xen/arch/x86/i8259.c | 2 +- xen/arch/x86/include/asm/cpufeature.h | 5 - xen/arch/x86/irq.c | 4 +- xen/arch/x86/mpparse.c | 6 +- xen/arch/x86/msr.c | 4 +- xen/arch/x86/nmi.c | 12 +- xen/arch/x86/platform_hypercall.c | 8 +- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/setup.c | 6 +- xen/arch/x86/traps-setup.c | 4 +- xen/arch/x86/tsx.c | 4 +- xen/drivers/passthrough/amd/iommu_init.c | 6 +- 42 files changed, 256 insertions(+), 269 deletions(-) -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245951.1545288 (Exim 4.92) (envelope-from ) id 1vxsHZ-0008Cs-42; Wed, 04 Mar 2026 19:53:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245951.1545288; Wed, 04 Mar 2026 19: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 ) id 1vxsHZ-0008Cj-1D; Wed, 04 Mar 2026 19:53:21 +0000 Received: by outflank-mailman (input) for mailman id 1245951; Wed, 04 Mar 2026 19:53:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHY-0007ik-3Z for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:20 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c9ac4c69-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:18 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:15 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9ac4c69-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=n38ZjhsGawuyw6lmA6lfhKxwDPGYCWpFChLhtXFi5tLqsRZJ/VYDYcblahoMbqDFmWVXgg1G4DoQdOARRE2UnE/pBxVWfgzYvnbQRa/gHUTw8aGNROMXpRtK0PNeocRs4ePWinS0ZQQ1G2U7/WziYahiLwaRMVD7cckIDri4uTvTQ6cxpObfKmU/hgZhLNWiidns5Vdr/Zu6saRrdjuZ84G560x/0ZeFEkW9y95NlemI1f7XKAk/9DwvoyOdtCL/99tVGEux+11IhIGg6NBNNYvyMev4bGsu6skWn+jfkvsbz79Ps0aB0BsqON7qWpFAhvZ+PSKdkgmRjYpiZhyDwg== 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=a1ZPnGi7r9oYX1eGFu1Ek0cz/C13jvr2b37l7ThSCSs=; b=ryYBbkpVxkYsZjxe/da3Lbaw+dxojxCxj7Kjljt8BE9sxCfdopz+1B8lsJk7P8wJKgpOqUu67PR2mf+sncsKc1s48ZovgfrwkKGtopmP/cM43DPLbOaX1tXvwhvwb3Oe5vyeRe7A8w/b/Fe5JrbBqaygi5nGlxWys9qtRSqxi8rGeKWUdJW+VnLuLFq4IBExUGEcid0SU0UMmPxv2Ci1eWwKU1blD8zLaRWolhuSbPZ+U2PwcOSqES9TGqUD7VEHEGcvtKAAKq8ewvLK8syVT2xzKz6pgimd/eQ98hjf3CQrlUO4D0YDypRx993maLUJFN8EjHg32JQnlFXMMO9ZBg== 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=a1ZPnGi7r9oYX1eGFu1Ek0cz/C13jvr2b37l7ThSCSs=; b=N3766J+zXxvQQJcF8UP6ldCK5QfxDPJv8BIFsobkkNzHTitlpKG4Ir6k9NYZed2mVAB1uK763f9lpBDNWammVSfeW/V4a9b5XAeE2OOMoozQnVPz1/uk0LvBEo1SiBJ7XhPYsfevJim7twlcPxvLW0Dlt2o+RaVHEqj/a4sGqkw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 2/6] x86: Remove x86 prefixed names from acpi code Date: Wed, 4 Mar 2026 19:53:46 +0000 Message-ID: <20260304195350.837593-3-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0260.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::11) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: b1f33329-3dc6-405c-21b9-08de7a27ac76 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: tWAmq6oYFRGC8VMicIQjPiqNWnle07+z7MYU2IxDJ7Igv4MZiZg7LrNPYXP65gCWWrA0SfTEdAck0mDoH9Kvxq761EeJwamKXLlcJmC5/BcvS5QyU6wENk+fTwnbKjBJTS3K2WxJTOSrjtEl/yOQWHsrdbSHeW1YT3W7Pwh2rndh4rf9qn5yiYsYhiZpcQWQA9dzz3iCCHrG75HX9aenPsQLmiCDtUKpCca/SV9mnduUySrIfmztf2JLBHnoxzbwfqHHEgjgA1Fuk6cEgPjSp+p9nSA6CYKhqR2gAT44fTGEpwUvijUh9n1uZCxZk8tywJmZbWGYLXYe1sd5YuEAVDs1jNu6hNqgZfWsJJWg9ahPDNclE+yEKSE2tpeRuPOq5TjQUjCQoZPRFS1Ju6z7PMbgIlluPplh7kL0M4iCdap2/CIVg+h80XXVhkr40cOp8QBVdnleXjnj9uMDCKiWwotWm2V1O7SYQmJnnO7llzOhiTBdF7C67azsjBXE1HwndhbDccGkkbTfKr9vI44X3bfu8SoRceizQrZNQUYkgqqG+nj480aZnt9KDjL3y9rI155E5rjlZNnqc5/xrVxCH/libj0M0GgO2vkf9pqq8pwOoG7/0JabjcVlHeNWLZhznD6yVkW6sMy241SqyrcA5VKu0dwjuoWHAGzshzeqnljpW/M//wzGP5hfF5JLh9aLBKcpKdarxRYk5pC+RMKHJB9BUYDYVDoC93zobw1vzrE= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?05/fWnlVTEMNLaJRrjjWFa7eWJLt4vHDiFf51EBvwEk8Fc0av1kAlByywjDs?= =?us-ascii?Q?kDi5RpvuR8I7g31y0EbYXo3nEsKl0HFNkZiZh/OPr54myVAfRNAi8/uFx++E?= =?us-ascii?Q?K9RjeQFWF43AqkFHUm9wVDQ3Y0x5K7JPwrmYfa6BaCo05cPTDSabLU1Lp7tf?= =?us-ascii?Q?AYyB+wvTVfmMxJHNGvwJ7dr2Gqs2iAIYg3VrCGguFXSSSF5jR0VHu0bIwxB0?= =?us-ascii?Q?SIWvHrQGjhOaV88JledSfcjiIy/z4TUpGj3g2n4PX1W8cpJDAjnE1t2VpirX?= =?us-ascii?Q?iE3jcPEKZFlt/8naCaoviaOAZRfurISz72rhTiWMMvSFNQ/3r6LnqRhIThDN?= =?us-ascii?Q?u+tbLENKqXOwUAsqpmim+dhYsnigABhfanJ+3nMBzhoQ+rk6LBmo+WtGGE35?= =?us-ascii?Q?ckVcK8a1etFv2a3+kyQ0qiLEUXHEiPY97g636RAMv1EanHzGGRPwBPZTweA5?= =?us-ascii?Q?mlucEAoFHhhGbo4vHplHdry+heFNugJBVnKXpRyXauNUm5tSUmad6Jr5nDgA?= =?us-ascii?Q?A2NrZ9wJHrVq/AZ3DH61sAOeULyM9gMItVvOkrQRt7uFxCMqsN2aWpr+Amfw?= =?us-ascii?Q?ykSe1fbIU/NhwGknMEO67z39IPmYM6Cv9/QgK/6yCXTamKn8KB9IuO/Qm1ks?= =?us-ascii?Q?g6Ao+Q1cPNoKLlSF1Uh0ftCn1eC+VNL7X632fbCFaujpRB1snx2eEq3KoATK?= =?us-ascii?Q?OdoOBR/hnORYDDPRyd/fT0v4Ck88mOQuJpH2mxgu3EgYycNxRf2aEw70iUUN?= =?us-ascii?Q?odxREy0eaWUbjr75rTywBIHXnPtKElZUyxVMO+JZwReqcTZjOB/6D+7PuBiD?= =?us-ascii?Q?a0HsKjJmmtH0W4r8YoJKKTt7s9JpbMjzgB68pXJmy3H3SBgVOTTiJRQdDGzq?= =?us-ascii?Q?WofzJHYwGhcpWihlbqWoWaZ8vZMN/qFa1UXlsoO3ChSyU/FgegxzAdkR/pPr?= =?us-ascii?Q?LkEFvhtRO4rL7Gk3eTjwkiJTXSifzZp48H8zUgd2ZMF0r8v/OktumHxgeAwO?= =?us-ascii?Q?IaHsr7Ck4zEsp1G0i3M/4r1nV6Y8T0HckkXkcdIDA/yn6PxQmEJiu4vh4Nfr?= =?us-ascii?Q?Yy+RUKa/wJNOq2meBZIL+UpOi/dXd+4R3YZDK0x1EgH90A2GqFLApcD4OrlR?= =?us-ascii?Q?25Llm+pkdXZBIqycujxvRfTceadlWaeNW+WHa0BNrPiooU1R/x6fweelK0OU?= =?us-ascii?Q?PkCJyV8KZYLAxdrmio+pIqS3XC84GpcHiLXJmZcUpreNpFs+KUKlmdF7dkCO?= =?us-ascii?Q?ILHMZH/76bY6zkG0ByWNdoyOmfC1ItLStDKH0FF2eOAOSL6/P2yOHIYPw4UB?= =?us-ascii?Q?YhTnsKTsG5/iSFH3JMn9w2e+VT/tkxQHNCmTbTGkJYl46PC3+VFrP9T5U2gm?= =?us-ascii?Q?ul+V40R9E5KX66oHzDIIY3MshV+3YQ1aAcenWiis0zEWIWmZaQPz249ojiPo?= =?us-ascii?Q?y4UUXWIfkNP9+ADrtExq2HnY218vW3AmnCHr2RjQWQXou8Zp2kvTa9P+tBdw?= =?us-ascii?Q?KXZehPxks8aZyORJ26XdUkwHpHUoRYtZV83OkZlAr2DbD2WDUvESm2gY0MxN?= =?us-ascii?Q?+RVzpTGSsAbKRnp+zhcuss/Ccuf/8h1pM+HoTGS3mXa34uwo2gODrRXMqans?= =?us-ascii?Q?qsBjqY5aJutG/2i9dpgVbEvuH/QRDDHQfj+sbdb1bVnYW+9ctC2d+FDKFdzF?= =?us-ascii?Q?r6rkqF+6l/Pa7Ltfvanom0TyCejmnAJupO9xkXkzD5yz7VoGSORj+MybMEAW?= =?us-ascii?Q?EB99WmICKg=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1f33329-3dc6-405c-21b9-08de7a27ac76 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:14.9687 (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: KdOXM5OepvSdeokTNldoEk4ABtZ0Pj2ZF7RY5a+m2Qoz+e3SSBgBX6uxqs2kd++pteHU1LCF+178C8klR+Y8dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- Inside do_get_hw_residencies() there is an explicit check for `c->family != 6` Do we need to add family 18/19 support here? --- xen/arch/x86/acpi/cpu_idle.c | 20 ++++++++++---------- xen/arch/x86/acpi/cpufreq/acpi.c | 2 +- xen/arch/x86/acpi/cpufreq/cpufreq.c | 4 ++-- xen/arch/x86/acpi/cpufreq/powernow.c | 4 ++-- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c index 0b3d0631dd..1d2ef776fe 100644 --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -178,10 +178,11 @@ static void cf_check do_get_hw_residencies(void *arg) struct cpuinfo_x86 *c = ¤t_cpu_data; struct hw_residencies *hw_res = arg; - if ( c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6 ) + /* XXX Does this need to be extented to include fam 18/19? */ + if ( c->vendor != X86_VENDOR_INTEL || c->family != 6 ) return; - switch ( c->x86_model ) + switch ( c->model ) { /* 4th generation Intel Core (Haswell) */ case 0x45: @@ -915,7 +916,7 @@ void cf_check acpi_dead_idle(void) mwait(cx->address, 0); } } - else if ( (current_cpu_data.x86_vendor & + else if ( (current_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) && cx->entry_method == ACPI_CSTATE_EM_SYSIO ) { @@ -1042,8 +1043,8 @@ static void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flag flags->bm_check = 0; if ( num_online_cpus() == 1 ) flags->bm_check = 1; - else if ( (c->x86_vendor == X86_VENDOR_INTEL) || - ((c->x86_vendor == X86_VENDOR_AMD) && (c->x86 == 0x15)) ) + else if ( (c->vendor == X86_VENDOR_INTEL) || + ((c->vendor == X86_VENDOR_AMD) && (c->family == 0x15)) ) { /* * Today all MP CPUs that support C3 share cache. @@ -1059,8 +1060,7 @@ static void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flag * is not required while entering C3 type state on * P4, Core and beyond CPUs */ - if ( c->x86_vendor == X86_VENDOR_INTEL && - (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 14)) ) + if ( c->vendor == X86_VENDOR_INTEL && c->vfm >= INTEL_CORE_YONAH ) flags->bm_control = 0; } @@ -1416,12 +1416,12 @@ static void amd_cpuidle_init(struct acpi_processor_power *power) if ( vendor_override < 0 ) return; - switch ( c->x86 ) + switch ( c->family ) { case 0x1a: case 0x19: case 0x18: - if ( boot_cpu_data.x86_vendor != X86_VENDOR_HYGON ) + if ( boot_cpu_data.vendor != X86_VENDOR_HYGON ) { default: vendor_override = -1; @@ -1648,7 +1648,7 @@ static int cf_check cpu_callback( break; case CPU_ONLINE: - if ( (boot_cpu_data.x86_vendor & + if ( (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) && processor_powers[cpu] ) amd_cpuidle_init(processor_powers[cpu]); diff --git a/xen/arch/x86/acpi/cpufreq/acpi.c b/xen/arch/x86/acpi/cpufreq/acpi.c index d0ca660db1..de67f1aee2 100644 --- a/xen/arch/x86/acpi/cpufreq/acpi.c +++ b/xen/arch/x86/acpi/cpufreq/acpi.c @@ -454,7 +454,7 @@ static int cf_check acpi_cpufreq_cpu_init(struct cpufreq_policy *policy) /* Check for APERF/MPERF support in hardware * also check for boost support */ - if (c->x86_vendor == X86_VENDOR_INTEL && c->cpuid_level >= 6) + if (c->vendor == X86_VENDOR_INTEL && c->cpuid_level >= 6) on_selected_cpus(cpumask_of(cpu), feature_detect, policy, 1); /* diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c index 5740c0d438..9ef62b3538 100644 --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c @@ -133,7 +133,7 @@ static int __init cf_check cpufreq_driver_init(void) ret = -ENOENT; - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_INTEL: for ( i = 0; i < cpufreq_xen_cnt; i++ ) @@ -252,7 +252,7 @@ __initcall(cpufreq_driver_late_init); int cpufreq_cpu_init(unsigned int cpu) { /* Currently we only handle Intel, AMD and Hygon processor */ - if ( boot_cpu_data.x86_vendor & + if ( boot_cpu_data.vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD | X86_VENDOR_HYGON) ) return cpufreq_add_cpu(cpu); diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c index beab6cac36..55166eac72 100644 --- a/xen/arch/x86/acpi/cpufreq/powernow.c +++ b/xen/arch/x86/acpi/cpufreq/powernow.c @@ -143,7 +143,7 @@ static void amd_fixup_frequency(struct xen_processor_px *px) int index = px->control & 0x00000007; const struct cpuinfo_x86 *c = ¤t_cpu_data; - if ((c->x86 != 0x10 || c->x86_model >= 10) && c->x86 != 0x11) + if ((c->family != 0x10 || c->model >= 10) && c->family != 0x11) return; val = rdmsr(MSR_PSTATE_DEF_BASE + index); @@ -157,7 +157,7 @@ static void amd_fixup_frequency(struct xen_processor_px *px) fid = val & 0x3f; did = (val >> 6) & 7; - if (c->x86 == 0x10) + if (c->family == 0x10) px->core_frequency = (100 * (fid + 16)) >> did; else px->core_frequency = (100 * (fid + 8)) >> did; -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245953.1545298 (Exim 4.92) (envelope-from ) id 1vxsHe-0008Vk-EC; Wed, 04 Mar 2026 19:53:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245953.1545298; Wed, 04 Mar 2026 19:53:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHe-0008Vb-BC; Wed, 04 Mar 2026 19:53:26 +0000 Received: by outflank-mailman (input) for mailman id 1245953; Wed, 04 Mar 2026 19:53:24 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHc-0007ik-Ij for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:24 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cbc687e3-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:21 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:19 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cbc687e3-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s5FrXUw11Ok8BT/ZirIWInhg8jIoCMqChP+Mdj0FNLx6nVrL751YhteT3kxSwQDuGNltMj325E5Bqmb9T0ovY/MayWb5kQsF1+E6YtJW/SyDd1Nzv6JLTfim5uFoooXKzh459c+qco1qB9R6KWv2VKEKhhQKipPPQEIukRtSltrSu6mMo2ZEkuKMgHfeJhIWYAvVMCD6Rr1BDw9V2WjnaAgI6F4afyFU9NHIeGJT4LMUPqkyioMWP2wq3MzIHRpmvmbmEPeV7IXSvVzHivHMlF+K8WeSYXttqW6kFpj6X4soOJ9VOIPNhge6Zs52IvxZGKlci3SVtKdPEcJ8vbV1NA== 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=hPANznstjJv8a9l5wYBDzqoZVdkqO/BbwSmXViXUd2M=; b=YyJrn3+kt4mDci4QBEH91laDIxS3iNx/MfYWBAfF24sgIWLIDAUtgrs5x8ZvbgXFV4p9FXZww5eiijiRduQdJXvixKkve+jwWRK3qSBhUMNqo2jz1QtBvINGGMa9YQ/sIPWE0zSgJ38Tkf9ePghRoLExDAZjzqtSRC9nAhJq5K1FBC7o0344i2H862E+BqlIZf1B+lx0Uq9Sl/EtYTbQoGFHqup6/5W8NaL5RrwL6TF52BmElhtmQ55iZ6J/fjauo4sFlHc4N4wdVMW5Fdt0f44j660QqwS+LI30hdhZpkh23TmvR6Mq+jNO5AkIBBuU1tRxB87R2RHMVVU+oWyTlA== 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=hPANznstjJv8a9l5wYBDzqoZVdkqO/BbwSmXViXUd2M=; b=vJE1UHM+LcISvaiBLa8bM8rUKsyid+in/M49mGCISkYfndKn5S3AiQgfjr4cRlQ8LdkfdAcfr5ro3pFbST3wVnwKT7fzbdlD3nk4tBryHsSsMCcGfdKANOewpHpFnduKmknbp8Ggzm7dWf/TEK59poq8zpHvZgrEQMaVFV8kWRM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 3/6] x86: Remove x86 prefixed names from hvm code Date: Wed, 4 Mar 2026 19:53:47 +0000 Message-ID: <20260304195350.837593-4-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0253.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::6) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: b8014dc9-3350-4c69-eec3-08de7a27af22 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: 2CAuK6Ta2xQG8FFIkVwmA1OW0T8qcdUgcDjHDkbvX7uoP1f399dDiT6rVReeFdiJv6he3HICQto3/5WjcgbLQTJDp+SiJzSJFAitAWZtRY29EuVFtwtQgbR89U0/SfcDlrwbpVASnw2QgYDWLiJWKf5xIIYlExfZxpCekEhSj+0WRMZzVpdC6eXgKHt7rD9Pz+9Ht78JldWBk5s5cIjlhkKfritxIfVXKZ/8BGTwTJYhrDtoPC2bQD0nGVkueIDu8ld/sWqax5KAU1FmWkb9QD+Dk1+BtZD14LAzptN7LU0H6P4WghuerNwBUvatf1vBQa/Z7yzqJShkz5XifpMor7Lz58JsvuokXf91gbrRMAKlT0wH4nhGDFiHWyI9g5P4Cf52kJ9LoEHNQtrpheo3VrkUwAjFOddm9wavmGhHMvMFwmLPwl5OsAemV1rr3tRv+XeXnV34qzvnnDApW4uTa8y1TCY109PUUvh38ywWuYzz2Bp8k7sb/xF4FUyRPr5tTmDRHURwbrt+PbtvREHF05L+H8imkNNDhXWx264xaK7mEUBYTfyDdUkUJ6uE2BwRMfi9EfIaQw70GaVoqhjPTBOFlEAuk7M62OxNg6opRbMmuLW1Y5YgdElQZEPuKu9vyPlw4bfZ3Z7BMAsZxAk+gE7ZENAtfwo3RhpGV8TNWQYKeMAl3yMTD/wNnxTfwLcX8tdEqacyS0UdSEhA95wuAB24YNuehuL5RbFuNnx6RlU= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GB/rLf23iHYAU491efqXTTjy5o7BYoMk2OTog9on5JtU4Gv/8RVpTzNQKajF?= =?us-ascii?Q?1d6pAm0i9PWaM4yI4ZOG4bTNXw1OexDUrXAcpsqPqBLU7fVnNzU46HaA1K1e?= =?us-ascii?Q?V1C3wj6odnvQ6w4uZmV0JWigUoz6AOq1n813gVmLGNNYryKYTIaB5/hAecj1?= =?us-ascii?Q?9k9Z2kk9zsRWjKAUP+iYscC7AF5Q3SkkdXbDprzEuBDT2camFzOilI/Q2kSj?= =?us-ascii?Q?bABsewMik4PvsF5oymnP46hZI1R46+8ngVYBrgqys1v8Y/YjMQzP3BbRdeY0?= =?us-ascii?Q?5OQJVohnCaD8SpWj9tdrcNfPXBC835CYdJhAXhA9ATYZ3jdZSwjBfYPmaspb?= =?us-ascii?Q?2gKR2QB9e1j1BUX+1SD+ZRqvkBWzPUwdy2kagugT93AEmPY27dGcTMXbHoVf?= =?us-ascii?Q?RvqmC0NuNv2W882ztxIZ/uRUuoFse87Tm2CyXvqPuehSLG+Qzjw8DU1O4djR?= =?us-ascii?Q?x0HGChN4txa9ddbalP2UXyurSV+kXacCyU/IAke+CAtPZBbQGrbtyfg/9nSJ?= =?us-ascii?Q?OsuAffG0lqI5r94gDTXdksK55H/4+sJ04csyMGGNLiNOFuFxkmWaC1ckuB3T?= =?us-ascii?Q?NNTvXW/XmpIENQveu4ynSrzwBzo1TGTt8aGaQYE4bkikOqQUR7g2K03vpuWG?= =?us-ascii?Q?gOrHDmH28CZW5nyAoJGksdFkoouZaqrNCyBt4Tvlf6YwUYF567M0OBTbWyYJ?= =?us-ascii?Q?0V4Bk0DqlUcz9GGBTnn3burYNXf16lvell4ncnh2acx9G3P+pnd1FRWXbDgj?= =?us-ascii?Q?M7DSVNsCJN4+TVL3L276cGrOfhF37jegWsHxH4iHHhDo5uZpFsVs5SHGxS8X?= =?us-ascii?Q?sy2L2iLLkUVLN2htcOpmRFkNFDrP3umNl6I3JcDXdE5+gPBLUH6VyaAat64b?= =?us-ascii?Q?Y+JiJRGpU9qKLH+1f8Nsd5oHaByWsVaSV25IezrWgGIEmgvzdjc9UIEQLTRQ?= =?us-ascii?Q?a0oQAO2qQKqF1yNnnTS66pIgp+gSX03R1wECn1vEtMn4Qohm309QCZp8dk1i?= =?us-ascii?Q?G+LTNqwo5C1DoVk+i0aZOOVORBo8M/RiO07T41+k7wM35qsFs+A++C1G1x3v?= =?us-ascii?Q?uDsl69k97t3GmjU3dMY1Qj+OJJxuUMm7vkZV/Xh6PEqEUvhI8t/JXthApEkD?= =?us-ascii?Q?BsWTefivYbCJTwiM4xVoWGSJAE4n1h/1PEgePh7XE5XDgkBfHN9H2qTMLsgL?= =?us-ascii?Q?+y6XOWvwoDn5+fM2XTOrMLvsjlJxuVhrd1ARnl4sqw65ME9mbVLQPKAJjclZ?= =?us-ascii?Q?30vTAVWoJByc9qSZHSEwiU8CL3AayxiY7zgDo8QW2QI2F8USSeUKGwU/ubd8?= =?us-ascii?Q?AXZVjHajuRs89YBLRnzQXiBeEBeRbuYzaLX+CyH2fW+Lnx12re+VrSFzTDM7?= =?us-ascii?Q?RevQwajg5Xg7es9wKfSHSZa9NENRrQD3QFMP2pfIF/OQvrgBZleaORSMJZF9?= =?us-ascii?Q?XWuhpIGABAP9UkmpfrQQZ9Zp0gZRWU4Ufc4HhpMTxbIQ3wAB3r5HPexklLgR?= =?us-ascii?Q?btbFYcR5nB+jLD8Jo44cgsHskzHulu5lSU0Jkbe12HJ6LI2dTTeWnqiEdhUt?= =?us-ascii?Q?uKYTO7YQpXX6hh30Li7C0QZfPKDzJSG2A4BHoQX5XuscJxeh5+ETSC4zPE3H?= =?us-ascii?Q?B5N+sxfiOfpU31KJcodoY1P+oEgkWfego1OMpoIcecVP33REE6aLKVKEHBNS?= =?us-ascii?Q?H/g8gxOS64ucS1/YqGiW50HQjj65wNcEZb3+MrzBkOUeZKaAXeX4a8pEMrl3?= =?us-ascii?Q?Cez9/GU0JA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8014dc9-3350-4c69-eec3-08de7a27af22 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:19.4529 (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: O3S66BRmQPtyJSh2XTrtx4MJay7sB+zAsVyT5GJeU3hXvs5IR5NgAilpXyAPylW4jUz3lWpAeZSeFu0gduvrRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- I couldn't find any information about these Intel family 6 processors: model 0x5d: /* SoFIA 3G Granite/ES2.1 */ model 0x65: /* SoFIA LTE AOSP */ model 0x6e: /* Cougar Mountain */ Should I add them to intel-family.h? --- xen/arch/x86/hvm/hvm.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 6 +- xen/arch/x86/hvm/vmx/vmcs.c | 4 +- xen/arch/x86/hvm/vmx/vmx.c | 278 ++++++++++++++++++------------------ 4 files changed, 144 insertions(+), 146 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4d37a93c57..6ad52e1197 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3850,7 +3850,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) { struct vcpu *cur = current; bool should_emulate = - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; + cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.vendor; struct hvm_emulate_ctxt ctxt; hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 18ba837738..1320abe392 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -590,7 +590,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) u32 bitmap = vmcb_get_exception_intercepts(vmcb); if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.vendor) ) bitmap |= (1U << X86_EXC_UD); else bitmap &= ~(1U << X86_EXC_UD); @@ -1057,7 +1057,7 @@ static void svm_guest_osvw_init(struct domain *d) * be conservative here and therefore we tell the guest that erratum 298 * is present (because we really don't know). */ - if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 ) + if ( osvw_length == 0 && boot_cpu_data.family == 0x10 ) svm->osvw.status |= 1; spin_unlock(&osvw_lock); @@ -1791,7 +1791,7 @@ static int cf_check svm_msr_read_intercept( if ( !rdmsr_safe(msr, msr_content) ) break; - if ( boot_cpu_data.x86 == 0xf ) + if ( boot_cpu_data.family == 0xf ) { /* * Win2k8 x64 reads this MSR on revF chips, where it wasn't diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index c2e7f9aed3..d3b1730f1d 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -2163,8 +2164,7 @@ int __init vmx_vmcs_init(void) if ( opt_ept_ad < 0 ) /* Work around Erratum AVR41 on Avoton processors. */ - opt_ept_ad = !(boot_cpu_data.x86 == 6 && - boot_cpu_data.x86_model == 0x4d); + opt_ept_ad = !(boot_cpu_data.vfm == INTEL_ATOM_SILVERMONT_D); ret = _vmx_cpu_up(true); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 82c55f49ae..c332d5078d 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -34,6 +34,7 @@ #include #include #include +#include #include #include #include @@ -502,72 +503,75 @@ static const struct lbr_info *__ro_after_init model_specific_lbr; static const struct lbr_info *__init get_model_specific_lbr(void) { - switch ( boot_cpu_data.x86 ) + switch ( boot_cpu_data.vfm ) { - case 6: - switch ( boot_cpu_data.x86_model ) - { - /* Core2 Duo */ - case 0x0f: - /* Enhanced Core */ - case 0x17: - /* Xeon 7400 */ - case 0x1d: - return c2_lbr; - /* Nehalem */ - case 0x1a: case 0x1e: case 0x1f: case 0x2e: - /* Westmere */ - case 0x25: case 0x2c: case 0x2f: - /* Sandy Bridge */ - case 0x2a: case 0x2d: - /* Ivy Bridge */ - case 0x3a: case 0x3e: - /* Haswell */ - case 0x3c: case 0x3f: case 0x45: case 0x46: - /* Broadwell */ - case 0x3d: case 0x47: case 0x4f: case 0x56: - return nh_lbr; - /* Skylake */ - case 0x4e: case 0x5e: - /* Xeon Scalable */ - case 0x55: - /* Cannon Lake */ - case 0x66: - /* Goldmont Plus */ - case 0x7a: - /* Ice Lake */ - case 0x6a: case 0x6c: case 0x7d: case 0x7e: - /* Tiger Lake */ - case 0x8c: case 0x8d: - /* Tremont */ - case 0x86: - /* Kaby Lake */ - case 0x8e: case 0x9e: - /* Comet Lake */ - case 0xa5: case 0xa6: - return sk_lbr; - /* Atom */ - case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36: - return at_lbr; - /* Silvermont */ - case 0x37: case 0x4a: case 0x4d: case 0x5a: case 0x5d: - /* Airmont */ - case 0x4c: - return sm_lbr; - /* Goldmont */ - case 0x5c: case 0x5f: - return gm_lbr; - } - break; - - case 15: - switch ( boot_cpu_data.x86_model ) - { - /* Pentium4/Xeon with em64t */ - case 3: case 4: case 6: - return p4_lbr; - } - break; + case INTEL_CORE2_DUNNINGTON: + case INTEL_CORE2_MEROM: + case INTEL_CORE2_PENRYN: + return c2_lbr; + + case INTEL_NEHALEM: + case INTEL_NEHALEM_EP: + case INTEL_NEHALEM_EX: + case INTEL_NEHALEM_G: + case INTEL_WESTMERE: + case INTEL_WESTMERE_EP: + case INTEL_WESTMERE_EX: + case INTEL_SANDYBRIDGE: + case INTEL_SANDYBRIDGE_X: + case INTEL_IVYBRIDGE: + case INTEL_IVYBRIDGE_X: + case INTEL_HASWELL: + case INTEL_HASWELL_G: + case INTEL_HASWELL_L: + case INTEL_HASWELL_X: + case INTEL_BROADWELL: + case INTEL_BROADWELL_D: + case INTEL_BROADWELL_G: + case INTEL_BROADWELL_X: + return nh_lbr; + + case INTEL_SKYLAKE: + case INTEL_SKYLAKE_L: + case INTEL_SKYLAKE_X: + case INTEL_CANNONLAKE_L: + case INTEL_ATOM_GOLDMONT_PLUS: + case INTEL_ICELAKE: + case INTEL_ICELAKE_D: + case INTEL_ICELAKE_L: + case INTEL_ICELAKE_X: + case INTEL_TIGERLAKE: + case INTEL_TIGERLAKE_L: + case INTEL_ATOM_TREMONT_D: + case INTEL_KABYLAKE: + case INTEL_KABYLAKE_L: + case INTEL_COMETLAKE: + case INTEL_COMETLAKE_L: + return sk_lbr; + + case INTEL_ATOM_BONNELL: + case INTEL_ATOM_BONNELL_MID: + case INTEL_ATOM_SALTWELL: + case INTEL_ATOM_SALTWELL_MID: + case INTEL_ATOM_SALTWELL_TABLET: + return at_lbr; + + case INTEL_ATOM_SILVERMONT: + case INTEL_ATOM_SILVERMONT_MID: + case INTEL_ATOM_SILVERMONT_D: + case INTEL_ATOM_SILVERMONT_MID2: + //case 0x5d: // XXX + case INTEL_ATOM_AIRMONT: + return sm_lbr; + + case INTEL_ATOM_GOLDMONT: + case INTEL_ATOM_GOLDMONT_D: + return gm_lbr; + + case INTEL_P4_PRESCOTT: + case INTEL_P4_PRESCOTT_2M: + case INTEL_P4_CEDARMILL: + return p4_lbr; } return NULL; @@ -804,7 +808,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) int rc = 0; if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.vendor) ) v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD); else v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD); @@ -3073,71 +3077,71 @@ static bool __init has_if_pschange_mc(void) * IF_PSCHANGE_MC is only known to affect Intel Family 6 processors at * this time. */ - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || - boot_cpu_data.x86 != 6 ) + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || + boot_cpu_data.family != 6 ) return false; - switch ( boot_cpu_data.x86_model ) + switch ( boot_cpu_data.vfm ) { /* * Core processors since at least Nehalem are vulnerable. */ - case 0x1f: /* Auburndale / Havendale */ - case 0x1e: /* Nehalem */ - case 0x1a: /* Nehalem EP */ - case 0x2e: /* Nehalem EX */ - case 0x25: /* Westmere */ - case 0x2c: /* Westmere EP */ - case 0x2f: /* Westmere EX */ - case 0x2a: /* SandyBridge */ - case 0x2d: /* SandyBridge EP/EX */ - case 0x3a: /* IvyBridge */ - case 0x3e: /* IvyBridge EP/EX */ - case 0x3c: /* Haswell */ - case 0x3f: /* Haswell EX/EP */ - case 0x45: /* Haswell D */ - case 0x46: /* Haswell H */ - case 0x3d: /* Broadwell */ - case 0x47: /* Broadwell H */ - case 0x4f: /* Broadwell EP/EX */ - case 0x56: /* Broadwell D */ - case 0x4e: /* Skylake M */ - case 0x5e: /* Skylake D */ - case 0x55: /* Skylake-X / Cascade Lake */ - case 0x7d: /* Ice Lake */ - case 0x7e: /* Ice Lake */ - case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ - case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ - case 0xa5: /* Comet Lake H/S */ - case 0xa6: /* Comet Lake U */ + case INTEL_NEHALEM_G: + case INTEL_NEHALEM: + case INTEL_NEHALEM_EP: + case INTEL_NEHALEM_EX: + case INTEL_WESTMERE: + case INTEL_WESTMERE_EP: + case INTEL_WESTMERE_EX: + case INTEL_SANDYBRIDGE: + case INTEL_SANDYBRIDGE_X: + case INTEL_IVYBRIDGE: + case INTEL_IVYBRIDGE_X: + case INTEL_HASWELL: + case INTEL_HASWELL_X: + case INTEL_HASWELL_L: + case INTEL_HASWELL_G: + case INTEL_BROADWELL: + case INTEL_BROADWELL_G: + case INTEL_BROADWELL_X: + case INTEL_BROADWELL_D: + case INTEL_SKYLAKE_L: + case INTEL_SKYLAKE: + case INTEL_SKYLAKE_X: + case INTEL_ICELAKE: + case INTEL_ICELAKE_L: + case INTEL_KABYLAKE_L: + case INTEL_KABYLAKE: + case INTEL_COMETLAKE: + case INTEL_COMETLAKE_L: return true; /* * Atom processors are not vulnerable. */ - case 0x1c: /* Pineview */ - case 0x26: /* Lincroft */ - case 0x27: /* Penwell */ - case 0x35: /* Cloverview */ - case 0x36: /* Cedarview */ - case 0x37: /* Baytrail / Valleyview (Silvermont) */ - case 0x4d: /* Avaton / Rangely (Silvermont) */ - case 0x4c: /* Cherrytrail / Brasswell */ - case 0x4a: /* Merrifield */ - case 0x5a: /* Moorefield */ - case 0x5c: /* Goldmont */ - case 0x5d: /* SoFIA 3G Granite/ES2.1 */ - case 0x65: /* SoFIA LTE AOSP */ - case 0x5f: /* Denverton */ - case 0x6e: /* Cougar Mountain */ - case 0x75: /* Lightning Mountain */ - case 0x7a: /* Gemini Lake */ - case 0x86: /* Jacobsville */ + case INTEL_ATOM_BONNELL: + case INTEL_ATOM_BONNELL_MID: + case INTEL_ATOM_SALTWELL_MID: + case INTEL_ATOM_SALTWELL_TABLET: + case INTEL_ATOM_SALTWELL: + case INTEL_ATOM_SILVERMONT: + case INTEL_ATOM_SILVERMONT_D: + case INTEL_ATOM_AIRMONT: + case INTEL_ATOM_SILVERMONT_MID: + case INTEL_ATOM_SILVERMONT_MID2: + case INTEL_ATOM_GOLDMONT: + //case 0x5d: /* SoFIA 3G Granite/ES2.1 */ // XXX ??? + //case 0x65: /* SoFIA LTE AOSP */ // XXX ??? + case INTEL_ATOM_GOLDMONT_D: + //case 0x6e: /* Cougar Mountain */ // XXX ??? + case INTEL_ATOM_AIRMONT_NP: + case INTEL_ATOM_GOLDMONT_PLUS: + case INTEL_ATOM_TREMONT_D: return false; default: printk("Unrecognised CPU model %#x - assuming vulnerable to IF_PSCHANGE_MC\n", - boot_cpu_data.x86_model); + boot_cpu_data.model); return true; } } @@ -3431,23 +3435,20 @@ static void __init lbr_tsx_fixup_check(void) * fixed up as well. */ if ( cpu_has_hle || cpu_has_rtm || - boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || - boot_cpu_data.x86 != 6 ) + boot_cpu_data.vendor != X86_VENDOR_INTEL || + boot_cpu_data.family != 6 ) return; - switch ( boot_cpu_data.x86_model ) + switch ( boot_cpu_data.vfm ) { - case 0x3c: /* HSM182, HSD172 - 4th gen Core */ - case 0x3f: /* HSE117 - Xeon E5 v3 */ - case 0x45: /* HSM182 - 4th gen Core */ - case 0x46: /* HSM182, HSD172 - 4th gen Core (GT3) */ - case 0x3d: /* BDM127 - 5th gen Core */ - case 0x47: /* BDD117 - 5th gen Core (GT3) - BDW117 - Xeon E3-1200 v4 */ - case 0x4f: /* BDF85 - Xeon E5-2600 v4 - BDH75 - Core-i7 for LGA2011-v3 Socket - BDX88 - Xeon E7-x800 v4 */ - case 0x56: /* BDE105 - Xeon D-1500 */ + case INTEL_HASWELL: + case INTEL_HASWELL_X: + case INTEL_HASWELL_L: + case INTEL_HASWELL_G: + case INTEL_BROADWELL: + case INTEL_BROADWELL_G: + case INTEL_BROADWELL_X: + case INTEL_BROADWELL_D: break; default: return; @@ -3476,19 +3477,16 @@ static void __init ler_to_fixup_check(void) * that are not equal to bit[47]. Attempting to context switch this value * may cause a #GP. Software should sign extend the MSR. */ - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || - boot_cpu_data.x86 != 6 ) + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || + boot_cpu_data.family != 6 ) return; - switch ( boot_cpu_data.x86_model ) + switch ( boot_cpu_data.vfm ) { - case 0x3d: /* BDM131 - 5th gen Core */ - case 0x47: /* BDD??? - 5th gen Core (H-Processor line) - BDW120 - Xeon E3-1200 v4 */ - case 0x4f: /* BDF93 - Xeon E5-2600 v4 - BDH80 - Core-i7 for LGA2011-v3 Socket - BDX93 - Xeon E7-x800 v4 */ - case 0x56: /* BDE??? - Xeon D-1500 */ + case INTEL_BROADWELL: + case INTEL_BROADWELL_G: + case INTEL_BROADWELL_X: + case INTEL_BROADWELL_D: ler_to_fixup_needed = true; break; } -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245954.1545308 (Exim 4.92) (envelope-from ) id 1vxsHh-0000MO-MT; Wed, 04 Mar 2026 19:53:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245954.1545308; Wed, 04 Mar 2026 19:53:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHh-0000MF-JF; Wed, 04 Mar 2026 19:53:29 +0000 Received: by outflank-mailman (input) for mailman id 1245954; Wed, 04 Mar 2026 19:53:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHf-0007ik-SJ for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:28 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce6cf8b7-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:26 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:24 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce6cf8b7-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z3wKQwBCJfiwGCPHf/5Hp/Hu6/AGsbeo7DlG4YonOGF9x0Me1HIgNGXL24/MoasdWjjCqUVatJrG/YoLFHwTqRMUmKl+0jxz8n8oJ60S0jIhaA+MPUSlc3EH/sI8Ov0yjgO0kD2uYj7+KmPfJPoav/NqsRxRpMHePhiRGMlZNcMqZPdMXgAJt+1Cvk4fRzw/M1SUsw3blWVog62lsdSAYo5iHWV5kmoeYVDqufxU9jjGj5eas3fHihHIPnM7SaBGKqmgmWJ6yO/lM8wDRrCyCyZJ0KCzAFfD3sRW23OAGtbW00rPPBiclLfK+omQoutxlY8rTsqDgskFpMJV6rjE8Q== 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=C8uSxdZ9apq9RNkJQVruOhBEhgTE/HpOqrFEHfxII2M=; b=w/WUJ5i4Ivr5Rizdq7JFTQtSN6prGVITq/dgrM0954Ay9AhzMmB6jovP+wb37QRmJn+vpgURuaFws9PATBQdW3QktFuCAxaRakS/TcVW0QQ+usAJMiwxoGHOcYvIQlR/f+rJVnI6Oa2lVZysNVQeRn9Fa1Trr7tJzZayRgb5AT1PpxIP8wmW7RY2bJoo7BzRBCtUMDoqJsAi0Tlu/HO0TbM2W5BJ9FI5PLTLw1TmbmcuP3iFTdb89WY+falxDqKWqtfP6k7VYhzWFqbkJ7zalHjnq3GzTwE8mCH0I7mFMBzlwIqlzH/Af8sX7yMbto+SQWuRKJdLI9xWy4sptklKKA== 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=C8uSxdZ9apq9RNkJQVruOhBEhgTE/HpOqrFEHfxII2M=; b=hIn1mYMS0uXI82zAM0lJX4GC9qAr+M1xjTpQWWSQN82jrCFuaaJGsmR0GXlywAuOtuqF9RHLLWj1vgBBBw5UVwjYy+gRWS1itaaC7G7JTywnlWshs3iv7nNCTgWfSmt44f1zriaOINPWDdUz7TGec1OWJQT6P6NkK0JgdQ0qtzM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 4/6] x86: Remove x86 prefixed names from x86/cpu/ files Date: Wed, 4 Mar 2026 19:53:48 +0000 Message-ID: <20260304195350.837593-5-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO4P265CA0265.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:37c::17) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: d7fe414e-9bbf-40ea-d2f2-08de7a27b1d1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: qYnya3Kj/mCDXnreaAYWP+aY/XZsP0TfaeBEQ8sLrXbCNlCpoflrQj6vYtJM3vbAZY9LMP06qYcTgurgbQ2Jv7fhbPv014v9lG+xZD8FaQ2FYugEukDbxBqjIMvu2L7oYaZ2xllz6ioWrCGbkFbvtDdC1eim16+ae1H/PiO7QB/+BCn7FtEX22ylJnfmFlTHdTy8biZoNQjWdus72Tuz2nUpnoOCOYQy32zmlm8uT8W4hUxu4JlVjx9DxQGv6VcV/66dlLiLn85SU/LmAzZEoDRDOwHj+3lPS+Cbs7FaIXENDwXdN/AGBip74bmHQsD6z8DhZCjzqA40IxN/FG4RgJZFOYmj43H1lTE90Qf118oWmhOQTHMZ4DVGe52fWhCA0olPYqomO8OS73DBVnwYHk1tqwP0Qqp+XFczRS9x768PW8CFU+5KVfVGnQz+WQp3+L600vl3Wk/rnwLD5LgGOMOw6+TVnPVbp/QZeimVoTtmsISU2U0Lnfz947uc8rPHneG9EMK7XYDW2MwP9hAVN2qEq2BeixrCUID2+lbLkBB3n8mA0xoRHZj0Gpjc4A9YBlTKyvprGjxtuKEARDhuEBGE2fQlc57t/IUEV6fHAM2cEDbCfJJg1RZsTD5EJfohNvU3UZkjXh1it8rFGz6JzBaqplikHQ+gGvmNyUOgJgnOOVcpekLqiG//pWbPzLn1JIc1LVod1BEzi1JP9ygqmtR289e//W//0mMjKFC6xZU= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GkjGMSVOSNP9wzBJ6W7V2c6wR6b9/xijqVuvxlMcQJuWbTAS2KyJ6cspAwUQ?= =?us-ascii?Q?6pdXGaA+7pai1FP3qC2Kz4PHmLzYRev6DEw5nFeIVfc/YBQYotVXhlQM5dNo?= =?us-ascii?Q?L32x7mdBQknH2AnHQMEUvs/DvMb3KEhDyKYu2LzZVeuo60RwBpsK0Z4JkZUL?= =?us-ascii?Q?/3akBhtMJoFLS7SDRps6SQhSZ+72NUFGHWe0Zsni6wgr7gL13B8gCjOzapMf?= =?us-ascii?Q?+LYQjg7gZ4K9b5kTwIgK0TIFdrshNxoTIJ5Eb+OT1Q4EqK/oCgY2RnZlZ72Y?= =?us-ascii?Q?2AaB6rR7i2QAn7IO+lhsJDNQ9ruvKcUb1ion8GihF5Ye+MGZUvKgL08hU1zm?= =?us-ascii?Q?pDuHEAPX8wbNRTr6ts9Ln/U6+WlTzukddaDwFgFx5XBmnSudgvZYJUqsBT7e?= =?us-ascii?Q?cKgFbOgH8kt+36VGMNMJAP+GRD1qkWdIVRhiOP7o2GgD4bMN0pTyGB+A2I3g?= =?us-ascii?Q?I1t8Ik1OO90kmyJUxLgwRlrVcWeSDj8Jpj8RSioXBRbIWJW1J1K9Lbnzcngl?= =?us-ascii?Q?KuKcaeZPSuP6shGcs+OciFKmRfU2cUdADsIqhQaF5Bm1wN8A4JNT2Eu00/qA?= =?us-ascii?Q?4JFmcduI5JwNp1eikE8B9L3dOKpe2BtjDxGf68FWhh5MtC3O+ebP1aCvwZI9?= =?us-ascii?Q?DHPm1xcdojuDsB1YxpH54FB3ftE8l0DnzG8wvZZiLQnMfb1bK8bK333KKvRC?= =?us-ascii?Q?7EKm/607dZW9pfHVQLcw28x3VXLQIMub5RWr+6NNw79NDK5rOsQZegxWSbj2?= =?us-ascii?Q?LWwGNVmqzsg3ToPfcdumIxmuP+U8+Ma3BjN2F7hQ0z1P+NqrCgr8PwL0bOWe?= =?us-ascii?Q?FnhxFA806N1du3SOaHg4pg2N0dEf7rFJiigKLPx9/eYfg9UieF1Iiyd983Re?= =?us-ascii?Q?ZJQq6t/RH/DisAFw0cw0AUnJZ/zAiQKDBV8E4z3FOHq5JllKjeitmZl1bOWq?= =?us-ascii?Q?+xYA8ldrFeLY3rdegixl22wqgjYWKuVImuV2Q4oXnzm2IBD18FsRv/tCjiZ8?= =?us-ascii?Q?buwrpI3A41u7G5hsKNmP2KoWN45BMu49Yajmt+GosIUg+CNQBQUDc+x/ZnU0?= =?us-ascii?Q?+ApYjqQuQ97HGZa/zNR8C4MktmPcI/PXah1lslAOTlHQ432jvK0+679uK61V?= =?us-ascii?Q?0ILXh6cQq7rS0GmoABB72jsWmWxIQ9M/LHYYr8zcdvKKQyEi5EF3uU2XI/8l?= =?us-ascii?Q?BR5ovNU0VuQskEzPHGQQgBgdxNVB9OVPjEwJ8IqNH0ubK3M5paHc0MVP8Xmk?= =?us-ascii?Q?D44YE9wrn1C1Mbb1Avnsbhb2bEf7WRbwoo71RTdwZc8X1AAX0hcepJ861xp+?= =?us-ascii?Q?DVS/QmCUmI1w5FC68ZZw0jM4t59Z9fTwQVoVO6e7p/H8OOu6eJtwFErSSF5W?= =?us-ascii?Q?ZWV0X+42OKWYuEjtATdqA6QWU2dOVcsg9M9VrI0J58Dzxhz7dTAna2seIVlc?= =?us-ascii?Q?EfIejeg6Wsx/7TjIIS0txF6+IE3wdb/8RQfQIsQaUN1uFVoi1Mm80Ve554Ka?= =?us-ascii?Q?p+iyuWTUFEk5gafGecUnfiSZGoo4G1hgD1fDrSQe7VWBuGAbHVUEzHuBmFkN?= =?us-ascii?Q?a8I+KM855yquwU2qUjf+HGdI5pjJKFf8DXvf4Iw+FiBiJKpaqGinxS7CHoqT?= =?us-ascii?Q?wkC/7S//5Ln2Lfr81+SU7hrHc9r3ifTsWxNapIR6BQiem+z9u2NyetUuDpw2?= =?us-ascii?Q?cmQmaG0rjgLU+h3SuL1wYoRHtImoVLK40PpdbDBjdxDjoWGDgzR8J31shp79?= =?us-ascii?Q?0aarBUb2pQ=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7fe414e-9bbf-40ea-d2f2-08de7a27b1d1 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:23.9622 (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: dTvzmGK2/qOVhSnJF3Y2+3cFLoAqV6HcqC/qHa8hIqdMVbQhGnJNCwHwlV+NCRMNfuy9DKepL1lrIe8y7eX5uw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- Inside core2_vpmu_init() there is a check for family == 6. Should this be extended to family 18/19? --- xen/arch/x86/cpu/centaur.c | 4 ++-- xen/arch/x86/cpu/hygon.c | 4 ++-- xen/arch/x86/cpu/intel_cacheinfo.c | 6 +++--- xen/arch/x86/cpu/mtrr/generic.c | 6 +++--- xen/arch/x86/cpu/mwait-idle.c | 4 ++-- xen/arch/x86/cpu/vpmu.c | 4 ++-- xen/arch/x86/cpu/vpmu_amd.c | 6 +++--- xen/arch/x86/cpu/vpmu_intel.c | 6 ++++-- 8 files changed, 21 insertions(+), 19 deletions(-) diff --git a/xen/arch/x86/cpu/centaur.c b/xen/arch/x86/cpu/centaur.c index d2e7c8ec99..9123b05dc1 100644 --- a/xen/arch/x86/cpu/centaur.c +++ b/xen/arch/x86/cpu/centaur.c @@ -41,7 +41,7 @@ static void init_c3(struct cpuinfo_x86 *c) } } - if (c->x86 == 0x6 && c->x86_model >= 0xf) { + if (c->family == 0x6 && c->model >= 0xf) { c->x86_cache_alignment = c->x86_clflush_size * 2; __set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); } @@ -52,7 +52,7 @@ static void init_c3(struct cpuinfo_x86 *c) static void cf_check init_centaur(struct cpuinfo_x86 *c) { - if (c->x86 == 6) + if (c->family == 6) init_c3(c); } diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c index b99d83ed4d..7a9fc25d31 100644 --- a/xen/arch/x86/cpu/hygon.c +++ b/xen/arch/x86/cpu/hygon.c @@ -41,12 +41,12 @@ static void cf_check init_hygon(struct cpuinfo_x86 *c) /* Probe for NSCB on Zen2 CPUs when not virtualised */ if (!cpu_has_hypervisor && !cpu_has_nscb && c == &boot_cpu_data && - c->x86 == 0x18) + c->family == 0x18) detect_zen2_null_seg_behaviour(); /* * TODO: Check heuristic safety with Hygon first - if (c->x86 == 0x18) + if (c->family == 0x18) amd_init_spectral_chicken(); */ diff --git a/xen/arch/x86/cpu/intel_cacheinfo.c b/xen/arch/x86/cpu/intel_cacheinfo.c index e88faa7545..a81d0764fb 100644 --- a/xen/arch/x86/cpu/intel_cacheinfo.c +++ b/xen/arch/x86/cpu/intel_cacheinfo.c @@ -168,15 +168,15 @@ void init_intel_cacheinfo(struct cpuinfo_x86 *c) * Don't use cpuid2 if cpuid4 is supported. For P4, we use cpuid2 for * trace cache */ - if ((num_cache_leaves == 0 || c->x86 == 15) && c->cpuid_level > 1 && - c->x86_vendor != X86_VENDOR_SHANGHAI) + if ((num_cache_leaves == 0 || c->family == 15) && c->cpuid_level > 1 && + c->vendor != X86_VENDOR_SHANGHAI) { /* supports eax=2 call */ unsigned int i, j, n, regs[4]; unsigned char *dp = (unsigned char *)regs; int only_trace = 0; - if (num_cache_leaves != 0 && c->x86 == 15) + if (num_cache_leaves != 0 && c->family == 15) only_trace = 1; /* Number of times to iterate */ diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c index c587e9140e..190be7f1b4 100644 --- a/xen/arch/x86/cpu/mtrr/generic.c +++ b/xen/arch/x86/cpu/mtrr/generic.c @@ -218,9 +218,9 @@ static void __init print_mtrr_state(const char *level) printk("%s %u disabled\n", level, i); } - if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD && - boot_cpu_data.x86 >= 0xf) || - boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { + if ((boot_cpu_data.vendor == X86_VENDOR_AMD && + boot_cpu_data.family >= 0xf) || + boot_cpu_data.vendor == X86_VENDOR_HYGON) { uint64_t syscfg, tom2; rdmsrl(MSR_K8_SYSCFG, syscfg); diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c index 5962ec1db9..6776eeb9ac 100644 --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -1637,7 +1637,7 @@ static int __init mwait_idle_probe(void) lapic_timer_reliable_states = LAPIC_TIMER_ALWAYS_RELIABLE; pr_debug(PREFIX "v" MWAIT_IDLE_VERSION " model %#x\n", - boot_cpu_data.x86_model); + boot_cpu_data.model); pr_debug(PREFIX "lapic_timer_reliable_states %#x\n", lapic_timer_reliable_states); @@ -1816,7 +1816,7 @@ bool __init mwait_pc10_supported(void) { unsigned int ecx, edx, dummy; - if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || + if (boot_cpu_data.vendor != X86_VENDOR_INTEL || !cpu_has_monitor || boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF) return false; diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c index c28192ea26..64328bdf3f 100644 --- a/xen/arch/x86/cpu/vpmu.c +++ b/xen/arch/x86/cpu/vpmu.c @@ -398,7 +398,7 @@ int vpmu_load(struct vcpu *v, bool from_guest) static int vpmu_arch_initialise(struct vcpu *v) { struct vpmu_struct *vpmu = vcpu_vpmu(v); - uint8_t vendor = current_cpu_data.x86_vendor; + uint8_t vendor = current_cpu_data.vendor; int ret; BUILD_BUG_ON(sizeof(struct xen_pmu_intel_ctxt) > XENPMU_CTXT_PAD_SZ); @@ -815,7 +815,7 @@ static struct notifier_block cpu_nfb = { static int __init cf_check vpmu_init(void) { - int vendor = current_cpu_data.x86_vendor; + int vendor = current_cpu_data.vendor; const struct arch_vpmu_ops *ops = NULL; if ( !opt_vpmu_enabled ) diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c index d1f6bd5495..943a0f4ebe 100644 --- a/xen/arch/x86/cpu/vpmu_amd.c +++ b/xen/arch/x86/cpu/vpmu_amd.c @@ -532,7 +532,7 @@ static const struct arch_vpmu_ops *__init common_init(void) if ( !num_counters ) { printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n", - current_cpu_data.x86); + current_cpu_data.family); return ERR_PTR(-EINVAL); } @@ -557,7 +557,7 @@ static const struct arch_vpmu_ops *__init common_init(void) const struct arch_vpmu_ops *__init amd_vpmu_init(void) { - switch ( current_cpu_data.x86 ) + switch ( current_cpu_data.family ) { case 0x15: case 0x17: @@ -585,7 +585,7 @@ const struct arch_vpmu_ops *__init amd_vpmu_init(void) const struct arch_vpmu_ops *__init hygon_vpmu_init(void) { - switch ( current_cpu_data.x86 ) + switch ( current_cpu_data.family ) { case 0x18: num_counters = F15H_NUM_COUNTERS; diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 1e3b06ef8e..c623554e37 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -917,7 +917,9 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) return ERR_PTR(-EINVAL); } - if ( current_cpu_data.x86 != 6 ) + /* XXX Does this need to be changed to include family 18/19? + * Is the core2_ function name misleading? */ + if ( current_cpu_data.family != 6 ) { printk(XENLOG_WARNING "VPMU: only family 6 is supported\n"); return ERR_PTR(-EINVAL); @@ -958,7 +960,7 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) sizeof(struct xen_pmu_cntr_pair) * arch_pmc_cnt; /* TODO: It's clearly incorrect for this to quirk all Intel Fam6 CPUs. */ - pmc_quirk = current_cpu_data.x86 == 6; + pmc_quirk = current_cpu_data.family == 6; if ( sizeof(struct xen_pmu_data) + sizeof(uint64_t) * fixed_pmc_cnt + sizeof(struct xen_pmu_cntr_pair) * arch_pmc_cnt > PAGE_SIZE ) -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245961.1545317 (Exim 4.92) (envelope-from ) id 1vxsHo-0000uT-2T; Wed, 04 Mar 2026 19:53:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245961.1545317; Wed, 04 Mar 2026 19:53:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHn-0000uM-VS; Wed, 04 Mar 2026 19:53:35 +0000 Received: by outflank-mailman (input) for mailman id 1245961; Wed, 04 Mar 2026 19:53:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHm-0007ik-2A for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:34 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d1f4b33e-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:32 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:28 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d1f4b33e-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UBu/gcvu514ASS/FLMZkWnmlcogcqamezZYztaRFnhx2dRj+ASBIxo5gOyWVZsjDrO+Hb+m7pOa3CGkS+s4/fBDwcSqFY7eUjDraF1S4DFgTfNS2UPhjFdVHiXSeUoyBDoFyu71Qr21NINQzkbF5MZY149fHDr2gSAPH/JPb8E32CoaXzryDNbFBhO0/+ACcrcH5Gj1BV3IwMRqOh00FV+rBVSASB5iVB/c/60s5dtEB4lM3yioH/xJo+opSOwQkaFrR/7PxFI46DgSMgDMLbdfUguvbUMk9q6mxcnFSb0a6d0etbHqVlnAzG+UFnOkRxUx7NNKNQF6H61XgqHqyFw== 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=vihGUYdNoEcTWfXNkSEwuKOxDjEQZzvneznmn0lSWQc=; b=Ji1w94j17Aux3uK36xA/s3RbT8igmqKNIcbyzb1xWCucauSke6xSanasWq5NYFng+kWZwnZvIXVBVhYhS12Q+myrwAzqvTOIeWRRIG8j+D+ja39WBllxiF1fzaelUUbJppHYg+5xgxl0+V/aTme+UM4mopRGPLjEBu2bg0mSCy4WtR3gZ1BURxWq81PyU7kLf75P1DEIXES6iIQ7sohef7dRKxR5egiVRvqClbVE4weW8HOCfCMzjzThKPQ4XyCUqnILwT47vsWecMkEGSik0zmW3cSHstuz8Bxg+2YbxDIW4qScTqnGn5Xt5i6vvomPFHfEuf7XZGRPpxD3W3ueew== 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=vihGUYdNoEcTWfXNkSEwuKOxDjEQZzvneznmn0lSWQc=; b=tSKsiaI3c6eFxQ6bBFnF/B+yclwvm52O2v6dDNhFn0EZMTKjHmnninqKdXlmbKXSa9NzwqHstAU1hePe7tMrJ00ZaFc5rvTs2aB5AswHNq5RIHsBIKrdBUgvGNGN6yRx9NqEiU7hKKo+56G+oWjHhUOkHa/2VV/+uOqAN8X7b+Q= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 5/6] x86: Remove x86 prefixed names misc Date: Wed, 4 Mar 2026 19:53:49 +0000 Message-ID: <20260304195350.837593-6-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO6P123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::13) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f321e42-7525-474a-9432-08de7a27b470 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: MZ+JnYsIJBZNMv6GEZCZKn6QC9Zs67wasgC3Qr5wbD+ybRJl78bF5Z9OmiZ274iL8s57PnZ/SIkh0uvrYGoFvxz3kO7W+sHdE95jQ1dK5O8iMqs0n0SKi39wHbuBtfw3TSYE6Lu3qVGq8X7MjejxpmCebG88+lM3PM2BuKAtmmgqC5WzHlN7HjRMhKFv+CawtL8qpjfGAC4KBYrcZLw/5JsWqaxdQnNZkoJZrymAORM5HLuNziCvtTGJcxYp7VuNHqDqBJQ/F1CfMwyodFIxa1b4YAIruy7SUSLHZBJk+gugldGyHmd1aUNQqR8oq8NXhCKAl4gdfZywyFs/OP76GgVF+KUzTZhFLsaytD0d3y57Rv4RNlBnrQYRWbUEFI0TSLJwHNtYve6VrwEPcFie7KTkt1CDmFmwBe1DGhKF59+0qwxxjpOMh3wlcUN6PitJgnm/HXomsHmhMlFU3cQukoTarncsBgNaUP8THRpyR5moBolJtZqKWMHzaD+uWOj2qu3Sf0xJo8PSuzlylOI7+HcUYQ4OUhYe5YglKz7yvLeDULS6Lq5knfHj5cXzh4yu0AXpi8UxGeOyNPhYRiJ4d8yoQidEFMbPDOv06rXl6YC0FN4AYY2g/Hjadje11hAUBLpbMt3bgwPYZNFYsEGaWfIUuWgTz6rYYgmH4q9GBJo3BIOCjmoiJ0jFNjC/TXuIHjEC52OLb902qM6PomeWrvfBLEuzDjQmQF3TA1nx+I4= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?p1WaoMyBpueLuya4zqEDf2Xk0rXsuXHgG1Oy/Iv5TlFEUswvPkzy4wUl0YRa?= =?us-ascii?Q?tyxeRWoAc/LaIdXSKWhky3KbcyctLwiTKsAj/7T1PAYkZAJWD4h51JoodPKB?= =?us-ascii?Q?tSzMTODKZO8C385oyTAvR2Hxwo9PytyAruNprRlZIfPDfswkKUDpke95o5rG?= =?us-ascii?Q?hqbX4adbHqvT6cmKEyDObx368Y+Z+oDjwHVCFgUwlYOL+T2ne1F1ht7PbsOH?= =?us-ascii?Q?IvubySTxB3zhEbXO0ebcTJDVel8287Sv86xIl0fJWpXH7E22PoM4duCxmTiD?= =?us-ascii?Q?npEgx5w4rbxGD9qG1TTnH+BWp+n9g8AraQ+rf6tir2HESSaHQeiHNLW0DlNx?= =?us-ascii?Q?asflRwSlGkCQKZ4lfmM+k50vL6wulya1v4uGEvDZmgP2m8BhKBjOcKLEdxKs?= =?us-ascii?Q?8xtJNIyQcp9ych20mmsL0YgC2TnoWI1EatUWTr249YXEO7n3+EwhlslMM14y?= =?us-ascii?Q?edeHGyX1r12VecsKwVEVQ03Xzij4Uq7haKEBXi544PtObE1Ds0xI88i0jlDH?= =?us-ascii?Q?BNsFe3ChT2tH+qG24I7cced99/HIcRJEEgrXIDCUm1YHp39KbhoOHSw2bNhG?= =?us-ascii?Q?JukGE/zV579j0+YOvkrILPgpwzgGG1qiu1ObTvId4SoXBc8DfK0CSJlSSr8f?= =?us-ascii?Q?2YA/9UQ+I6NfdFsQXqILvRdRkND792M+n8NT6j5o4YAkLxTo3yX9qDe4OoRX?= =?us-ascii?Q?Ydn0ykAlGNHhsjI3Hjs1ixYSJJ9fOiAsym4y2ssltj6J1o9QX+dTs+skPw4T?= =?us-ascii?Q?aN/ES06KOVAzN6QP5oYGghinfGoJ+JpYxiA17lhyCnWgldNv+W9Juf/Y6vpq?= =?us-ascii?Q?LVA7W6Ai1dOu+tYQR0eNWsSNTSNZLJwzFp4sRe/pJU3u1JumA6lBv+ge5rvV?= =?us-ascii?Q?K+XEfr3AktNDdOq4YQcPbpIwpIcbpNKovU3Ly8m/TxABFb8KpcZgv5ztUI3O?= =?us-ascii?Q?j0F9F9g0GlTlE4GzSpWPlhDK1DwyYOVzNqoxm4hO09tiAGr7q79woL8iEGn2?= =?us-ascii?Q?l/WtjRIl5b5ZsAD0dWnDmt55TcgxBOxI0+5tYlF9mnwGrW2b4AQppJvpufa9?= =?us-ascii?Q?eSAEUwXkziZT0w683ShfK32AfwrB9QdsrT/yWPr2LFLydadFa9Qxy3mCG6qm?= =?us-ascii?Q?+RgYqa8y8qFpAFxN1nabOQf0d2eg/aDo6MH3RwHrl8SWT8TocF1PHy5YzOFh?= =?us-ascii?Q?lhJcWzCDaf38+rpLrXhb+/qJKscvactSnoHMvY6ThHKn5hzQpbweWIYarSAH?= =?us-ascii?Q?2pPdugbBI4ebn9wyHSzwH8Np0atzr3Jj8qz14KnF+pE23ztxcn3PybZnzpHG?= =?us-ascii?Q?CV7HWMibsVL/nYnwzwKMVXnPRcu392eNsSyBxZGI03CImDSiM1H1413fJweE?= =?us-ascii?Q?QWavWCFKAFKyKLw+kh+Ys4gZOvUeMF910YQmF+AU2LbIkw4d0jZ+1xWVV6Ap?= =?us-ascii?Q?6EGiiC7NMKF59ALek3Y2dX8DgYguWe6ujfCLwpjD2Bn64erOyYK9nHMF+7LB?= =?us-ascii?Q?NPcGgvA9VVgTxW2JPXzojDOL+x004407BscKijpDmvXokK520norgcoaWHg1?= =?us-ascii?Q?pSdxmZkFDlRPDL8lOa09a3NfaW7U3oa9N5B7+aI6g/cnLmNaBesxVz1ecfnb?= =?us-ascii?Q?6R1cpPCH3L05zS1mc9pRi9gQPubis9hrOWNcxdHXNTaifulKfpHrXiOpv3v9?= =?us-ascii?Q?PvVklbwqsWapq1XzKQgqh5l/Y2++9Xe6o9Lu1jWO2M5CddwNIBC8nQidNjfp?= =?us-ascii?Q?s0MydMRlhA=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f321e42-7525-474a-9432-08de7a27b470 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:28.3868 (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: IjpGxxJlbP2Lx8Yhu7eMd6Yuh+rfor4nZFl+B2VrNyCGYYKXmjptSEJp9RMQzQLmF3EkF9GGxRRIbowla7KpAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 struct cpuinfo_x86 .x86 => .family .x86_vendor => .vendor .x86_model => .model .x86_mask => .stepping No functional change. This work is part of making Xen safe for Intel family 18/19. Signed-off-by: Kevin Lampis --- xen/arch/x86/alternative.c | 8 ++++---- xen/arch/x86/apic.c | 2 +- xen/arch/x86/cpuid.c | 2 +- xen/arch/x86/dom0_build.c | 4 ++-- xen/arch/x86/domain.c | 12 ++++++------ xen/arch/x86/e820.c | 2 +- xen/arch/x86/i8259.c | 2 +- xen/arch/x86/irq.c | 4 ++-- xen/arch/x86/mpparse.c | 6 +++--- xen/arch/x86/msr.c | 4 ++-- xen/arch/x86/nmi.c | 12 ++++++------ xen/arch/x86/platform_hypercall.c | 8 ++++---- xen/arch/x86/pv/domain.c | 2 +- xen/arch/x86/setup.c | 6 +++--- xen/arch/x86/traps-setup.c | 4 ++-- xen/arch/x86/tsx.c | 4 ++-- xen/drivers/passthrough/amd/iommu_init.c | 6 +++--- 17 files changed, 44 insertions(+), 44 deletions(-) diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c index 9f844241bc..5ed0c26725 100644 --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -89,7 +89,7 @@ static bool init_or_livepatch_read_mostly toolchain_nops_are_ideal; static void __init arch_init_ideal_nops(void) { - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_INTEL: /* @@ -97,10 +97,10 @@ static void __init arch_init_ideal_nops(void) * actually perform better with the "k8_nops" than with the SDM- * recommended NOPs. */ - if ( boot_cpu_data.x86 != 6 ) + if ( boot_cpu_data.family != 6 ) break; - switch ( boot_cpu_data.x86_model ) + switch ( boot_cpu_data.model ) { case 0x0f ... 0x1b: case 0x1d ... 0x25: @@ -111,7 +111,7 @@ static void __init arch_init_ideal_nops(void) break; case X86_VENDOR_AMD: - if ( boot_cpu_data.x86 <= 0xf ) + if ( boot_cpu_data.family <= 0xf ) ideal_nops = k8_nops; break; } diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c index fb38be7ec3..d69ef9e16a 100644 --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -406,7 +406,7 @@ void __init init_bsp_APIC(void) value |= APIC_SPIV_APIC_ENABLED; /* This bit is reserved on P4/Xeon and should be cleared */ - if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 == 15)) + if ((boot_cpu_data.vendor == X86_VENDOR_INTEL) && (boot_cpu_data.family == 15)) value &= ~APIC_SPIV_FOCUS_DISABLED; else value |= APIC_SPIV_FOCUS_DISABLED; diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index 5decfad8cd..6e9b15c9c3 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -437,7 +437,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, case 0xa: /* TODO: Rework vPMU control in terms of toolstack choices. */ - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || !vpmu_available(v) ) *res = EMPTY_LEAF; else diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c index 0b467fd4a4..864dd9e53e 100644 --- a/xen/arch/x86/dom0_build.c +++ b/xen/arch/x86/dom0_build.c @@ -572,10 +572,10 @@ int __init dom0_setup_permissions(struct domain *d) rc |= iomem_deny_access(d, mfn, mfn); } /* HyperTransport range. */ - if ( boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) + if ( boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) { mfn = paddr_to_pfn(1UL << - (boot_cpu_data.x86 < 0x17 ? 40 : paddr_bits)); + (boot_cpu_data.family < 0x17 ? 40 : paddr_bits)); rc |= iomem_deny_access(d, mfn - paddr_to_pfn(3UL << 32), mfn - 1); } diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 8eb1509782..b36e113724 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -319,7 +319,7 @@ void domain_cpu_policy_changed(struct domain *d) if ( cpu_has_htt ) edx |= cpufeat_mask(X86_FEATURE_HTT); - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_INTEL: /* @@ -372,7 +372,7 @@ void domain_cpu_policy_changed(struct domain *d) { uint64_t mask = cpuidmask_defaults._6c; - if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) + if ( boot_cpu_data.vendor == X86_VENDOR_AMD ) mask &= (~0ULL << 32) | p->basic.raw[6].c; d->arch.pv.cpuidmasks->_6c = mask; @@ -387,7 +387,7 @@ void domain_cpu_policy_changed(struct domain *d) * wholesale from the policy, but clamp the features in 7[0].ebx * per usual. */ - if ( boot_cpu_data.x86_vendor & + if ( boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ) mask = (((uint64_t)p->feat.max_subleaf << 32) | ((uint32_t)mask & p->feat._7b0)); @@ -400,7 +400,7 @@ void domain_cpu_policy_changed(struct domain *d) uint64_t mask = cpuidmask_defaults.Da1; uint32_t eax = p->xstate.Da1; - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) mask &= (~0ULL << 32) | eax; d->arch.pv.cpuidmasks->Da1 = mask; @@ -427,7 +427,7 @@ void domain_cpu_policy_changed(struct domain *d) if ( !(p->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) ) edx &= ~CPUID_COMMON_1D_FEATURES; - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_INTEL: mask &= ((uint64_t)edx << 32) | ecx; @@ -457,7 +457,7 @@ void domain_cpu_policy_changed(struct domain *d) cpu_policy_updated(v); /* If PMU version is zero then the guest doesn't have VPMU */ - if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + if ( boot_cpu_data.vendor == X86_VENDOR_INTEL && p->basic.pmu_version == 0 ) vpmu_destroy(v); } diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c index ca577c0bde..872208ab37 100644 --- a/xen/arch/x86/e820.c +++ b/xen/arch/x86/e820.c @@ -426,7 +426,7 @@ static uint64_t __init mtrr_top_of_ram(void) /* By default we check only Intel systems. */ if ( e820_mtrr_clip == -1 ) - e820_mtrr_clip = boot_cpu_data.x86_vendor == X86_VENDOR_INTEL; + e820_mtrr_clip = boot_cpu_data.vendor == X86_VENDOR_INTEL; if ( !e820_mtrr_clip ) return 0; diff --git a/xen/arch/x86/i8259.c b/xen/arch/x86/i8259.c index 5c7e21a751..d2a08661f8 100644 --- a/xen/arch/x86/i8259.c +++ b/xen/arch/x86/i8259.c @@ -419,7 +419,7 @@ void __init init_IRQ(void) * the interrupt. */ cpumask_copy(desc->arch.cpu_mask, - (boot_cpu_data.x86_vendor & + (boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON) ? &cpumask_all : cpumask_of(cpu))); desc->arch.vector = LEGACY_VECTOR(irq); diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c index cc2934bfca..739fc04bd1 100644 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -2011,8 +2011,8 @@ void do_IRQ(struct cpu_user_regs *regs) * interrupts have been delivered to CPUs * different than the BSP. */ - (boot_cpu_data.x86_vendor & (X86_VENDOR_AMD | - X86_VENDOR_HYGON))) && + (boot_cpu_data.vendor & (X86_VENDOR_AMD | + X86_VENDOR_HYGON))) && bogus_8259A_irq(vector - FIRST_LEGACY_VECTOR)) ) { printk("CPU%u: No irq handler for vector %02x (IRQ %d%s)\n", diff --git a/xen/arch/x86/mpparse.c b/xen/arch/x86/mpparse.c index c1171f7a3a..1b41aa573f 100644 --- a/xen/arch/x86/mpparse.c +++ b/xen/arch/x86/mpparse.c @@ -511,9 +511,9 @@ static inline void __init construct_default_ISA_mptable(int mpc_default_type) /* Either an integrated APIC or a discrete 82489DX. */ processor.mpc_apicver = mpc_default_type > 4 ? 0x10 : 0x01; processor.mpc_cpuflag = CPU_ENABLED; - processor.mpc_cpufeature = (boot_cpu_data.x86 << 8) | - (boot_cpu_data.x86_model << 4) | - boot_cpu_data.x86_mask; + processor.mpc_cpufeature = (boot_cpu_data.family << 8) | + (boot_cpu_data.model << 4) | + boot_cpu_data.stepping; processor.mpc_featureflag = boot_cpu_data.x86_capability[FEATURESET_1d]; processor.mpc_reserved[0] = 0; diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index ad75a2e108..6a97be59d5 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -170,7 +170,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) case MSR_IA32_PLATFORM_ID: if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) ) + !(boot_cpu_data.vendor & X86_VENDOR_INTEL) ) goto gp_fault; rdmsrl(MSR_IA32_PLATFORM_ID, *val); break; @@ -190,7 +190,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) * the guest. */ if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || - !(boot_cpu_data.x86_vendor & + !(boot_cpu_data.vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) goto gp_fault; diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c index a0c9194ff0..447fac19d3 100644 --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c @@ -216,12 +216,12 @@ void disable_lapic_nmi_watchdog(void) { if (nmi_active <= 0) return; - switch (boot_cpu_data.x86_vendor) { + switch (boot_cpu_data.vendor) { case X86_VENDOR_AMD: wrmsrns(MSR_K7_EVNTSEL0, 0); break; case X86_VENDOR_INTEL: - switch (boot_cpu_data.x86) { + switch (boot_cpu_data.family) { case 6: wrmsrns(MSR_P6_EVNTSEL(0), 0); break; @@ -362,7 +362,7 @@ 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.x86_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); @@ -387,16 +387,16 @@ void setup_apic_nmi_watchdog(void) if ( nmi_watchdog == NMI_NONE ) return; - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_AMD: setup_k7_watchdog(); break; case X86_VENDOR_INTEL: - switch (boot_cpu_data.x86) { + switch (boot_cpu_data.family) { case 6: - setup_p6_watchdog((boot_cpu_data.x86_model < 14) + setup_p6_watchdog((boot_cpu_data.model < 14) ? P6_EVENT_CPU_CLOCKS_NOT_HALTED : CORE_EVENT_CPU_CLOCKS_NOT_HALTED); break; diff --git a/xen/arch/x86/platform_hypercall.c b/xen/arch/x86/platform_hypercall.c index cd4f0ae5e5..0431f875af 100644 --- a/xen/arch/x86/platform_hypercall.c +++ b/xen/arch/x86/platform_hypercall.c @@ -104,7 +104,7 @@ static bool msr_read_allowed(unsigned int msr) * the platform doesn't actually support this MSR. */ case MSR_TEMPERATURE_TARGET: - return boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + return boot_cpu_data.vendor == X86_VENDOR_INTEL && host_cpu_policy.basic.digital_temp_sensor; case MSR_PACKAGE_THERM_STATUS: @@ -688,9 +688,9 @@ ret_t do_platform_op( const struct cpuinfo_x86 *c = &cpu_data[ver->xen_cpuid]; memcpy(ver->vendor_id, c->x86_vendor_id, sizeof(ver->vendor_id)); - ver->family = c->x86; - ver->model = c->x86_model; - ver->stepping = c->x86_mask; + ver->family = c->family; + ver->model = c->model; + ver->stepping = c->stepping; } ver->max_present = cpumask_last(&cpu_present_map); diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index d16583a745..0fd05c7059 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -174,7 +174,7 @@ static int __init cf_check pge_init(void) { if ( opt_global_pages == -1 ) opt_global_pages = !cpu_has_hypervisor || - !(boot_cpu_data.x86_vendor & + !(boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)); return 0; diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 27c63d1d97..e5f1b4b787 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1407,7 +1407,7 @@ void asmlinkage __init noreturn __start_xen(void) * supervisor shadow stacks are now safe to use. */ bool cpu_has_bug_shstk_fracture = - boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + boot_cpu_data.vendor == X86_VENDOR_INTEL && !boot_cpu_has(X86_FEATURE_CET_SSS); /* @@ -2038,10 +2038,10 @@ void asmlinkage __init noreturn __start_xen(void) /* Do not enable SMEP/SMAP in PV shim on AMD and Hygon by default */ if ( opt_smep == -1 ) - opt_smep = !pv_shim || !(boot_cpu_data.x86_vendor & + opt_smep = !pv_shim || !(boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)); if ( opt_smap == -1 ) - opt_smap = !pv_shim || !(boot_cpu_data.x86_vendor & + opt_smap = !pv_shim || !(boot_cpu_data.vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)); if ( !opt_smep ) diff --git a/xen/arch/x86/traps-setup.c b/xen/arch/x86/traps-setup.c index d77be8f839..1aff0327dc 100644 --- a/xen/arch/x86/traps-setup.c +++ b/xen/arch/x86/traps-setup.c @@ -243,10 +243,10 @@ static void __init init_ler(void) * Intel Pentium 4 is the only known CPU to not use the architectural MSR * indicies. */ - switch ( boot_cpu_data.x86_vendor ) + switch ( boot_cpu_data.vendor ) { case X86_VENDOR_INTEL: - if ( boot_cpu_data.x86 == 0xf ) + if ( boot_cpu_data.family == 0xf ) { msr = MSR_P4_LER_FROM_LIP; break; diff --git a/xen/arch/x86/tsx.c b/xen/arch/x86/tsx.c index fe9f0ab4f7..38371487b9 100644 --- a/xen/arch/x86/tsx.c +++ b/xen/arch/x86/tsx.c @@ -148,8 +148,8 @@ void tsx_init(void) { printk(XENLOG_ERR "FIRMWARE BUG: CPU %02x-%02x-%02x, ucode 0x%08x: RTM_ALWAYS_ABORT vs RTM mismatch\n", - boot_cpu_data.x86, boot_cpu_data.x86_model, - boot_cpu_data.x86_mask, this_cpu(cpu_sig).rev); + boot_cpu_data.family, boot_cpu_data.model, + boot_cpu_data.stepping, this_cpu(cpu_sig).rev); setup_clear_cpu_cap(X86_FEATURE_RTM_ALWAYS_ABORT); setup_clear_cpu_cap(X86_FEATURE_TSX_FORCE_ABORT); diff --git a/xen/drivers/passthrough/amd/iommu_init.c b/xen/drivers/passthrough/amd/iommu_init.c index 00d2c46cbc..d77dd85112 100644 --- a/xen/drivers/passthrough/amd/iommu_init.c +++ b/xen/drivers/passthrough/amd/iommu_init.c @@ -840,9 +840,9 @@ static void amd_iommu_erratum_746_workaround(struct amd_iommu *iommu) { u32 value; - if ( (boot_cpu_data.x86 != 0x15) || - (boot_cpu_data.x86_model < 0x10) || - (boot_cpu_data.x86_model > 0x1f) ) + if ( (boot_cpu_data.family != 0x15) || + (boot_cpu_data.model < 0x10) || + (boot_cpu_data.model > 0x1f) ) return; pci_conf_write32(iommu->sbdf, 0xf0, 0x90); -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 19:53:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 19:53:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1245965.1545323 (Exim 4.92) (envelope-from ) id 1vxsHo-0000xO-Ca; Wed, 04 Mar 2026 19:53:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1245965.1545323; Wed, 04 Mar 2026 19:53:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHo-0000vh-71; Wed, 04 Mar 2026 19:53:36 +0000 Received: by outflank-mailman (input) for mailman id 1245965; Wed, 04 Mar 2026 19:53:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxsHn-0007ik-KQ for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 19:53:35 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d39365d0-1803-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 20:53:34 +0100 (CET) Received: from BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) by DM4PR03MB6079.namprd03.prod.outlook.com (2603:10b6:5:392::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 19:53:32 +0000 Received: from BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07]) by BY1PR03MB7996.namprd03.prod.outlook.com ([fe80::5068:e1b5:b478:8d07%5]) with mapi id 15.20.9678.016; Wed, 4 Mar 2026 19:53:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d39365d0-1803-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Z+DpwdNYvCUbuEZvQetU/o2rC+YTGyy7slJFQUX8uJS93iAevtdVC3v43og9tGp0SMS0D7Hw2wDt5ILyHe8WMhOdBaIxYly6PtZ9VcjsWhE3Pce5MZ37Bd7VUL2GCjSqkZHIA0q+q6osuFel0h6bewvuofefW4A2vdnTaZ4eNW1ARbLEHw0smk6abBJnoPCbXushu64o6okvfMWSmexbhKWkB4ehMJvctqvRSX6XoEUpzQki8Qxl9xtoVLt+VGx7AxQiXMaPraqPVCVCexn5hPul7W8xgVKliRfG6vvJcAueojknb7hFZ8WxoD8HxePhTr920mDHPst4GKvzSBBK7w== 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=nnVnsWYWKG7SVBrj/TXgZDuFUFT7AP5TCSelHpEbdVI=; b=W+NuaJcYpALgg+ksN8YfAKWxHeLghoxvKf4kSgFPjYqCLjeg6URo/lTpFaqrM2fT3a+FdHQuv0uYAwrm2/lLLlT5MYI/4h+k36zfvh6a/bays+3iCfpXQcJd71RKdXzlDyzx6fzYlmzpnl1zvuXXgqxWdvE7BQrP6zff9XJztl2X5pC2AWqXS0YGOB2I/3RIdFf1vvWxFm9CThze1910sBjBDZhXbBPtP9cOcMrSsL92KUjnkMYI8Bz4gMhSlZemCkjrApgG5dDwZ5fYzdS7d1rTfIN1OrSiw0EB+CKOzkvYtz0NMzkflt9at8In8qcT2a6a5HYnzTibs3n7SJF4Nw== 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=nnVnsWYWKG7SVBrj/TXgZDuFUFT7AP5TCSelHpEbdVI=; b=LEBG8FLkSzNT/KVmvoYe+hqRNLdSLmiZkaiSiO9OTdMh9fH3XE1y+rfuNANmWQhh1gZIt29CtGvXb1+1xvOAaqNq9/zdQnq14y8HMv6SNA5R0AxxcZFLJjvYJHGxYyTtWUu/eSpgMtmfKioxeDNJogm3nELSI2QbunjPSU+RSE4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Kevin Lampis To: xen-devel@lists.xenproject.org Cc: jbeulich@suse.com, andrew.cooper3@citrix.com, roger.pau@citrix.com, Kevin Lampis Subject: [PATCH 6/6] x86: Remove x86 prefixed names from cpuinfo Date: Wed, 4 Mar 2026 19:53:50 +0000 Message-ID: <20260304195350.837593-7-kevin.lampis@citrix.com> X-Mailer: git-send-email 2.51.1 In-Reply-To: <20260304195350.837593-1-kevin.lampis@citrix.com> References: <20260304195350.837593-1-kevin.lampis@citrix.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: LO6P123CA0014.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::17) To BY1PR03MB7996.namprd03.prod.outlook.com (2603:10b6:a03:5b2::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7996:EE_|DM4PR03MB6079:EE_ X-MS-Office365-Filtering-Correlation-Id: 9feeda4e-46d0-475b-0d4c-08de7a27b6f2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: 0BToux3SEX8HOCLeeSSk6r2QIFwTw8ptRRbrGV7CwdCDwNSnEENQtqasyhzvKERVTPKV4/d0yzp4246eLTwtyoMLHF6r4M4qBMec0Q6Neq2NwFvbaEPBunEXG3WbBT2CIg2nP4Fl9L79bXkaDjwPYa6HZWovCMYBGh8lKb3rzTELhn72/XAY3LvYxcf10s3i9OaoIzJG4tXg/tJVznXeVXjoUyjW6FMFTDE2vsC5TfEPaausPyEjO7Jimmfv9WAfDae15m/ZSRSb9h/SYifbLWp8fZz6pkHuHNrvNwLVhQzqELYCOS/LEWSzppMV0dHtQzP01XwZJKGLOYmddySv3rOwII4Tqd0usvS+opNpcSK190cQyRCyPxXdPNgqR0p5E/bwkWT1yk+g2q7PGJgbEdfRKXT7jq9lL30crbm1pQMmfdvhJUcfI7sqwIapoXYoeZYOenMDj5pFJnzmPRGgfivri1vS6e9x+uy1uJMCfg0HstuDVbrpFsKXh9G/o2RrbOkijP8L/odo8HiDuDyyWLXhAYpzjvTnCzRb3cf19MdJwsDS3Z76DQ8mccVyUYGzKeNOvKTqipqr6EXSKlRZg8Z2RlXpBCZpjxVO41KQJ33i2QT1FVQ8EiWoRCRKgPUVIvBNI/m/a4UwbmbH0vC+GluNQRnoRjBA/PsuON2EfqDAleURh8RlNXpFyHGhxjWGiLYW9YVJZ+jxUDKDXrrJwLZM14fhQihjgPWgzNNXjLA= 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)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?loIK/d+NJUcGvTov20LAbL4h+0pMICbvhCbwbVlIdxCoUHH9W3NZir6ndFxe?= =?us-ascii?Q?tac9gWMcu3d7b/YoRLDbYPzvniQTxllMfvZLtXKAsSLofr/MGlmcAw+FXa6F?= =?us-ascii?Q?L9JCqpgwF3cUqf0dQ2PL7kCMtLYAP64OmCFZtehKhR+sBg8M0rW8/+Em2hX4?= =?us-ascii?Q?CCHbwX6HaL0EUZL77zwFNIZJ4up2ucW+ldnprEXFLuiqGdhZJ9mVtf2uRtar?= =?us-ascii?Q?hGvpK57bGXO7BsrXxPTvlu+vN5ZfcQA9JDBtlCgypSDS2p6nGV7jj9UOC7AC?= =?us-ascii?Q?Nj8S6BKxX9cuADNr0OdUaZT0eNwZP/xkRGJCLpUjKkdZisjP+EjQMSWTdXZw?= =?us-ascii?Q?QEeoFd+6cLNCsIZDZraz0u69WZbMO+05mA0aet5x0OpWFs5CeDKDjHRYSs8H?= =?us-ascii?Q?+6z2TmO5DHg0WQKP1ejoSO+kDV0gmC1QsRDcvdPM5lRuX2QP332WD+Nj/muj?= =?us-ascii?Q?rmzOg0+aslSdCeHnvAkKiEjw5GRTazILyqJ29clfNPkTjYMERG3NKdwktu/A?= =?us-ascii?Q?8SSwKSX9SKW1R4TPUQ+8wxPJCbIZ/4+XQXncR7Ot2uwpfrvLBVRVCHOoLuuz?= =?us-ascii?Q?wH22YAu3S/5TJm5exuzKQTK2WnEiPRJV6gB64D/ZqcxeIwwL1F0fw0i7Vp6h?= =?us-ascii?Q?yb/yMM61AXif9eG1Tn2mIGtbKJ5LkzDnnoj5pAWTiIgq2E7GxERt9EocEoxh?= =?us-ascii?Q?ZTMNinw/tj78e9PLEpaNmduYJJo3njCk39i7d2chaI9Ib9EINQ0+lhuxNJqc?= =?us-ascii?Q?Woj/zIf290KdQWIfWbqaZffrB+6+LoExsVgFvPWrTKw9IKpnX1J73ARdOy6D?= =?us-ascii?Q?Y9iTI8oMBXX+cQrDt79YUZ0KhIG0tVefB7gx/pjT48SEe4/DUCcQ2AFJl53i?= =?us-ascii?Q?tJEkbokwHYl+s+eg0kgkxJQW9pnHQEuwPaO8fD7fXPIGlAhxyxIP3rmaw54A?= =?us-ascii?Q?4SBeSw17nbPQZhDsPGMIVEpv30CPJoFpZ73qb3tV0z3R81aCIFvpBpiLc6aA?= =?us-ascii?Q?IWt9wnYL4ze96PT8WpLJNrJ7vFDyFIMMSedLIPx6TG4xl8kISABl7D0M2YR+?= =?us-ascii?Q?dvRiBLPXO5bkCf3N1AJu7CHSOMDWkJWG4aAcgmRWBvA2V9nZtFa2mVbo0+9c?= =?us-ascii?Q?rqlxVD85t3vZVUFeCFHkNqIKyJZ0lzQidrKN/lcBLjIk3rI0G1yuPl9r8sG+?= =?us-ascii?Q?Ng2Uw87lmRfyEtGNQvhfQU+FLybtueZXMOCr7kpUaTqhowY37dX1t4kC4blK?= =?us-ascii?Q?90m7epHt56tgS6XLZjKpGYQCX0cI4QxBfG7m9A0Dhkv3e3siEQOOUyluOD3V?= =?us-ascii?Q?VN6rzCxKb+SOadtJ+4m6n8LJtPu+l8xlTZpn92CxQMrN8vjsyKeKEUbmebit?= =?us-ascii?Q?2dGliWxFgsG1VvlXltBTAkh1ScaYR+lGSCUfO2m/lkLAja8PDZmPNtQ6bqdm?= =?us-ascii?Q?Fk/d//IEfiU0wTqvjgka3GK39b73rJYkDQbPYj9+r+TjnWIIbFSfnOr6+VsI?= =?us-ascii?Q?AISJstRWlHIENo+VQCqHZS1YwdueBJyrrU2VcNSqMm5WT+6IJfw0pQiQeOVd?= =?us-ascii?Q?PgZXBo/xEJgsvtlVzoW5XpRUbYYNS+VL2fZm4jnu+ZaS2InAksVZr055zRHm?= =?us-ascii?Q?lFNYbbRJtE93LQIR3f4PZ617YNZkMb75ZqauISn07GcqqpgLkApiRqH6CX2B?= =?us-ascii?Q?O0E2TRSf//VPbF0ccWCucFMfHnWcuU+/eR1Rgr0JT+VyqAjkS3HYWAoBuWKB?= =?us-ascii?Q?nfkDkRLHmw=3D=3D?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9feeda4e-46d0-475b-0d4c-08de7a27b6f2 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7996.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 19:53:32.5625 (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: bz+dXb/uCkyyrZNw5sh0LIA1sxMw1pFcDNUljzF4ZgKoBEimyNCTj9l1TMBTFqTtavgYueJP6SftzFr5MOed3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6079 Signed-off-by: Kevin Lampis --- With the first patch for intel.c this now compiles. https://lore.kernel.org/xen-devel/20251124111942.1325635-1-kevin.lampis@citrix.com/ --- xen/arch/x86/include/asm/cpufeature.h | 5 ----- 1 file changed, 5 deletions(-) diff --git a/xen/arch/x86/include/asm/cpufeature.h b/xen/arch/x86/include/asm/cpufeature.h index dcd223d84f..09b1118cea 100644 --- a/xen/arch/x86/include/asm/cpufeature.h +++ b/xen/arch/x86/include/asm/cpufeature.h @@ -43,19 +43,15 @@ #ifndef __ASSEMBLER__ struct cpuinfo_x86 { - /* TODO: Phase out the x86 prefixed names. */ union { struct { union { - uint8_t x86_model; uint8_t model; }; union { - uint8_t x86; uint8_t family; }; union { - uint8_t x86_vendor; uint8_t vendor; }; uint8_t _rsvd; /* Use of this needs coordinating with VFM_MAKE() */ @@ -63,7 +59,6 @@ struct cpuinfo_x86 { uint32_t vfm; /* Vendor Family Model */ }; union { - uint8_t x86_mask; uint8_t stepping; }; -- 2.51.1 From xen-devel-bounces@lists.xenproject.org Wed Mar 04 22:34:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 22:34:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246049.1545337 (Exim 4.92) (envelope-from ) id 1vxune-0005ow-6W; Wed, 04 Mar 2026 22:34:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246049.1545337; Wed, 04 Mar 2026 22:34:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxune-0005op-3S; Wed, 04 Mar 2026 22:34:38 +0000 Received: by outflank-mailman (input) for mailman id 1246049; Wed, 04 Mar 2026 22:34:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxunc-0005oh-CY for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 22:34:36 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 50a91c7d-181a-11f1-9ccf-f158ae23cfc8; Wed, 04 Mar 2026 23:34:33 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 150CA60053; Wed, 4 Mar 2026 22:34:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93CB9C4CEF7; Wed, 4 Mar 2026 22:34:31 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 50a91c7d-181a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772663671; bh=xtXiT6HoQdMIWu8cMUXATW0+N0I6AwrbMofSK5cScOo=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=nftlr+2Kn5zf3LbCRv8rT1Uqt20lvfH1sSG7gDi2AIWBjEkSvUXrNTSyefzr0YfX2 ooAr07FsoZDHZJM2vVaReF/OGfw8hxlllUyfMpX9cBuNRd3CwV6vok8tKSGSr6W9gf HYH+8LicxHj+WbAflJo7llMdOe4wCHHGb0xBww6kiqSlPIZN27U2YNkR+OG7ymx2j6 k+ZAMh5QNlKQJOkIpmtgCPjjDZAu+Og7oc7bRm5wlpR1wIOlZTv7w0M42DyPDBIUAB RLzLa+tBB1mKCCuRKudYupgp+qUGllTJQl5etZ+KJreLpoQqi2KqZvlJ9D1idV5rd6 fOJZ7tdyyJ6Xg== Date: Wed, 4 Mar 2026 16:34:30 -0600 From: Bjorn Helgaas To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() Message-ID: <20260304223430.GA41322@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> On Sun, Mar 01, 2026 at 02:04:19PM +0530, Vijayanand Jitta wrote: > From: Robin Murphy > > Since we now have quite a few users parsing "iommu-map" and "msi-map" > properties, give them some wrappers to conveniently encapsulate the > appropriate sets of property names. This will also make it easier to > then change of_map_id() to correctly account for specifier cells. > > Reviewed-by: Rob Herring (Arm) > Reviewed-by: Frank Li > Signed-off-by: Robin Murphy > Signed-off-by: Vijayanand Jitta > --- > drivers/cdx/cdx_msi.c | 3 +-- > drivers/iommu/of_iommu.c | 4 +--- > drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- > drivers/of/irq.c | 3 +-- > drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- > drivers/pci/controller/pcie-apple.c | 3 +-- Acked-by: Bjorn Helgaas # drivers/pci/ > drivers/xen/grant-dma-ops.c | 3 +-- > include/linux/of.h | 14 ++++++++++++++ > 8 files changed, 22 insertions(+), 16 deletions(-) > > diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c > index 91b95422b263..63b3544ec997 100644 > --- a/drivers/cdx/cdx_msi.c > +++ b/drivers/cdx/cdx_msi.c > @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > int ret; > > /* Retrieve device ID from requestor ID using parent device */ > - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", > - NULL, &dev_id); > + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); > if (ret) { > dev_err(dev, "of_map_id failed for MSI: %d\n", ret); > return ret; > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index 6b989a62def2..a511ecf21fcd 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > struct of_phandle_args iommu_spec = { .args_count = 1 }; > int err; > > - err = of_map_id(master_np, *id, "iommu-map", > - "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args); > + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > if (err) > return err; > > diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c > index d36b278ae66c..b63343a227a9 100644 > --- a/drivers/irqchip/irq-gic-its-msi-parent.c > +++ b/drivers/irqchip/irq-gic-its-msi-parent.c > @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u > > struct device_node *msi_ctrl __free(device_node) = NULL; > > - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); > + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); > } > > static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 6367c67732d2..e37c1b3f8736 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) > * "msi-map" or an "msi-parent" property. > */ > for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { > - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", > - "msi-map-mask", msi_np, &id_out)) > + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) > break; > if (!of_check_msi_parent(parent_dev->of_node, msi_np)) > break; > diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > index a5b8d0b71677..bff8289f804a 100644 > --- a/drivers/pci/controller/dwc/pci-imx6.c > +++ b/drivers/pci/controller/dwc/pci-imx6.c > @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > u32 sid = 0; > > target = NULL; > - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", > - &target, &sid_i); > + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > if (target) { > of_node_put(target); > } else { > @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > } > > target = NULL; > - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", > - &target, &sid_m); > + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); > > /* > * err_m target > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > index 2d92fc79f6dd..a0937b7b3c4d 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > pci_name(pdev->bus->self), port->idx); > > - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", > - "iommu-map-mask", NULL, &sid); > + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > if (err) > return err; > > diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > index c2603e700178..1b7696b2d762 100644 > --- a/drivers/xen/grant-dma-ops.c > +++ b/drivers/xen/grant-dma-ops.c > @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > struct pci_dev *pdev = to_pci_dev(dev); > u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > > - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, > - iommu_spec.args)) { > + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { > dev_dbg(dev, "Cannot translate ID\n"); > return -ESRCH; > } > diff --git a/include/linux/of.h b/include/linux/of.h > index be6ec4916adf..824649867810 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, > return of_property_read_u32(np, propname, (u32*) out_value); > } > > +static inline int of_map_iommu_id(const struct device_node *np, u32 id, > + struct device_node **target, u32 *id_out) > +{ > + return of_map_id(np, id, "iommu-map", "iommu-map-mask", > + target, id_out); > +} > + > +static inline int of_map_msi_id(const struct device_node *np, u32 id, > + struct device_node **target, u32 *id_out) > +{ > + return of_map_id(np, id, "msi-map", "msi-map-mask", > + target, id_out); > +} > + > #define of_for_each_phandle(it, err, np, ln, cn, cc) \ > for (of_phandle_iterator_init((it), (np), (ln), (cn), (cc)), \ > err = of_phandle_iterator_next(it); \ > > -- > 2.34.1 > From xen-devel-bounces@lists.xenproject.org Wed Mar 04 23:48:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 23:48:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246068.1545348 (Exim 4.92) (envelope-from ) id 1vxvwv-0006zZ-7p; Wed, 04 Mar 2026 23:48:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246068.1545348; Wed, 04 Mar 2026 23: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 ) id 1vxvwv-0006zS-4x; Wed, 04 Mar 2026 23:48:17 +0000 Received: by outflank-mailman (input) for mailman id 1246068; Wed, 04 Mar 2026 23:48:15 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxvwt-0006zJ-5L for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 23:48:15 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 99c2c338-1824-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 00:48:11 +0100 (CET) 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 624HRnnn1455840 for ; Wed, 4 Mar 2026 23:48:09 GMT Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cpj182g5j-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 04 Mar 2026 23:48:09 +0000 (GMT) Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-899bef1ea49so264839706d6.1 for ; Wed, 04 Mar 2026 15:48:09 -0800 (PST) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a12357fa9dsm1597108e87.33.2026.03.04.15.48.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 15:48:07 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 99c2c338-1824-11f1-b164-2bf370ae4941 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= UJZs6BbEFPW8OUhQ3kN9LgfRkepS1RZtU3P9VDciA7k=; b=aVdHPngsjbyqgrIW m0MJv9aGvPSOv7JHKGUvwROWy47iUsBdiQmtf8e0Vc2Bz3qNf7NAxjbYrjpXQhaX EKCyjBQQVy3MK7f/jU4u0nknS/GaC6/sGyDa+XlKtdvBgiyRJ0lbzrrfNrkVMuBh f3euURbkqHuLnHx12azkHWv8cwQiOUvW0nubrOJYqPhT8oL5TQ+VQUCQ34e+5xE5 9M3r3YAGA6/v6aUxLAxzIZ37vMVDkG7+r5SY5xMSNg+q9Wppsol1jYxs64OOMeaL dhQKmoQFsQ/I5gNQKL8MQ2Os574Lbh57rptn8P8Aj4ezUttSie6dKLNuheXOOduW hmaQuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772668089; x=1773272889; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=UJZs6BbEFPW8OUhQ3kN9LgfRkepS1RZtU3P9VDciA7k=; b=ee6zVxboDA3lJJksKOmWstfTQfZ3i8kS6YR4IGf23H1ksPBXMp3eq6HFvKNgRO9hMX EIK36jZWgPD+Seoar28v+R4uPmAFU0BbVLENJtapBsIDMe3lZSLzQ03J9vswCnx1+XRM FHU3SS6M7KBP0Vw+ZSClrf1U1FMv8SM9/0Dna/MaORjtutqWRX45pUFeDOd6O5yGRWJg lXVAuIfOpJaS1b3g6cFiGTu1n51dVD2Z+oTTGG0Kfqq3ve9f0OwdB56Ajn0X9NGZYNyD 50zO6sqUEpVIELnYvidMq/23gGEzs3Qx0O72Ow2UrxyouPH4LZCqMYQ2v+OcOe9oEMCq Tghg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772668089; x=1773272889; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UJZs6BbEFPW8OUhQ3kN9LgfRkepS1RZtU3P9VDciA7k=; b=pJJOdP3ERdQnU73kg8mrLQYaplxegTURWr930aslpfR58paqveGsM/GGEX4V18pPBG Vf021OtLuvHkW4DMI6Z3YrkLCoeTKvH2cVGGaODZlxvsoNPgUmrpd6S9E+PBZ+FAL1c1 EVLKzALblAWlWssNVwO1kMhcrHdd7BA1ub54fCPlr32tB+NuCMyIQIVIHdaq33NcZ2op AHKjxC0ciBGiVGeca6TMw1E3UriWAeRlBDyhQjQ4jY9VhjS05YpT8AV+2XC7akgtMpme x0JZPoiCiid60M5FuCceMfE7LH39jVNm64n1XbsO1j9b5FXDdPQy02mo8jw0/jeoTaqx 1aog== X-Forwarded-Encrypted: i=1; AJvYcCUaH+iTABNLPwjDGtEFVlfCqLAcxj1OOhiHq7f3v3aS5X/ZyaMnL1IyDN5r/80DdPGz35nhPIlR/rI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzatv6B0ohXd4i8Wiu4PLfAg6Jov8u+fgu6ZZL61Xb9QI1dw8GF PI9QZfGKaBjyOAdqEQ2Gbzr9ADgEns60DcWgKYa3lr73FX14C/0pnNuLD+BQIy0kRUneiRFRYuU O+HIbYfdruiMP8Y9F2E8AnKtjk0OuK7vUkOHpUQZkDKdoXylQwKdVHN2QWpF4TzC/RHIQSw== X-Gm-Gg: ATEYQzw3N3H949vLjWk86GctGyCWHaEyXem0nG0MfFIQPWwjJW0wruaz9WHELZw5sfm +643e2rWJOvc/6j6oAw+Fgvd5hGFhWV+jVPyvJ/8Dgy9IrLMqYKdwDNm+RiG2HPWIbzWTw1l+Me lP6DSm3WazxP4PM7mZ8WRBluIxNLSEm1KY6dIVjySheTEtVQ391erbacorB2axQnD6Tog6RIpVw 2kVdR/R1VkVxQzHt55tMzVizxChbxKweyGzGL011rXpve72U0XM25pv4aI9V7ne2/4bA4p1WtXA WkPFDLceBBPCrthf/43Dm1NSd7AVpHmV8E52LgPzVfNreqixLwoum69HziZgu/imn9hNt/TwNKr nMK28EBJEpH3DFs0LOAkza7ltbVF2qd+byDLoipXHmxcvT5PdrpM2/Dt/cUUgWG7vggSjnmS68u MsP5CBJ4Tbt3BvLezT3O+ZUkdVGrcd6z3Lg7M= X-Received: by 2002:a05:620a:460b:b0:8cb:7b27:9336 with SMTP id af79cd13be357-8cd5aedbea3mr527937785a.5.1772668088879; Wed, 04 Mar 2026 15:48:08 -0800 (PST) X-Received: by 2002:a05:620a:460b:b0:8cb:7b27:9336 with SMTP id af79cd13be357-8cd5aedbea3mr527933085a.5.1772668088325; Wed, 04 Mar 2026 15:48:08 -0800 (PST) Date: Thu, 5 Mar 2026 01:48:04 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Marc Zyngier , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Rob Herring , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() Message-ID: References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> <86342janlx.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Proofpoint-GUID: aBp8TEo2zQjJRPCDn0cIdPVBl7Ijo2yu X-Proofpoint-ORIG-GUID: aBp8TEo2zQjJRPCDn0cIdPVBl7Ijo2yu X-Authority-Analysis: v=2.4 cv=Ed7FgfmC c=1 sm=1 tr=0 ts=69a8c4b9 cx=c_pps a=7E5Bxpl4vBhpaufnMqZlrw==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=EUspDBNiAAAA:8 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=srtYxZOELw0pIWJIyL0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=pJ04lnu7RYOZP9TFuWaZ:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDE5NiBTYWx0ZWRfX2q+4Anqg7TN9 aZyzcA9wszhNuF9SyuQO/VhQVpf4lMJT29QjPENtwia+t8nNg7ohs3dTEb+QQpvG+uX5v8BHjwZ uroXhcnlYMUbIuSkqGtd040dcwfSRZIDcbZNk+1Xv+cuN+kBiLLLQcBtBOQg2A1CfNUz0xUwQOK DxG4fV/ZHTsn8JdCX19anIZKb2R9xapcjJwXQZGXxHwIVIZsT/pSk+5G+de/TqiYyuS464tQTNa Le2OsHCwQ9kef6pS6bSdchI9ozzm/1gw6Y7a1ThwGUv8dNhDm62Hky6Fnqpm9OVsDzyxC/Lya6O rewyO/voexc8GK1VM97aYsOwF9pxxXDirIhkwNIuXdaSCh6Nd8oz21s9eJ/CsB8vQWaH5LIfXMT es0//ODSjAkBLLkX0pIqdp/qejwbR9TYjMzgbuzYs94/qCJrewzbPrFt6aU//9MizIBXoKSVpfN ruAYxHcGTKQvO22DWkg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_08,2026-03-04_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040196 On Wed, Mar 04, 2026 at 03:02:14PM +0530, Vijayanand Jitta wrote: > > > On 3/1/2026 3:16 PM, Marc Zyngier wrote: > > On Sun, 01 Mar 2026 08:34:19 +0000, > > Vijayanand Jitta wrote: > >> > >> From: Robin Murphy > >> > >> Since we now have quite a few users parsing "iommu-map" and "msi-map" > >> properties, give them some wrappers to conveniently encapsulate the > >> appropriate sets of property names. This will also make it easier to > >> then change of_map_id() to correctly account for specifier cells. > >> > >> Reviewed-by: Rob Herring (Arm) > >> Reviewed-by: Frank Li > >> Signed-off-by: Robin Murphy > >> Signed-off-by: Vijayanand Jitta > >> --- > >> drivers/cdx/cdx_msi.c | 3 +-- > >> drivers/iommu/of_iommu.c | 4 +--- > >> drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- > >> drivers/of/irq.c | 3 +-- > >> drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- > >> drivers/pci/controller/pcie-apple.c | 3 +-- > >> drivers/xen/grant-dma-ops.c | 3 +-- > >> include/linux/of.h | 14 ++++++++++++++ > >> 8 files changed, 22 insertions(+), 16 deletions(-) > >> > >> diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c > >> index 91b95422b263..63b3544ec997 100644 > >> --- a/drivers/cdx/cdx_msi.c > >> +++ b/drivers/cdx/cdx_msi.c > >> @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > >> int ret; > >> > >> /* Retrieve device ID from requestor ID using parent device */ > >> - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", > >> - NULL, &dev_id); > >> + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); > >> if (ret) { > >> dev_err(dev, "of_map_id failed for MSI: %d\n", ret); > >> return ret; > >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > >> index 6b989a62def2..a511ecf21fcd 100644 > >> --- a/drivers/iommu/of_iommu.c > >> +++ b/drivers/iommu/of_iommu.c > >> @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > >> struct of_phandle_args iommu_spec = { .args_count = 1 }; > >> int err; > >> > >> - err = of_map_id(master_np, *id, "iommu-map", > >> - "iommu-map-mask", &iommu_spec.np, > >> - iommu_spec.args); > >> + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > >> if (err) > >> return err; > >> > >> diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c > >> index d36b278ae66c..b63343a227a9 100644 > >> --- a/drivers/irqchip/irq-gic-its-msi-parent.c > >> +++ b/drivers/irqchip/irq-gic-its-msi-parent.c > >> @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u > >> > >> struct device_node *msi_ctrl __free(device_node) = NULL; > >> > >> - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); > >> + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); > >> } > >> > >> static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > >> diff --git a/drivers/of/irq.c b/drivers/of/irq.c > >> index 6367c67732d2..e37c1b3f8736 100644 > >> --- a/drivers/of/irq.c > >> +++ b/drivers/of/irq.c > >> @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) > >> * "msi-map" or an "msi-parent" property. > >> */ > >> for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { > >> - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", > >> - "msi-map-mask", msi_np, &id_out)) > >> + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) > >> break; > >> if (!of_check_msi_parent(parent_dev->of_node, msi_np)) > >> break; > >> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > >> index a5b8d0b71677..bff8289f804a 100644 > >> --- a/drivers/pci/controller/dwc/pci-imx6.c > >> +++ b/drivers/pci/controller/dwc/pci-imx6.c > >> @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > >> u32 sid = 0; > >> > >> target = NULL; > >> - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", > >> - &target, &sid_i); > >> + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > >> if (target) { > >> of_node_put(target); > >> } else { > >> @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > >> } > >> > >> target = NULL; > >> - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", > >> - &target, &sid_m); > >> + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); > >> > >> /* > >> * err_m target > >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > >> index 2d92fc79f6dd..a0937b7b3c4d 100644 > >> --- a/drivers/pci/controller/pcie-apple.c > >> +++ b/drivers/pci/controller/pcie-apple.c > >> @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > >> dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > >> pci_name(pdev->bus->self), port->idx); > >> > >> - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", > >> - "iommu-map-mask", NULL, &sid); > >> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > >> if (err) > >> return err; > >> > >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > >> index c2603e700178..1b7696b2d762 100644 > >> --- a/drivers/xen/grant-dma-ops.c > >> +++ b/drivers/xen/grant-dma-ops.c > >> @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > >> struct pci_dev *pdev = to_pci_dev(dev); > >> u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > >> > >> - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, > >> - iommu_spec.args)) { > >> + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { > >> dev_dbg(dev, "Cannot translate ID\n"); > >> return -ESRCH; > >> } > >> diff --git a/include/linux/of.h b/include/linux/of.h > >> index be6ec4916adf..824649867810 100644 > >> --- a/include/linux/of.h > >> +++ b/include/linux/of.h > >> @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, > >> return of_property_read_u32(np, propname, (u32*) out_value); > >> } > >> > >> +static inline int of_map_iommu_id(const struct device_node *np, u32 id, > >> + struct device_node **target, u32 *id_out) > >> +{ > >> + return of_map_id(np, id, "iommu-map", "iommu-map-mask", > >> + target, id_out); > >> +} > >> + > >> +static inline int of_map_msi_id(const struct device_node *np, u32 id, > >> + struct device_node **target, u32 *id_out) > >> +{ > >> + return of_map_id(np, id, "msi-map", "msi-map-mask", > >> + target, id_out); > >> +} > >> + > > > > Any particular reason why this is made inline instead of out of line > > in of/base.c? Also, some documentation would be helpful for the > > aspiring hackers dipping into this. > > > > Other than that, > > > > Acked-by: Marc Zyngier > > > > M. > > > > Thanks Marc. > > I made them static inline mainly because they’re just trivial wrappers > around of_map_id(), so keeping them in include/linux/of.h avoids adding > new global symbols/exports and keeps the callsites simple (similar to > the existing of_property_read_*() inline wrappers). > > That said, I don’t have a strong preference—if you’d rather have > out-of-line helpers in drivers/of/base.c, I’m happy to respin accordingly. > > Re Documentation, Sure I'll add comments for of_map_iommu_id() and > of_map_msi_id() in follow up patch. ... in the next iteration, please. > > Thanks, > Vijay > > > -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Wed Mar 04 23:58:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 23:58:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246077.1545358 (Exim 4.92) (envelope-from ) id 1vxw6h-0000Mt-4r; Wed, 04 Mar 2026 23:58:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246077.1545358; Wed, 04 Mar 2026 23:58:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxw6h-0000Mm-1U; Wed, 04 Mar 2026 23:58:23 +0000 Received: by outflank-mailman (input) for mailman id 1246077; Wed, 04 Mar 2026 23:58:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxw6f-0000Md-EH for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 23:58:21 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 03e2b7d0-1826-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 00:58:18 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2403A44100; Wed, 4 Mar 2026 23:58:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 241F4C4CEF7; Wed, 4 Mar 2026 23:58:16 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 03e2b7d0-1826-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772668697; bh=DPt5htaOCfcgqP4MO7Lq2RngC1FbWjZzqXZYuC57Qy8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=c5S9RKS4ZjuSN0YHIAeMDXCJyy8MzdXORIQXJew3n0sUik9MbmfH9yqGvq1d4/xxz PAC4Lrb69SAI8lHjtSQUCl8NgfS70S348p4d0ActpJkbWGlM92PplCAUXXk9NRBuiJ zq9W2mQ2t/nVIFfq0nFcy+XyDBNdJBp2k54cN2frZt9i0JtodIxBFAN4dA+bYhj28d 4KLyMl+Jmcl5u0yhRzUTl628lxOWl3pOLkRnuD5dLn3dbnN6qx3vQGSH1sqQ9K33Vd bApM1gpqiLc+1QHLXwtxMZXvz0wFYhiY8nxrq0MvabSeKOzPdCrQmP8TTtql++xZmn BEIo81ePGzN5g== Date: Wed, 4 Mar 2026 15:58:12 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" cc: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 1/5] xen: mapcache: Assert mapcache existance In-Reply-To: <20260304015222.979224-2-edgar.iglesias@gmail.com> Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-2-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Assert that the mapcache was created prior to being used. > > Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Wed Mar 04 23:59:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 04 Mar 2026 23:59:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246087.1545368 (Exim 4.92) (envelope-from ) id 1vxw8B-0000yh-HF; Wed, 04 Mar 2026 23:59:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246087.1545368; Wed, 04 Mar 2026 23:59:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxw8B-0000ya-Ea; Wed, 04 Mar 2026 23:59:55 +0000 Received: by outflank-mailman (input) for mailman id 1246087; Wed, 04 Mar 2026 23:59:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxw8A-0000yQ-2n for xen-devel@lists.xenproject.org; Wed, 04 Mar 2026 23:59:54 +0000 Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c000::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 39e6047a-1826-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 00:59:49 +0100 (CET) Received: from CH0PR04CA0105.namprd04.prod.outlook.com (2603:10b6:610:75::20) by LV3PR12MB9259.namprd12.prod.outlook.com (2603:10b6:408:1b0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 23:59:42 +0000 Received: from DS3PEPF0000C37D.namprd04.prod.outlook.com (2603:10b6:610:75:cafe::9e) by CH0PR04CA0105.outlook.office365.com (2603:10b6:610:75::20) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.23 via Frontend Transport; Wed, 4 Mar 2026 23:59:38 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by DS3PEPF0000C37D.mail.protection.outlook.com (10.167.23.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 4 Mar 2026 23:59:42 +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.17; Wed, 4 Mar 2026 17:59:41 -0600 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.17; Wed, 4 Mar 2026 17:59:41 -0600 Received: from ubuntu-20.04.2-arm64.shared (10.180.168.240) 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.17 via Frontend Transport; Wed, 4 Mar 2026 17:59:41 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 39e6047a-1826-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zRQVnpgc4hLT/7Ac1eUzku7lu+B9GfbNeX/oxzpcWUD7kRGtsKgg5J4UV1IRX7bap+o8YKP/9j31uBcqY3Prfk03Dms1eAzGiK5L1XADjvL9l5yNHOiXlJDpvV5UEyu+KdZC1JNOKa4N7CyHXSF1KwPKxs6mcYboOsGqbu2gNYPqDHVKXeVwPpOvQgvfwBraWzkUrgAChiD8ewfzPA0JfO6dWlCZXa+CSK2m05SVtXNUbYe2Wi+e8bwktZkF8x0FB5onqioavloKdBpwap9HCthWu6lbsjw9f62rIRZOMbaXP018PRVJKkY3NHFebXK23oFaqv/gqERUpAmR6mN92Q== 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=ch29dcSMJucCWbOaueIqD6MTsLWj7sStnHz2sZuGtI4=; b=TZ7cN/oMjc34/E8loK/1UnPtcCC8zh4VX3/0Ns6BsfmFTetx9+pkSWQZ0YkDkuZtK4dtWZ7ic3+m7vb1Tl+dypyfNNK5C9Bs/fNWWAL/ZIsCvuZc0Wra38exzZyR/xQmrTEKpzkEuXuwZHmN9v23biU0/VCr7UpTybq7AwBIl1juNxjDAh85VQkZodBPTALwwPVxdJUXhxuNGonHxCyuokpihKFUWntgw2WmN2a4wUR/tgIl+fJLSdCYUPsylqqlIRzXqwRoOStm2PBs1UmU3c2r4Riksts0RWi6eaVydJjct5iyfvJLLgrUWH6IOGBpVtpEO4cEjitscHhNs2+WWQ== 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=ch29dcSMJucCWbOaueIqD6MTsLWj7sStnHz2sZuGtI4=; b=hFcSOHIuOdBMiwj3GB5ZfWHTCxFdjjB6ubY0dJYODFxvfnSd5dDygHr+dsKD5A0REbUmD55Wt++Rvn4CCeN3sg7ZP1NqHHrZba9JT9Yr7ZQ+kwZfJG33ybQVH/nnZcMSD+VpMfR0A9maG9ki3bDtNYCGZCSHoqSTp7ZMZLIgPGI= 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 Date: Wed, 4 Mar 2026 15:59:35 -0800 From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" CC: , Stefano Stabellini , Anthony PERARD , Paul Durrant , , Subject: Re: [PATCH v1 2/5] xen: mapcache: Add function to check if the mapcache is enabled In-Reply-To: <20260304015222.979224-3-edgar.iglesias@gmail.com> Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-3-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS3PEPF0000C37D:EE_|LV3PR12MB9259:EE_ X-MS-Office365-Filtering-Correlation-Id: 496567f6-e8ad-416c-ac81-08de7a4a1a5e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|1800799024|376014|36860700016; X-Microsoft-Antispam-Message-Info: sV8sZ+wqsVBoZhIsq3qxSEoqKvabd20wGRyiEOa3WQLZXGZv1khrRRmyxaIkKt0lYRhARVrvJ+4zWnAfKasw//yp6I//cDfauh+w2UdD2qW5uM++NdZIFlNlA95G31k5vpETDuNzbaaTAZ8s3s71FMwdvG4tZCSVQN69kbfqgxWWGEI2mdIEZDCxg5jwujymqT0XGTV5f5aSFi6LjDUVPKQD2AAEKM4MmOSrqIjpp7nNmlgjVIn8vk50ZpknJvRizq/21UFWLC3YN/MlA6s8T4vbr4rkIA8hxx0G9kDnU20PeBhx7WEECqOsZPTJMR5n2X6ZTpBm8PxiDP2HkKIiQznlgHEN30lPeBa0q7z4m/iFrRVdBAWZJbpkXAmgy1xaR4Jeh8N83Mh0eGj2upj0JxklMQ9yEzwfoiSKkFQinn4eIE5CiBdFC9vEpKy1Cydc4BNjq9jIcF157f8mQnmuEiT2RLs7iy+9Ytk2NHl9gOJmcMxdQNI+/qsZ9Boht/7z+7URO30/aWpvf7YJxuGTokrVD+Ek5u2cWh9i/x+oOGUCvvZgzqoOrX4Tib/vTxeN5XwoJ8EYLF97FcpeLzivw7PvPlLkWpspLQ8utze1TWGGBUyEmPnLU3fmh9kkjPJxcv1BUhi6WvLeJ9X5qCNborJ2rqNCkHpHK7kFpHy+4at4QtTIw7DHuZLvKD4qpwtiH19eqHmaSq1KAPJa2Dk3fydmf44fQW31SoVTMlaevLkZa0O7VxGrmPUpmY/kLBFvoJHxSIgGq87H6d+a0ZPaBg== 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: Nict4oubIoCW7Ll+jOvGsrF9yj+lzfYC9R9PGLoBzATbHJ36Xi45aH3FB8uQf/CW7w0v0Rxmpb5eb5lgTeMCHHWv2gJAAFwMliKxVyZVjJJQYcB05rYq0FfwJqsROoCbwV5GhH1C0gvDy0G+fX3aUGudtf7HJGKtCmp7kR5ocx0LpcnjZ7zFuXVt+OIowBtd2L6h+TO7U6XYvjBf87sQl2ez2erNf2FqsjAMiKrYEONwGMRkhTYae67Loaa3TDGV/BlTCVWSmPbWfxBZID2Wg1Q0V6bIOn2dbi62d4dxF3/4hMsd5nsNkNY5Su3jE7vYiDsYQmp8wG79Zafyf9e2b5y0vVxdzH+KfdOtdJsczG343sXHX35uHHXsy8E2/4iUy6aDBH/zxHKlv5CLtqycdJXKUhNLfZ0O3Ub0FSMc70eTcamb5PBDCCIfH+IUfEQY X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 23:59:42.1138 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 496567f6-e8ad-416c-ac81-08de7a4a1a5e 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: DS3PEPF0000C37D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9259 On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Add function to check if the mapcache is enabled. > No functional change. > > Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Thu Mar 05 00:07:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 00:07:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246100.1545377 (Exim 4.92) (envelope-from ) id 1vxwFX-0003KA-Fz; Thu, 05 Mar 2026 00:07:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246100.1545377; Thu, 05 Mar 2026 00:07:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwFX-0003K3-Cy; Thu, 05 Mar 2026 00:07:31 +0000 Received: by outflank-mailman (input) for mailman id 1246100; Thu, 05 Mar 2026 00:07:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwFV-0003Ih-Aj for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 00:07:29 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4b1e5ad1-1827-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 01:07:27 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1340040C29; Thu, 5 Mar 2026 00:07:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2D85C4CEF7; Thu, 5 Mar 2026 00:07:24 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4b1e5ad1-1827-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772669245; bh=pjv0XFNJ1B5r1groVKrNX4KoO8JMgModOOta/p4M1fk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DHStb9EIea9qnBsSQExLEgGK0/h6CsKUQmdcrfXkCl+xgD/o7EBY3m7YaEajxoWns dpxGvfQcu9QQW2UXdlQ3fWgPZcrnNYCHwO6B/MD3Z7M6JH1Cm/2/dD6ZajsdckseMS jLGgjaSCFFJhk/MVNfPX9vxIz2Lu6xE4qEDcfp5S9SoEz/6cvj6K3bbPrJL5HTvkBx ELZUM/JOZ2IL76JOBFGINI+6dM30VwkVWTR0tV9Ml81+PqDzAo01J9MWIYlNYk0EBQ 6QZR+447fwE/yG9xqR5sPAVs+A/ku8ItYvAXKDt//aBMqDqpUqXY6B/EIu1+mOxM5i 7P2g3Hbo+LsIw== Date: Wed, 4 Mar 2026 16:07:23 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" cc: qemu-devel@nongnu.org, Paolo Bonzini , Peter Xu , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 3/5] physmem: xen: Conditionalize use of the mapcache In-Reply-To: <20260304015222.979224-4-edgar.iglesias@gmail.com> Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-4-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Conditionalize use of the mapcache. This is in preparation > to optionally disable the mapcache at runtime. > > Signed-off-by: Edgar E. Iglesias > --- > system/physmem.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/system/physmem.c b/system/physmem.c > index e5ff26acec..64e6d50f8f 100644 > --- a/system/physmem.c > +++ b/system/physmem.c > @@ -578,7 +578,8 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat, > is_write, true, &as, attrs); > mr = section.mr; > > - if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) { > + if (xen_map_cache_enabled() && > + memory_access_is_direct(mr, is_write, attrs)) { > hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr; > *plen = MIN(page, *plen); > } All the other changes make sense. For this one, the code inside the if check is not strictly related to the mapcache. Are you sure it should be changed? > @@ -2577,7 +2578,7 @@ static void reclaim_ramblock(RAMBlock *block) > { > if (block->flags & RAM_PREALLOC) { > ; > - } else if (xen_enabled()) { > + } else if (xen_map_cache_enabled()) { > xen_invalidate_map_cache_entry(block->host); > #if !defined(_WIN32) && !defined(EMSCRIPTEN) > } else if (block->fd >= 0) { > @@ -2736,7 +2737,7 @@ static void *qemu_ram_ptr_length(RAMBlock *block, ram_addr_t addr, > len = *size; > } > > - if (xen_enabled() && block->host == NULL) { > + if (xen_map_cache_enabled() && block->host == NULL) { > /* We need to check if the requested address is in the RAM > * because we don't want to map the entire memory in QEMU. > * In that case just map the requested area. > @@ -2785,7 +2786,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, > RAMBlock *block; > uint8_t *host = ptr; > > - if (xen_enabled()) { > + if (xen_map_cache_enabled()) { > ram_addr_t ram_addr; > RCU_READ_LOCK_GUARD(); > ram_addr = xen_ram_addr_from_mapcache(ptr); > @@ -3787,7 +3788,7 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, > if (is_write) { > invalidate_and_set_dirty(mr, addr1, access_len); > } > - if (xen_enabled()) { > + if (xen_map_cache_enabled()) { > xen_invalidate_map_cache_entry(buffer); > } > memory_region_unref(mr); > @@ -3898,7 +3899,7 @@ void address_space_cache_destroy(MemoryRegionCache *cache) > return; > } > > - if (xen_enabled()) { > + if (xen_map_cache_enabled()) { > xen_invalidate_map_cache_entry(cache->ptr); > } > memory_region_unref(cache->mrs.mr); > -- > 2.43.0 > From xen-devel-bounces@lists.xenproject.org Thu Mar 05 00:26:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 00:26:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246118.1545398 (Exim 4.92) (envelope-from ) id 1vxwXZ-0006lq-2L; Thu, 05 Mar 2026 00:26:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246118.1545398; Thu, 05 Mar 2026 00: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 ) id 1vxwXY-0006lj-W0; Thu, 05 Mar 2026 00:26:08 +0000 Received: by outflank-mailman (input) for mailman id 1246118; Thu, 05 Mar 2026 00:26:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwXX-0006WK-TX for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 00:26:07 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e66c7057-1829-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 01:26:07 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D149361340; Thu, 5 Mar 2026 00:26:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6B08C4CEF7; Thu, 5 Mar 2026 00:26:04 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e66c7057-1829-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772670365; bh=UepqIuLUKCKQnNwC65D5tmrrRilTbI7Lk7HQcWTAN+4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GX9WQERhXAUVKacd6EkeI8nb+Eudhlsnoe568bmhGvFi6Voe8M/SE7e9joocIU7Ue tpds6qLTJ6kOcdokTG6vze9TUGMi6C8iRBAIuXiqJpx97XQnR6BdP/mJhbPD6p1/zc tCKv+eR6PXo28O1KK2bAaE7+8e/568CXRLbKT9cSQgb9i80yDwlFMye2kdaBpMmntG 3+C1IH/p2yeMcgDKPKMx1i7pAQUxVvtBV6RkLJ7Ug8tR7y55hU9ERqISqYHfN51BOB lapA0cqHweXRseVGeyPZBufXX2aYq1ERfUsG3gxR7ObAJEZZcoENcRjAIDOIqvvUd6 V5A30nL6s3F3Q== Date: Wed, 4 Mar 2026 16:26:03 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" cc: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 5/5] hw/xen: xenpvh: Add prop to enable/disable the mapcache In-Reply-To: <20260304015222.979224-6-edgar.iglesias@gmail.com> Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-6-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Add a machine property to enable/disable the mapcache. > Default it to enabled for backwards compatibility. > > Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Thu Mar 05 00:26:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 00:26:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246116.1545387 (Exim 4.92) (envelope-from ) id 1vxwXP-0006WY-SH; Thu, 05 Mar 2026 00:25:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246116.1545387; Thu, 05 Mar 2026 00:25:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwXP-0006WR-Pj; Thu, 05 Mar 2026 00:25:59 +0000 Received: by outflank-mailman (input) for mailman id 1246116; Thu, 05 Mar 2026 00:25:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwXP-0006WK-DU for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 00:25:59 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e0885a26-1829-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 01:25:57 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id BF77B408F6; Thu, 5 Mar 2026 00:25:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34732C4CEF7; Thu, 5 Mar 2026 00:25:54 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0885a26-1829-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772670355; bh=T9uUSh3wGNO8C4j8rIVXQSqKyC5PcYdW03zABygi9cI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=g3Zyr3Bx8O8NCtMEcZh2kuj7QqM+xaaeOwBUJeG9C3OsjQW93/xCj5tlVcCv4/Pzb QMZI7b7AdqJofYa0EZ4IcOb6InxLsGUC6CkCRmKLeIlzsb23MOiwrDbiniHihRp7fk bvq10B/elksbGnUo/pPZTqYX/nPMfpfuwSMgU3bGbJvhVNVoj3DrUqmyZjocsHwrqG TauERRVsiXiRH8kguCyMMUYkfcI65w8DCc7WidD415uwG8It5rRwcoVs5aclL+ajk8 WmVP+lxcMGVqhdhL01l3AWuh2lFo7s7Isg+9+3vgNdxosaEwUhpQ4ksX7++ibCGLnq umwnayngfMjkA== Date: Wed, 4 Mar 2026 16:25:52 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" cc: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 4/5] hw/xen-hvm: Add a mapcache arg to xen_register_ioreq() In-Reply-To: <20260304015222.979224-5-edgar.iglesias@gmail.com> Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-5-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > Add a mapcache argument to xen_register_ioreq() allowing > the caller to optionally disable the mapcache. > > All callers still call it with mapcache = true so there's no > functional change yet. > > Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini From xen-devel-bounces@lists.xenproject.org Thu Mar 05 00:49:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 00:49:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246135.1545407 (Exim 4.92) (envelope-from ) id 1vxwtk-00027A-Nk; Thu, 05 Mar 2026 00:49:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246135.1545407; Thu, 05 Mar 2026 00:49:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwtk-000273-Ky; Thu, 05 Mar 2026 00:49:04 +0000 Received: by outflank-mailman (input) for mailman id 1246135; Thu, 05 Mar 2026 00:49:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwtj-00026v-Ab for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 00:49:03 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 17252ede-182d-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 01:48:57 +0100 (CET) Received: from MW4P220CA0011.NAMP220.PROD.OUTLOOK.COM (2603:10b6:303:115::16) by MW4PR12MB7360.namprd12.prod.outlook.com (2603:10b6:303:21a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.20; Thu, 5 Mar 2026 00:48:51 +0000 Received: from CO1PEPF00012E84.namprd03.prod.outlook.com (2603:10b6:303:115:cafe::ab) by MW4P220CA0011.outlook.office365.com (2603:10b6:303:115::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.21 via Frontend Transport; Thu, 5 Mar 2026 00:48:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CO1PEPF00012E84.mail.protection.outlook.com (10.167.249.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 00:48:51 +0000 Received: from localhost (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.17; Wed, 4 Mar 2026 18:48:51 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 17252ede-182d-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vet7qkzyVwXzNX0dFVcKbHFYfbXwG4ehSYVmAcWkU+9buyuTE3Wqp2vNNvBGJSGZkF/JwCDDuCdKJ9B1pW4lbSl2LSRBTO1Vnncgj9ZXt1EazMBxF4Zba42bHEo3+FNdWfMCBqyr+iFYrZZUHS2cwt252kyLKrCIvbNOXNM6Et3SuGcfAw2Z/Gps7XZ4VECR/xsOsvwsSdAUmxMkqDPIKsS+SSqAbIu49z+mzMFO+TK1Ivk7MylHvyW5my1bZyQcDt0jhJLxLOAPpvU47fygze30UgdObDzzqiYZPrsHfTW5UvxsPZYwIZuDKHh+6AHD2TDOxjTPHZ26G8k6iB//jQ== 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=JIRQPm886RSi0wUulemYEN6mW0bQtLHWBDnqeSXByvM=; b=CeeKE67Y2w1tV/7VUi1/u/oW0hG0j8lufPdIXJNSrCu6vv5JYqYJqiSU+yuRflPglUtUDMi8cAKir+/IcZWpNYy+S+u3zYEGMUzvVIT8cMFEMWpJWnIL1ZsT6pVYoK9LIE00t+dH/9Q6B0/1UFatizVL3VexF6mGkr54TINvDw7xCQpZDdtLIUxMXmtJhV+spQcW2bM7LMTQZxOjJQtKdB9O07ButoT6vdLGzxaf6YRo5yww6UcCeMZ9oi0+FsAsuu/VNAwwGx+CWRNV8LXmBIAPTwT9E8w+R17xYrPEmW8Lut7e0oDTGWxBFKi0kmZvXwzEZG4WVrf3xhMqQeSgKA== 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=JIRQPm886RSi0wUulemYEN6mW0bQtLHWBDnqeSXByvM=; b=DzJQBUsNCccr2eTfDj6O4Bst3yQixDU3jWTLjr5krU2jQwT8cha/1oXPHZ1fB66Pw/zby5Fd0Jqi8z0OXCXFalinKMa8SspCb/PBskSlGtcUaK+tVyMGThiptsqaRmk+Fz2DD6J7PrTmHbux7HCxOakiZZV+5C6rnjocLqcyFYo= 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 Date: Thu, 5 Mar 2026 01:48:49 +0100 From: "Edgar E. Iglesias" To: Stefano Stabellini CC: "Edgar E. Iglesias" , , Paolo Bonzini , Peter Xu , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , , Subject: Re: [PATCH v1 3/5] physmem: xen: Conditionalize use of the mapcache Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-4-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.2.14+84 (2efcabc4) (2026-01-25) X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO1PEPF00012E84:EE_|MW4PR12MB7360:EE_ X-MS-Office365-Filtering-Correlation-Id: 0530a134-e785-4650-3aec-08de7a50f870 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|82310400026; X-Microsoft-Antispam-Message-Info: aSrjvPGButsZ6z+3LAFs0fUt93q7c7LKl2Oqb9IfDHPbPOHPMb1/ZRa/2N/AfZtY9RNLgpfhop9RmUa75iIMZcvFuulRQJv6+XCfPC85eBVwbFC+1ZixclHldjripAAodUid9ku1mgXnIWahkQ14w/8rZ2itCTnQiX1AiV51PHTBxyXXR8yTFop5rTlV9IqF+tqpeJHRQBN7H5pTNk5Lbt96kjh6HTgp/GlNoptG5u1+9gp/5DQ7j/QNgGmssNfE6XfuEL3Y4AraHLwzZLt5WZk6t7OVyEOxTisMJA8mJlR4mM9d4DDB/Marz/mIzyREoCG5mDVdH/yjtHwT/CazaKV6r5oB6gniUprVhX2qvKX8yghNTqtsim0bQXcxwuF0TNVGVnAuI0yCxQy8RKjP9aEFFTWnhQFM0b/uJMhi/hncHzhSJJMXHgcEh3kCILANc6ItS3KCWdtPw2m/ZcxVHgYO+9wL+dxTuGnQFtF0KdBHXexchIjSyz8AoQzXRaUtB8zreNybdrsYMUMpcuvk+AnMY4vL0dQc+GDaM7X371sxiiTBXBoOmWuiE3HZW17WPrk+qyDALsTbwRNBnSRY1JrIDAS9o1R2fllWWcRpWU4qE13eUuqAUUpgUdXwO48cZF1T4z18Jxtb4J/ZpnL1WtJFeNKz72+eEeb0BysNdlOVhSYI6ZUHWc0THo4tbaJbEBX5ts5BxV0afKwNxiWo9z+kcjuEHou0czbBZX0gHUrGbJFAHLE/S+yoNJMwFvcZSf4HEaoibpH+xU2QRiLjMQ== 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)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: txNWR7aYI+raqgKNKqS7mD7AT6urrqvmst5MvXsT6fATdPzWPCxssEkmkAPqoy3qjMWzJthY06ngIyifu/0tthYQfHEoI3pqlFL00r5dGU6rpP2vvM7F+yxqiBSckHh/MGQ1TN/n5wcL9dm0AQME55kiOcbTvL8XOt0nsakxWSHwvKE2dUaAVtk/doO4UiekFVW1ChtRN9O8JZkN3nkfnULGz8acaI6y0G269D16QwbeZv2xwco0U2nwfsIg1lfKS9kA8P4Iik8+j1tCkhJe+jOgT/eKC8+Dlh0WCg+nGgZHP6EiO9fIbQtwT0bA8vfaF0b4NcyJawLXKbox6KmI5Ng0WwAxcENDCLf5knaZXFEhFOIUoBHh94fCTTphypYDkbF6ljefH8oHPOVqzpxIsLejmB1JwrTpFOKo5oEYvZUVjvfVXkDUzhYZ1NvJfpVQ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 00:48:51.6454 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0530a134-e785-4650-3aec-08de7a50f870 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: CO1PEPF00012E84.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR12MB7360 On Wed, Mar 04, 2026 at 04:07:23PM -0800, Stefano Stabellini wrote: > On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > > From: "Edgar E. Iglesias" > > > > Conditionalize use of the mapcache. This is in preparation > > to optionally disable the mapcache at runtime. > > > > Signed-off-by: Edgar E. Iglesias > > --- > > system/physmem.c | 13 +++++++------ > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/system/physmem.c b/system/physmem.c > > index e5ff26acec..64e6d50f8f 100644 > > --- a/system/physmem.c > > +++ b/system/physmem.c > > @@ -578,7 +578,8 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat, > > is_write, true, &as, attrs); > > mr = section.mr; > > > > - if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) { > > + if (xen_map_cache_enabled() && > > + memory_access_is_direct(mr, is_write, attrs)) { > > hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr; > > *plen = MIN(page, *plen); > > } > > All the other changes make sense. For this one, the code inside the if > check is not strictly related to the mapcache. Are you sure it should be > changed? Hi, yes, when the mapcache is on, we limit translations to the current page because the next page might not be mapped/locked or could be in a different mapcache bucket with a different virtual address. When mapcache is off, guest RAM is fully mapped (same as non‑Xen), so we can skip capping plen and allow a larger mapping. Perhaps we should add a comment to clarify? Cheers, Edgar > > > > @@ -2577,7 +2578,7 @@ static void reclaim_ramblock(RAMBlock *block) > > { > > if (block->flags & RAM_PREALLOC) { > > ; > > - } else if (xen_enabled()) { > > + } else if (xen_map_cache_enabled()) { > > xen_invalidate_map_cache_entry(block->host); > > #if !defined(_WIN32) && !defined(EMSCRIPTEN) > > } else if (block->fd >= 0) { > > @@ -2736,7 +2737,7 @@ static void *qemu_ram_ptr_length(RAMBlock *block, ram_addr_t addr, > > len = *size; > > } > > > > - if (xen_enabled() && block->host == NULL) { > > + if (xen_map_cache_enabled() && block->host == NULL) { > > /* We need to check if the requested address is in the RAM > > * because we don't want to map the entire memory in QEMU. > > * In that case just map the requested area. > > @@ -2785,7 +2786,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, > > RAMBlock *block; > > uint8_t *host = ptr; > > > > - if (xen_enabled()) { > > + if (xen_map_cache_enabled()) { > > ram_addr_t ram_addr; > > RCU_READ_LOCK_GUARD(); > > ram_addr = xen_ram_addr_from_mapcache(ptr); > > @@ -3787,7 +3788,7 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, > > if (is_write) { > > invalidate_and_set_dirty(mr, addr1, access_len); > > } > > - if (xen_enabled()) { > > + if (xen_map_cache_enabled()) { > > xen_invalidate_map_cache_entry(buffer); > > } > > memory_region_unref(mr); > > @@ -3898,7 +3899,7 @@ void address_space_cache_destroy(MemoryRegionCache *cache) > > return; > > } > > > > - if (xen_enabled()) { > > + if (xen_map_cache_enabled()) { > > xen_invalidate_map_cache_entry(cache->ptr); > > } > > memory_region_unref(cache->mrs.mr); > > -- > > 2.43.0 > > From xen-devel-bounces@lists.xenproject.org Thu Mar 05 00:52:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 00:52:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246146.1545419 (Exim 4.92) (envelope-from ) id 1vxwxK-0003kz-AT; Thu, 05 Mar 2026 00:52:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246146.1545419; Thu, 05 Mar 2026 00:52:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwxK-0003ks-62; Thu, 05 Mar 2026 00:52:46 +0000 Received: by outflank-mailman (input) for mailman id 1246146; Thu, 05 Mar 2026 00:52:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vxwxJ-0003kl-Az for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 00:52:45 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9d0f3f9b-182d-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 01:52:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 965AC61340; Thu, 5 Mar 2026 00:52:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39414C4CEF7; Thu, 5 Mar 2026 00:52:39 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d0f3f9b-182d-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772671960; bh=fwGZAvEnOWJP1q88WAtMQ66ow+06FNYeMCKKffwLsNk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FqcfnY3P0kA97DAbjwb4HiVnesUTQqEmhtNX2YYJEgXrujXjDqjDZDquiZl0d017M BVyUwf2Kx4hrvxjgVvUHiJ+pTSzRUc+Uyk4aqzdZotfyBqI9yB338+ACLBrkqUpHUK IIhDkllhxR0HLN1yQ/aERVbYq13OW8+4IlBgxx1mXKUWT8UZCYed5Hxr7Fgj8jD9lW UIvbjbBC4fZewgO0zPp4w2I2Vhm6DGTVAv2HY1etoD7QaysKhK7w0dnMNncjrzPzOL YhN7SymeUQMuJo1arxO/0gPuIz22Y1RGKqBqTr5u2k4uSAE6LcoNXXZs5PP2YoD6pC 0ll/DQYEvL/WQ== Date: Wed, 4 Mar 2026 16:52:37 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@ubuntu-linux-20-04-desktop To: "Edgar E. Iglesias" cc: Stefano Stabellini , "Edgar E. Iglesias" , qemu-devel@nongnu.org, Paolo Bonzini , Peter Xu , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , anthony@xenproject.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v1 3/5] physmem: xen: Conditionalize use of the mapcache In-Reply-To: Message-ID: References: <20260304015222.979224-1-edgar.iglesias@gmail.com> <20260304015222.979224-4-edgar.iglesias@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1595222509-1772671960=:250016" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1595222509-1772671960=:250016 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 5 Mar 2026, Edgar E. Iglesias wrote: > On Wed, Mar 04, 2026 at 04:07:23PM -0800, Stefano Stabellini wrote: > > On Wed, 4 Mar 2026, Edgar E. Iglesias wrote: > > > From: "Edgar E. Iglesias" > > > > > > Conditionalize use of the mapcache. This is in preparation > > > to optionally disable the mapcache at runtime. > > > > > > Signed-off-by: Edgar E. Iglesias > > > --- > > > system/physmem.c | 13 +++++++------ > > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > > > diff --git a/system/physmem.c b/system/physmem.c > > > index e5ff26acec..64e6d50f8f 100644 > > > --- a/system/physmem.c > > > +++ b/system/physmem.c > > > @@ -578,7 +578,8 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat, > > > is_write, true, &as, attrs); > > > mr = section.mr; > > > > > > - if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) { > > > + if (xen_map_cache_enabled() && > > > + memory_access_is_direct(mr, is_write, attrs)) { > > > hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr; > > > *plen = MIN(page, *plen); > > > } > > > > All the other changes make sense. For this one, the code inside the if > > check is not strictly related to the mapcache. Are you sure it should be > > changed? > > Hi, yes, when the mapcache is on, we limit translations to the current page > because the next page might not be mapped/locked or could be in a different > mapcache bucket with a different virtual address. When mapcache is off, guest > RAM is fully mapped (same as non‑Xen), so we can skip capping plen and allow a > larger mapping. > > Perhaps we should add a comment to clarify? Yes please! Add a one-line in-code comment, and with that: Reviewed-by: Stefano Stabellini --8323329-1595222509-1772671960=:250016-- From xen-devel-bounces@lists.xenproject.org Thu Mar 05 07:18:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 07:18:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246208.1545428 (Exim 4.92) (envelope-from ) id 1vy2yj-00035z-86; Thu, 05 Mar 2026 07:18:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246208.1545428; Thu, 05 Mar 2026 07: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 ) id 1vy2yj-00035s-4p; Thu, 05 Mar 2026 07:18:37 +0000 Received: by outflank-mailman (input) for mailman id 1246208; Thu, 05 Mar 2026 07:18:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy2yi-00035m-9M for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 07:18:36 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8412105d-1863-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 08:18:32 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-439a90f194bso3843852f8f.0 for ; Wed, 04 Mar 2026 23:18:32 -0800 (PST) Received: from [10.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-439abdf5430sm37530903f8f.5.2026.03.04.23.18.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 23:18:31 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8412105d-1863-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772695112; x=1773299912; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=9yv7oBYtDclcfyhKCmhWSB01nKNJwfpg+GASZYYfBMU=; b=DIYXmX02ocdvkhzDuvZZhz2b8CCcweRj4ruy+55PEFan9N86m2zgvbxOcVjQvE8TkI If/JUxuVL7ZIUjGk0eoCSSYoofQ9Tq+zr19ET8kWuFuCcRkuSNZ2bqTTLBf4hQc1QOnI tn6AsWmw1fhiIsYBZZhZ9iyJtjkBQbp8NBETKbNVlC6xFZ9avzn4Mp7eOxHecOgOuis1 +I0lumeXQQS0CK1FHjHQg9g/oOsDynMfXWRCvi33s0jCuGTPKXvKsYHr45QRpxapOT53 VMo6W4nUQs5ntCR7P+uO2p5kZ7afVJjb65cP29vOh6cky7zb54szufpl3s1cNTRXGw/K CQrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772695112; x=1773299912; h=content-transfer-encoding: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; bh=9yv7oBYtDclcfyhKCmhWSB01nKNJwfpg+GASZYYfBMU=; b=QnfJOumtu/LIgbExyL31NsQIYdGXM2OE2mhGJC+3mxUAzLypHrwgfYbB52+GsoiliY EzJMrS9GeFHc757SMZUmehIY1hPW341HI5vg+W1fRYaXDVjUqyPcOM9+TKsLdJr6VUEj owKFIMxmcn+UIjdM2OxstfSBs6TjNdiws1BMl0vgPdVWkQpWLVLeRFFtDd3r+VuDpwGx 2LczDE+5WaOzzIoSSLUvSr3y13xD4kKNpt2/wbYBjZs0YfY9jRdCA/sg6lzQXSrsvz3w bKhLdg1+z/EuLGB3Je6bdr1nBj1/qZ3Fq4ZAJb9XjYJZWetDcGnjx2ZwIsNNtEvTlx98 btCg== X-Forwarded-Encrypted: i=1; AJvYcCWrWUDIfzqc0U7iSgbieGE9ui6zPj4jut+wQQw/rWuP1mjORRo8RANxmWipmwgPkTh7us7FLdWEprU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy/jGfyqVx6+LChx1TkgqqnDbKGZi5COyNa86hZVJnQSyNUI7MI bzhnw2Xjj2aBJtWqjc6awil0XtDhf56tOreR1vLcbWpaEhfn7TEovetxDB2uimgyKvBwDkAu88K Giw4= X-Gm-Gg: ATEYQzy6XxdJiET7bW42hLz8qKNpi0X2F0BfVfLmKWazyqbog7hDZ5Ln75BdXvdkb7O 1o6+F2DGKM9os3nfkKuDLYBE9lMyVMZpYkz8kouEoFmmyEQinyiYewYQ99eQtYXhXJt9nZRgExo USLPuqeThnTFtH825/RBYQvaz+B+z03RMZPZptihCGDh343kPYloPtHwu5T9K+jyFxAQvcqrsdL gfK/24uNggZZwUVynxkvFBbVA3WqVn7fGkdWy9UO7/hJYk0ugWAoyiYjLhYHrrcNBCSvVMkyrXK IU4PTPIjJvsuf/4cW4/bzAZxtFPvrUHhfQWrSTQeQrRsOTpbozlrHIxzMC/HzhSPbnN9wvAtFKY tj5BVHcYi/rAMYb/VwQrA86GzsLftjrPotwcZgO0bb4tiU4ICFkH8RmSnD4Hmc3gGOmiHhRg7q8 svzIUbFoi46MEDxgV99IVeI5oM3fv+n/pWnIP/jucnbT09gCPUmFDW+hLLjNJESMy0xf9qB0j+F sNuHXvLPF3z00Y= X-Received: by 2002:a05:6000:24c2:b0:439:aeeb:53e2 with SMTP id ffacd0b85a97d-439c7fd304emr9063120f8f.29.1772695111648; Wed, 04 Mar 2026 23:18:31 -0800 (PST) Message-ID: <6d88e3d7-3059-41ca-bf4b-6c9232e9f8c6@suse.com> Date: Thu, 5 Mar 2026 08:18:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <6357ad3f-85c8-4fe4-a2c8-8b0a0a97f1b3@suse.com> <32bd2cc9-86ee-4470-af7c-f52838e0c4e1@gmail.com> <23b77208-5321-4dad-8974-f943b38ef104@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <23b77208-5321-4dad-8974-f943b38ef104@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 20:29, Oleksii Kurochko wrote: > On 3/4/26 4:07 PM, Oleksii Kurochko wrote: >>>> +void vcpu_sync_interrupts(struct vcpu *v) >>> The sole caller passes "current". Are other uses of this function >>> planned? >>> If not either "current" wants directly using here, or minimally the >>> parameter >>> wants renaming to "curr". In fact ... >>> >>>> +{ >>>> +    unsigned long hvip = csr_read(CSR_HVIP); >>> ... this suggests it's unlikely for the function to be valid to call >>> with >>> other than "current". >> >> Agree, I will drop v argument and use current inside >> vcpu_sync_interrupts(). > > Then would you be okay with using current instead of v argument inside vcpu_update_hvip() > and vcpu_flush_interrupts() introduced in the next patch? If they're going to be used only on current - yes, sure. Of course in the overall picture you still want to consider whether to have every function fetch "current", or whether to have a caller calling multiple such functions in a row fetch it once, and pass it into the functions (possibly adding ASSERT(curr = current) in each of them). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 07:22:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 07:22:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246215.1545439 (Exim 4.92) (envelope-from ) id 1vy32K-0004Yj-Ng; Thu, 05 Mar 2026 07:22:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246215.1545439; Thu, 05 Mar 2026 07:22:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy32K-0004Yc-JT; Thu, 05 Mar 2026 07:22:20 +0000 Received: by outflank-mailman (input) for mailman id 1246215; Thu, 05 Mar 2026 07:22:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy32K-0004YW-1W for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 07:22:20 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0b04010a-1864-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 08:22:18 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-439ce3605ecso322610f8f.0 for ; Wed, 04 Mar 2026 23:22:18 -0800 (PST) Received: from [10.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-439ae0e7abasm35460460f8f.23.2026.03.04.23.22.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Mar 2026 23:22:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0b04010a-1864-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772695338; x=1773300138; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=7e+isCW/I9FrRY3kOc/NnHm7ijvXSJCvzCcAYg5805Q=; b=bRGKWNX706lZ73geg5oZWWHAhrcu1atTyx693cuPz2N0yJ6FQN0e+rwRExEDwL185y KrF3PUCBfIKCxtTy6KIdwxa7VzdgoV8iyfR005mq1naoZxtF5sWQTuAxha7oIH1WCZL/ nOORyO0BzZ4YtFQL+deyuEiJBtC5LsET0G1AhMU9w9ENDb/aaHlixo8L8K635FlMx1i0 H+ajU+Dedl+5hCT9ckm6UctTFEdcsX8a3/W6DPi6rI1SBRNlx3H92VYsOagTZZpyN3oL hOfsdlJXRubY45Uzr0se/QRTYWI6+rMw/xgtftaMg5t/FWn05aUkM6862L0YERXX5S6V wPvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772695338; x=1773300138; h=content-transfer-encoding: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; bh=7e+isCW/I9FrRY3kOc/NnHm7ijvXSJCvzCcAYg5805Q=; b=UNweELXWF/ur4geeOvEcpph1NCE/BfRzZfghwMpxQ35OzW/UkljTW/M6Qk7ZxGct4d VkRbIHeb4NdNF639FRSfDgG0i5trr+dFtKboXKguwzixRW7RdYY+/ropfFXGHYy0T8m1 gNvak+cDFgJSeqHMgCL20j2cOSYi1Ps/RHIT0XGxWNJY6XxApdIFPvEHHTFubwjOSbM5 Tww5FV1DKBrB8iRXjKBeg9c0hu8Te9s/k8zj5+2fZf+ohDPfsmHzxTTTHQM7uqy+ppOF z7B2lagBMVCGHc58h2v1lbKX1OLmqSSo8DifPx1D+gNo8LGG6/pafXzXrLpTl8R5kwSB zwrQ== X-Forwarded-Encrypted: i=1; AJvYcCUj/ueYTsL7dGDeLPvqOUlheFPMrqzRW8bvQe0/8vUOH847lwtoEefup8FpoOQIeHxwj6HLNGF2IGE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy16TCkelDW8LlqZ2dVdwxOE2Me691RDeKfHpj1IQxPaQFjto6x pMr9T5uoOO5RSE1wi6oGpSb5jXD3JjrsCHGcTSlYkvr89ca/lbeinQITqGthwoWvew== X-Gm-Gg: ATEYQzxfAhghSHerN0kv/rEfCAHanj9oWgf/H24mdo7B0QeKnZJptaslO1gb0UGhhL5 YEZnEEiyFgm4WacT7YAHA+215bRvU2rP7xLWkix/cr0wYgxEnAtb86BDkuafmL2rNCeYnp+MTUv VpJt5eI3IUYlIqETLJFYZJJiOma9z5hlRbczPnMxbsvn33HhClq9O+FIe9M5RAEY+IUGVwC11zB kQd8NA70gYQP/6LkAscqGxyT2F2BP563Ddi9YvUpSP827cyXzyc5WXjcF0oklG37gqVaxLBH5l1 TKY/oB+eqhbCZhNchK+N+6S6+K9Xf+taY84LBZ9Ryk26on7dz1O7WTOud+BbRGBMdT8g+2H+WH0 1MurCPEEiS3+PDDkBmQ8REnFXw+ACQmTTZwSKt5pCJz6xG70dWlYyQQypLA5ZSD8SqQqdUIlQV3 m3Rll7GyJm0Ke9sCK6a1haKgWFthDPojv3vGG+dAHdgMOHcMKp9uMcqJ+zdmqFrqzz9EzUnu6zw zo9xi/fcudP/lM= X-Received: by 2002:a05:6000:609:b0:439:af25:e4ea with SMTP id ffacd0b85a97d-439c7fb73b9mr8778964f8f.25.1772695338085; Wed, 04 Mar 2026 23:22:18 -0800 (PST) Message-ID: <63982343-6929-4ad6-9f33-61f6c1db5eb0@suse.com> Date: Thu, 5 Mar 2026 08:22:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 02/10] xen/page_alloc: Optimize getting per-NUMA-node free page counts To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , "xen-devel@lists.xenproject.org" References: <5e4d4674-1e1a-4902-bcd0-a24fbd13dc8e@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 19:21, Bernhard Kaindl wrote: > Jan Beulich wrote: >> On 26.02.2026 15:29, Bernhard Kaindl wrote: >>> This only needs moving the ASSERT to before the subtraction. >>> See the previous commit moving the BUG_ON for outstanding_claims. >> >> Please can you avoid such statements? You won't know in which order the >> patches are committed: Patch 01 may go in weeks or months before patch >> 02. > > Thanks, ok, will remove. > > - NB. I do think the first 3 commits should best be applied in one go. Such would want stating in the cover letter and in all affected patches (outside of the commit message area of course). Preferably with a reason (it's not quite clear to me, I have to admit, but then I also haven't looked at patch 3 so far). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:08:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:08:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246243.1545449 (Exim 4.92) (envelope-from ) id 1vy3ka-00024S-6g; Thu, 05 Mar 2026 08:08:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246243.1545449; Thu, 05 Mar 2026 08:08:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3ka-00024L-31; Thu, 05 Mar 2026 08:08:04 +0000 Received: by outflank-mailman (input) for mailman id 1246243; Thu, 05 Mar 2026 08:08:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3kY-00024F-DY for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:08:02 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6ccb5f44-186a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 09:07:59 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4836f363ad2so90745145e9.1 for ; Thu, 05 Mar 2026 00:07:59 -0800 (PST) Received: from [10.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-4851fae02a8sm39359085e9.5.2026.03.05.00.07.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 00:07:57 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6ccb5f44-186a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772698079; x=1773302879; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=Ll9oBLATbnRIzMJVChV4eHyxGWZ6bdG7yEjwsKUccM4=; b=aZTmXXczQtfPnc7xGMybMS+9ZcZBZnx2r8PPI9uAbB+xT5JjNSPHk/gtHFH0Vi2bbz NzLQU4aOVzY3XaRMh6ip4Slxtgm44X6z9AS7vjc2KRp2yvTjbhFw7l43bFkxaJ41jPIa pi/DmKSL9jo1b8IV9+7X8bbMgol68Q95aMHonA98jbEL4dMTvXfZRGJMOkZACDvGlzoc AVNGFvUKhWvortwJvEv+XQo6seuqyiuKu+9Xf+yB3hj8gkouqp7UoIqEEyPjLQQDWLBU CSXa5XYsYK+ki0tqiDyP+54KSVCEfNAr5ITnud2jHVukCzgQaQ9jLNBFsmrOWWu2k13j G/PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772698079; x=1773302879; h=content-transfer-encoding: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; bh=Ll9oBLATbnRIzMJVChV4eHyxGWZ6bdG7yEjwsKUccM4=; b=b+VCmg9taLDnDv4nUGueuIuTuy1UYV20vKSI80VcZe+kdQLLCctJ0NcE44w6op/heQ vmMlKVJAOvaqDYmsu/mynGSmoDYMrw5d+f4wGga/skXFl3rNuCIiacJ08watIIjIHFM+ 0AuTHy/Ckul8mBtqogz4ic0tK7fQx3mMhDK9k0Wl5N3aKpU/tuVGigph1IoWMjZ4vpyH f3gL7KC7/GDsnsypN+CcWcuhCjdKlW+hywtQO97IAozAkGhv5D4DvoTl2/P4ZnANkFj5 WWyYfMN26Z+5m2Jc4IqZ+3ts1zKmU/BjCSKaqJs0moEJKXzQFMyPmjTOpYHaBJL7mY6P xcmA== X-Gm-Message-State: AOJu0YyEjXGcEDQI1sljuhm4jQvoWevadX6gUAEcU+PnOSH1/jnSQF/v ybP2Yu65VraQyt1qZmlypqhCa/Xjg+yUvubf11qH9DhtPhq9btceEQPvOgJ2NmO7Lg== X-Gm-Gg: ATEYQzzFSqG53UbIuWL77udaHA1y7cZ6baDysRVuehEOr/hMbgYKBH97VK5Fmw4R8Pj a46+XEnx8BrJwwf9WCb1Ir3Oyrl1O8Eg5QGVoNyP0d+AQZIMKxfISS/zbkKlmPVAdaOWLSpTKww mwIL/loMnT5dON7nfxLIUdn5knACoHOcGUil5BggVIW6If+3eIhdSY6NusUG43apte4xU54VRnv FBmMx/z0jcgldjJTlIkFWh9ucJ2/HxvjUydoG+9peBVGz5HZ/9QTK/NWMtwhOPod+C5B1cUjodk Fd6ZZ/hX+UlSIeJTAALizaWi21s84reLfOVVw/sHYF+T2nIoAI7NHiorEX4lC6OWnjBeidywbJX 1WGJXF0sk47+SvDj0V+PVHg/GVj3d4VrlG+Xdix4pcAbZg6+tj6D8LrskIt0zMnFBRBeebOskEU rn+WMrYvAaLtRfQ3u4S+ihr/yUVPmWebE/haEM/RzfU0BtIecBKc3cx7Mdah+qLFOsnPTs3jDIZ P5eaXFB2kzg1oA= X-Received: by 2002:a05:600c:c4a5:b0:477:b0b9:3129 with SMTP id 5b1f17b1804b1-48519831168mr73337455e9.3.1772698079120; Thu, 05 Mar 2026 00:07:59 -0800 (PST) Message-ID: <1f80f87e-8e58-45de-8785-1efec5169176@suse.com> Date: Thu, 5 Mar 2026 09:07:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] domain: use unsigned loop induction variable in complete_domain_destroy() To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> <80129c3a-77cb-4cb1-b3fd-128454e3db0b@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 18:36, Roger Pau Monné wrote: > On Wed, Mar 04, 2026 at 04:48:07PM +0100, Jan Beulich wrote: >> On 04.03.2026 16:38, Roger Pau Monné wrote: >>> On Thu, Feb 26, 2026 at 10:01:45AM +0100, Jan Beulich wrote: >>>> --- a/xen/common/domain.c >>>> +++ b/xen/common/domain.c >>>> @@ -1475,7 +1475,7 @@ static void cf_check complete_domain_des >>>> { >>>> struct domain *d = container_of(head, struct domain, rcu); >>>> struct vcpu *v; >>>> - int i; >>>> + unsigned int i; >>>> >>>> /* >>>> * Flush all state for the vCPU previously having run on the current CPU. >>>> @@ -1485,7 +1485,7 @@ static void cf_check complete_domain_des >>>> */ >>>> sync_local_execstate(); >>>> >>>> - for ( i = d->max_vcpus - 1; i >= 0; i-- ) >>>> + for ( i = d->max_vcpus; i-- > 0; ) >>> >>> Is there any reason we need to do those loops backwards? >>> >>> I would rather do: >>> >>> for ( i = 0; i < d->max_vcpus; i++ ) >>> >>> ? >> >> I think it's better to keep like this. The latter of the loops would better >> clear d->vcpu[i] (to not leave a dangling pointer), and there may be code >> which assumes that for ordinary domains d->vcpu[] is populated contiguously. >> Hardly any code should touch the vCPU-s of a domain destructed this far, but >> still better safe than sorry, I guess. > > Yes, you are right. sched_destroy_vcpu() relies on this specific > top-down calling. > > Since you are adjusting the code anyway, it might be worth writing > down that some functions (like sched_destroy_vcpu()) expect to be > called with a top-down order of vCPUs. I've added /* * Iterating downwards is a requirement here, as e.g. sched_destroy_vcpu() * relies on this. */ ahead of the first of the two loops. > For the change itself: > > Acked-by: Roger Pau Monné Thanks. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:16:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:16:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246254.1545458 (Exim 4.92) (envelope-from ) id 1vy3sP-0003db-TO; Thu, 05 Mar 2026 08:16:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246254.1545458; Thu, 05 Mar 2026 08:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3sP-0003dU-QI; Thu, 05 Mar 2026 08:16:09 +0000 Received: by outflank-mailman (input) for mailman id 1246254; Thu, 05 Mar 2026 08:16:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3sO-0003dO-LV for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:16:08 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8ee91161-186b-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 09:16:07 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN6PR03MB7670.namprd03.prod.outlook.com (2603:10b6:208:4f6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 08:16:04 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 08:16:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8ee91161-186b-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C8EscSIkYhwy37DDGXCQKkzLGtK9lLCV1+hvrG/xQ4DI4sbWdSmsI5+YII3LRvnu78RloW+OXUP5MwaSnx+Ce2TmGKYuytpZd2A6JOm87IWOp+K7UvNKnOhnRGBtpRaNOIugRjEv6SNp/jH8w69mcmwURPlwp383RbfP9Ve3CdPhgtFTcmabDabQ6zsRkiR7SSlV305DkZnY5FoeuirH2Va+m+sIRILPhXVgbOpg/Qqdz2GFaqycerqLw5znbZsTZBl7/iw7XTzFccUXebgNYFjcyrLw63/17CE6Cp+BY3wey760r7OkhCQaaboTEcIHiekEzFLY3QIg0zvFJj/Mrg== 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=tXrrTFjBnPUpxvOLmHQfRDee3fworYRtsARCth8g27o=; b=WDQ+r2/VagFGjOQbeNOPzEqSEd63UP4YFNjhhFJFyli2+wTvaTYb0knDqzZ9cn/0MD7D4f4AtLxI6nwaXHRI9EIwghntaXp3VoDmh5g7+frhmloTM214KXHpAZ8ujbgmsQCCyZVbSlrT9kr5BWzOFNgQ9ItBmehucM1clPh+z2j1j28QFSL+dppVplE91+l+bVLOpIVdftWt2FH/Pu3SuoDRYU8eDXRZUO1BsMDgiivgsLmKGoVEbHCTJ2AQWkJ6EcYGvu8T++k/YEOHpuvHJaa+dmzhPHaATRZl4in32ISXr2tXAnqaoVlhoEvDWMT7/iiDEDfia//7u4sa2W+yRg== 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=tXrrTFjBnPUpxvOLmHQfRDee3fworYRtsARCth8g27o=; b=P2m8dd2oB7z1bI0l9M44IU+H5GMtf0pboBko8PvOUHvsncxuCZ6d2uVi8aHX8xaJxAzEQ+3VlMnm488OuOKSIt44/9U1kborbHhWjI6OpW0r3fOKKNRW8yfJv4aAjYEeyqIpHXhPCa0GrHmpeGSsB3fnlJUIHeaRZz/Ppn3pS6c= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 09:15:59 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] domain: use unsigned loop induction variable in complete_domain_destroy() Message-ID: References: <7af56fa6-4254-4704-9843-a0d099e6bb0b@suse.com> <80129c3a-77cb-4cb1-b3fd-128454e3db0b@suse.com> <1f80f87e-8e58-45de-8785-1efec5169176@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1f80f87e-8e58-45de-8785-1efec5169176@suse.com> X-ClientProxiedBy: MA2P292CA0025.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN6PR03MB7670:EE_ X-MS-Office365-Filtering-Correlation-Id: 1615daf4-4922-4e70-92cd-08de7a8f70a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: Pbowc4iC8uTzPeOIGHNUHl8mZJo43h+KS9MIKZeQNb+sfbGyvCvqaYuBjC5PtEfPE/d2euyHLyBMmle+71iiwm3PKGjgA7i+j7gAMyy4Tjqjm+7KkkeziBVfIacxKACZh1JGAP04sJttmgCry4/ii4oQvp4P1jQNlPDD/Ej2+X5i8YsxiRe3YAy3zTPkHfc6ycVc8kPgYxJlIVBGnWNmRjLJmdbqhj891SkppElVxPx22awnUzyGWjFNIXkNNirm/eLch53hrNvmhYo/sogkF8e4h5DZM/sDLHO3g4/HtdLK+3CADLJ0tDWO0XqVUC+emYKXvAPmLVs39kU7kxo3M04k0i8Knt1GowZnEPNmQ5rv27F8fEoN7U62DN3OCv8P/H6oukoXxFpjS7+YHfrfQhT9jbAX8BPpuzsIOR5rrIWxiwflwf+NkNjM8XoJbtc+pC1vN8UDa+vRsn+Lk5iMG+4kVFGBtx86ue0kMc1vyZv/WynAZPUV+4nRD01TOUE5KU15UtsidTBC18pKOfV26EFVwt04JFKDnTrvqcN3quYHuOG7QWSGHZzlJsRUkBC84DrXkrKYPekD2Uz/lkkCnSKFlWvWA5O+iJhUhp8/kJHFahgN8b4+1pS9KRTJ7eLQy8AFWlTSk/GO0e9j7MsJqd+/4NeVSUFIfuy9ug75AfgoyMrlK+3DYrNBGS7RIrtQFt57YI3snRbJY9I/95k/cbllXEEWNbRVpDAW0JhicQc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TGxpSURiNWJ6NjhTaXRCSG9EaGxmaHJKTFh5NzVQSGNrSEVjZ2NQTHlLVnJP?= =?utf-8?B?WkY0bUxaS0Rvc0svd0JiNExVL3pUeHRwck5ncVZkQ0daSVh3UUNlRCsrOURH?= =?utf-8?B?STVyaitQbnI2Yy94UFhtRnAreTlvb2dkRDRtNmNSOGFyYVRVMklrNzdVWG1u?= =?utf-8?B?WUxxMlJSYTcwc1FDc0ZaZUZNejgrSGdkcXB6cnNYWWdhcGg4YkJxb3pyVDVM?= =?utf-8?B?b3c1SGhjdk95clY0bjVXTTNMTDZGUm1adWgyeTU1eTZKYWt0d2JsUkoxOFBN?= =?utf-8?B?WklpaDRBNnE2VVVibXc1RWlRY29FYlVxTm1kamg4ZUFGblAyWkNQdkVvSWM3?= =?utf-8?B?eG5qdUdlSDZ5SytHeXR5aEFIQ0FabDhPME54TkUxWlRldFYydHZaUG9QTHIz?= =?utf-8?B?bi8yTHh2T3lreUFPK0pLSXlQY2paUm5lWVBTVWlYRTluUHFuVlgyZFFEbTR4?= =?utf-8?B?N0p6eFdUUmZVbSsxbjJ6ZUpSWER5TG9PdFl4OTBaeFJiNC9EUmFpaGp5a0lH?= =?utf-8?B?ZlUwaDA0V0hwdzJmd1JOMWlseXBrY2xOa0ViZFpreGp0cEdTbU1DTmZHRmhO?= =?utf-8?B?L09ZeUdSN1l1K29zVWlCaXo1djBRMjZtN1BBalF4WXlic3NpTVNkZUUrbTI3?= =?utf-8?B?ZzBjMStSZVBqYjZCcHFXOER5NENXc1JNdXBXUzFQT0Z2ZkplaFZDYjBtbGxC?= =?utf-8?B?cFhkMnVCeE1aM1pKZEg4WGVzOHlRT2NYdGgrZVpzY2Nsd1VabWU2emMyWUM5?= =?utf-8?B?NnAwMXRsREw5aHFrT0cvNEJ2RUxmSy94NDkyUHlxVlE1cUFzdHNWSFdYa3ZW?= =?utf-8?B?QmlYTmxhK0h5S1hEL1dySXNZVnNWMU92bDBxazBXdmZpM3h6N3B2RzZJWndD?= =?utf-8?B?T1g4b2FwbzVQMjNsaUNpdWJqSHFKaldkZEZjbEY4TVRLemdUc3hOUXhGVzE4?= =?utf-8?B?Z01RUDJEZFllaHdNRHlyTWtiaXkxU005Q0pIcGMybVl4T3pYZ3JKRFFPOTJY?= =?utf-8?B?MG0zWGd5L1dMaWJNRUhTRmRFSGI4RTBJZ0RKeWZGQUxBd090aDRjY2paanFj?= =?utf-8?B?ZHpIZmZXY050WnFYaGQvNDdDQXdWMHFZcENVMzNGOTVvM3B1TmZuME13ZnZE?= =?utf-8?B?WWZ0UFVBUHJtMy9xY0I1b0h3RUhLT3BYMFRWZkI0WUdrdHk3WXk0UytmQkJ5?= =?utf-8?B?S3ZjUGp2R2lUOWhMck5SM2tHVHJsdkJLejI0eDdCMnowZHlIc3NjcDU5RzZw?= =?utf-8?B?bS9Sc3FVejM0dDhaUzZFSkRpR1hiQ21VNjZBcEU3TStnUVhqWHBKS1hDaDBk?= =?utf-8?B?aU9rcU1acnFNbnl2a2t2S2dmcjRSWGNKU1RFZlNaVUh3bUdjVWlNbTZYNEVV?= =?utf-8?B?NGYwbWpnSnovelIxNkkvMklDMm9tanp2ei9sdCsydURDNldwUDZNT1pkeEZq?= =?utf-8?B?Mk1uN3pTOE1ZeHFld21rNzliNEtsb3BLQSt4UWZlQ3dNc2U3ekFCS1d1dzN3?= =?utf-8?B?TTRPcDRkRG1sWWVrckRqT1ZaRExzVDlFbnBiOXlJOUlHcFllS1g1UU5nNmpm?= =?utf-8?B?b1lSa083U3o0N3g3LytwNzRYSEpTN1preksrbjdiSWFIanBESkdobUNuTlpK?= =?utf-8?B?UWRKOFh4TFhhOXExUkNmTkQrM1puSU0vaE5LVFd3UUNlUWxkdXJ2ZWEweWdN?= =?utf-8?B?Nkw2L2ZrTWRWbjc0U2tOYnFtaDR2MWYrYW9xWDV6OGd3a09VV1ZoY2Y0WDlR?= =?utf-8?B?cHVqVmNZNEZXWXo1TUZWWWtrMWxGZ1dCQzRka05PZWtaZWIxK3ZuZHB1a2pR?= =?utf-8?B?QjRaQU1YaWxsVy9PNG84R2dnMU1sbVpvM2dsVlFVZTA3MmUvd1NNVlNLTVpW?= =?utf-8?B?dFM1SktBWFh5RTNFbitYZnVPRkNiVTRBME40SFRPM3RqekZWZjBRSXkvT3h5?= =?utf-8?B?UmM0WWtwR1k5K3RxMW9hMHZBMnkrY0tJc3BpdkJURzM3OXcwdCsycE9TWi91?= =?utf-8?B?Vk9TUjRMajREWHB1a0ZWN1Jab0h5UFIwWEhPb0E3RWV3ODlqZ2tZRUhSUEQr?= =?utf-8?B?NXZHVEJsVUNIL2YvWE41OTRJVXlURWtDL0tVcE1XOEd6a3oyNWNGMjZzbzU2?= =?utf-8?B?dTRKTFBVVkh6ODlVSDFTVi9JeGI3Ykkxa2dDdFRzb1pQVmFFR0JnQythdEFw?= =?utf-8?B?WGpTbU5NY0YzOCt6azVZRFJHOUUvanZ3T2M4VndNVWdlUTZHTlNlL1B1QXRk?= =?utf-8?B?aWZyT1ExNnVpMFZJUTNBVjNOWExSdzUxRWx5ZTZwSGFHOVBLanJWNEhDQzI4?= =?utf-8?B?bmlMMzhqQUk0bXN5aWxrNmg5UlBpcFpKQnRpOUhDR3ZsTXRiSmY4Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1615daf4-4922-4e70-92cd-08de7a8f70a0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 08:16:02.4003 (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: Z5HOahORdvJkpARXWbhuf+5811S69rRRgBVWRvuI/ZkQiYkb4orHoj9FzYqYpGbfXHgh2Q78QKNHUrWMf8Rgeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7670 On Thu, Mar 05, 2026 at 09:07:55AM +0100, Jan Beulich wrote: > On 04.03.2026 18:36, Roger Pau Monné wrote: > > On Wed, Mar 04, 2026 at 04:48:07PM +0100, Jan Beulich wrote: > >> On 04.03.2026 16:38, Roger Pau Monné wrote: > >>> On Thu, Feb 26, 2026 at 10:01:45AM +0100, Jan Beulich wrote: > >>>> --- a/xen/common/domain.c > >>>> +++ b/xen/common/domain.c > >>>> @@ -1475,7 +1475,7 @@ static void cf_check complete_domain_des > >>>> { > >>>> struct domain *d = container_of(head, struct domain, rcu); > >>>> struct vcpu *v; > >>>> - int i; > >>>> + unsigned int i; > >>>> > >>>> /* > >>>> * Flush all state for the vCPU previously having run on the current CPU. > >>>> @@ -1485,7 +1485,7 @@ static void cf_check complete_domain_des > >>>> */ > >>>> sync_local_execstate(); > >>>> > >>>> - for ( i = d->max_vcpus - 1; i >= 0; i-- ) > >>>> + for ( i = d->max_vcpus; i-- > 0; ) > >>> > >>> Is there any reason we need to do those loops backwards? > >>> > >>> I would rather do: > >>> > >>> for ( i = 0; i < d->max_vcpus; i++ ) > >>> > >>> ? > >> > >> I think it's better to keep like this. The latter of the loops would better > >> clear d->vcpu[i] (to not leave a dangling pointer), and there may be code > >> which assumes that for ordinary domains d->vcpu[] is populated contiguously. > >> Hardly any code should touch the vCPU-s of a domain destructed this far, but > >> still better safe than sorry, I guess. > > > > Yes, you are right. sched_destroy_vcpu() relies on this specific > > top-down calling. > > > > Since you are adjusting the code anyway, it might be worth writing > > down that some functions (like sched_destroy_vcpu()) expect to be > > called with a top-down order of vCPUs. > > I've added > > /* > * Iterating downwards is a requirement here, as e.g. sched_destroy_vcpu() > * relies on this. > */ > > ahead of the first of the two loops. Thank you for adjusting that. Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:17:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:17:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246267.1545468 (Exim 4.92) (envelope-from ) id 1vy3tg-0004Gv-9s; Thu, 05 Mar 2026 08:17:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246267.1545468; Thu, 05 Mar 2026 08: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 ) id 1vy3tg-0004Go-6A; Thu, 05 Mar 2026 08:17:28 +0000 Received: by outflank-mailman (input) for mailman id 1246267; Thu, 05 Mar 2026 08:17:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3tf-0004Gi-Lz for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:17:27 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id be9cfc8e-186b-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 09:17:26 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4836f363ad2so90834185e9.1 for ; Thu, 05 Mar 2026 00:17:26 -0800 (PST) Received: from [10.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-4851fae0202sm34657045e9.6.2026.03.05.00.17.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 00:17:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: be9cfc8e-186b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772698646; x=1773303446; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=QEjeYz6lnIlzwxWNrjsCG0up/pNF6u3rQp6W7WOXyaA=; b=RN+1F8fOi93FZ/Iz2PcbpI0nCJcTRweCiG+Lq3Tq72Q/72JObprmHIgRw+2XCyQj8q cWD87rE6SbZo7HyyH9BG3vvx8LJQmzWAuWxixTc+8LZreQU13e0ZQx/BUUbZZClYlec/ Wf9w99JRH2IniSYnLJu40ywCxtLlihPmnt0B5Z19X/9wjBNly9/Q7FWKplWyYwZw+M2d kSiA6i8v5JncWk+btsZFhO8WvfSHur9EouSdkkpDa2/lh9hp4izeLSZU6aw96ucAxJVQ 93WIHXQEShtNyULdJCzBIY9umQVNFpjeOGPXRA4YF7HMgRJm0gDwitW45qPcYaAhahoZ Pu/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772698646; x=1773303446; h=content-transfer-encoding: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; bh=QEjeYz6lnIlzwxWNrjsCG0up/pNF6u3rQp6W7WOXyaA=; b=O9FeSIBGKFykBSFMvYB/VYTr8ch2MZ636A+uoDZfxHN/tqNxYuAJ1Q/IpgEGRF0lIT 1YpFpYvw9ivbfVe1MeZgRg8k7Z15ZeEg/3MN1I4gc8v2RnWZAAepHGWOL4KhU3EYeQpr k/Xy23VwS2bT3vDMvHkIJUT6ll1n1AjjtF2FPQ7+OrC86iOz0Oqvv3aOXSWzUcLZx1lz 9Glu2L+O0Z7+czTxUOQJZSH4rRQ8NYyibQixE//7Ko0W0cNqhl5T0YW5sdLaM/e8QLpl VSO+8ikgTzAjU3ceJg/zeiU5bxO9bAHZ0nQHOgE5pk+q/VMWDhJZhDaZcAeHaKbUkGhU BhBQ== X-Gm-Message-State: AOJu0Yy8iVV2KrjFlOWSQhQzDho2+q/NR2PF+A8FQTMts5BRHSLJY7Sz ZSvsDqzFACGVLLVPcPiVCKVubXfpaLMn7TnZuBsZSPw9oRZl2jwMrFiw8W5P70O0Lg== X-Gm-Gg: ATEYQzzE6y5He/qPPWXGgeHZhyThfVU2U1Y81i6gKHV6KI+tJWgxqeonDYPxaFDS+IF QXjBP0nqo8h6Rvyo/G6FZZjI/xG62vPCkayBYieQ4YuOwJ3VxFejsDVKWEE+Y1Bsle+Fdu4P8Im iw+yt1AJs9ASzc62K8UAhFkHU4o3fo32e59FLB6i1c994871f6UFUYXXVa5gxg+P7wo1Dqj5cz+ lVD+bVCC8vfOEPkYzWTa+SXujt+1XYBTFEyEyYnF7vJEbLN1FEtUn+V70GOBHDXBWXqwV/vUgS4 HT/bQtpdE+H8elQLP6tN4BXra/Sgpxc6WJI0ZJDw2Oci5cDHzlSg3rxYiYY1JrA2MDjQ/0l1YoE z7XXBKS11f1vEaux3q+g0gMyCBw+EEgLx49eqkl/CXXfxlT7XLwv/7lLphbshG0WhZghOxfZ3V+ U1+wTS715YYYCoBnDWAAbRQtijYjbhVI58cbgNyIqCIaQwof7+fflcBxO9kjRDMOM0YQzcUKCR0 gn1x4Up3bo5k2Y= X-Received: by 2002:a05:600c:8b86:b0:483:3380:ca0c with SMTP id 5b1f17b1804b1-485198bf9f7mr98613605e9.35.1772698645782; Thu, 05 Mar 2026 00:17:25 -0800 (PST) Message-ID: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> Date: Thu, 5 Mar 2026 09:17:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 17:36, Roger Pau Monné wrote: > On Wed, Mar 04, 2026 at 03:37:25PM +0100, Jan Beulich wrote: >> The treatment of ACPI_PDC_CPPC_NATIVE_INTR should follow that of other P- >> state related bits. Add the bit to ACPI_PDC_P_MASK and apply "mask" in >> arch_acpi_set_pdc_bits() when setting that bit. Move this next to the >> other P-state related logic. >> >> Further apply ACPI_PDC_P_MASK also when the amd-cppc driver is in use. >> >> Also leave a comment regarding the clearing of bits and add a couple of >> blank lines. >> >> Signed-off-by: Jan Beulich >> --- >> Including XEN_PROCESSOR_PM_CPPC may need accompanying with some change to >> arch_acpi_set_pdc_bits(), but it's entirely unclear to me what to do >> there. I'm unaware of an AMD counterpart of Intel's "Intel® Processor >> Vendor-Specific ACPI". Plus even when the powernow driver is in use, we >> never set any bits, as EIST is an Intel-only feature. > > We possibly never need to set any bits there for AMD, as those _PDC > Processor bits are Intel specific? Indeed, that's a possibility. >> --- a/xen/drivers/cpufreq/cpufreq.c >> +++ b/xen/drivers/cpufreq/cpufreq.c >> @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ >> { >> uint32_t mask = 0; >> >> + /* >> + * Accumulate all the bits under Xen's control, to mask them off, for >> + * arch_acpi_set_pdc_bits() to then set those we want set. >> + */ >> if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) >> mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; >> - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) >> + >> + if ( xen_processor_pmbits & >> + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) > > Currently the CPPC driver is AMD only, and hence when using it we > don't care about filtering the _PDC bits, because the ones Xen knows > about are Intel-only? > > As you say, we likely need some clarification about whether there's > _PDC bits AMD care about? > > Linux seems to unconditionally set bits in _PDC, so some of those > might actually be parsed by AMD. Or it setting whatever it wants is meaningless on AMD systems. Where I have extracted ACPI tables readily to hand, there's no _PDC there. > I think we might want to split the setting of XEN_PROCESSOR_PM_CPPC > here from the addition of ACPI_PDC_CPPC_NATIVE_INTR into > ACPI_PDC_P_MASK. The latter we can possibly untie from the questions > we have about AMD usage of _PDC. Hmm, yes, I can certainly split the patch. I'm looking at it a little differently, though: Us leaving any P-state related bits in place when cpufreq handling is done in Xen has been a mistake anyway. What's unclear is solely whether because of us driving things some bits need setting (likely none if AMD systems indeed don't surface _PDC in the first place). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:19:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:19:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246275.1545477 (Exim 4.92) (envelope-from ) id 1vy3vS-0004nB-JJ; Thu, 05 Mar 2026 08:19:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246275.1545477; Thu, 05 Mar 2026 08: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 ) id 1vy3vS-0004n4-Gc; Thu, 05 Mar 2026 08:19:18 +0000 Received: by outflank-mailman (input) for mailman id 1246275; Thu, 05 Mar 2026 08:19:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3vR-0004mh-Hh for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:19:17 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 001bf376-186c-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 09:19:16 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4836d4c26d3so59982355e9.2 for ; Thu, 05 Mar 2026 00:19:16 -0800 (PST) Received: from [10.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-4851faf089csm20814995e9.12.2026.03.05.00.19.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 00:19:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 001bf376-186c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772698756; x=1773303556; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=RT5LRfOTjxi11ExpjXBqs4bzGkA0Zt33gMWSQGL1UJE=; b=Ap5k6W8xVDDj2jEkcjk9pgfnq1BJ0QZxcfx6r7awHSbBFkQqB97OHZJwKdTdvr82Tp S4NJlrSG0Axya114mUiZ1BKSotKvrxxw9gp+aKNP8jcUsPVqFE08H9dd1Z5VfKlL6vbh +FOwJemMkKp03+/lRSxTZP6bQfhvreeEOYv3yXmWsI1aKsisnTrQgYqBFM79Lgeasn4e 5PmwTUsgcjNMmiU0HG1C12shPoZsRkqRtfaaD2TSmPEYb9TguF/9fs2yl9zA7QAEzHIn SUPeXbM08mrLclJ8MppEQ38C983CXE6tj2hlH2YqskWVmVICZw/DK/vCeu7zmHFIy8tz JQXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772698756; x=1773303556; h=content-transfer-encoding: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; bh=RT5LRfOTjxi11ExpjXBqs4bzGkA0Zt33gMWSQGL1UJE=; b=kHo0JRegUDpHgQG+coYfTQzQGjNGzsNEiyswA32mD79ifeuGJcelIcJTVuUX8DX0cP BMITnrzHYJPp0VPC8QeNbpXukDOJCcYhD1hoTx3BbjKsxgOcHuhf+yMIInWB/IU2a9yM 9r6jbARoBDPD7bt0Y95KcUmH5KtKHgwnxD/oAYGA07RmUwvn9ZVZ1pQFLkBIwOA+sdTg Pzh1RBchEdY+Wj+5adMoE5yuLOzDPuYMOzwZBkDgOltwY3Q50WPtNoQkox45xuru3Y/E nEomBxJsFqigpqdUc5Tp1SY3fnQtRZqVDZXbLivExWM6xiM/+GPrni5xsxehgCnUxBse 1rtg== X-Gm-Message-State: AOJu0YzZLxfDhDUw45Pq0tgDOgwpMSCcPNDwvERKo4aE4hhDScKlh6Rr XWlY8tih8vnpZa4tyPsviV5FOM855Hb0zIIXmL1w+RrftkXJqWSIRAs0tcPWxhI1Pg== X-Gm-Gg: ATEYQzwNsxivuLKNfd5yrdmuU1Sdc2k7AW1tPAKJmTZIH83R6lB5PZeQCIJVkcu3Pl7 jjg9pnKVpjWWdaxmyGh5A8HDWbB1P7CoKTcn2yeaDzxQUQ17MOfcJl49M/G+zDQ8MRcaLKMAwHu O6tJP492xchwlhxH5JsdRyqWcvLGopUNteYTsfUpqFwxNJrg4K3ArzIIJ8c01BdTfXt8u/THHRB R55WnqTINissQ5AP2WuLZkjW30Yp5rcxoCDIyQpOMWaLe4ir8MjQVFUdHAlXqUDPbQC7PmgaT5A vbkhQS3sNbknSc8baWW2IrUh+acutaAm8e+RHiDipcBiM21diLfyx6pQlzuX54mvss8xwNWKmBv wWC09E4A2uHfVNFuoks0o8v31mZsgMizJ2st+xO2rzkwZAh0J8CPzINSBBDdCCO6JnazcEc8pyV nnHslC+QSkL0xbOqVlEPRMk8m5EM385Wp18lDIRWmbHIvDLzU8/8C3+eL5w8w1XFAzWPzlTVXP/ OLMDou4VPfK3fZxpcGAGvA2BA== X-Received: by 2002:a05:600c:6098:b0:471:1717:411 with SMTP id 5b1f17b1804b1-48519888e49mr80752505e9.24.1772698755702; Thu, 05 Mar 2026 00:19:15 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 09:19:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] vpci/msix: check for BARs enabled in vpci_make_msix_hole To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand Cc: xen-devel@lists.xenproject.org References: <20260226025740.71673-1-stewart.hildebrand@amd.com> <1e62a5ad-f865-4477-a899-0182dec38901@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 17:54, Roger Pau Monné wrote: > On Wed, Mar 04, 2026 at 10:39:56AM -0500, Stewart Hildebrand wrote: >> On 3/4/26 10:23, Roger Pau Monné wrote: >>> On Wed, Feb 25, 2026 at 09:57:38PM -0500, Stewart Hildebrand wrote: >>>> A hotplugged PCI device may be added uninitialized. In particular, >>>> memory decoding might be disabled and the BARs might be zeroed. In this >>>> case, the BARs will not be mapped in p2m. However, vpci_make_msix_hole() >>>> unconditionally attempts to punch holes in p2m, leading to init_msix() >>>> failing: >>>> >>>> (XEN) d0v0 0000:01:00.0: existing mapping (mfn: 1c1880 type: 0) at 0 clobbers MSIX MMIO area >>>> (XEN) d0 0000:01:00.0: init legacy cap 17 fail rc=-17, mask it >>>> >>>> vpci_make_msix_hole() should only attempt to punch holes if the BARs >>>> containing the MSI-X/PBA tables are mapped in p2m. Introduce a helper >>>> for checking if a BAR is enabled, and add a check for the situation >>>> inside vpci_make_msix_hole(). >>>> >>>> As a result of the newly introduced checks in vpci_make_msix_hole(), >>>> move the call to vpci_make_msix_hole() within modify_decoding() to after >>>> setting ->enabled. >>>> >>>> Fixes: ee2eb6849d50 ("vpci: Refactor REGISTER_VPCI_INIT") >>>> Signed-off-by: Stewart Hildebrand >>> >>> Reviewed-by: Roger Pau Monné >>> >>> Thanks. >> >> Thanks! >> >> I would like to point out that this now needs a rebase: >> The helper vmsix_table_bar_valid() should be moved to the new private.h. >> I'd be happy to send v4, assuming I can retain your R-b. > > Sure, please keep the RB. I was actually going to see about doing the rebasing when doing my next sweep (pretty soon, i.e. after finishing going through email). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:21:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:21:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246285.1545487 (Exim 4.92) (envelope-from ) id 1vy3xr-0006Hs-Vv; Thu, 05 Mar 2026 08:21:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246285.1545487; Thu, 05 Mar 2026 08: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 ) id 1vy3xr-0006Hl-TC; Thu, 05 Mar 2026 08:21:47 +0000 Received: by outflank-mailman (input) for mailman id 1246285; Thu, 05 Mar 2026 08:21:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy3xr-0006Hf-4v for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:21:47 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 572b95bc-186c-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 09:21:43 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN6PR03MB7670.namprd03.prod.outlook.com (2603:10b6:208:4f6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 08:21:40 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 08:21:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 572b95bc-186c-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gYNdTzTZL5EQrjiYcRRCAtPQTW+zuaD+0lQFIAZ2HpP/dtXK17WFm8P7Yh0owLnjCU2t9fMhnhFjru7UkMiNTMZAKQNgofDAhpnsmWlTu4zE5Fvo4vhO+OqWcJmDY7B5U+byFgFxHiCN0HNLmknm9KxIF+qv658cMWpoEFIuhvSizFrOB1wwp6qrMfFBka4ypyXIjaFoCHP0lmItQLvIp5YCXiUbEAfzwHpbzuFT6Q/hvG6sHZG2/6Nd8rCTWupL7BqG3QZ2/TPkb3X6wPqERyzuXcfhEaMz4con40MrURFf2Xhl2DH3T+tBVxYMaTqmz8u/OY6sZNn7sjhWn+PDuQ== 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=pbagBmizmxbYiOjp43L/459VWcp+y6LwL4g6BQXNYmU=; b=mOv5tPfrOav3wR696Z7G8RoiThqNSZk3MPwsW2PKyWN7N1S5SlTdw94Nwx4I07FJHA5WgzJQm5GLUAlueHpKBZ5Uoc7rqanpe+8NpHfzks7S8nxqQZK99aosY8JNaxISBQMj4W4NI3HGc+AgS6o3LwA6KZgcc+UAKt5O13Tlpls6fOvjxp/dSYzTIt2MFIf1MYRDEY7d6ye29GUa+tl4q/TC7ulqaw+Q33Mda4d8jGQAHzbyJcvFGjkS8SdMBdOI+P7FYzcKWIt0wAT/z33eWlyb8S3/AkTuOKMEblfTgHRcc2xsEGT+F7PGeiKz4iCtenVP9PQlQayMsJ/geFsHSA== 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=pbagBmizmxbYiOjp43L/459VWcp+y6LwL4g6BQXNYmU=; b=Q2/nn4ewJ3f6a9N/e9NrVj7ejlf7mh89wEh3DQgkQo6zNiaim3XuVNY2DRFMomjOWpaE67Kv9nWMrxg9sH9CbZ5E/knWDBVMivHxGyp8v7Gv/8o2dpYDxAEPTwEIUEd5qpcCnHh4BBD2yKO+Yfu1kVtSrDVzHktJ9WG+iuNh9kk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 09:21:30 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Bernhard Kaindl Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini Subject: Re: [PATCH v4 01/10] xen/page_alloc: Extract code for consuming claims into inline function Message-ID: References: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7dd887bc26830d6c50e5bc2606391963e65285a1.1772098423.git.bernhard.kaindl@citrix.com> X-ClientProxiedBy: MR1P264CA0156.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:54::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN6PR03MB7670:EE_ X-MS-Office365-Filtering-Correlation-Id: 83a9535c-df93-4dde-0575-08de7a90366c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024; X-Microsoft-Antispam-Message-Info: yRt43RM0upJF7Sm1CJOb6/iJa0r15F07nt9XoNw2TB5wnOcy/AjJSlYd523ljW2OClFTBaAP/mlzfpoh9dlV7ElGPRtNHOOpAq10M5qNB6hf9YNKHjeTuX/tpBeL12s0GIwEAEEdxBr4PhJh4pBQHpj3UozckEcHwj69oIqVBDMCzbaPjSuPpe92xPOq54ilF7m90hJYxKJGJCa8s2OxUq00bCNsQuHqi1QcKwn6q8dYg1isRQ3LQvkg51YjSP/pAVnGH3fwbQVvXeqP0isXfyxrRIlo2QXZncEcli80dFqxTFza14eHC2ewPLSCWsGXaCGz+ipCrTDaiznndSAJKGhTy4J27a1fHLWa6FphsR11ClUlxkLEC4XGArJtlLthV1JkcKMpl8GB4kQ0pqP6ftNRmZ9LiqnNyFwAw6/jAtLhjx/xY1FusoOOn7OxXSAz0WB+V2MHjlQUv57S27lNf/+EZjl/0sUaj0ab0OY6LD6bWg5s7FUGnbi0IPdTIQlhfHZ74nlnMyHV3kd0E8MN0ng/2qqWfmWLiIsYdqbLNs+ZDQLgkyfi8tIho1iuWtLjls0BW5Ss9IaAKa6zQl1nNqOPKDPmhx083x/cexhBPvv3NMVVDlv0gqmEDkLwL46DQA2QVE0b8wvVR8yViwleZTrW3Cv02HNeUNqXcu06oroU005aTuJ9WUuU4XeD2wDLuiiK9/fVmTSMBdSRDGVjtOxOjj3d6x84A1+J3Eeibnw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VjBuZkFPTk90U0MyNVhIamw4dWxNeVlMalFmSjlHMnJic21OOEorS2tiMERU?= =?utf-8?B?S2NYN1BTbXpHeUVMMHRHVTZTdzB3TWh5d3hqRTVGU1lIMTR0T0lXaStoa2hB?= =?utf-8?B?T1FvRkNmK1Yybi9EOVBDN3hzV2labGZ1MzJtRkxWZzF3RDhNUVdUMkd4dGxE?= =?utf-8?B?OWtGY08wTmFhZWRLQkkvL3lEWkdJaGdqRUhMS05rdGhYTDY5ZWlFK3d4dEhZ?= =?utf-8?B?b2o4OTZZV2lKVEhLTlVzYXBEY2plT2VYN2ZhYkFTaStqRWdPQzlyYy9vQ2ti?= =?utf-8?B?cTkvb21Jd20zd0kvSVZjTGRVQ3Y3a0Z1NlNCOEhFbnZFcjVJUFR5cFIrcTlO?= =?utf-8?B?SWNUdy9hQjhPcmhneGttcmpRTjdOMUxFOU11blVRaWVnQ1RRQXNrRFV4eVBy?= =?utf-8?B?K0ZJSk5uMGxsT3NweTdyTVhMOVdkV3J5aEh2RVJNTlR4VzVVOEtkMkVDeEow?= =?utf-8?B?cnB1aUNjODFRemh4WXJmWlVPeUJzUEltK1ora2kyN0F1dGg5MFlPa2tpTytn?= =?utf-8?B?ai9SWUlsNnlOaWhWVWgyREVmZGdmSXd0UlJIdld3ZjY0R000ZVJBNXE3UUd5?= =?utf-8?B?SVNxU2hzUUkzQTR3SUtINXl0VzBweE1GbEF3dHg1MGZkZitCZlRmSUM5V3hF?= =?utf-8?B?MmpCODhWemVmY2tYNFNEd1dSMVJLZjJvMWJPVFdUa0RkUWNKL3ZVOFpsRFhE?= =?utf-8?B?ZG8wMytkZ0E0elplZ0E1SkJ2NjByc2w0WFNiTWQ0bHFueTFCZXRsSUU0MUxz?= =?utf-8?B?T1NmMmNSVGphanpoSjZrODE5SkJpR25HUmFqY1A0d2hCZ0RqclQ1cWJ0UG1i?= =?utf-8?B?K0o1TnFPWjFqT1h3L1owQ1IyTEF1LzRueGVEQ015elNLSnFONjZGb2ROSnZz?= =?utf-8?B?bFdhMUJMc3FIY3Q4OUR5OGpYUVRPMFNVYWtDKzVaYUFXSWZuUjRZV0theHla?= =?utf-8?B?dktPaC9zR0xmUTlJYTg1VHFMVHV3UjNHeFNid2R3SERNc21mMndBa0Z1Qlpq?= =?utf-8?B?V2FVK1RhQmlWZWZMNmVQbTdZR2NJdmM4WHJHcnlDbzFhWlFpMnVlMGZubi92?= =?utf-8?B?MVdRMm9LdzE4TlVXa3lsbVJ3VkpQRkhuOFlHV0NrOWdxTFRaaGo2SmtVNTVY?= =?utf-8?B?cm1ueHdpaWJDbGZHQ1dxNzhFUUhubDc1d2pFeUFmOC9zYklLZ0VhbmZGZVlQ?= =?utf-8?B?Uno0TzJzOWVaS2JWeFQ2dCtlNUtxUzNaZDFRS2FMYnQ2LytiWEcvWGhZUWNB?= =?utf-8?B?akFUUVZMcEhKbmZ3ZEsxd1dwUmpMTk9SVG1zRWFjc1FXeG5PZlZ1cmpIS0kx?= =?utf-8?B?SzlTVG8zc3dGZmQvMTA3SkNqK0VwS3llRmExSkxsZFRLSHlyRGNPbndMVkxR?= =?utf-8?B?Szg0VXprRXl1K0RzTzlqUmMybng5TjVpMWFCSktRbnBGTjJaa3B6d2lINUZC?= =?utf-8?B?a2pZWlZwVXN1MEVpOTF5QzIwOW5jSkdiOXZ0VVZmM0t5ZlNzZGZwZmhCK002?= =?utf-8?B?bHRpWTRKNU9EcjVQMEZyVzEwUkZOSnU3YTIxeTdUV0lGaCtRWndnYThqNHVu?= =?utf-8?B?L3MveGQ0VHEzelpZWHdJRWYwNFNQNVVaTnJLdlN0Uk81Y1IzdnpQRC9jalpN?= =?utf-8?B?NnVBaklyVTRoelRGdVVyVnRKSVlrTklmTTZ5UGZ1RGtMTWNCK0dpYXpmM2R2?= =?utf-8?B?L3Q2UHFGSU9ZYXdMbmllOWx0QkZQejFrWU9XMVk0L2dYT0RQS1BNelQ1SXRJ?= =?utf-8?B?bnFzbHpXanBpaVRhbkI4RWNTVko2M2pLdG55Uk9tVXIzQmE5d0hBMTcrdE5j?= =?utf-8?B?SWViNEhZSGwyZnNPTy81V0VpZ0JsTHZ6TjV1bUhnSzhxSlYwemhqMDRCQmZx?= =?utf-8?B?am54ZXBjeWpoMW9ZNjNDVzRxeGZoclVzanZrczZKOGxIOWdJSHhFWFgxUFRK?= =?utf-8?B?MlB2WDVyR3JMV0ZyYUdPUm1nWklHSE1NVEIwRkNQTkd0VGF2eW1rY3ZnUWxW?= =?utf-8?B?UVlSVzcxRXB1TnNsbmY1RU04RDkzRS9rajVlNzcybW9Obm1DcGVtc3dRYk0z?= =?utf-8?B?RmtySzk3dmR1WUl4WHVvb1JwZHN5am81U1dFdzhrOS9YcURsUWRnb3JUL2lq?= =?utf-8?B?cXhxVnpYZDVYL1lUeXNGUHJGWkxUU2huNDJKTWFsSk1pRkxuUktWVFdFRjRL?= =?utf-8?B?aThqY1JIYkYyOGhLS0svME1ldW84MTkvci9DUklXb1h4WnNXNDM5eTlrRWk4?= =?utf-8?B?UGtCK3FZaU13QjY2ZmN0OUx5UmpMVW5HY1lLc0dJWWduckNnSUU4dHFxdUZh?= =?utf-8?B?ZFJUZS9qZW5PbkNJWkV3MXkvV3U3MDJRazRoQ3hjc0NZSlhsMS83Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83a9535c-df93-4dde-0575-08de7a90366c X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 08:21:34.3633 (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: Kfp0dZsx5ta1uK/kYVc7/Z5RshLat8CWTnqq/Z1/XyqWOg8z0j61R/S+scUrilO/Ci5KLNqDejDrsgQeyUcL+A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR03MB7670 On Thu, Feb 26, 2026 at 02:29:15PM +0000, Bernhard Kaindl wrote: > Refactor the claims consumption code in preparation for node-claims. > Lays the groundwork for adding the consumption of NUMA claims to it. > > Signed-off-by: Bernhard Kaindl > --- > xen/common/page_alloc.c | 56 +++++++++++++++++++++++------------------ > 1 file changed, 31 insertions(+), 25 deletions(-) > > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c > index 588b5b99cbc7..6f7f30c64605 100644 > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -518,6 +518,34 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) > return d->tot_pages; > } > > +/* Release outstanding claims on the domain, host and later also node */ > +static inline > +void release_outstanding_claims(struct domain *d, unsigned long release) > +{ > + ASSERT(spin_is_locked(&heap_lock)); > + BUG_ON(outstanding_claims < release); > + outstanding_claims -= release; > + d->outstanding_pages -= release; > +} > + > +/* > + * Consume outstanding claimed pages when allocating pages for a domain. > + * NB. The alloc could (in principle) fail in assign_pages() afterwards. In that > + * case, the consumption is not reversed, but as claims are used only during > + * domain build and d is destroyed if the build fails, this has no significance. > + */ > +static inline > +void consume_outstanding_claims(struct domain *d, unsigned long allocation) > +{ > + if ( !d || !d->outstanding_pages ) > + return; > + ASSERT(spin_is_locked(&heap_lock)); > + > + /* Of course, the domain can only release up its outstanding claims */ > + allocation = min(allocation, d->outstanding_pages + 0UL); > + release_outstanding_claims(d, allocation); > +} > + > int domain_set_outstanding_pages(struct domain *d, unsigned long pages) > { > int ret = -ENOMEM; > @@ -535,8 +563,7 @@ int domain_set_outstanding_pages(struct domain *d, unsigned long pages) > /* pages==0 means "unset" the claim. */ > if ( pages == 0 ) > { > - outstanding_claims -= d->outstanding_pages; > - d->outstanding_pages = 0; > + release_outstanding_claims(d, d->outstanding_pages); > ret = 0; > goto out; > } > @@ -1048,29 +1075,8 @@ static struct page_info *alloc_heap_pages( > total_avail_pages -= request; > ASSERT(total_avail_pages >= 0); > > - if ( d && d->outstanding_pages && !(memflags & MEMF_no_refcount) ) > - { > - /* > - * Adjust claims in the same locked region where total_avail_pages is > - * adjusted, not doing so would lead to a window where the amount of > - * free memory (avail - claimed) would be incorrect. As Jan mentioned, you really need to keep this part of the comment. Claims had been broken since its introduction because the above was not respected, and that resulted in the accounting for free pages being transiently incorrect while an allocation was taking place. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:40:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:40:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246295.1545499 (Exim 4.92) (envelope-from ) id 1vy4G6-0000tq-Ff; Thu, 05 Mar 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 1246295.1545499; Thu, 05 Mar 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 ) id 1vy4G6-0000tj-B6; Thu, 05 Mar 2026 08:40:38 +0000 Received: by outflank-mailman (input) for mailman id 1246295; Thu, 05 Mar 2026 08:40:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4G5-0000td-0G for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:40:37 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fa5390f3-186e-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 09:40:35 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-439b9b1900bso2989290f8f.1 for ; Thu, 05 Mar 2026 00:40:35 -0800 (PST) Received: from [10.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-439abdf5430sm38025527f8f.5.2026.03.05.00.40.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 00:40:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fa5390f3-186e-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772700034; x=1773304834; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TKw83thhZwmgNZhCPSgiFZE6zAnl4nn7a0lA8g2gzBs=; b=DNDbI+In282ONKhXXVRLncQmRpVOAjREaCYbeYtf6dXJ2w2aXNE/99FvVF/5vkDnWJ ngA0sm4AMehGS3nFT4K7EAcqxGDaxKPuilgfKU9erIXH7vMA7k3e6mW8edSe2bu86Crd J/0VBBNveM0IGE7fXS4MHKxQn+NXdADs9aEXw5MydVtFHZxNnbOTtjKoDEE1d48rfPzD RRrW/VnM2H4VKvQkoPqkDsOwnRb7NCMv5loOlg6y6HHwYyf10tlQ9gOAIDvguB8j/ZkJ 7Dm7VXzbs7PJdHm7g10khSQN/w9oaopoBomE2z1UsCKizv36vj4NnvwCVK4F5ik8Ktzz +YUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772700034; x=1773304834; h=content-transfer-encoding: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; bh=TKw83thhZwmgNZhCPSgiFZE6zAnl4nn7a0lA8g2gzBs=; b=tJes4Wcy3uZRzz5lfyqGPcxLZKgu06Fh79PiHL74U7172bOdIPzTJB3USj0hN/JzKx IYhXa/NWyLNxE9qcOX6vUAN+qJtMMbHWO5FZ643RzlyoXSDIfxwLhiGbC6nSJ/+KHE/D Oa47OgKu0Goq8OTV+mz5nW8qdUwNDX6cR/wpjT0luCuKf8uGPlfR4yM+5tt/SIS6WaWo Dc7WbmnzC2gd6R0nX9ZOfFMA7PWYitPvaZeVxbQs4grQFIFXm6uAU5d03wNFwrgD6jVa Bslm63BrM+819PJlvqmSgrC5T/eWqj8q8y3sX7OC895ciicOJ9/TTC+0pqKSaDQFM4S2 mdfA== X-Gm-Message-State: AOJu0YyhAxoza5TLEWqVW80f6jBKvQnE2Ej+XQXakOnWgGbFCEb5ATnN 4AJbMylTTkLSkH6z2F7XmeEiDGsz1udv6204peAgC9nWGvBelyFlPNGObveAYJsQDBZFR8ucTdS D3rk= X-Gm-Gg: ATEYQzyBuMlNSvBy2DLhyqFR73MLiYbTi1W7k7+WJwOk1voFY6fFZR6unFDlJHhDOgl C+LPy1wMlbVprkq8ERTdiBYsbTbZbgP6/OOuXhavvvOrxjShudTFzEy4w08GmwpDrCk0LApplJH ZC0MyfsvwRxh/H5vv+kI1P7e+vt4fepcJO6hFw+iLq3i+0uaOCOUvYpbVpfBZmltZaZ33nCWfiz MJyDH8Tq1R8yx03Fz7MrxUtxfqT9bXT/6e8AKkOkW9ldbYymqn0Ybyg4mwQBSuPiesl7VRycVvA FYdLsOThTKBTRlBAPqKmrXJr9oWgIQTN2X5jxdy3Ym4Md4oLY8+Fln/HRNDBLo9yN4afyupXAZg 1i7+5VYPcURlvLeB4/c5GFcDynXnUy75Q8Zzp9Hi/E4DwK1DGDf94Crt1s/a8pSicWYFV+sNCH1 sFlMrl4+1MUyanqJLCmoyhOImH/c53mL7Z8n/QL2gEDS77/si6CDtZqHo87/kmLgyjsTqwg26M/ kGhbIeeNohVRNg= X-Received: by 2002:a05:6000:144f:b0:439:afd8:621c with SMTP id ffacd0b85a97d-439c801fb47mr8541014f8f.55.1772700034404; Thu, 05 Mar 2026 00:40:34 -0800 (PST) Message-ID: <5a16e95b-25a5-477d-8445-4843d2fba576@suse.com> Date: Thu, 5 Mar 2026 09:40:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <7d7b75b7-80c4-4c23-8678-b33f4c90132c@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 17:53, Roger Pau Monné wrote: > On Wed, Mar 04, 2026 at 04:39:00PM +0100, Jan Beulich wrote: >> On 04.03.2026 16:06, Roger Pau Monné wrote: >>> On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: >>>> @@ -349,22 +352,23 @@ int vpci_init_capabilities(struct pci_de >>>> return 0; >>>> } >>>> >>>> -void vpci_cleanup_capabilities(struct pci_dev *pdev) >>>> +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) >>>> { >>> >>> You could short-circuit the function here, ie: >>> >>> if ( ext_only && !is_hardware_domain(pdev->domain) ) >>> return; >>> >>> But I'm not sure that would simplify the code of the function much? >>> Likewise for vpci_init_capabilities(). >> >> Such a short-circuit would need replacing / dropping once DomU support is >> added. I was hoping the chosen arrangement would make for a little less >> churn at that time. I'll listen to your advice, though, just that the >> question gives the impression you're not quite sure either. > > Yeah, I wasn't fully sure. IT would be nice if we could add those > short circuits now, and then once domU support is in place we just > remove teh shortcuts and it works for domU also. But I fear more > changes will be needed anyway, at which point the short-circuit is > not that attractive to use. As per your other request (calling ->cleanup() even for DomU-s) the use of is_hardware_domain() would go away anyway, and the function would be ready for use for DomU-s as well. >>>> + >>>> + vpci_cleanup_capabilities(pdev, true); >>>> + >>>> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, >>>> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) >>>> + ASSERT_UNREACHABLE(); >>> >>> Ideally this would better be done the other way around. We first >>> remove the handlers, and the cleanup the capabilities. Just to ensure >>> no stray handler could end up having cached references to data that's >>> been freed by vpci_cleanup_capabilities(). >> >> And maybe not just that: For the hwdom case cleanup_rebar() adds new handlers, >> which we'd wrongly purge again right away. (Because we pass "false" for "hide", >> this isn't an active issue right now.) >> >>> And we should take the write_lock(&pdev->domain->pci_lock). >> >> Now this is a request that I'm struggling with some. I can see that callers >> of vpci_{init,cleanup}_capabilities() assert that the lock is being held, yet >> it's not quite clear to me why that's needed. Shouldn't vPCI internals all >> synchronize on the vPCI lock of the domain? > > Right, the callers of the handlers already hold the locks, and the > removal of the handlers should also hold the locks. The point of > taking the d->pci_lock is to avoid the device from being removed > while there are vPCI accesses against it being done. The vPCI lock is > fine for vPCI internals, but functions that deal with addition or > removal of devices need the d->pci_lock to avoid races with possibly > freeing pdev->vpci while in use. > > I think you are right, and for the usage here (that doesn't add or > remove pdev->vpci itself), the internal vPCI lock should be enough. Well, we could take two positions: Either we say that as we're being called from a context where the PCI device is being operated on anyway, we can assume it can't go away. Then no further locking would be needed here. Or we want to explicitly guard against that, in which case (seeing that nothing is added / removed), d->pci_lock may want read-locking? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 08:51:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 08:51:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246308.1545509 (Exim 4.92) (envelope-from ) id 1vy4Q9-0002fQ-Eu; Thu, 05 Mar 2026 08:51:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246308.1545509; Thu, 05 Mar 2026 08: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 ) id 1vy4Q9-0002fJ-Aq; Thu, 05 Mar 2026 08:51:01 +0000 Received: by outflank-mailman (input) for mailman id 1246308; Thu, 05 Mar 2026 08:51:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4Q8-0002fD-6V for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 08:51:00 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6acf36a0-1870-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 09:50:54 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB6534.namprd03.prod.outlook.com (2603:10b6:a03:38e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 08:50:49 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 08:50:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6acf36a0-1870-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SW3Cyp4l/y4VkGlcMoe2dAw9hCSGS7bcExQLMn5oXrM7X5lJlx5ND9hicEOYb6gPCYS3VdWcIBfQ5Tl1NCbUcSeJwf27zoAnbXrCPT7LwfJZl0tDn7S8XVC09OZhuipJhMhu6izKE8SOpyl0/FB36PJIbK5kJ6KX+KelB/iNBSO2pVNXdF9RxBgpgFthIG6IhMxa5rPpw/kWX2+Zfo9QOI+/xHgxOqhyesk53NUxOtsWL/lBNdkLFmOZwAVSuF2QFqVe2vvOvaypWDugYhWF/JagAtV0CKFXiWi2DR8XUfwLskjdsSTno0/ZcJvbc8OMigq654J7cdxBjGxyn740ZQ== 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=yhKML0+vEIxkGGxamiIJllZsv3zny0fmnhubU2tvKPc=; b=jdEO+0fDSZ6Nyr7tnUgu8sMJrvCrcDUWehl804FCCvboNfFgz1OQPEp54TEDWUyc1Q7v+usJM7bzAyAARs1g5pAvh+imMuiFsCCQjX3LgQi1ykSWu4FIPTyQLJ/Oezg9l9zV3vnLo1CDqJVW8x+EhaOHpAVrLCdXk5+vw1hJhUBanKm5AznPqDC8eq/T4f08R/sHTpggUlC6rEfgpU1eCD4SFATOgnxstJ889y1gM4KtQC2t2t9pgUfbFljeOYkZ/cbQb0OImACOVOFTbOL4eNjrXZcN5L9hmK8G2EBJTDbsGkJVWr4epFgwMKQ+mLFu6KHFpG51c8ZcEyRhHSuKFg== 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=yhKML0+vEIxkGGxamiIJllZsv3zny0fmnhubU2tvKPc=; b=wSDn4kfhFtB8vJDYWBiRxvPXF6Vokkv6PtOhxr0mSUl5sxGTfRULB3HXLpOpVIjfhbbyirIsXljRoo99igD5sf7pnQ+JTfB2kIP4dJBP/R6iwPB/3Xfh1hYuh6HwCq0RPH8pElyjkw9P4L4PzjWyyiv9+H/rbZmHGoJUWRyH/vg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 09:50:45 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Message-ID: References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> X-ClientProxiedBy: MR1P264CA0074.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3f::29) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB6534:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d9e8341-a50c-4df9-b5b2-08de7a944cb4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: VscHNN2wjnQezb34t5LCoUnAaRdTtmEsQwu2YrzH0fVGL9kDtyg7x8oU+l2mOtUYP9SvuHr/5VDEI+0xbsB88OdXFWfWjEH0ETyFFOsL5rdFOuzVCUiKDF6aJb4HG1KPX+8dPp0zAdgPKqoJ2CzLv9DOr8UwRMVaxEc7DN6PAZLRGtQdOGY+EiP3X1CXBzVfO9bYWTLld6KpsiPsD4m8dkHCPrcF4bt0EjGNrfrz7ziXByypJafRH+w2PYHrTZrP98VcnA6iLoHMcNBkfjpSpD2owJ5NFUqMZrGaoFVxEelK1NDEip/exkmTjyX9Sz0WAdKj5vPhYrJpCa76w9gJYbXH7YCCvJKNuZ4HjO3IReewnv2cwj/fMhhYMAa8dqtRVIhFpl4J/9h4FnW/GY24SKfuOb9V14HXlEpzGdG24HIQU4iO3vrAyF3EWN2hDh1fFxccW8H0ugDILqZMDIddAXtLLmShIoROpuBs2a7OjC0GuQuLKj3QZDzF15Lpj5xY5DpgP/qa7lvyuigWQHvRfR7DIeG1n+MKqup8WMd84phEO2y0tYnhHOdyuLvV7X+gE0OsmZe92uiUeL1JS1BCEPv2E3MOhma33Di5e6XTlGcTf5Lf/7x0HPCAcwS8GASn43LbmzGqgYVdYxdK9rZg0nGdft32EJUcpCNC9GglShvmafa80xbe580vzBh87peazNHnmsI/xf+uKRKFy4koz08uWms2CO244dDO81AtbkE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TXlJY2tCNzl5ejRkbSttT3h3R2ZkOVg0U1dGcUNvREdoczBSUzV5dkV0ekhR?= =?utf-8?B?cTRoL25BSGZWTWc0dWx0MnFSc2FHU1Z1RHNaMHdNUUpRTHpSRDlxQ3lSSGpJ?= =?utf-8?B?MytHcGQzQmdMd01XU1dHbllOdWlHTGRLaS9JZkN5V29LY1RLUjdmMElKems0?= =?utf-8?B?RmMrTE84NWdMTkk4bWdsbzR5MmgxM3pzZUI3QzBvMlpCbTBWc1RVOHJkc21v?= =?utf-8?B?M0xFbEV3eVZHMnEyUjhZSmU4cHNwcVkrYlJwUUhwT1JHYm4wMEQ1SHdaSmpG?= =?utf-8?B?R2piSU5lQzBDL3NSQWpNOEF0cExGUVBqcUpCcTByYk0xRldmaHc0dlp3bnd4?= =?utf-8?B?NmxoRGJQNnZRdmRXT01TL1NUQUQ1WkIwN3VERFp6cUxDUkdlMmpRNXk0M21F?= =?utf-8?B?cTM1Vm5sa21rYzlsMlpOMWQ1eEdMRFJBK3puQVFTVW9GSGRGT3hHbkxybDJC?= =?utf-8?B?Y2xrd3QrMW1qZlJXNHZBRGU3WXpUT3EwVU5EbURZc2dlTXhiQ1FQNC8xajNU?= =?utf-8?B?YXFHcFRPQ0U2Y1plL0Uwb0pNc0lodXZRQmxkaUwwVlZ6RDU3NFo1ZkQ5eTNB?= =?utf-8?B?RVpGcS9XUTkxa1VBZEZJMHIrL3hPWi9ETkErQVQxa3dzWW40NjVDZTVPQnNv?= =?utf-8?B?ZTdlOWdEbC9QenVoVXhHekxwVG1VNFI4SjZoQ1NmVHAyMVdnNVd0cGp0Qnpo?= =?utf-8?B?QnZabUdGVlEwUVNEMDUwSWVEWGZsTVVLSjhFVnZFM3dUQW9lUFFTdTBmaEZh?= =?utf-8?B?RC95Y1JPMG81R2RQOVBveGdsdHZuWDYxSDRVVGZWTEdnTTd3RVNrQWNXZVVx?= =?utf-8?B?dXlzL2tpci96bDVaOXNJenZKcTR4OWFLcmxxVDJseUNEditTMWJNTXl5UkM3?= =?utf-8?B?OGROWnhoM2pkQUNNck5GRXliMWFoV2gyaVlHdjEyeS9RTzhSb3Q3R0FTeEU0?= =?utf-8?B?dGpiTzRLb2M4cEZDRTdCR1Uvc1l4c0ZEeExKNUY1YWFNYkZ2ZHlnTS9sa0dO?= =?utf-8?B?WVN2akVjVW56cHhKV1hjQlhkZW5ESENyV0dDV3BUbm5DOFFiMEhmc2k0Rk5i?= =?utf-8?B?V1hzV3Y2RDMzcjZIbkt5QVI4dmxFNnpYWS9VUDVyWFVvbU9sWFZkbVZFZC9K?= =?utf-8?B?SWZBeVFzUjh4a09VVGhMamVsYmhyR3hNQktUa1F3QVZtRWRMZXRETnYvMnFQ?= =?utf-8?B?OGNFRFpPWHFxZU40TkJhVWRidHdVVksxVHRZckE4NnFTdFgwK2d5VVQ4WnV3?= =?utf-8?B?WXppSU5PcGtWNFdKTVFvbWdWejJ1UVJCSlIwb1UwN2RnYkFSZXo4Wk05b1lV?= =?utf-8?B?UGhXT2t2VDMzTy8yWTNsUkN0ZmlRa08xYVdKUHh6VGt4dXdvNktpdU9KWTc3?= =?utf-8?B?WHh4bUowY3htQjNWaDBLQXBNZjdKQXd1L2VyZW11SVNMaUtlMW1MZFc4UUpC?= =?utf-8?B?NFVVNXNHMnJDUjRrVit3K1B3VjQ1aUVMU3hXQkZUMTA2VC9pNE9UZkQ2aC9y?= =?utf-8?B?d3A5TU5tVjVXeVA5Zkk4UjVacDZwY1RLVmJ1TW9xTldpSmNuQnNlS3hPcCtN?= =?utf-8?B?Y01jN0U0NUNLclFhQUNYR3laUlpMMkYzeVpzZEhyUU5CU1NQTlRqNFN2TjFH?= =?utf-8?B?R2F6YjMveW5CTUVnNjBscHJva29QV3JhZldjSkZNMHFTTUhSeVdTSmVhRC9R?= =?utf-8?B?Zm9rOVJ3SE1KbWVGb3Z4OG4zRGhBYlBPSzY4SVdWMGUySno4UE5YVXB6bjdm?= =?utf-8?B?MTBqSWpRUVRiTlZnMmI5N1pBYVpTbUZVSlNXS1ZlZzg4SnpPcDFiREFCYUNq?= =?utf-8?B?cGUrVFh0L2taSm9HRnVobU5PSWVPbnVGNzNZR0JIYjczdmNPK2dvVGZoNkRI?= =?utf-8?B?MzFGQzRTTmxXOWpUWXVjSS94NW10VWhja1pxU2hLZ2RFTjNvbnN4ZEZoS1ow?= =?utf-8?B?U1ZsUi8yZE9RblRwNnpNd1ZYZTg4YzZEbTlkY1ZmSUNwMTFBZHNnZnljTFY2?= =?utf-8?B?bjY5YnVVclFPWGlKQUpJbTQ4YlpVbGdleUVQdzZtRmVXQnR3TnFabjFDMDhR?= =?utf-8?B?dG5RNHNCdnJiOFFOWW5aVEJ6b2NINlVwczZvMkMvbXZzeU96UWk2Y3dQNTc0?= =?utf-8?B?WGxxMVowOEVXZkdmSldIZWdGQmpLK0dUbENNN0pZYzFGMWFuTHA4RmZIYXVH?= =?utf-8?B?S0xMNmh1Zk1Bbzd6MFV2MnV0N1NoUGl0Q0FxTm9rUGJaRVE1K09wbVJEL1R6?= =?utf-8?B?N3JXZktGNXhlUVJzc2l5b3cvdnFyREtYUEVSZWMxeEg1VzZtMEVUa2J4MXR2?= =?utf-8?B?WFVuVm5rMDd4alhZNzN5dy84TGpYWUdrYkgvRkVXaTRhQjh3SGV0dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d9e8341-a50c-4df9-b5b2-08de7a944cb4 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 08:50:49.5911 (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: jljAOfFXE9eqxjSwqe8EhKosadhqOYhAGYK3lUjuGJXWgXqRJelEWHNltJ8Y9vwR0xHkgJMz2ZXVJ6YWvJXeUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6534 On Thu, Mar 05, 2026 at 09:17:23AM +0100, Jan Beulich wrote: > On 04.03.2026 17:36, Roger Pau Monné wrote: > > On Wed, Mar 04, 2026 at 03:37:25PM +0100, Jan Beulich wrote: > >> The treatment of ACPI_PDC_CPPC_NATIVE_INTR should follow that of other P- > >> state related bits. Add the bit to ACPI_PDC_P_MASK and apply "mask" in > >> arch_acpi_set_pdc_bits() when setting that bit. Move this next to the > >> other P-state related logic. > >> > >> Further apply ACPI_PDC_P_MASK also when the amd-cppc driver is in use. > >> > >> Also leave a comment regarding the clearing of bits and add a couple of > >> blank lines. > >> > >> Signed-off-by: Jan Beulich > >> --- > >> Including XEN_PROCESSOR_PM_CPPC may need accompanying with some change to > >> arch_acpi_set_pdc_bits(), but it's entirely unclear to me what to do > >> there. I'm unaware of an AMD counterpart of Intel's "Intel® Processor > >> Vendor-Specific ACPI". Plus even when the powernow driver is in use, we > >> never set any bits, as EIST is an Intel-only feature. > > > > We possibly never need to set any bits there for AMD, as those _PDC > > Processor bits are Intel specific? > > Indeed, that's a possibility. > > >> --- a/xen/drivers/cpufreq/cpufreq.c > >> +++ b/xen/drivers/cpufreq/cpufreq.c > >> @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ > >> { > >> uint32_t mask = 0; > >> > >> + /* > >> + * Accumulate all the bits under Xen's control, to mask them off, for > >> + * arch_acpi_set_pdc_bits() to then set those we want set. > >> + */ > >> if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) > >> mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; > >> - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) > >> + > >> + if ( xen_processor_pmbits & > >> + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) > > > > Currently the CPPC driver is AMD only, and hence when using it we > > don't care about filtering the _PDC bits, because the ones Xen knows > > about are Intel-only? > > > > As you say, we likely need some clarification about whether there's > > _PDC bits AMD care about? > > > > Linux seems to unconditionally set bits in _PDC, so some of those > > might actually be parsed by AMD. > > Or it setting whatever it wants is meaningless on AMD systems. Where I > have extracted ACPI tables readily to hand, there's no _PDC there. Oh, interesting, so there's no method to start with. Is there an _OSC method however for processor objects? _PDC is deprecated, and maybe AMD systems only expose the equivalent non-deprecated _OSC? > > I think we might want to split the setting of XEN_PROCESSOR_PM_CPPC > > here from the addition of ACPI_PDC_CPPC_NATIVE_INTR into > > ACPI_PDC_P_MASK. The latter we can possibly untie from the questions > > we have about AMD usage of _PDC. > > Hmm, yes, I can certainly split the patch. I'm looking at it a little > differently, though: Us leaving any P-state related bits in place when > cpufreq handling is done in Xen has been a mistake anyway. Yes, TBH I even wondered whether we might just wipe whatever the OS sets in the _PDC bits and completely fill it from Xen (unless for the weird/broken case where dom0 is driving cpufreq?). This is kind of what Xen already does now. However see below. > What's > unclear is solely whether because of us driving things some bits need > setting (likely none if AMD systems indeed don't surface _PDC in the > first place). Since we have the parsing of the ACPI related data done from dom0 it's not only Xen that needs to support the feature, but dom0 also needs to know how to parse it. Or we just assume the driver in dom0 must strictly know how to parse data from the features enabled by Xen. Maybe Xen supported bits should be & with the dom0 ones? So dom0 would set what it can parse, and Xen would AND that with what the cpufreq drivers support? However that would be an ABI change. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 09:00:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 09:00:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246318.1545517 (Exim 4.92) (envelope-from ) id 1vy4ZA-0004Ma-6Z; Thu, 05 Mar 2026 09:00:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246318.1545517; Thu, 05 Mar 2026 09:00:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4ZA-0004MT-3z; Thu, 05 Mar 2026 09:00:20 +0000 Received: by outflank-mailman (input) for mailman id 1246318; Thu, 05 Mar 2026 09:00:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4Z9-0004MN-7G for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 09:00:19 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bab1791e-1871-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 10:00:16 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-480706554beso83982945e9.1 for ; Thu, 05 Mar 2026 01:00:16 -0800 (PST) Received: from [10.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-4851fb3668csm46722955e9.13.2026.03.05.01.00.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 01:00:15 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bab1791e-1871-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772701216; x=1773306016; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=HMlMivLVNc4EFqEg/5TpfRMuBK0JJc1ca//jhnipcfE=; b=FxDcdjXb0OQVMInLpsJ8lDE+0EXa/sglTdaI0Lncl/SMqvf2MzDBcmRktJBR7ZLUMB ZI8wGJyLUM1vEt+qpfWtX2vok+WmIGRZZXQJSvj0TPwKdCSwKFU2bwOuKKLSON1pXrAD STs9hDw34rQUd1u6793zgeNFG7cxeLrTbVcZRDK8F3XPyRb3/XFCo3RqnWb0YxJIlsFP 6ZPVSitPI2zU8c+NP68IUHhm0rVv60gNdJtHSZthu4uAuLL4QhLwakHRNDP8MEAj6wZ9 SMJJ4gcYL0flir+xb1sEDVS8WmIZq4d9vi2Xxkp8hCJ035yyHKvpDAv68ovqTaDJtK92 HMXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772701216; x=1773306016; h=content-transfer-encoding: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; bh=HMlMivLVNc4EFqEg/5TpfRMuBK0JJc1ca//jhnipcfE=; b=eqIud5pUNBfwe7hU3PdthNG0JfDPhrwro+dYOOxtTvI7KelnFOI2BfaLAaxu9SIpcV unzxCMGwr6NVHfJS3Q+jqvSkoyBteYrpEb2gPPkj4QrdV+UHzAQ9HFPOAndbKRKRa5tB 1qxoP4PCl6ZwkApoOqT2UE5YbWpS3DAufSwRu2sKm+KVpzxcqde6wUhVwZeFqdK/zK+H ZTJ/XWrM0are/uLWZ32kIij73ijgMGhpQBWRjhXBYtJW1rRL6g0KSQ+jAIOCEmr4qqc8 1FbD6ZGuTXedaZAhGHkZ9dbXJQZoNU8Ka0CoAqbhAPWQnlczkCMvyEjs0LZ/iTivGe/2 vOCQ== X-Gm-Message-State: AOJu0Yz2bStY0WzXYhgvdA3FNjEvNciHCbaah0Y5HHAEkdxDeS5OqAB2 mlwcY+pShtHAe2+x+z9ysXdzHUw0CeVGoz+9ZqkUbkChBEFAtp4v1TV7h5z3V0Td6Iz4iJzZa8c E8Hs= X-Gm-Gg: ATEYQzwHgzb3Rzj7PZtLbF7OSCuOU/mt1js6w4MquL9QfRqa2u97Fm7WSZqE+w80KEP Ylb8mhBHck6JQ/0gI0Qf8j0FyRlUUIdV6fPyDA1iw1G+Tp7wEnwzspvOowQP4ipbNxmJReFVFnz lePbxAV445py6GjgOVh1hliUZg2OTAiB4Ye6RyO3z7MkUGdZ0rElNpeVAzCtush2ORCohhwTwW8 7ZB8r9EcO4NuVK9pPZWALCzQF2j3zpNyVzf/e6S4jmKfPSeVs0tAGaM5Hg6PMvl1DEZyUVspzgK qqf4cRaDBLP22MOv4OQXJ1jfkNJq+Pugxze+BJZC3hREhTcCgnCT0h9F8NaQANTXbh4NWl8HobP 1pAR7bOtiGcd/oDw8p6K2c08S580lOYxNUsbIvvD8Yrx785cL1lgoOfytWjc/ttouJNpQg6ZJKf GyI1mWLcPJ0lQ2OSDGhQkZJpRwoKP4/AZGQt5Ogl/XRby78EiCUwKficOiQqWBAewxhAWJ+X66 X-Received: by 2002:a05:600c:3b9e:b0:477:5cc6:7e44 with SMTP id 5b1f17b1804b1-4851984f5bemr91299105e9.11.1772701215671; Thu, 05 Mar 2026 01:00:15 -0800 (PST) Message-ID: <2c3fdfb6-5788-4177-a264-56719e1ae804@suse.com> Date: Thu, 5 Mar 2026 10:00:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 16:06, Roger Pau Monné wrote: > On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: >> When Dom0 informs us about MMCFG usability, this may change whether >> extended capabilities are available (accessible) for devices. Zap what >> might be on record, and re-initialize things. >> >> No synchronization is added for the case where devices may already be in >> use. That'll need sorting when (a) DomU support was added and (b) DomU-s >> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). >> >> vpci_cleanup_capabilities() also shouldn't have used >> pci_find_ext_capability(), as already when the function was introduced >> extended config space may not have been (properly) accessible anymore, >> no matter whether it was during init. Extended capability cleanup hooks >> need to cope with being called when the respective capability doesn't >> exist (and hence the corresponding ->init() hook was never called). >> >> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") >> Signed-off-by: Jan Beulich >> --- >> vpci_reinit_ext_capabilities()'es return value is checked only to log an >> error; it doesn't feel quite right to fail the hypercall because of this. >> Roger brought up the idea of de-assigning the device in such a case, but >> if a driver doesn't use extended capabilities the device would likely >> continue to work fine, for Dom0 this probably wouldn't be quite right >> anyway, and it's also unclear whether calling deassign_device() could be >> done from this context. Something like what pci_check_disable_device() >> does may be an option, if we really think we need to "break" the device. > > We may want to add a note there, stating that we have considered all > possible options, and hiding the capability and hoping the owner > domain would continue to work as expected seems the less bad of all of > them? While adding that note it occurred to me that in order to keep the device as functioning as possible, in the re-init case vpci_init_capabilities() might better not bail upon encountering a failure, but accumulate the error while continuing its loop in a best-effort manner. Thoughts? (One of the two return-s is already guarded by !is_hardware_domain(), so that could be left alone for the immediate purpose.) Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 09:20:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 09:20:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246327.1545528 (Exim 4.92) (envelope-from ) id 1vy4s0-0006FY-N6; Thu, 05 Mar 2026 09:19:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246327.1545528; Thu, 05 Mar 2026 09: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 ) id 1vy4s0-0006FR-KD; Thu, 05 Mar 2026 09:19:48 +0000 Received: by outflank-mailman (input) for mailman id 1246327; Thu, 05 Mar 2026 09:19:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4rz-0006FL-At for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 09:19:47 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 723c745d-1874-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 10:19:44 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB4951.namprd03.prod.outlook.com (2603:10b6:a03:1ef::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 09:19:41 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 09:19:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 723c745d-1874-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kDRXGtPnAvTe0dmgmvvL+M34WbJzW9eAZaLRs0ZkfvX55W5b1N3gHxE6B/x6ZDdb2SOFoeqqsjyu/AuUvKYG3xlq2Kkdw0Jho/nfEcfOUPw8t2s3HxexCdewDfx79UHG73Cb89xXTM3Yo7IUeYBU8qQZ1fh5vrnYsl3QtvjwB8Ew3LNLGZS8hc1O2AznhDchlER6t69y0bkgYxURL8X0gQg1npJpdQXFB3El4eSrUM9omXQRNq8hbjN5148X4+tk2kOpxCYPlb8I83B89X/ULiMUlevrlPPVBfaAZOanWzCjkoTGIBKo1b9EktHvImupKlwBsAvQLvP3BBYidFWdFA== 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=Hf9J4F468TSJFlAphny8iLQP1YTtiuyQKklzuuP/sIs=; b=LliZ/Ay6qcqi9jbn3dBR1hJ/i7X62VIFFEEIoKNeRS0t5i0lYfvhKQzOpJDI0FWSKaFuRDhsIgM0/tW9+l4mgHvoKzFdmV8lzFedtZycY7+UHXFOUbRG4xS+cEeMjee9KipMdcsVygzXwdcUICtS1a4FNFomcioxzBDOu2iQ1kv28RvRSBKYZAi+j6Vo9SjMkB9QnFpokGFpNG37raVWsMLnCCgwqD20es2L1rQM4EwnstpaFU//MV092KbrvhEFa42GeFcoJC0XxvqNm3W4FG5vNJtpyws3le0CH0Kla9Dv1YHXaQCIiv13veRyLHS0xBBhnZiXWBOAibooydrgNg== 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=Hf9J4F468TSJFlAphny8iLQP1YTtiuyQKklzuuP/sIs=; b=azhk2Ll3CFnf7eDyUHeNSeMXdLRSd8J1UKNJgg3qQzzF04dpb07kNJOkq20sxQK6NgGZfr7FYrPwtWgkiaNXnr8k7QhgVaMpJNfKxQJq1/O24WLJmphqXelcDrrxpqvqJ8W0u3jcNQ1sNFVxomJA7t/3dh4Osr4PiVG8zDk2R9c= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 10:19:38 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <7d7b75b7-80c4-4c23-8678-b33f4c90132c@suse.com> <5a16e95b-25a5-477d-8445-4843d2fba576@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5a16e95b-25a5-477d-8445-4843d2fba576@suse.com> X-ClientProxiedBy: BLAPR03CA0095.namprd03.prod.outlook.com (2603:10b6:208:32a::10) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB4951:EE_ X-MS-Office365-Filtering-Correlation-Id: 8d159ba5-78c4-4d40-c3c7-08de7a9854d0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: 7j2iVmoR2l9BQeeVhG3/OYhHfyBz8KSIOuCRNk4LnX0lOBqXJKX3F12T+wsYkbuNcyMthdPGPQT6KMc6Dil5tdA6ct4J1oWTy/5AOAVsG1Oq2x8zNBbSYTUqAFxb6px0Y7w7BuLiuKT31PrX4vtF2jUYJL0dRxdw1D+LRyWR/UuU2xG993Ekq3vuH/eyQr/46RC/YpYHyaOUyMzDJZKlNH1rKD51nm7eJ4mL4aZ0hveCzoDP9uhY39SBRNDpz/mzAhn9fBlLp5xkDSk7oK3m967POXv/u+7zVzRU6Ez5bP1ZFPU1a9QNpK8/vDPuEAEUR8fsnVuk6RnAqxzbQz1jVdWEQp7hzX8sg4vG457I7ikcotOp6LM1Ul+toyFKZm9TMealW5K+TvFgusJK04pHBmM+mpBmgXnOZyG1cKLpteoiym3/h0p7l91FOqvpxCRp72Oz9k8kKtxlHJPsCET5t8wLVHaW7cLOwy9EuBFXWGSynBQQteuMKug/FTKvxCwaxaoqVuaK54BBhB5qPCH76TWNx5Et08dNOvSp3NuIAQ9IAUtki6eqrLQmeXmVeOzFg0SMwpHjIt6q2bSYyLEmDrsrzuTAa6em+WbTh5ZBNhZIRonGpoafV1PbDDrOZ6PABYzUxPrM8evR76YrIlq9rUtzir7wU2TcHoSaD4ciBQKOxq+kmVwFp12Kwvx3kTDZBq8Fbmq+0VWpBKcZTXvQffRvE7vDD5mlSlvOa08QDE8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Lyt2ZWNzWVk0YzlsR2VMK2VIajZQVnFGQm1MZk14NlFCbTdROXptVTI3L01M?= =?utf-8?B?VXFDWFJNSDg3MW1wMXdCTFkrRXZaeTYxc3lTcnlxd0crdS9jUjNqK1dUNzln?= =?utf-8?B?TWlnTFRoZmFnbHBGTkJyeDAvTTUyVUQ0WmlDaE5XcVQ5bWpBZVRDUnFQdVJ3?= =?utf-8?B?MVFrNzRhUEtOcFhVVjNwZHlZbDB1MG5aS3JGeTBHWElEdUVSQ09aVmJqUWV5?= =?utf-8?B?UzJzTFoxcHJGenVldWtmd2hpbjdJVWhHUXBwaXVsQVozS05LUkZkeGJYT1ox?= =?utf-8?B?NDRNNUVTdGxrVW1Fakx2SFp5Z3BhLzJtTmZkb0RVcmhwNGVTN25sU2ZvLy9y?= =?utf-8?B?MjlSRjJEaHBqd2s1ZlRrcXJpakl1ZjJSallTOUpiTXBWUFh4YWwzS3pHTGQ0?= =?utf-8?B?azBRQ2ZGeWR4Y1R6QWFUdzliWm5Oa083YzR4TFNLaWlOVExXdzg5TzZocUhs?= =?utf-8?B?NjY4c3dYREIxRnVxRVl6cUQ2cUNvMTdKRlAwTFNWNmVQUEV4Y1lLdHFuSEwz?= =?utf-8?B?TURaRFdXTjJ6Wi9kVDFLMGpFMXFwaEVLR0gyVjIyREVub080enFQMlJkQUl4?= =?utf-8?B?ZzBrWjR6Q1VoWkZINUhxdzZkMitZbUVqMGViOStoblU2N3ZGMytBd0lnNnM3?= =?utf-8?B?bGlSamFMN2t6b3c3bjZKQ3BFTEhTcm9UM2NaMmowdzB3N0dvMG9NOHNjMFBn?= =?utf-8?B?R0U2SkQ3NE8zUG9lZHg3bmZGQUJrUE4yZ29YR2V1aFZJZDNSdnVjQkxidjJu?= =?utf-8?B?Vi9jaitQRXFnV0NSdmNtaEpRem1qbldrVEhseVZqTkJWV2pCL1VtNUhXZVF6?= =?utf-8?B?QTFRdHdsTHFpOWtIeUdkM2w3aFhkZTBueEgweStFazc3Mnl1OTJxY3pkYVJ1?= =?utf-8?B?MnhxYWZOTmdPQnNkWmt3cmdjcUtLL1N2SS9jT3RzT3RvZEpiTVQ5aDZNYUQx?= =?utf-8?B?dFpMVmdvVERRVndVaHZwdTFpcExybU5qNFF2VGZCbUhKSTFlaGpEbEp5L1J6?= =?utf-8?B?aU1WMWNXKzhoaTNVZ25aMmszQzhQOGNEa1VYRG9mUmhsRFNiSzRaUGYrV1hT?= =?utf-8?B?Q2lmNjVLR0RaQlBxYzFGdFh4Mk5vaTBMaG9LSHFiM3gvWnY1SWRaanRDaG5Q?= =?utf-8?B?d1dDZm9DR05wY2FJSGFybXRjdjFYeDZWTkhTWkh2SDBkb0NKZHdNN253MlRP?= =?utf-8?B?V2c1OENhQTV4ZW4vbThoQllXMGVvdVpDZS83cEswdlNUZE1EZW90YVlaUTEr?= =?utf-8?B?RVhsWnl5TG9OOFk0QUh5Nkp0Mkl0VEZRMFVjelhmRE53VGU4UmN1L2l6encw?= =?utf-8?B?YUZueFp3VFhWRmp3M1VyU3pTVzhja295d3F5cEhZZk5TWVdia0JzcVV4enlJ?= =?utf-8?B?NUx0aFV0MGNzTS80UnlKSlhXMW90N0ZQZXY3YW1McXcrdmxoaW9PbzloaU1Z?= =?utf-8?B?OTFLTFVtKzNETFAxek9UWmhYTnl6SS9JcVR6NGhVZEJ0OElNTzBwdkE2dUUw?= =?utf-8?B?VnNQTE1ZTEwwYjdGcDdRREhqRlVpaEtyK256MlE1RnMrNGphTENLMTFmOExL?= =?utf-8?B?RVZMcm9IT2FzUElxUG9BZkxMa21lcXQycUFyMXBhR0QxRWZER05SOWhVb2RP?= =?utf-8?B?TFBGTHZiUi9Sa1FraVVmMlh4aG1kOVNqTU1weGNacW5SSWpsVUhmTHpscm1r?= =?utf-8?B?OUxWVkx5cDExN3V4cHZvZjBlbzdwS3B1SWRuV1NCektCdFFXNUkzS2x5Q29E?= =?utf-8?B?TkNCVXllZjdrWE9FblpzMkx6RC9SK3JTS1J3ajdLSzgyMGp1ZUN3SWJkc3RK?= =?utf-8?B?YWhUcmMzNmFKMFg5SFV0UXBNdUw1bGFlajdzcjZ3Y1hLMm9FUGp3Y3hFazNR?= =?utf-8?B?VTZNaFJHRExNVkFqK25uWktJMzZSbmpnMzgyZlpOZVZSeExvN0loVUpUb1N1?= =?utf-8?B?YVJpTUczWnRBUDZTbDhsWUowT0E4SHkwVUJqbW9DSmRsV1lycko2QWkxWk8y?= =?utf-8?B?NzNvclFTdk9wOEk4eHJaZlR0S0dvU0tBY3JWYk1LdndtbkdTS1pZSzd5cDRz?= =?utf-8?B?a094Q1dyc2dUVmdFUzUzNXJlUUs0TC8vVjJxVzZackpOeC9FRXNVUmtQVm9F?= =?utf-8?B?cUI5eU45NzJWWnJIK1VGSityOW5qYWo3blUvOG9PVFAyUDVUUXFGV0xDU1Bp?= =?utf-8?B?Y0MxMkl1bEc4cmxlRGNwY3R2czZuczNWcGtPOWRkMG1aVm5YZ3E0ZzBTSVc3?= =?utf-8?B?eUYwZjE2UGNicWFvRnU1M2ZJZnZ3TVBHR2xUdWFvOFpWbm5hTjJtYzBYeGps?= =?utf-8?B?cmVNNDNNSHBvOWVqZXN5TnZnR0JmdFpmQXlzVWVxOVR5QkFhME55UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d159ba5-78c4-4d40-c3c7-08de7a9854d0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 09:19:41.1963 (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: AiRViKe+eMvfaaQo3mYuXHAafQXpxgTwyMZgHzkrLf4Gcy9L4X8W6Y9IRBHW+jvaWS21ehWKZ+nyw+8nrtK5rQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB4951 On Thu, Mar 05, 2026 at 09:40:32AM +0100, Jan Beulich wrote: > On 04.03.2026 17:53, Roger Pau Monné wrote: > > On Wed, Mar 04, 2026 at 04:39:00PM +0100, Jan Beulich wrote: > >> On 04.03.2026 16:06, Roger Pau Monné wrote: > >>> On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: > >>>> @@ -349,22 +352,23 @@ int vpci_init_capabilities(struct pci_de > >>>> return 0; > >>>> } > >>>> > >>>> -void vpci_cleanup_capabilities(struct pci_dev *pdev) > >>>> +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) > >>>> { > >>> > >>> You could short-circuit the function here, ie: > >>> > >>> if ( ext_only && !is_hardware_domain(pdev->domain) ) > >>> return; > >>> > >>> But I'm not sure that would simplify the code of the function much? > >>> Likewise for vpci_init_capabilities(). > >> > >> Such a short-circuit would need replacing / dropping once DomU support is > >> added. I was hoping the chosen arrangement would make for a little less > >> churn at that time. I'll listen to your advice, though, just that the > >> question gives the impression you're not quite sure either. > > > > Yeah, I wasn't fully sure. IT would be nice if we could add those > > short circuits now, and then once domU support is in place we just > > remove teh shortcuts and it works for domU also. But I fear more > > changes will be needed anyway, at which point the short-circuit is > > not that attractive to use. > > As per your other request (calling ->cleanup() even for DomU-s) the use of > is_hardware_domain() would go away anyway, and the function would be ready > for use for DomU-s as well. OK, so that one is (possibly) sorted then. > >>>> + > >>>> + vpci_cleanup_capabilities(pdev, true); > >>>> + > >>>> + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, > >>>> + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) > >>>> + ASSERT_UNREACHABLE(); > >>> > >>> Ideally this would better be done the other way around. We first > >>> remove the handlers, and the cleanup the capabilities. Just to ensure > >>> no stray handler could end up having cached references to data that's > >>> been freed by vpci_cleanup_capabilities(). > >> > >> And maybe not just that: For the hwdom case cleanup_rebar() adds new handlers, > >> which we'd wrongly purge again right away. (Because we pass "false" for "hide", > >> this isn't an active issue right now.) > >> > >>> And we should take the write_lock(&pdev->domain->pci_lock). > >> > >> Now this is a request that I'm struggling with some. I can see that callers > >> of vpci_{init,cleanup}_capabilities() assert that the lock is being held, yet > >> it's not quite clear to me why that's needed. Shouldn't vPCI internals all > >> synchronize on the vPCI lock of the domain? > > > > Right, the callers of the handlers already hold the locks, and the > > removal of the handlers should also hold the locks. The point of > > taking the d->pci_lock is to avoid the device from being removed > > while there are vPCI accesses against it being done. The vPCI lock is > > fine for vPCI internals, but functions that deal with addition or > > removal of devices need the d->pci_lock to avoid races with possibly > > freeing pdev->vpci while in use. > > > > I think you are right, and for the usage here (that doesn't add or > > remove pdev->vpci itself), the internal vPCI lock should be enough. > > Well, we could take two positions: Either we say that as we're being called > from a context where the PCI device is being operated on anyway, we can > assume it can't go away. Then no further locking would be needed here. Or > we want to explicitly guard against that, in which case (seeing that > nothing is added / removed), d->pci_lock may want read-locking? In this context the caller is already holding the pcidevs lock, so there's no risk of the device being de-assigned. My reasoning for taking the d->pci_lock in write mode was to prevent any concurrent access to vPCI while the changes to the emulated config space is taken place, but you are right that the vPCI lock if used properly should prevent races. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 09:20:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 09:20:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246329.1545538 (Exim 4.92) (envelope-from ) id 1vy4sK-0007VH-1L; Thu, 05 Mar 2026 09:20:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246329.1545538; Thu, 05 Mar 2026 09:20:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4sJ-0007VA-Up; Thu, 05 Mar 2026 09:20:07 +0000 Received: by outflank-mailman (input) for mailman id 1246329; Thu, 05 Mar 2026 09:20:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4sI-00071S-Es for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 09:20:06 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7f3796cb-1874-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 10:20:05 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48375f10628so52144415e9.1 for ; Thu, 05 Mar 2026 01:20:05 -0800 (PST) Received: from [10.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-4851a82c876sm31883335e9.0.2026.03.05.01.20.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 01:20:04 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7f3796cb-1874-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772702405; x=1773307205; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=bRZdLSl3plZmUkZHFDVey1I7mkbthVlt1fgWI8LrAxU=; b=TAumixN/9mLN0GXyVcIx+8yPcjFvM0/6okb91YGR6LjPkOb5HrFTswxlS7rzDf7HzD kuT/raRN+3+L162qDTPMuJtKDkALKGly8y/k6J+y3Q5Edk5dNV3EkPOSo5iQS3IBXsbm FodcAY8wtkJzCFNsjH5eHFlt1xkMo5mdnNDT8YtioH3IMkjhpITVT8TJw8qy8DCfOUIz 5BuiXCpKhe8QWYTjhPNK1+xqP/teFONrBUBzU+1Xd9tr2j/zdos5YTvEqB361Jo4hQvx bZU0+sVlW0zbv3HGlmbWO0TrH2HRHD9bHPsZYlWTf3WDUl8NtXf3ngY7h6ByYYXcxfFi D3Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772702405; x=1773307205; h=content-transfer-encoding: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; bh=bRZdLSl3plZmUkZHFDVey1I7mkbthVlt1fgWI8LrAxU=; b=ZOf3Elw6unU+USMdpxpZEzNvrpMxtgMNakXlduTNfrU3nr1ENBehP8v0hGN0bLSOet 58E7MwBlEqwQFWaeMCDHr7VzKH/LXL/FdXDuwW2q8orzd4NpFoF80i1NMhUOKhINqtCb EbxV0oPsLLbzlf/YvhDzivi4w0R6JKLMqym1BHN8XnpXZF1/Pv8Vb7Bi1AHMd5waDQUW anvYk2UJuXRxIDqx2RVCRdio2nj+MfWeLEBpLknjs6qW5k1zDAWwaYNv6kQHY6NgFtuk FvYfQCxgQxKn1sm8Bucf0RcbPtxXqvgKswVyteN7tHClLtLPQ6P/BDB+xhFm8kdRQfGg ahOQ== X-Gm-Message-State: AOJu0YxlCf6if/EDdaH5L8z20FTGvXtkgGNGvU3OT7Kwd4GNWnjWA/RL 0hOiosa+MHNXUwXxQIoK59C2zje7lR0+eKe164X/EI85ck1k8M3WtIffFx7ke4bTag== X-Gm-Gg: ATEYQzxs8+j7e95AFY5ziVaLycB7wcA6gbB7IekBCzPfaht97TVNE+JyD1CeBdQk+o2 LOxalzs18oRE3wW8GgGB4qFg6YvUaBkjk/vpVYVZzwng2vsMyAjXKLM5phvzxpGgvv1gaEUt8j/ tuEUuZIkoyQGbMInUSZ50aayl+NUgkkME1UkZB0RbnX/3zd1WaFmbbR4/KB5gxx7mhabX9rstGb VE2M+yBTXqAREjC+6j6VVYDEyHhjImYW5kKBXDzaFAYMOUqRoF0uRdLIDUu3YF2pjOntNGesal9 X64Qhe97lHkFP3J1oKX67ioom0inV79ec36v426gmcuIe/J1lQWbbgVyNTBarp4cB66dTRBW7H3 xU8JrfYyxqwedzUGfwJQHIYWSHelLHs9JRPDGcRTF61/lg201M/fcKn58YSt9GFN2a1pv8ZVhPL 0p8UHZvMmDKV8quaeTYpdCoC4k8moCCIuXDLddtjIcH6bd4GhoFAXW7sf+kL1F6bn3T3Zwoz631 Yzh0Bg/4RVlsYk= X-Received: by 2002:a05:600c:470d:b0:483:c490:8ed with SMTP id 5b1f17b1804b1-485198a37c8mr82083575e9.32.1772702404884; Thu, 05 Mar 2026 01:20:04 -0800 (PST) Message-ID: <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> Date: Thu, 5 Mar 2026 10:20:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2026 09:50, Roger Pau Monné wrote: > On Thu, Mar 05, 2026 at 09:17:23AM +0100, Jan Beulich wrote: >> On 04.03.2026 17:36, Roger Pau Monné wrote: >>> On Wed, Mar 04, 2026 at 03:37:25PM +0100, Jan Beulich wrote: >>>> --- a/xen/drivers/cpufreq/cpufreq.c >>>> +++ b/xen/drivers/cpufreq/cpufreq.c >>>> @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ >>>> { >>>> uint32_t mask = 0; >>>> >>>> + /* >>>> + * Accumulate all the bits under Xen's control, to mask them off, for >>>> + * arch_acpi_set_pdc_bits() to then set those we want set. >>>> + */ >>>> if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) >>>> mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; >>>> - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) >>>> + >>>> + if ( xen_processor_pmbits & >>>> + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) >>> >>> Currently the CPPC driver is AMD only, and hence when using it we >>> don't care about filtering the _PDC bits, because the ones Xen knows >>> about are Intel-only? >>> >>> As you say, we likely need some clarification about whether there's >>> _PDC bits AMD care about? >>> >>> Linux seems to unconditionally set bits in _PDC, so some of those >>> might actually be parsed by AMD. >> >> Or it setting whatever it wants is meaningless on AMD systems. Where I >> have extracted ACPI tables readily to hand, there's no _PDC there. > > Oh, interesting, so there's no method to start with. Is there an _OSC > method however for processor objects? _PDC is deprecated, and maybe > AMD systems only expose the equivalent non-deprecated _OSC? There is, yes. >>> I think we might want to split the setting of XEN_PROCESSOR_PM_CPPC >>> here from the addition of ACPI_PDC_CPPC_NATIVE_INTR into >>> ACPI_PDC_P_MASK. The latter we can possibly untie from the questions >>> we have about AMD usage of _PDC. >> >> Hmm, yes, I can certainly split the patch. I'm looking at it a little >> differently, though: Us leaving any P-state related bits in place when >> cpufreq handling is done in Xen has been a mistake anyway. > > Yes, TBH I even wondered whether we might just wipe whatever the OS > sets in the _PDC bits and completely fill it from Xen (unless for the > weird/broken case where dom0 is driving cpufreq?). > > This is kind of what Xen already does now. Indeed (except for the T-state ones, as support for that was never added to Xen). > However see below. > >> What's >> unclear is solely whether because of us driving things some bits need >> setting (likely none if AMD systems indeed don't surface _PDC in the >> first place). > > Since we have the parsing of the ACPI related data done from dom0 it's > not only Xen that needs to support the feature, but dom0 also needs to > know how to parse it. Or we just assume the driver in dom0 must > strictly know how to parse data from the features enabled by Xen. > > Maybe Xen supported bits should be & with the dom0 ones? So dom0 > would set what it can parse, and Xen would AND that with what the > cpufreq drivers support? However that would be an ABI change. What cpufreq drivers are you talking about here? When Xen handles P- state transitions, the drivers in Dom0 would preferably not even be loaded. That's what the forward-port did. Upstream they may be loaded, but they then can't actually do anything (and they may exit early). Coordination is necessary only with the ACPI driver(s), and that's what this function is about. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 09:23:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 09:23:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246345.1545549 (Exim 4.92) (envelope-from ) id 1vy4vG-0008H8-G9; Thu, 05 Mar 2026 09:23:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246345.1545549; Thu, 05 Mar 2026 09:23:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4vG-0008H1-Bw; Thu, 05 Mar 2026 09:23:10 +0000 Received: by outflank-mailman (input) for mailman id 1246345; Thu, 05 Mar 2026 09:23:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy4vE-0008Gv-MS for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 09:23:08 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id eab49cdb-1874-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 10:23:06 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BY5PR03MB4951.namprd03.prod.outlook.com (2603:10b6:a03:1ef::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 09:23:02 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 09:23:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eab49cdb-1874-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=B0IzIvXX+DUxAQsZPIuKvjE7r140VHs+vDvxCWuwHOvVGKPPRzCRMLVNkUdRx5qZZt9p975V4rS1Z6D7tCCm1IladvkRyo9uweNTln7trwmu1RRF3U8MDwOOLlYFvhiWHmdPuxL5T/NtM3dQij7+nr7Dt4yd8swFC2vtnuMoilR8JJYgJx7w/lkdUVN1d1+SXi68pbhsgRe5QIJvXsMZ3DcTT69Dz0omDrGW22A8caT3XkKusLCo/r1dtNqWNuHKyLLz8dw1Xtfys2Ho5xiu88hSmuw8rXVWDPYXydyawGRME/n7TYfh1kIiNy/7I1rdLjLOHV+XKfCZytsHOuVc1Q== 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=FnqH61YeoPBXGbVx1OCxJwj77CibYbG86rJfkhJtWt8=; b=MjbsPOGFWCgldrvLP1Z4lbT4AjevvzM8gKxs1rslPnQsnsg9R/JaaZ7RrBDSKvi6VVzWv3k4TqHq7K/ffTFYCdRsJm3UqX3KYlzooZmDIdWcNTIfYYB0xu3fT5VEQ0zy/jhBPSHQNsdg7g+umHb8yukDVEiU9KzkNr+12RWd5eE8EkFiScodklanEtQqvhHYxwqUjZjGNhYaudHd4QsXBDrgdwn+sKMu6rv5lsEAhl5ufSdoyhTIw90i2dBiovYwjH7rEF6TKFTXJMDZjdQh3jy9LNuMuYLLmu8wq4blyAHTa+W5mWWQvhG3kxA9r8E9ft8HaucIw7jnMm5obrM2iQ== 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=FnqH61YeoPBXGbVx1OCxJwj77CibYbG86rJfkhJtWt8=; b=y/wI6g4F+dis1hycsQYBJbDXCyJyIXifbnZGNJ3Qq8mzsLB6d6r0J2670id52opaTQV7ofn7+R/AdND/z9sQLoHzN2uupsGfwOdSx7XlIZw9yahaUbQwhW15V7tN4T02DJkphpxONldThO2CPckSyj+YDolQGleGU3LdSpBBMu4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 10:22:59 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <2c3fdfb6-5788-4177-a264-56719e1ae804@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2c3fdfb6-5788-4177-a264-56719e1ae804@suse.com> X-ClientProxiedBy: MA3P292CA0002.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BY5PR03MB4951:EE_ X-MS-Office365-Filtering-Correlation-Id: 2a6815ef-1c7c-4764-632e-08de7a98cceb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: jsFjfPD3z3aTWb9fu21YqVL8UvPL5bH+EjiZFYyX5F8KMxDeycg/dSIIn+pu/vTwEJW0hOE68ESGQpqCjaGiXqGjzSi6oBxvwK+pWAEHeWI95yUdFD8Sa7GyJXgmQJeWwNGMQFGX1HAF+yCKS+CXSpiSIcweP5yKxc7eiI8I57ePmCQm3r3qEasSZYUWhERykEHj6YdOiO4nfxs6u/5317IE4Gyd+6S74S6KBUs8NmJBKTH8MaaV5+ao4QrJdKUaBEW8FhBcp577dJoN1Wz+GZKj9dUseePpPYjY5hlkK5ojBztLvj3ZVJ6yncDCjC7v/NtiDY1SG7XM184hXF7Mc2FvqNbqxA+naYi86l1mQcA/uxjOGHUJGTh9JiEKVil049Uj6TgqFgnEj7GVjB8BXa08tdCA5C39pKXbVAOyVkt+o77k2zQm/11AaKHgudRNOhuqhIzWhZJevFIBQk+sofYvAKZTFDTgusXDNzobv0gcvb9u046DOvn/TwxtQCatoS1EjySiBRDfGNs/ZUnMhk9XvXYh8NFfgvMEJzreiLuvNOVQG6ZpNIQFPKlmSxKiPIAN+iguhQYv5DeCgeMddpyHJUnUPQn9fGLQUT8oxS1l4OaBBRHI5kbTuf14yLV2qkTjTco/s/WZlehje44t+mUCGBBUg/CSAivaxoQKKJPJIya4MSQSxeMVpITQfOx/TfV3kW65zk0CWShzbSXFNpySo1J5PzoJuctk8FrlK58= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dlZGREJKVHJPOFpzWkpKWDlvMjY4Mjd4bmZHbmd1Q1ZDMlBSaFFwNWJDM3Np?= =?utf-8?B?eTc4Q0NvcDV5RldBZU9uT1V0emFVVWlCdWpaOTZWWkRiN2xxUENER0xQQWtk?= =?utf-8?B?akVKRDJLeEtxREFQaTYyTkx0WmY5V3o3WFZpQVh5ajlWTG9OSVZ0bUt0aENp?= =?utf-8?B?L2Zpd2VuQmRpT0s0TSs0QURkL2E4UWkvZjN4YWxvekpZQlQ3R0xwSXd1eVow?= =?utf-8?B?UnQ2eTQ1OHZXT0h4eFdNQ1c4U29TN1EzcStHSnpzVHc2OEptL2dqWGQrMUZH?= =?utf-8?B?cTFZbkFZK1lyWTlMb0NmNndmSDYvMTVBUDZXZnVnSkR2MW9UWTUvM1BRMmc0?= =?utf-8?B?RHQvMU9MM0F1Y1dkdU1FU0FYaVg0c2Uyd2RjK0tNTkltdnkyQTcxV1Brc2VI?= =?utf-8?B?Nmp5QkQzY0RBc1BwMDY1cnJDZURWRHpMTS9Ya3Y5bHdmNEM2MTR3WUdYV3lk?= =?utf-8?B?TlBLQWRjYUZKeTNKL3hEU1RhQ2hyQzZ5SFdRUUNzVE9BR2xxRGppWk5US2ZJ?= =?utf-8?B?WWdoU0xvdnpldFVjcS82Q0cxUlpXVGxGUEc2L0pqL3BoK1k0VVNKQTdabmJ5?= =?utf-8?B?VmtSUDZrYUhCSjc4Zm1MeFNxckFiSEdvdjg2UWFyWmhYRjIxVjBUTC9OUURO?= =?utf-8?B?dERkbGJhS1B6Y3lGSzR6TzRNY3QvTTlUTVVvdFVuR05xSk1JanRUYWpVN3Jk?= =?utf-8?B?d05kYmdWQ2pSVy9QT1B6bWtzVDMrSENyZFF6RnFFSUFmL0ZabU45VFZtM1JF?= =?utf-8?B?N1pSd2RjWU9uYWRkVldBRlU3MVIyM0pGU1RkTThmelEyK29PbnczbGk4V1VN?= =?utf-8?B?cUE0OVdWRCtweElmMDM4a2dKYUQyeVlBS2RRQlpIOWhrUGFScXJqK1lLUkFj?= =?utf-8?B?QlBnMlEvSFNBd0I2Z0l3bnJ4M0V4SzJzdkxId3M0Ny80WVkvNnNYa3YyQnR4?= =?utf-8?B?dHNmZ3VpNnpQSUxnV1pxZG9YTzJVZlNoTkM1RXRKQm1jc1p1VDB3SVlHQlgz?= =?utf-8?B?UlV5WTJhNGVWU1liM2UraUViV3RYQjNhbFZDTGZMbVl5aWRQdnNXblh6OThN?= =?utf-8?B?QUNHcDc0dExpMzlNck56U3BhM1FGdHZTbDRWc0owZ3I3WW5oYzg2VkZIbzZo?= =?utf-8?B?TGhPM2lOT2dPNEdYemRZQXB3RkRYbmdFa1dPYWRrQ0R5cEswMGcrc28vWlBa?= =?utf-8?B?dlJNVHlmV3BmNDRGTWNXWC9WTEVaMXVBbGpZbkRoUHNraUJ1bW9xUVMrWE5N?= =?utf-8?B?QWtMNVhtSjQrejlUcjFtM2xaVlEyUStIUmtUZHhLdUtJb1NWK0dMOTRPQVd4?= =?utf-8?B?eE5PVnZZNHprRy9HQUV1VVdiTkg5Lzk3N0wvMlNsVlhZU015djl2NjdGWTBJ?= =?utf-8?B?eW1jaUlsdTh3RVZ1QlVHR2tTeW40aHZxUlNpbzZkL1o0UStmYlZxV00reGVs?= =?utf-8?B?Mmt5dWluWEJ0dVV6VGlwdyszM3VienZ5cUNWN09WZUg3eXh6NFVLa1BMTXhK?= =?utf-8?B?SzRzdFBlWDRBUm1xLzlaWUZpQVd1VjF6ZEhaTHZLZ0tFM21zMXlNdC9WMmkr?= =?utf-8?B?aXBCVTMybDd4S2N3bEFSZVFrUCs3NE1SNnZBRTFTYVVZTFdXK3NPb2NIU2Ro?= =?utf-8?B?OUp5SHNWbTdMNTkvS3l2eFpEV2ZHQlY1SWJXOEFMa1UrNXY5ZnlwamdvNERq?= =?utf-8?B?cW83eVRhZjdsczFrVFVQaStiM2Fjb0U0bm41NG01c09aWExiR1RjMUlabUg5?= =?utf-8?B?MndGaTZ4VUd6S01jNTlMSFp4TXE4OWdNRHFpZTBFeWFhYnFYUzQ5bGFPK0ZY?= =?utf-8?B?N3Z0R3lmRXp3RkUrbUsyWXh6enRIUjZ6VGszUndERFRXRDRJcU1TQUF3cVdK?= =?utf-8?B?Q1NUYzRJOXZuZUhpa3VXY2dNb1ZrZ1dTR3BXSURpM240VTVJZXNwYStkbnk5?= =?utf-8?B?RjJuRkRkNVdhQ0hvUnRvaU5CT0FuUFJScXFDUkZ1ZnBzZDdQR29yL21kbEZL?= =?utf-8?B?VGZpZlhnbWhGc1pxQjAvWnNjdTNpak8wTUNqQ0V1cWpnUTRWT21OSi94QjNr?= =?utf-8?B?V1ljVmdtaW96bkp4OEgxOFBOZUdXZnJMSzMrWUNtY2ZmQ0VsRkUvcjlPNE8w?= =?utf-8?B?aHlyaDk0bGF2U1Zha1A3WTFpWXdEYXNrdmNxOEQwMEZzRytIazArNTIvUEl0?= =?utf-8?B?cy9TaTJsV2h5TzVKV0x6RkIzVmxMdmNMNDM1djNnaHNHVnJVK3JkUVVOREhm?= =?utf-8?B?eHFPcldraWxKQkx4dVd3bDdIYTJtOEthaEI5QWhRbjlEMjZzeU0xU2xyZlBr?= =?utf-8?B?L3hKODdIUHU5OUxYcndRVVFEVnB5YTNrQmJjaGp4aXNhZFJRRTVMQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a6815ef-1c7c-4764-632e-08de7a98cceb X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 09:23:02.6615 (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: 23m7ealdRJc4QP//JMG1raNuqnlqAjLTOa1pRDFDsRzj9zJp4IpFy3r+CBfAVPB5R+RLRxKQXerXk0CGdKkeXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR03MB4951 On Thu, Mar 05, 2026 at 10:00:13AM +0100, Jan Beulich wrote: > On 04.03.2026 16:06, Roger Pau Monné wrote: > > On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: > >> When Dom0 informs us about MMCFG usability, this may change whether > >> extended capabilities are available (accessible) for devices. Zap what > >> might be on record, and re-initialize things. > >> > >> No synchronization is added for the case where devices may already be in > >> use. That'll need sorting when (a) DomU support was added and (b) DomU-s > >> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > >> > >> vpci_cleanup_capabilities() also shouldn't have used > >> pci_find_ext_capability(), as already when the function was introduced > >> extended config space may not have been (properly) accessible anymore, > >> no matter whether it was during init. Extended capability cleanup hooks > >> need to cope with being called when the respective capability doesn't > >> exist (and hence the corresponding ->init() hook was never called). > >> > >> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") > >> Signed-off-by: Jan Beulich > >> --- > >> vpci_reinit_ext_capabilities()'es return value is checked only to log an > >> error; it doesn't feel quite right to fail the hypercall because of this. > >> Roger brought up the idea of de-assigning the device in such a case, but > >> if a driver doesn't use extended capabilities the device would likely > >> continue to work fine, for Dom0 this probably wouldn't be quite right > >> anyway, and it's also unclear whether calling deassign_device() could be > >> done from this context. Something like what pci_check_disable_device() > >> does may be an option, if we really think we need to "break" the device. > > > > We may want to add a note there, stating that we have considered all > > possible options, and hiding the capability and hoping the owner > > domain would continue to work as expected seems the less bad of all of > > them? > > While adding that note it occurred to me that in order to keep the device > as functioning as possible, in the re-init case vpci_init_capabilities() > might better not bail upon encountering a failure, but accumulate the > error while continuing its loop in a best-effort manner. Thoughts? (One > of the two return-s is already guarded by !is_hardware_domain(), so that > could be left alone for the immediate purpose.) Right, yes, that would be preferable. We already print a message for the failed to init capabilities, so there's no need to print another one in the caller. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 09:45:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 09:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246370.1545570 (Exim 4.92) (envelope-from ) id 1vy5Gx-0002xo-Bj; Thu, 05 Mar 2026 09:45:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246370.1545570; Thu, 05 Mar 2026 09: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 ) id 1vy5Gx-0002xh-8C; Thu, 05 Mar 2026 09:45:35 +0000 Received: by outflank-mailman (input) for mailman id 1246370; Thu, 05 Mar 2026 09:45:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy5Gv-0002xb-GN for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 09:45:33 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0cce88f2-1878-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 10:45:31 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48371119eacso93340205e9.2 for ; Thu, 05 Mar 2026 01:45:31 -0800 (PST) Received: from [10.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-4851fadeb5bsm43355515e9.5.2026.03.05.01.45.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 01:45:30 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0cce88f2-1878-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772703931; x=1773308731; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=u35ZfvqWtF9yNhv2mrL/KlcTzbQ+4dd3N9VGDV9JC/I=; b=c58tsw59UOIXpJE81mFE1n3muTGEhzd/zHZrsFfJiqTA9j5Zb8awomB01emgCSlMpE adC0Y6bkpEBVRW/HIvU8h1NoGcISXx0hH8MAG7bAahRaVM9zMyEiTGbQz0zCtWEX0mrv ZK0rIlbaYUNnBLh/T0OJhQaPH98Q8CoXW0K7xHiDQG5Xq+lHY/urOePWcW+CG6vFu+9V fSfiEQhCClA2lj2MazbvjRzgpxLgnmkIHMFa/V/RMWvSL2HYzqrE7utXKgHSfEjq/3UX ypNTcZPEmtkke+jJN+NAu97lpsF4mfKdkbNweoE4xAHmMPJQJiY1b5zQmyG5xRBgDtWO cwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772703931; x=1773308731; h=content-transfer-encoding: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; bh=u35ZfvqWtF9yNhv2mrL/KlcTzbQ+4dd3N9VGDV9JC/I=; b=dTycBCiqiICZ1h27o4KVi/8SMHz6HwkK+8C8DC7lTIw9EbicwwAr1Fy0+XzoJ6O2wB +RaIcEMt+l4SDXgQp58FQd8FQnTNqyZNX0KoEyeVJ5aCm1Jmi1cz/L9CwbBLKI1jQwAH AipVio2QmI3djtro4h+405MJaqBfPJF85Kqbwr4buRyvCTh4ROhU9W2fiMQzRCw8pTE8 gxQJVvXlI8MjqSsafP0tE0Bq/HT2rOulC7mTIKkHeQ52OlhoGBG8H38GeUd1QrGaPcen 35MC6J4DJRPZFKZqyAXKVwi7frhf+evJMx2THOkbfIw3EYh0bg34nep/3kygS54fWocQ b9gg== X-Gm-Message-State: AOJu0YyX1XBUa2whv08AiWNpvy765ZhvoDbuwg+F/zI3BmF6Px8YglVv ZCtBm8/xMlRlDgROXHZ9NGPHAQQkV9+Mzcx9tHm/DWCxlGxAIjdDo5cPUt0DA6NnZg== X-Gm-Gg: ATEYQzz2AYzjDKqTwUdoDZ8ffUSAYYJo+uYr6hb5/u6A6cc3XD09IIl50VeYBWSOd3E CxmdRBnEMQdFgGvX4xizayVAKczmAKDbTGAfVlqPnUwxNbEoaZnSAh+yYFKmSH0JMI+xqpMRUmW 4Z4iBQVdfGl0s81Hl6AeDfytVSHUJ5/gXGgKZEwk3rL7nmvSqK4oIcP6SyX7eT7oqpk5htTmS26 z+8IgdAm4zocC5FLxdBrYb4tCPnbz1FqxbKikdih6nlFqEsFvSUWD6C/qsZfM401uC5N9u871W4 PpgbKDZ5E0Rqesl8zfdCl6X8HVb4r/RaerokfYOALRUFkzxjcA4a4/4sA11KF4D8KShO3IHiR71 J6cOwB3z63DGAqIYL7YYMcLlk7Y22LZj+dCpWg6hAV803k4IP+gCcYIVaEDRczOwoKD+5Vb+LYg bBZC/aOHMc+MWP7JaH9WMwjQ0y8dhGk2A5N/Eezhu7y2UcKgyBvcgVM9FlclBcDreCZNPgt9Sjc PftIRMU9M77+aE= X-Received: by 2002:a05:600c:4f4c:b0:477:5c58:3d42 with SMTP id 5b1f17b1804b1-48519849bd4mr93711395e9.10.1772703930948; Thu, 05 Mar 2026 01:45:30 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 10:45:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <2c3fdfb6-5788-4177-a264-56719e1ae804@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2026 10:22, Roger Pau Monné wrote: > On Thu, Mar 05, 2026 at 10:00:13AM +0100, Jan Beulich wrote: >> On 04.03.2026 16:06, Roger Pau Monné wrote: >>> On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: >>>> When Dom0 informs us about MMCFG usability, this may change whether >>>> extended capabilities are available (accessible) for devices. Zap what >>>> might be on record, and re-initialize things. >>>> >>>> No synchronization is added for the case where devices may already be in >>>> use. That'll need sorting when (a) DomU support was added and (b) DomU-s >>>> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). >>>> >>>> vpci_cleanup_capabilities() also shouldn't have used >>>> pci_find_ext_capability(), as already when the function was introduced >>>> extended config space may not have been (properly) accessible anymore, >>>> no matter whether it was during init. Extended capability cleanup hooks >>>> need to cope with being called when the respective capability doesn't >>>> exist (and hence the corresponding ->init() hook was never called). >>>> >>>> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") >>>> Signed-off-by: Jan Beulich >>>> --- >>>> vpci_reinit_ext_capabilities()'es return value is checked only to log an >>>> error; it doesn't feel quite right to fail the hypercall because of this. >>>> Roger brought up the idea of de-assigning the device in such a case, but >>>> if a driver doesn't use extended capabilities the device would likely >>>> continue to work fine, for Dom0 this probably wouldn't be quite right >>>> anyway, and it's also unclear whether calling deassign_device() could be >>>> done from this context. Something like what pci_check_disable_device() >>>> does may be an option, if we really think we need to "break" the device. >>> >>> We may want to add a note there, stating that we have considered all >>> possible options, and hiding the capability and hoping the owner >>> domain would continue to work as expected seems the less bad of all of >>> them? >> >> While adding that note it occurred to me that in order to keep the device >> as functioning as possible, in the re-init case vpci_init_capabilities() >> might better not bail upon encountering a failure, but accumulate the >> error while continuing its loop in a best-effort manner. Thoughts? (One >> of the two return-s is already guarded by !is_hardware_domain(), so that >> could be left alone for the immediate purpose.) > > Right, yes, that would be preferable. We already print a message for > the failed to init capabilities, so there's no need to print another > one in the caller. Hmm, that's another aspect I didn't consider. Yes, the log message in the caller is redundant with the present code structure. If we expect that to remain like that, I can drop logging anything from physdev_check_pci_extcfg(). Which then re-raises the question whether vpci_reinit_ext_capabilities() might better return void. At which point the comment I put in physdev_check_pci_extcfg() (upon your request) would want to move there. But my earlier question went in a different direction, and you didn't comment on that at all. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 10:00:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 10:00:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246392.1545583 (Exim 4.92) (envelope-from ) id 1vy5VP-0005xH-NY; Thu, 05 Mar 2026 10:00:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246392.1545583; Thu, 05 Mar 2026 10: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 ) id 1vy5VP-0005xA-KB; Thu, 05 Mar 2026 10:00:31 +0000 Received: by outflank-mailman (input) for mailman id 1246392; Thu, 05 Mar 2026 10:00:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy5VO-0005x4-9q for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 10:00:30 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 23c27d3a-187a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 11:00:29 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439c5b40f60so1605059f8f.0 for ; Thu, 05 Mar 2026 02:00:29 -0800 (PST) Received: from [10.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-4851fb3666asm28701775e9.14.2026.03.05.02.00.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 02:00:27 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 23c27d3a-187a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772704828; x=1773309628; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=jcpGEgEdNDn1d5L/htnJMQZXZeNQSDK3grLyRzw5sBw=; b=X5VkzwoCZsu0X7YHTHsOaCqZioLZht6XLeX7TSU0TkJdqgR9WTW5pXfuIRcTCFSF2U JihFogfrTIW5nrk56iQOGaY/LswEVW+ivbO4fcFRdS62fT9HcjywFXBrNh8iCVSZxan2 3g+TqR5+AROEO5SbscyYSaVPYDG0XgDmL0KeX1ulS+L2DiTlovFGRwsIILVG46waCxVy 2IDYz78mA0ZQ/nnrZlPrVawSF5kSiPUoqVwumFvC6L76jHkfIeP5BUITpUpUnAIJGG7a 1fegjESRTFBvRxBprYfBz9ODiZxMlphvEr6+p6M+wKA34Fgr2IWSV+14vDuQd2weho0w V5lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772704828; x=1773309628; h=content-transfer-encoding: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; bh=jcpGEgEdNDn1d5L/htnJMQZXZeNQSDK3grLyRzw5sBw=; b=FNt0DtiYo4mOV9RUYa03jgbOXrr4fRZSW5FaVNBshP0VvWKJ1qAF2bYYkrVtrdS3rn Tr1AgmFvVvFk7AG30Avs+4vg8tHuqGKhAjszFwViRl36/vSQskxs+gfDMxmlYUMrBPqd TiuCA5fj4qkkIA5KPaIB3wr2DUCxmPurkzpzK5ISXnFdkGF1VtOT5K9nID5lbKhsXVVw wEUKLCYLpJDEM8+OK/2iCzObv36SQufFpHNCAPuNJK7btVsHtjuMB0JV+u25ULD8TQvB KArtfnkrgEDVUNQRkmK4DJxewtDqxZvqrUJJgIxYhWOXpvsT6WEcubNDQRilLsOs308n IdhA== X-Forwarded-Encrypted: i=1; AJvYcCUZ178/ne2Olyh+LyMNlBjogGqeJDqMZGdPNz1gTquO6FCbaaQVEBbCa6vuoMKxENfCtSxrywXdkIc=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywrd0oFxfnoPIdEYTIplZtk8+fpR3VpEW4LGhtYkPhuynP6guRY o9mxv+3LBtr+UR8oU/A4OiczAXjrmag+jR7RdboUzs/K/Rp9jcIfoNpPRBmJUvAhK3J9O13V74u xHIo= X-Gm-Gg: ATEYQzwXiWwLiugUcXS/hoeZ0NLx2orOhFrL21q1aEpeqpREd+aQLnxiGgUAmJpxdXx y/At5EvawAC+CVGWy1t8Y4p29iL/opdvtTb/tUHrQPxunbHpI6h865pLuGt5j9HTxzV92LN3NSU m4WUGX7wRydKYE0skJyxJU5CU5KSZqnyPnAUxEYSVXdG905tbgZsgBfJlUszVFzmMP4vrYMnLFB xRIc2pYsT0Y3rNHMU53+uq5ASqzvViia3unkFD9MzKd3TKTFsjDaYFTpkWX15I8POUdPhXDiKbO jzpUT9Bv0aiDik4sSfEZe9AGl0f0+80tOJJ8uWsU7dMME+h9ofKNUg8E3yn8dHuoPJLNTq7bcdl rIL28f7ADMkYStESd3y0aXt2xpZH8kyGFn6eneTD/rabgCaBhlPgKMt6IGrPk2nTFnLfc8QGUVW S1HxRHKrI9GFNUqti+3IecpQVqIsUGtTWbNRah3F3zFLLz+yaWRD3ClZGkMMtHadaRhMERq6yp6 wt/TnjxyWKSFcI= X-Received: by 2002:a05:600c:4454:b0:483:702f:4633 with SMTP id 5b1f17b1804b1-4851982700amr76787235e9.4.1772704828280; Thu, 05 Mar 2026 02:00:28 -0800 (PST) Message-ID: <9e873ced-59cd-4e5a-91d9-375e7cb2798b@suse.com> Date: Thu, 5 Mar 2026 11:00:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4.1 09/14] x86/pv: Adjust GS handling for FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-10-andrew.cooper3@citrix.com> <20260304171826.45847-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304171826.45847-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 04.03.2026 18:18, Andrew Cooper wrote: > When FRED is active, hardware automatically swaps GS when changing privilege, > and the SWAPGS instruction is disallowed. > > For native OSes using GS as the thread local pointer this is a massive > improvement on the pre-FRED architecture, but under Xen it makes handling PV > guests more complicated. Specifically, it means that GS_BASE and GS_SHADOW > are the opposite way around in FRED mode, as opposed to IDT mode. > > This leads to the following changes: > > * In load_segments(), we already load both GSes. Account for FRED in the > SWAP() condition and avoid the path with SWAGS. > > * In save_segments(), we need to read GS_SHADOW rather than GS_BASE. > > * In toggle_guest_mode(), we need to emulate SWAPGS. > > * In {read,write}_msr() which access the live registers, GS_SHADOW and > GS_BASE need swapping. > > * In do_set_segment_base(), merge the SEGBASE_GS_{USER,KERNEL} cases and > take FRED into account when choosing which base to update. > > SEGBASE_GS_USER_SEL was already an LKGS invocation (decades before FRED) > so under FRED needs to be just a MOV %gs. Simply skip the SWAPGSes. > > Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > --- > CC: Jan Beulich > CC: Roger Pau Monné > > v4.1: > * Extra comments Thanks. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 10:18:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 10:18:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246407.1545594 (Exim 4.92) (envelope-from ) id 1vy5mG-0007pX-3F; Thu, 05 Mar 2026 10:17:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246407.1545594; Thu, 05 Mar 2026 10: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 ) id 1vy5mF-0007pQ-Va; Thu, 05 Mar 2026 10:17:55 +0000 Received: by outflank-mailman (input) for mailman id 1246407; Thu, 05 Mar 2026 10:17:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy5mE-0007pJ-SO for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 10:17:54 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 92715f5a-187c-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 11:17:53 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB5751.namprd03.prod.outlook.com (2603:10b6:510:37::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 10:17:49 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 10:17:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 92715f5a-187c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iveqgx+reBQU8LR3yWdSYQnB2SpR9n8WxyYXrahwyCvxlfs0cGdrg1Gx+m90QF5FiQz9gbsO6QHflHIWklyjxUFIhJM7REDLdzKLdOmSRFEVlAiiUzhLRyXVBTezoKeI47pvfSNBy8SXXQZdHJbmqwgglQDqHbPhrOUThB+ulC8UpSMoJQFBgpAemMI13uQhFXwV/X4Nk/U9kcN4Gw31fjg+FH350nvQylH0T1vBuM4KAiFTp3Iy/91ssQ9NiK+kdbpbxXTAUp6jbzl+KX1/rTFCCmketMVpSiyi4rA/vecUItoPSMPoBqd6QR8FzL0OMZ1EEkDwnExCaFDWyOUpng== 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=yb2AtnC2c0l2A3eDXawoWOYwxLc4Uvk1WfvhikYEUXo=; b=KGXDRPwTyMjS7dlG4eWoPyvPZhbgUCGSh5w/naL+o3cx7jNS9Fq/KflVPiCwiF1OHXAXk9954YZIWZ8sseFPE6O+hVVBxv1fXS/EjNjVwyPNnUa01AZeKjBI6XH2OR2p/RSUSQLUS1+edjhCHTH6hCfXy63bSoWgfdf0hhCIQBYVWzeJnFAtuYcUFM0AKQR1MuWUHeeNhxx5+dJYWYjaPRXt+1rcCn7Q239lx4q7w12EE7DgZDVhwzceNlJPwXFLQl3HqXS3bYSHAeY6Ji1UZh8n2ylo5FmDs8fobCyMlNkjYItvOInjW/r2FUBJBsjl75Bztie7IpJblwqViAsz6Q== 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=yb2AtnC2c0l2A3eDXawoWOYwxLc4Uvk1WfvhikYEUXo=; b=QGQB2LL8i0/2EmQceE+7jNcWPdlF5yCJvOBRiIEIjO8zuB66EoNCx31Ax6uudd3qPwVvap9SQgBMgcOG3wtJUuTwxfbij+hZTbyG+Bom2TpLLTfOrsPwc4peFrrouc2BhGO6tHwBH4Z2ltOj96lJTSERRNVy4UO6Bw2451jLMuA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 11:17:45 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Message-ID: References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> X-ClientProxiedBy: MR1P264CA0009.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::14) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB5751:EE_ X-MS-Office365-Filtering-Correlation-Id: 0c12a01f-bc69-4f46-2548-08de7aa07428 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: 3sLo5tt0lGLeeVvqk+Qb2ULjuR1bj/tDFURXEi+EsYd6AOxmVLNXA6vEa6XLIDF0Gv+NctcjB/+yV62lH086ZPzDl+sTs/6gvohyvv0iOkuYkU+D2/QJrjM0GwFzCl2IM0PFprRXrRsm6CxcfOnPJwrODqthRQQZ1v42K5N1Qr/j4hrwepKkppMvt2ZuPEA5x3UOcCk2FjF9G+4GNBFTV0BUTlizovhyC1tuBpAEoTjuzeXYQkVMTtSOjEc7CkQUW30SABfGthfwFfsgBtTEKUvbBQEKfYhxgQYRg6wHG5H/dkmBXtkgrGxLgUGrVju98H1F9xU2uzFJ6OkTRhdUotv8zi1Jaarr2XrX6H0ZY81QCgQ4G7VFMYXj2jsEJtmYzaWjFTKfN5KAK3HT0PrlntNf6AwOH4xmPeg1lGF043nVJo2Y4Daz5vRh4RTiiZxNgpf27xY8Di+/tytrxIrlUKxNwzkkV7eYsKBf13XF0MeVF5dmto7D1dY6lhHyVQKX/1k4bRwmDqZMUjlgYsRr7QPTwX0q3di/MOxblz0A2XTloYG2xtQJqoGfWE9LoNQwbrZ+NdL/yC0yK3CpengAjrC3wfkPnoPAB5vXp6E/DlmWAyRFSjevIcgTp3b7XrB657mk4gxMgCO3WBmHfHKx9zp5/5qwpxXyB0d44Ey0xUQT3vNaq7Ox5uFuKhP0TRF+D1GiwvkVWws3zf3IW/60uEQT9cvgPN3ac423RbVCmwA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WllROHRWeSt0Yy9QdnJZN1R0MEwxK2NzTmdlUERjMEt0VXI0bzVaZElPNk1q?= =?utf-8?B?dFVuelJZSzh0VDF5VTBXQ29FZjM5WU9rVVpLUUg2VGtKOUFaVzA4NzhxS0lV?= =?utf-8?B?UTNHdFRjaTh0V2ZicFNtMDRHN21QTHdXRVpmL0szZzlwQ3JyVUw0VDFWL05Q?= =?utf-8?B?TzBFcllnV2tVanR1RFQ3Nms4SXBvNU0ySGpRMG05eURXRWhOWFJqV1VkdWox?= =?utf-8?B?Y1pKc0FVR29DL2dUcE9leHVvbVArYXhPbUlaSlhpYjNzajBLUU5QQjNmQlRY?= =?utf-8?B?dThjM212WW4xYzJhUEhsb0JWVHU0aUlDV09lczZ4T1VTaFZpeXFjaUUweStR?= =?utf-8?B?bGw1M3JuVjRRbTRZc2hvZE1mK0k0bXlnaUl1Ykp3a2xUdGh3WXlTTEdwekFV?= =?utf-8?B?clpqWkxBdk5nRWVZU3dpem5yQWtZMS9oeXliUUtnZEFOS3lGNXFQZzhhOGNF?= =?utf-8?B?QmV3VjZ0Q0hGWVB4NFdtMy9NbGVuRnNXeGJqUmlNbWVTNTF0cUNUa3BMOXBn?= =?utf-8?B?K0dndjUvcWEyUzFrK0xxNTRqZ05SaHlIRVkxUUp3ZjhTZm5waG5OZjNDWDYz?= =?utf-8?B?KzIyV0lwcHZzU0l3NmJjdC9DM1U3anh0eGZUcjBRTHozVFU4MVVPanZ0ZzNK?= =?utf-8?B?RTlxR20yME5GOTNJQysrdEhIem4xRzJQa3RKVlMxN0t6by9TMW5aalF5MmNJ?= =?utf-8?B?eDNkMityaXZxZzMrcEQ0VHMvdVVZMm1XS2c1NWxZQ2xscFVRdzZoM2pob0Fq?= =?utf-8?B?MVRKQkRXSmJITTlJZ1FxZENSbnZKZ2RoM1BuWi9VSWJTTTBKVWdXVlRzMlhy?= =?utf-8?B?TGhNZGdUK2lSYWRYb215NzBrZ2lyU2Q2T2o1OUVwWGgvUjlyRWZyVWRpV1JL?= =?utf-8?B?TXhBUnphb21DTDBxVnl0ZW40Zko0VHU3di95eWJuZ3ZjK0d6R2lod29EMXhp?= =?utf-8?B?WUVGSEErUlRadExYKytPR2xvZkRhandOVFRVNWU1UEtiaUJLQ2ZSdlhRRTA0?= =?utf-8?B?V0tXM3gzaWEzR2JnN1BlMHBGd2xWdWtYNHdhbnFHekJ3ZkMxNEdFelBRYUN3?= =?utf-8?B?aWs5UUNabGYrbktsNjJHcEk4SkUvN1Nqd0JoYWV1OW9mQXlzbWNLb3VyR3lU?= =?utf-8?B?azdzODAxbGd6RDFIczV5a0VCUGR4T3lXQVhaSDhveVpKeEdJWlhSZ2F2ZEJs?= =?utf-8?B?M0xjOVp6UW10ZUY4QWFUV0FQSVhUVnMzMUphK1BTcWVCTktVMHFxZnlIdmZO?= =?utf-8?B?S0pSRkZ5RUtkT1RIMllJcUN3U2QrOER1Y01rcEFaemVQK3poTWY5UzR5djZv?= =?utf-8?B?QmYxMGhHZ3BZQUxDRFBreGZMcmxJVFFJd0VUdUZITXQxSHNwVGc5RFpERkF4?= =?utf-8?B?di9nYzdJUmdlQnpSSldKSTNERWNBZ0wxblNJYXFMeUdmYnZJU1JPb0Z6K1dk?= =?utf-8?B?ajB2cnFMUmRvMHo2ZGpHUG1sVlowbEhnRUU0eGpxbWVYRVE2RTErVDVVWXBD?= =?utf-8?B?NTRKU25lN2tHdkdsbUoySmZqZnovTExhZ2xmVnAzNmdhN29HREJ6NW1pS3ZG?= =?utf-8?B?L0ZmT0d2NFdSclRvS1djd1A1N2dWM05ZRGJJU28wN0U0Ym1abHhPdVh2M3pz?= =?utf-8?B?N2JMSnRvWGVna2tLcm1heVdCQncrbU9valYwZm5WbnN5R3RmYiszZld4VzZk?= =?utf-8?B?UHYwQlFsSFQzL3JiRjFYRTlwZ1gxd0I1WWNtSnVza0hnTVBMajRhVW5weFlL?= =?utf-8?B?TVV3KzZNTDNxU2hyNVZkUVhsNzUyOGZtczlZSFJINGhBaEhWd1dYMnpvWWJW?= =?utf-8?B?NUZHck9IM1RCN1EzUkg0SmVyNlE2MC85UjNZUjBmWmNIeHNTRUNUR25iZXQx?= =?utf-8?B?OVJuWmU1c00ySGpLbURXV3FHMlorck5rUGkveCtpYlF4cXFlZHloNW1EUytG?= =?utf-8?B?MG9DbmsrVFNzWDJSRFpIWEgrVlVoejdjZjd3Z0w0SkY5eFNBcVc3RkVqVlNn?= =?utf-8?B?SW5GTUN3NEQyTlczUkRrWDBacmhpZHh2UnUrUWZCb2dEVVpidUNaUnYwbVlv?= =?utf-8?B?elUxK3NLd1ZZdXJBYWhDWjF4ZXdKa2dFUUhNbW9jeWx6VlBJbjQ2Z041a3Fl?= =?utf-8?B?NDBoQzBBOUlsUjU4TVRuWEpQZzFJb3JITFI1bUQ2RVF6UDM1ZzE5UGJYbFE1?= =?utf-8?B?SHV2bzVHby9wTHJSRy9STWt4dzg0Tzc4cWt1NXFWb3hmQnJlbWtWanVUZjBs?= =?utf-8?B?WTJXVHYwUXpKS3h6TTlSeDZnYTRjdTFsV3UyNStYVVY4TXJNZDJhOEJYZFhG?= =?utf-8?B?R3QvK29RbzJyOVFaL1lrbkV0b3VBOE5GZDRuMy80QmxHOU03SW9Jdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c12a01f-bc69-4f46-2548-08de7aa07428 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 10:17:49.7798 (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: wFpvwPipZipAkb0uwRquqQOv0l/S4C8+PlR4tPkq6rwjJARH9F4OmU68gXFOOQHsygpklOdlFbBPnXAS54yL9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5751 On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote: > On 05.03.2026 09:50, Roger Pau Monné wrote: > > On Thu, Mar 05, 2026 at 09:17:23AM +0100, Jan Beulich wrote: > >> On 04.03.2026 17:36, Roger Pau Monné wrote: > >>> On Wed, Mar 04, 2026 at 03:37:25PM +0100, Jan Beulich wrote: > >>>> --- a/xen/drivers/cpufreq/cpufreq.c > >>>> +++ b/xen/drivers/cpufreq/cpufreq.c > >>>> @@ -694,14 +694,23 @@ int acpi_set_pdc_bits(unsigned int acpi_ > >>>> { > >>>> uint32_t mask = 0; > >>>> > >>>> + /* > >>>> + * Accumulate all the bits under Xen's control, to mask them off, for > >>>> + * arch_acpi_set_pdc_bits() to then set those we want set. > >>>> + */ > >>>> if ( xen_processor_pmbits & XEN_PROCESSOR_PM_CX ) > >>>> mask |= ACPI_PDC_C_MASK | ACPI_PDC_SMP_C1PT; > >>>> - if ( xen_processor_pmbits & XEN_PROCESSOR_PM_PX ) > >>>> + > >>>> + if ( xen_processor_pmbits & > >>>> + (XEN_PROCESSOR_PM_PX | XEN_PROCESSOR_PM_CPPC) ) > >>> > >>> Currently the CPPC driver is AMD only, and hence when using it we > >>> don't care about filtering the _PDC bits, because the ones Xen knows > >>> about are Intel-only? > >>> > >>> As you say, we likely need some clarification about whether there's > >>> _PDC bits AMD care about? > >>> > >>> Linux seems to unconditionally set bits in _PDC, so some of those > >>> might actually be parsed by AMD. > >> > >> Or it setting whatever it wants is meaningless on AMD systems. Where I > >> have extracted ACPI tables readily to hand, there's no _PDC there. > > > > Oh, interesting, so there's no method to start with. Is there an _OSC > > method however for processor objects? _PDC is deprecated, and maybe > > AMD systems only expose the equivalent non-deprecated _OSC? > > There is, yes. Hm, then an OS would use the Xen _PDC adjusted buffer with the _OSC Processor object method I think, and we are back to the position of not having an AMD specification for those bits. > > >>> I think we might want to split the setting of XEN_PROCESSOR_PM_CPPC > >>> here from the addition of ACPI_PDC_CPPC_NATIVE_INTR into > >>> ACPI_PDC_P_MASK. The latter we can possibly untie from the questions > >>> we have about AMD usage of _PDC. > >> > >> Hmm, yes, I can certainly split the patch. I'm looking at it a little > >> differently, though: Us leaving any P-state related bits in place when > >> cpufreq handling is done in Xen has been a mistake anyway. > > > > Yes, TBH I even wondered whether we might just wipe whatever the OS > > sets in the _PDC bits and completely fill it from Xen (unless for the > > weird/broken case where dom0 is driving cpufreq?). > > > > This is kind of what Xen already does now. > > Indeed (except for the T-state ones, as support for that was never added > to Xen). > > > However see below. > > > >> What's > >> unclear is solely whether because of us driving things some bits need > >> setting (likely none if AMD systems indeed don't surface _PDC in the > >> first place). > > > > Since we have the parsing of the ACPI related data done from dom0 it's > > not only Xen that needs to support the feature, but dom0 also needs to > > know how to parse it. Or we just assume the driver in dom0 must > > strictly know how to parse data from the features enabled by Xen. > > > > Maybe Xen supported bits should be & with the dom0 ones? So dom0 > > would set what it can parse, and Xen would AND that with what the > > cpufreq drivers support? However that would be an ABI change. > > What cpufreq drivers are you talking about here? I was talking about the Xen cpufreq driver, sorry the context was confusing. > When Xen handles P- > state transitions, the drivers in Dom0 would preferably not even be > loaded. That's what the forward-port did. Upstream they may be loaded, > but they then can't actually do anything (and they may exit early). Well, yes, on FreeBSD I simply overtake the native ACPI Processor driver with a Xen specific one that has higher priority. So the native ACPI Processor driver doesn't even attach. I think Linux is slightly different in that it allows the native driver to do the fetching of the information, and then the Xen driver only does the uploading. > Coordination is necessary only with the ACPI driver(s), and that's what > this function is about. I think Xen also needs coordination with the driver in dom0 that fetches the information from ACPI? It's not only Xen that needs to report what the cpufreq driver support, but also dom0 would need to expose what it can correctly parse. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 10:20:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 10:20:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246415.1545603 (Exim 4.92) (envelope-from ) id 1vy5oz-0000u1-EW; Thu, 05 Mar 2026 10:20:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246415.1545603; Thu, 05 Mar 2026 10:20:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy5oz-0000tu-Bj; Thu, 05 Mar 2026 10:20:45 +0000 Received: by outflank-mailman (input) for mailman id 1246415; Thu, 05 Mar 2026 10:20:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy5ox-0000to-O8 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 10:20:43 +0000 Received: from CH4PR04CU002.outbound.protection.outlook.com (mail-northcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c105::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f657f35a-187c-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 11:20:42 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BN8PR03MB4979.namprd03.prod.outlook.com (2603:10b6:408:db::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 10:20:38 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 10:20:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f657f35a-187c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AUNes5knhiUinrJgSmL2Z6XhQ+i2C/e+mt0gphyLoii3wIwIoMAEZrLl8Uxkip2DqXCReb6kNkJ0fE7l78+1Xdm8w4cCVtCIQyMb9NZgjgOks/JEAt8Cxc1Tp0GwlaL58eZPQP6jbzMlmiDB1V+nxbEEBrXatwHLiO8GvU2lmvEzLpRftWKxM2h1pMFQa0LuQuJxNxnCf+3Nr9ZmitKoADoivgz5CTaXPOkxsakjGRAl2RFuMBtcHFrjh7GLiR67q9VaQ/pJJV4VW10a2NBAGSfHLJ5dZz8kvPrDTnXY4K7rc0ztzJh/fLrMm1UDQb9C3XEiqKNkR3Gc1A2AVAtuWg== 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=4RJYvuNY00CmLT6r8wK/D8hHjvTR3SciKVM+OrZZ6UI=; b=iWmeUhMCAB2yPyKdE8m4Gr7H0baYycxl1EB7SmmKhDJ9HUVA//ObPVVB9aNrNRj/iSlUs0UNzX34tb5PGBIMUtJ0wPo+xIeb2Mdy4IQtDeuTVarrWuWu5HtgyZ+x9eURBLaP9RyDOjwEw6UaKZIgWLtZz4bPaaKGA54+4/aB2CrMSO2jrh7Xvdg4tBnFR2bd6ltK+WITHSrDcnV7EelPzD7h3oNS9h5DoYSIBOhjzCforxFoF58d8tPRIWGl9EDumWkD6e2h9wVaBfVn/5CgJcXhxLT0Xw7mpvdQsvGMIuixRDShRtYAC7jBDPxBDRIlvksmLEt9cjNPAYvCjAaPhg== 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=4RJYvuNY00CmLT6r8wK/D8hHjvTR3SciKVM+OrZZ6UI=; b=boY9qpJ4tNJDdpzEG/Tr2cBrM46UafOw+Ko5TP9nmD9/ZdORPSNmWS8X+5Un4dR3C0AG3ZuO9MBCXkAm6qZionQV9sZbfDe/I47zd6cWennnnlgOvZW4jgQVs5vDxgZLIM9XmMmob5sqSdYZf3FdjjJI4w6x89P8/mmPAdPlaSo= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 11:20:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v5 5/5] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <6202d2d4-ad80-4e37-b1f6-cd9d19add72f@suse.com> <9f1fcbfc-e7b6-4ef3-8f58-c88f9667d606@suse.com> <2c3fdfb6-5788-4177-a264-56719e1ae804@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0004.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:2e::9) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BN8PR03MB4979:EE_ X-MS-Office365-Filtering-Correlation-Id: 6196aa5e-6b2e-423a-e6c0-08de7aa0d8b3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: QmTejN0EZvpzt4x/LFFrQaahJV5D/ntGN8l7OuJP9ImNhoJRWgnbVGcEOK3Laj0RT5RCLEEIPw+u80vRFlndTESTE48OrSE8bVoUhDLjIZYZQrCeUPBddsf1n/p5qqNuOVPzMuxgzWi6r3n59nYgttasGk1Fm3wv5cv7qBW//h4YyT7h6DwCCsIXzr+YjIX+kQkW4TeS86ZwuZzNkViHLGeCmjhXKL41I9vbD+7SFlIJ9MvuCUQsXWpB2BowNxcqqOGN13gJPaSzy2gvbyC6p2uGo6E5D850r7kqVZfi/4LCtSGKUPARZ+6M4CVzV53Nvj78tL0zFsqzJbYJGaHM8aknw0hkRphxFOy8Iw9NwHvkZFtnv1mt5kM5YCt3gNZNq0Pk5ax1KbxUq1xZIhw7ZisibulPNBD6m9jqVGkvrpctOsdGS3KX5JRZs/oM1ZGZHFtHhJDxM1jV1XaJkeaTOEvC8wPhamN0RPtNy0cWg9hVK1SPwuxn8acRrZOB2cYtqFgbl0TtmCCq6+8iLz5B+JRqoyxx3XQzwItGB9GJa1kKxiNXzLWK3CX6j/N20j0g3ownH3juZIfG0XgEJJZN6ni5SesiJYkNa+zNbcI8eeEWI3mNVC2JxeMp55/eL9JCrnRld0Mw2anomKbJCxN8NjtHfnOyHwCF2E4FJtYQnBwb2Y6eK4PixiDxalvq00tgpR8or+2m9zdPxxrcuJXpJAhRBEz+lEjQXp8Ei7RJtZA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?czVUaHRxaGpPVkZRNzA2QVgwcmNVODFBWkRDK21vYzZHdUlKbG12dTNkYTlR?= =?utf-8?B?eVhzVEtZbFFEeDVJK3lkZUZqT05XbmpKSGh3ckx3Tkkzd2N0ak9CRkFsTFdm?= =?utf-8?B?RWpkeU1YUnN0TlB3TDhFaHZCbkY5MWx2OEpQNmpxMDZQWEY2RncvdmpUZVor?= =?utf-8?B?Y3FhdjlZUmI3Z0VnNk1HN3pPQkY3YjJnSDlEYUhJME1lNFR3SHp1ZmRyRFNq?= =?utf-8?B?THVGOFIrM2Q0MjQrR3F4elZkVkYzM2ZKZCtYZVJJQnFURjZFUGlrTFNDTU9m?= =?utf-8?B?eDhydElXQXFwYk9wRkdZWE9PY0VLK2UwZ05CVG81VTZncEM5L2NNWTFabWlH?= =?utf-8?B?Uk11bkRvTWI1aUxya2VGb3NMeVRzTTRZTDc2aURnNkRiYTZUa0ozSW5XMVh5?= =?utf-8?B?YWppV296WEJzaU00Yko3TXFwcTZMSXlIcEZuWUxkSEhqbnYwUncwdlQ4VkRY?= =?utf-8?B?a3FzRm5URjNoRisxUHJHWEVPbGNzems1YW8yZUFHSWNweFQ1UHJiT2w0ZS9W?= =?utf-8?B?dDlRNWFuZUFHbEpOeVZBRy9UYzVnY2dNNDF5WGN4VmxNMi85Z2laa1l2cE5Q?= =?utf-8?B?ZnhyRk5wNlFTTHNVbkkwcCtoL0pLN1AyRTJHR0g5SFJPME53M21lYnFHZzBh?= =?utf-8?B?ZmpoMTVLand3NExVTWZqK1ZpZFI0Yk9SdFM3amZrVGpxWndmMTYzQWxJRDQw?= =?utf-8?B?clBJTjBzM1dDTXZaMjh2Wk9ScEM3WnQxL2N2MTFxSWhFdnVNd1NuZ0huMXN3?= =?utf-8?B?eitQYmYvVVovT3RlT1BETVpCZ3Jud0ZyTkNrNlBXNWJNTC8xdEFqenEyazMy?= =?utf-8?B?cEdVRWRtTG56VXdQa29QejZVb0RRRUNRWlZnRUdnTllIc2Y0eGhFQjNVeTVU?= =?utf-8?B?Q29YMzB5YWdnTGFoR3k2K0YwTjFKOWVLRlY2eHJlZjVyODd6dDJNUnA4YVI4?= =?utf-8?B?RVFnclNrT245VVpCYWR1eHJaVFBqZjdnL3lSQmYzNEgrMUtFUVhRTHM4NThN?= =?utf-8?B?NXJBcmFBOEUwQ0dIc0JQZzhUbWpXcWRFMFAyQXdFWm5sSm9UNmd5VGE3SWFJ?= =?utf-8?B?S0w0bzdnbmNscmJpSVpiRlFBb1hLTm5ISW1ibkRSSXRMQlNFcWpJclo2K0R5?= =?utf-8?B?Y0VlZytBV2UycGRaNFA1R3VqeXNVMFhKRS9UdTZKY3FPMi9XMVd6dXBOdTZL?= =?utf-8?B?Q1JlNkxqUzNCcE9xL3pIbTVyRFpzcEFCcEFaZG5LcmNjVEdWUnAxak9ES0pk?= =?utf-8?B?Mk5aMGc4MzdqM3Qwb2M4NTlicWhManpRbXlQQ3lXQVlaT0FRWTdSVzNSZFoz?= =?utf-8?B?blg4dUNPQ1hCckdRSmRScUM4UDhCTzRiRytMeFVXNmg2ZWkrYlZXbGdIbzk0?= =?utf-8?B?MElRRk9iTC85ekNzUld2NXR5MmxramcwcWNpV053QVhnY3JaRU9ITFZiTzVJ?= =?utf-8?B?bWI3Z0JIenZjc1dZSk1WQkIwRTc5ay93RFM2S0pybDJXMmhJc2RkSU0wbXBC?= =?utf-8?B?cXpEeWNnelhtanJzUlRjME1ZbDFsODhqSktrSWRzSFg3NnpKU2xGN2lIME9M?= =?utf-8?B?Q05uSllsdU1BMk9mSEMrR09ndTNsZndCUy81UUc0Z0FtdmZxYm5ZOUtWZjYy?= =?utf-8?B?QnF6U2w2UFltSEdoNTZUeXhUWXp2U1g3S3hkMnp0Zy8xRENiMWVmanRzVThn?= =?utf-8?B?cW8zL0VIMFYxbDltUngyQVhSNFhiYXI5ZGhIQ2lGOURJWlVZTVpVejFTQ1Q5?= =?utf-8?B?NmQ2RHU4Y1FRL1VFRmVUTW90dmcvdnh0YkZGalNUdlBDZlVqa2o5MUN6NlRZ?= =?utf-8?B?SFNmR2ZNb0c2bEZZalVaZnNKMFVzUTd2alJZZEVxV0ZvVHBrNHZXMmFBRk1x?= =?utf-8?B?cU5hMjI2TXROZlk5eE82c0doeVFVdkx6MG5QeTcrUnFlbU9DYmJFZ1g1ejM3?= =?utf-8?B?VDdlSk9kQTR4TU8rYkN4eXdvOUdTREZZM0Z4ZXpWWk91K0hKYTBtVGlwUTFt?= =?utf-8?B?Mm5CZDJyTzE2N0pvOUFDUUJSbHIzclliYXBGNG9FN3N0TW4xOVRVSHVuSDFD?= =?utf-8?B?RDJVN0NhUWlESUFvYnVWK3QreVFZSDc4bWdHL3RLMnAxRy9iWDZrK1BOM2R4?= =?utf-8?B?bXVOYis5RlNubkZnL255TFRwZUV1YktSTzF0ZnlyeHBrOWI5R3d2V1huNlN2?= =?utf-8?B?b3NBZmYyWnQ1YlkrWDhxb21yQy9STlk2UEJOaEVnMlJ0N0FEaEVEK3QxeDRE?= =?utf-8?B?TDU1YURLMDYzaFhHRHVqT3h6NkVZaVZYanlRTVppZFR4RnZMVUFmQXN6MEc1?= =?utf-8?B?MUFKWTMzaFg2WWZZYjdPTXJ6dlo5dUFpa0ZDYnFLOTk2MXlBNy9Tdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6196aa5e-6b2e-423a-e6c0-08de7aa0d8b3 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 10:20:38.4398 (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: YFIwK7bSSCIAO2HjS/M4kzbhyDBzay9cnz+qyLz8CS6YlF/y4BmGojPJW5BGzuJtG4GpLFwDsm6IXYHrlky1fA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB4979 On Thu, Mar 05, 2026 at 10:45:29AM +0100, Jan Beulich wrote: > On 05.03.2026 10:22, Roger Pau Monné wrote: > > On Thu, Mar 05, 2026 at 10:00:13AM +0100, Jan Beulich wrote: > >> On 04.03.2026 16:06, Roger Pau Monné wrote: > >>> On Wed, Feb 25, 2026 at 12:44:44PM +0100, Jan Beulich wrote: > >>>> When Dom0 informs us about MMCFG usability, this may change whether > >>>> extended capabilities are available (accessible) for devices. Zap what > >>>> might be on record, and re-initialize things. > >>>> > >>>> No synchronization is added for the case where devices may already be in > >>>> use. That'll need sorting when (a) DomU support was added and (b) DomU-s > >>>> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > >>>> > >>>> vpci_cleanup_capabilities() also shouldn't have used > >>>> pci_find_ext_capability(), as already when the function was introduced > >>>> extended config space may not have been (properly) accessible anymore, > >>>> no matter whether it was during init. Extended capability cleanup hooks > >>>> need to cope with being called when the respective capability doesn't > >>>> exist (and hence the corresponding ->init() hook was never called). > >>>> > >>>> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") > >>>> Signed-off-by: Jan Beulich > >>>> --- > >>>> vpci_reinit_ext_capabilities()'es return value is checked only to log an > >>>> error; it doesn't feel quite right to fail the hypercall because of this. > >>>> Roger brought up the idea of de-assigning the device in such a case, but > >>>> if a driver doesn't use extended capabilities the device would likely > >>>> continue to work fine, for Dom0 this probably wouldn't be quite right > >>>> anyway, and it's also unclear whether calling deassign_device() could be > >>>> done from this context. Something like what pci_check_disable_device() > >>>> does may be an option, if we really think we need to "break" the device. > >>> > >>> We may want to add a note there, stating that we have considered all > >>> possible options, and hiding the capability and hoping the owner > >>> domain would continue to work as expected seems the less bad of all of > >>> them? > >> > >> While adding that note it occurred to me that in order to keep the device > >> as functioning as possible, in the re-init case vpci_init_capabilities() > >> might better not bail upon encountering a failure, but accumulate the > >> error while continuing its loop in a best-effort manner. Thoughts? (One > >> of the two return-s is already guarded by !is_hardware_domain(), so that > >> could be left alone for the immediate purpose.) > > > > Right, yes, that would be preferable. We already print a message for > > the failed to init capabilities, so there's no need to print another > > one in the caller. > > Hmm, that's another aspect I didn't consider. Yes, the log message in the > caller is redundant with the present code structure. If we expect that to > remain like that, I can drop logging anything from > physdev_check_pci_extcfg(). Which then re-raises the question whether > vpci_reinit_ext_capabilities() might better return void. At which point > the comment I put in physdev_check_pci_extcfg() (upon your request) would > want to move there. > > But my earlier question went in a different direction, and you didn't > comment on that at all. Yes, I think we should accumulate errors. One device failing doesn't mean the rest will also fail. We should continue the loop. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 10:53:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 10:53:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246438.1545613 (Exim 4.92) (envelope-from ) id 1vy6Km-00053p-Rz; Thu, 05 Mar 2026 10:53:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246438.1545613; Thu, 05 Mar 2026 10:53:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy6Km-00053i-Om; Thu, 05 Mar 2026 10:53:36 +0000 Received: by outflank-mailman (input) for mailman id 1246438; Thu, 05 Mar 2026 10:53:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy6Kl-00053c-Im for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 10:53:35 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8e0e3322-1881-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 11:53:34 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4836f4cbe0bso66974715e9.3 for ; Thu, 05 Mar 2026 02:53:34 -0800 (PST) Received: from [10.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-439abded86esm39427342f8f.6.2026.03.05.02.53.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 02:53:32 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e0e3322-1881-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772708013; x=1773312813; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=+/0CQKkeqc2XR5r4TdFszbCjUpD29tLEnzlXyjTUqUo=; b=EXCcvy52QPb0Cm3nfQMZBq3WMLy+R0w1E7/8cB/wPpfo1VWKojGewieKIkpxnYjW2p UuTAFZeWhS2k1ju79lERzISjjsay9kR6OxOUFdd74WW2D3g/dzhh5KnQwM4vPGzTR6CC 39n0dDFWTXtC+kZfnJAAw7GWm0rRfILKZhNye4HMSLrqNsqZ6J6CAiEzActrB7HNkjtw PKWc72lwCiFqGBrG//nZY/mEhdq/4dwXpFg/Xa5Wi0xioDo+0Fpu59OdNThZuulpHaD3 oG76ZVd6zUbwdFpaJ1z4mkPr83R1XpK/NyVFfHGVlqPl2irvc3p3lUzSNPEcTOjR6k3n XwwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772708013; x=1773312813; h=content-transfer-encoding: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; bh=+/0CQKkeqc2XR5r4TdFszbCjUpD29tLEnzlXyjTUqUo=; b=DprOFZ5XnYh5NOI0wexFDvYWLw3Uq76zF1ZrroSthzN0TwpP9Yw+kDSm2IVTtWfgy6 cw9zYU37cGK0ZbVH7VtoCpBZZdOvkKnzuTG9HWL9W9G371eZhkWe3xaKMUIYTGtPSvF4 vLMlr1ilnLFuA7lhSCunqhcutdWuAtgAyWnxXKd5FpYMI+64/ndRwbvAknMc7yyUuLWI MNRH42aLaKn8VL8bvroSa9NHCfvkMIOf7a1WPf/cp0w2gvKRIqAxuy3lNpjj7eJIQI0X U256QYCVFoNBM+t/ob44lLfIHcSMFenMRPqnD9Hgd2Eq4h3CS1MlD6YomGXfpWvf3mPP vMpg== X-Forwarded-Encrypted: i=1; AJvYcCUrjVGFwfkV/14C9b/daDLgMG2VQDUIu22J5cUfeLV0K1IL4fpYtATGlaVy68z97wI8r3/MbgEbnBc=@lists.xenproject.org X-Gm-Message-State: AOJu0YweWEeRsFYulLNqw+vTPGnZIttAaFXiYjQ9qHUE0TL1WgFYrnj6 Z9Y6iGARHD8MWqVf7FoIm+MlBGl7y+J+iZYa1MO+SMTTc63iXPuM0vVX4FvfkA5bOQ== X-Gm-Gg: ATEYQzxYvUtW9X29rAUthP8KIZRQdwdcbsu1S/qYfCy7rgeLI2hf5MWlqmF2rNWKhWt Qjel9YxtIlpS1oB9e23S2gPp2KTVxgAo1vnTR3UGrXvqWL/Q55EpRMFraqJWOICUialfV7UPrvE jyn5VeaCmweZSrGMJ2qrN4EKC8Er4AQQnLfTMRRMSBvpVG1BILyIeBL83ImEoK83Djf0t6MmmqB 2hq+1nBkBMT/5O9EnQ+kLfasuoWzc0iwf/8SX70jCqZMe/RCuba/PxYZ9Jz+o5jBST/LAMfvOV1 8rjBctuWPbO9uE35y6kgCHTuho/wIRX1wKT72U+enuIGXJ1VFH4PZfkIiolRDDoUfyYpQS9wVIa SBeRxmIQn0ZmkwiFa5ulp3D3m4l/5GOss9ornZzfmeC3Lgqo9KDjF4Fz320alIiV4IJ+0GX2AT6 F0hzcHKcuDHFHxxkFr+xZImI9L/DukSrCxzBAY9peKyzhj1hwUrJPrkUg5Hi6ohiJxgOeQ43OHr 8soPDuXylmoRrc= X-Received: by 2002:a05:600c:3e8f:b0:477:73e9:dc17 with SMTP id 5b1f17b1804b1-485198d8b81mr91267535e9.35.1772708013257; Thu, 05 Mar 2026 02:53:33 -0800 (PST) Message-ID: <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> Date: Thu, 5 Mar 2026 11:53:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , Marcus Granado , xen-devel@lists.xenproject.org, Alejandro Vallejo References: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -944,6 +944,7 @@ struct domain *domain_create(domid_t domid, > spin_lock_init(&d->node_affinity_lock); > d->node_affinity = NODE_MASK_ALL; > d->auto_node_affinity = 1; > + d->claim_node = NUMA_NO_NODE; If, as the cover letter says, the new domctl is going to allow claiming from multiple nodes in one go, why would this new field still be necessary? > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -488,7 +488,10 @@ static unsigned long *avail[MAX_NUMNODES]; > /* Global available pages, updated in real-time, protected by heap_lock */ > static unsigned long total_avail_pages; > > -/* The global heap lock, protecting access to the heap and related structures */ > +/* > + * The global heap lock, protecting access to the heap and related structures > + * It protects the heap and claims, d->outstanding_pages and d->claim_node > + */ > static DEFINE_SPINLOCK(heap_lock); Nit: Comment style. > @@ -510,6 +513,71 @@ static unsigned long node_avail_pages[MAX_NUMNODES]; > /* total outstanding claims by all domains */ > static unsigned long outstanding_claims; > > +/* > + * Per-node accessor for outstanding claims, protected by heap_lock, updated > + * in lockstep with the global outstanding_claims and d->outstanding_pages > + * in domain_set_outstanding_pages() and release_outstanding_claims(). > + * > + * node_outstanding_claims(node) is used to determine the outstanding claims on > + * a node, which are subtracted from the node's available pages to determine if > + * a request can be satisfied without violating the node's memory availability. > + */ > +#define node_outstanding_claims(node) (node_outstanding_claims[node]) See the comment on the earlier patch regarding such a wrapper. > +/* total outstanding claims by all domains on node */ > +static unsigned long node_outstanding_claims[MAX_NUMNODES]; How come this is being added, rather than it replacing outstanding_claims? > +/* Return available pages after subtracting claimed pages */ > +static inline unsigned long available_after_claims(unsigned long avail_pages, > + unsigned long claims) > +{ > + BUG_ON(claims > avail_pages); > + return avail_pages - claims; /* Due to the BUG_ON, it cannot be negative */ > +} A helper for a simple subtraction? > +/* Answer if host-level memory and claims permit this request to proceed */ > +static inline bool host_allocatable_request(const struct domain *d, > + unsigned int memflags, > + unsigned long request) > +{ > + unsigned long allocatable_pages; > + > + ASSERT(spin_is_locked(&heap_lock)); > + > + allocatable_pages = available_after_claims(total_avail_pages, > + outstanding_claims); > + if ( allocatable_pages >= request ) > + return true; /* The not claimed pages are enough to proceed */ > + > + if ( !d || (memflags & MEMF_no_refcount) ) > + return false; /* Claims are not available for this allocation */ > + > + /* The domain's claims are available, return true if sufficient */ > + return request <= allocatable_pages + d->outstanding_pages; > +} This only uses variables which existed before, i.e. there's nothing NUMA-ish in here. What's the deal? > +/* Answer if node-level memory and claims permit this request to proceed */ > +static inline bool node_allocatable_request(const struct domain *d, > + unsigned int memflags, > + unsigned long request, > + nodeid_t node) > +{ > + unsigned long allocatable_pages; > + > + ASSERT(spin_is_locked(&heap_lock)); > + ASSERT(node < MAX_NUMNODES); > + > + allocatable_pages = available_after_claims(node_avail_pages(node), > + node_outstanding_claims(node)); > + if ( allocatable_pages >= request ) > + return true; /* The not claimed pages are enough to proceed */ > + > + if ( !d || (memflags & MEMF_no_refcount) || (node != d->claim_node) ) > + return false; /* Claims are not available for this allocation */ > + > + /* The domain's claims are available, return true if sufficient */ > + return request <= allocatable_pages + d->outstanding_pages; > +} And this is the NUMA counterpart, almost identical in the basic logic. If (for whatever reason) both are really needed, I think it should at least be considered to fold them (with NUMA_NO_NODE indicating the non-NUMA intent). In fact the node != d->claim_node would probably also apply to the non-NUMA variant (as d->claim_node != NUMA_NO_NODE). As to the comments in both functions, personally I think s/not claimed/unclaimed/ would be slightly more logical to follow. In any event, the first of these function looks like it could be split out in a separate, earlier patch. Then (as per above) ideally here that function would simply be extended to become NUMA-capable. > @@ -539,14 +607,23 @@ unsigned long domain_adjust_tot_pages(struct domain *d, long pages) > return d->tot_pages; > } > > -/* Release outstanding claims on the domain, host and later also node */ > +/* Release outstanding claims on the domain, host and node */ > static inline > void release_outstanding_claims(struct domain *d, unsigned long release) > { > ASSERT(spin_is_locked(&heap_lock)); > BUG_ON(outstanding_claims < release); > outstanding_claims -= release; > + > + if ( d->claim_node != NUMA_NO_NODE ) > + { > + BUG_ON(node_outstanding_claims(d->claim_node) < release); > + node_outstanding_claims(d->claim_node) -= release; > + } > d->outstanding_pages -= release; > + > + if ( d->outstanding_pages == 0 ) > + d->claim_node = NUMA_NO_NODE; /* Clear if no outstanding pages left */ I fear I don't understand this. If the domain has claims on other nodes, why would would it be switched back to non-NUMA claims? > @@ -564,14 +642,41 @@ void consume_outstanding_claims(struct domain *d, unsigned long allocation) > > /* Of course, the domain can only release up its outstanding claims */ > allocation = min(allocation, d->outstanding_pages + 0UL); > + > + if ( d->claim_node != NUMA_NO_NODE && d->claim_node != alloc_node ) > + { > + /* > + * The domain has a claim on a node, but the alloc is on a different > + * node. If it would exceed the domain's max_pages, reduce the claim > + * up to the excess over max_pages so we don't reduce the claim more > + * than we have to to honor the max_pages limit. > + */ > + unsigned long booked_pages = domain_tot_pages(d) + allocation + > + d->outstanding_pages; > + if ( booked_pages <= d->max_pages ) > + return; /* booked is within max_pages, no excess, keep the claim */ > + > + /* Excess detected, release the exceeding pages from the claimed node */ > + allocation = min(allocation, booked_pages - d->max_pages); > + } > release_outstanding_claims(d, allocation); Please can there be another blank line above this one? Why is the adjustment made excluded for the NUMA_NO_NODE case? That's odd in itself, but particularly with release_outstanding_claims() possibly switching a domain to NUMA_NO_NODE. Plus the caller looks to be passing in the actual node memory was taken from, not what the original request said (which is specifically relevant when the request named no particular node). > } > > -int domain_set_outstanding_pages(struct domain *d, unsigned long pages) > +/* > + * Update outstanding claims for the domain. Note: The node is passed as an > + * unsigned int to allow checking for overflow above the uint8_t nodeid_t limit. > + */ > +int domain_set_outstanding_pages(struct domain *d, unsigned long pages, > + unsigned int node) > { > int ret = -ENOMEM; > unsigned long claim, avail_pages; > > + /* When releasing a claim, the node must be NUMA_NO_NODE (it is not used) */ Why would this be? > + if ( pages == 0 && node != NUMA_NO_NODE ) > + return -EINVAL; > + if ( node != NUMA_NO_NODE && (node >= MAX_NUMNODES || !node_online(node)) ) > + return -ENOENT; > /* Again, can there please be a blank line after each of the if()s? > @@ -982,6 +1102,8 @@ static struct page_info *get_free_buddy(unsigned int zone_lo, > } > } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */ > > + try_next_node: > + /* If MEMF_exact_node was passed, we may not skip to a different node */ > if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE ) > return NULL; As per this, ... > @@ -1042,13 +1164,8 @@ static struct page_info *alloc_heap_pages( > > spin_lock(&heap_lock); > > - /* > - * Claimed memory is considered unavailable unless the request > - * is made by a domain with sufficient unclaimed pages. > - */ > - if ( (outstanding_claims + request > total_avail_pages) && > - ((memflags & MEMF_no_refcount) || > - !d || d->outstanding_pages < request) ) > + /* Proceed if host-level memory and claims permit this request to proceed */ > + if ( !host_allocatable_request(d, memflags, request) ) ... in the MEMF_exact_node case I see little reason to check the global value here. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 11:31:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 11:31:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246468.1545636 (Exim 4.92) (envelope-from ) id 1vy6v5-0001qK-Pn; Thu, 05 Mar 2026 11:31:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246468.1545636; Thu, 05 Mar 2026 11:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy6v5-0001qD-Li; Thu, 05 Mar 2026 11:31:07 +0000 Received: by outflank-mailman (input) for mailman id 1246468; Thu, 05 Mar 2026 11:31:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy6v4-0001q7-BP for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 11:31:06 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cba7f88b-1886-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 12:31:04 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-439afc58ac7so4942997f8f.0 for ; Thu, 05 Mar 2026 03:31:04 -0800 (PST) Received: from [10.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-439b4e771basm36774706f8f.0.2026.03.05.03.31.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 03:31:03 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cba7f88b-1886-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772710264; x=1773315064; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TZ+NLsEYwzCJxX04okPUm0W0QsmwdELejdWtO4TODvY=; b=XHhNBf+iqR+dSl/FCv0TmJUCHGH9ikPxaUYanU8lWDlxR0Bn67rGtwRefdOTihw+sc FjmTWfDR2HAreGfSn/D+Wh/tbEvABrbNS4iqmffRiq3uXdnHzO/dOolDC5yGuz701UKh ZLIqodgzUaHi3wbGdpcu/4fp5bfV+tgEkk1Jf85IXtXeI/PXR7G0N2LLwXZznZyzJZDH 1fyRIWHHWo5/nIRgxxLOJbYO1qzvKJeFFfd6XkgM9plpk6pzPH+yJ7HFhqEZzduynOUV JAaNHr1n0CIZfdMrovnFUtuwnEmeUwvfIK6IxkCLV8XVqP1W1tdS9ik9ARHRDGkqrBc8 j97g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772710264; x=1773315064; h=content-transfer-encoding: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; bh=TZ+NLsEYwzCJxX04okPUm0W0QsmwdELejdWtO4TODvY=; b=gXPUu0vZTDcUUhm0vLFRmHuIi3AHSWkwZwSAPlS/hmHtrXY4HktR3QXSQni9yuTHPl apPTfe9SDzHY+b+OdLfCcTThQwUv83MP7jcGxNBd2oTh4YHJZRk3lR2L6kleou1wRhIt yrStrfskKFWO6IT6rQ997P4LL5Sv5w4Hv6Im6+ERTK6lHO0nkSkExX2E7GetzCfjPB1W 3sTaWVEcVSA6aWyCPUy7bNLLhWp9/LCVCzOw3OC6TEstxWsec+1b2zeCK6xavKTC6k1E zJngk6pTaIpUYaYy1PDAwdXKWcMrQ7Q5B3ug6TNcMvlStZtmviMKkIhqNf7h/KIA6VyH /RpQ== X-Forwarded-Encrypted: i=1; AJvYcCUJhh/5AcJwedbibVVaYoAmVD3Eff/drxsTtxzyY0BDa6dxrI+goaM0bHXjYwEsa3TFenqr/FFZBOU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyc0n+2sX3WYgqsGay23ktw8faF9o7qEjVHV9gbaRWBtjnqCVn1 wSk7jw4aja46Nacu2uyRt628j5DmeqMxE58407jybbfg58aOZUcevQB9N2X0IKO+4w== X-Gm-Gg: ATEYQzy/FlcVpiDuBmYB86AyNzoCFY91oD60wtJrfEcmo2WiiazQlVX2rRvYKg1Dbc9 qFDcdNCQYvTiFQl8GFgj7WZ4q/0MIBOEPPDH8wi6hZqgd3h7gLss8g4MUvYgE3o2O8eYi4noNGi AoGkTYSJL2SoC99zUXSAE5K+5CL1rUPM2/ypBH79XxbJkxAKZ9N8EiFsn/tmcfDjzKhLwn9IqLO GjX9bGHXxCpfXScVkRYvx9F6cRcbwRWrxWyiXxxMhgH2VADSzqLydfDadlSzo2p29Qmxa74ewL+ LLfEhaTpPFFDJmh7a9Og5cIQz+eENZcr3Wz81VhAnL0myjGiCTH+KQKb4HRu9iYHprLtS2umMuP 1l3KxBiJ4VLfWqscjfHCA8mj7xr0RPSIvBaTJMruMTtnqWzpDFyO6Isc9uD5i/HjVxRUeWzJ75f uKJ8R5zW82ovS/WR+glURPOa5HYgn3hhXTzn+Nqq9ZsPli0y9fRJVScoHfzqUuPK54DJeWDD5IR Xxj13j7b/PFttZkjPnCRn87fg== X-Received: by 2002:a05:6000:26c1:b0:439:b7c9:2ef1 with SMTP id ffacd0b85a97d-439c7fafb66mr9551409f8f.20.1772710263950; Thu, 05 Mar 2026 03:31:03 -0800 (PST) Message-ID: <7d439bb1-7381-4fa4-af79-423e8c7fafb1@suse.com> Date: Thu, 5 Mar 2026 12:31:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 05/10] xen/domain: Add DOMCTL handler for claiming memory with NUMA awareness To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -268,6 +268,35 @@ int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d, > return rc; > } > > +/* Claim memory for a domain or reset the claim */ > +int claim_memory(struct domain *d, const struct xen_domctl_claim_memory *uinfo) static in domctl.c? Otherwise with Penny's work to make domctl optional this would be unreachable code. > +{ > + memory_claim_t claim; > + > + /* alloc_color_heap_page() does not handle claims, so reject LLC coloring */ > + if ( llc_coloring_enabled ) > + return -EOPNOTSUPP; > + /* > + * We only support single claims at the moment, and if the domain is > + * dying (d->is_dying is set), its claims have already been released > + */ > + if ( uinfo->pad || uinfo->nr_claims != 1 || d->is_dying ) > + return -EINVAL; As already alluded to in reply to patch 03, I can't help the impression that usage of this sub-op with multiple entries would we quite different (i.e. it would be not only the implementation in Xen that changes). I'm therefore pretty uncertain whether taking it with this restriction is going to make much sense. > + if ( copy_from_guest(&claim, uinfo->claims, 1) ) > + return -EFAULT; > + > + if ( claim.pad ) > + return -EINVAL; > + > + /* Convert the API tag for a host-wide claim to the NUMA_NO_NODE constant */ > + if ( claim.node == XEN_DOMCTL_CLAIM_MEMORY_NO_NODE ) > + claim.node = NUMA_NO_NODE; What about the incoming claim.node being NUMA_NO_NODE? Imo the range checking the previous patch adds to domain_set_outstanding_pages() wants to move here, at which point the function's new parameter could be properly nodeid_t. > + /* NB. domain_set_outstanding_pages() has the checks to validate its args */ > + return domain_set_outstanding_pages(d, claim.pages, claim.node); > +} There's no copying back of the result. When this is extended to allow more than one entry, what's the plan towards dealing with partial success? Needing to roll back may be unwieldy. > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -1276,6 +1276,42 @@ struct xen_domctl_get_domain_state { > uint64_t unique_id; /* Unique domain identifier. */ > }; > > +/* > + * XEN_DOMCTL_claim_memory > + * > + * Claim memory for a guest domain. The claimed memory is converted into actual > + * memory pages by allocating it. Except for the option to pass claims for > + * multiple NUMA nodes, the semantics are based on host-wide claims as > + * provided by XENMEM_claim_pages, and are identical for host-wide claims. > + * > + * The initial implementation supports a claim for the host or a NUMA node, but > + * using an array, the API is designed to be extensible to support more claims. > + */ > +struct xen_memory_claim { > + uint64_aligned_t pages; /* Amount of pages to be allotted to the domain */ > + uint32_t node; /* NUMA node, or XEN_DOMCTL_CLAIM_MEMORY_NO_NODE for host */ > + uint32_t pad; /* padding for alignment, set to 0 on input */ This isn't for alignment; it's there to make the padding explicit. > +}; > +typedef struct xen_memory_claim memory_claim_t; > +#define XEN_DOMCTL_CLAIM_MEMORY_NO_NODE 0xFFFFFFFF /* No node: host claim */ Misra demands a U suffix here. "host claim" (in the comment) also is ambiguous. Per-node claims also affect the host. Maybe "host wide" or "global"? > +/* Use XEN_NODE_CLAIM_INIT to initialize a memory_claim_t structure */ > +#define XEN_NODE_CLAIM_INIT(_pages, _node) { \ > + .pages = (_pages), \ > + .node = (_node), \ > + .pad = 0 \ > +} While only a macro, it's still not C89, and hence may wants offering only as an extension. Also .pad doesn't need explicitly specifying, does it? If you provide such a macro, identifiers used also need to strictly conform to the C spec (IOW leading underscores aren't permitted). > +DEFINE_XEN_GUEST_HANDLE(memory_claim_t); This wants to move up next to the typedef. > +struct xen_domctl_claim_memory { > + /* IN: array of struct xen_memory_claim */ > + XEN_GUEST_HANDLE_64(memory_claim_t) claims; > + /* IN: number of claims in the claims array handle. See the claims field. */ > + uint32_t nr_claims; Is repeating the word "claim" necessary / useful here? > +#define XEN_DOMCTL_MAX_CLAIMS UINT8_MAX /* More claims require changes in Xen */ > + uint32_t pad; /* padding for alignment, set it to 0 */ Same comment as on the other pad field. > @@ -1368,6 +1404,7 @@ struct xen_domctl { > #define XEN_DOMCTL_gsi_permission 88 > #define XEN_DOMCTL_set_llc_colors 89 > #define XEN_DOMCTL_get_domain_state 90 /* stable interface */ > +#define XEN_DOMCTL_claim_memory 91 Seeing the adjacent comment, did you consider making this new sub-op a stable one as well? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 11:38:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 11:38:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246479.1545644 (Exim 4.92) (envelope-from ) id 1vy724-0002T0-C5; Thu, 05 Mar 2026 11:38:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246479.1545644; Thu, 05 Mar 2026 11:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy724-0002St-9Q; Thu, 05 Mar 2026 11:38:20 +0000 Received: by outflank-mailman (input) for mailman id 1246479; Thu, 05 Mar 2026 11:38:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy723-0002Sn-PB for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 11:38:19 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vy723-006XQq-2L for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 11:38:19 +0000 Received: from mail-lj1-f174.google.com ([209.85.208.174]) by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vy723-00097C-2A for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 11:38:19 +0000 Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-389fa352b0eso127392171fa.1 for ; Thu, 05 Mar 2026 03:38:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=t5++F147kVljeJObCX+Hq7bCYgIw+fILQWtbrnZag0Q=; b=gdBDpOp +/HNelwB9DULGKC0VDWHopHTUEqC7xaeGdhtbuwAFUjyEx18lfLYXT2I7Yif+jnXtiiTtAeIGUdVV ekrXUR0yeBfpmvdQ237HlyaW0RaIJk9HkW4hTig6ED3CyssyVvTUlhrvkRrp2YlVUqaBctor0mFGn IPK0bqLmMA=; X-Gm-Message-State: AOJu0YxylZTqmGGC/SGURoY008UCeovjmvdrpKVqIuaNoQPtjdgxjexi CEnxeNwkRcweeTLDszfXl4O3r9neDZ4TJE6UVq4sl1VHUPVhNn1VP3pzwE/wUbtRpYUgQRvYBFe ZAJiNwZgS9nc0AYDPt0ZT1MhHo5egowM= X-Received: by 2002:a2e:3c04:0:b0:385:f0ce:e222 with SMTP id 38308e7fff4ca-38a2c7eb260mr23074891fa.41.1772710698530; Thu, 05 Mar 2026 03:38:18 -0800 (PST) MIME-Version: 1.0 From: Cody Zuschlag Date: Thu, 5 Mar 2026 12:38:07 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AaiRm50KtKPF8U5Z6NytGmpHt15Pvsj5P0bMZnuY4uijKlnaCJq19i5vkW2lcuU Message-ID: Subject: [ANNOUNCE] Call for agenda items for March 5 (Today!) Xen Community Call @ 16:00 UTC To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000079bc3b064c455f85" --00000000000079bc3b064c455f85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, My apologies for the late notice this month, the short February month (with some personal PTO) made this one sneak up on me. Today is March's Xen Project Community Call (4 pm UK time). We=E2=80=99d love for you to join. Feel free to participate or just observe= . This call is a great opportunity to see what the community is working on, align our various efforts, and share updates. Everyone is welcome! *Preparation:* - Add any proposed agenda items or missing action items: https://cryptpad.fr/pad/#/2/pad/edit/R-D-3LsJGJeZY8o2H9qpoFD5/ - If any action items have been resolved or are no longer relevant, feel free to remove them from the doc. I attempted to clean up the doc, so fe= el free to make any adjustments. *Call Details:* - Date: Thursday, 5 March 2026 - Time: 16:00 UTC (agenda begins at 16:05 UTC) - Find your local timezone here - Link to Join the Call: https://meet.jit.si/XenProjectCommunityCall We plan to open the meeting room at 16:00 UTC, but to allow time for switching between meetings and handling any technical issues, we=E2=80=99ll officially start discussing the agenda at 16:05 UTC. Want to be CC=E2=80=99d on future calls? Add or remove yourself from our Sign-up Sheet . See you today! Cody Zuschlag Xen Project - Community Manager --00000000000079bc3b064c455f85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

My apologies for the late no= tice this=C2=A0month, the short February month (with some personal PTO) mad= e this one sneak up on me. Today is March's Xen Project=C2=A0Community=C2=A0Call (4 pm UK time).

We=E2=80= =99d love for you to join. Feel free to participate or just observe. This c= all is a great opportunity to see what the=C2=A0co= mmunity=C2=A0is working on, align our various efforts, and share upd= ates. Everyone is welcome!

Preparation:

Call Details:

We plan = to open the meeting room at 16:00 UTC, but to allow time for switching betw= een meetings and handling any technical issues, we=E2=80=99ll officially st= art discussing the agenda at 16:05 UTC.

Want to be CC=E2=80=99d on f= uture calls?

Add or remove yourself from our=C2=A0= Sign-up Sheet.

See you today!

=

Cody Zuschlag
Xen Project - Community Manager
--00000000000079bc3b064c455f85-- From xen-devel-bounces@lists.xenproject.org Thu Mar 05 11:39:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 11:39:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246490.1545654 (Exim 4.92) (envelope-from ) id 1vy73d-00033B-Op; Thu, 05 Mar 2026 11:39:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246490.1545654; Thu, 05 Mar 2026 11: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 ) id 1vy73d-000334-Lk; Thu, 05 Mar 2026 11:39:57 +0000 Received: by outflank-mailman (input) for mailman id 1246490; Thu, 05 Mar 2026 11:39:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy73c-00032w-3L for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 11:39:56 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 074ddb87-1888-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 12:39:54 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-48371119eacso94730885e9.2 for ; Thu, 05 Mar 2026 03:39:54 -0800 (PST) Received: from [10.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-4851fb33815sm70708765e9.12.2026.03.05.03.39.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 03:39:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 074ddb87-1888-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772710794; x=1773315594; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=bUMNP0bb2H2lV5/sen2uEfAJ3WmTTIBJ029R1MIX8T4=; b=EH+RyDYAUSow31ERwF+WorG76syF0F0Sq0w2jFPsu9wyoKQVhvsHr9Pead5pMa0dgy +1Ts65AYaKC0smvPyEpMYkQbYrQDdvPd8w/FhkbARcG6Tb9l1silrW5ceovBYk87U9uD 5Yv7udmwRicls+o5LLNm2xONg5ysvtzAATxd2IGUDkMKc8IqHP+64BAA5um3pS4ruYLa ACjmo/cjVZqipPq/z8aE8HmB7qeSbAj8U2Mqa5cfhHxSzQwr5XF/wOcEDqakPhKWOTvb 0Yt5xHQGwixwBLZqAJNWi+S6Mp/5K5Ivqxai8Rp3Z/yZJb11XpFaAIdAW8Wc2iHdk7bB xJjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772710794; x=1773315594; h=content-transfer-encoding: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; bh=bUMNP0bb2H2lV5/sen2uEfAJ3WmTTIBJ029R1MIX8T4=; b=T7nyd5dtMzgGz1mTGVgiobOoR/7YhAG6VLLGIfIqQajiqp+0uIYrw0H5psuRi8u2jT T8DcmFHaDwlRoCciQEpOgQaQTgexDSb8ba5JRTGOh4jrNfT0XPEDjzIBYEC4e72NynxR G2JdCzVESao297VfRLpmAlcUnfVIrnHQGcAoHaasxJHQpsHuuqVGVl+TFlTtjKT0I9Qw Ws9DBfC2ImmXoFMhD3MPtHC8oODLo8JeAmAe6XThkDYwStEG4fAog6MFg7gVC5XPkp7l bL5p1PtbHw79lgQt2Zm0BpTKtp3NV+LM2hUNCF1LObcZTASGhOomjRYFd13g/gobOTL9 bJmg== X-Gm-Message-State: AOJu0YxttKZmlFqYgaZOvOrklnutgxqnX78CILAvoyH6M4BhvNW4wFMq +lIVvbjgyXZKuPbV0XwhuwouAC68PBcx3KLd1Bq0QAMGVDDzFhBVNPzEwnuKO/UHjw== X-Gm-Gg: ATEYQzzDPqWfqFCMDntA6/b3xqy3ZuYB2Jg6vir+jfSbP1S/mbg8aYngw0gegfnyDXx 8QPmZwkeSdw6k0SAE8n5875SjAFDn7WUkAQu8/L5hUJJBRL6vTveQQ1pd1pO9+uNSWBra9jOZye w4FbIsR4ewLosoWTdQmE7aoCjdjlg6Zs55+jBrGz7mq3/619fxrUTEEhUA6xJxKfpn8Sjv6ev1j e5BVDecEiO57qqxQKrTd47763ERlQya4PV/GzYOHfjFw5tLRbxVkDYLexNfsoXkL8RtfYFi2pD+ 4dpNSpUNHFiooA1zCD2XWpAnM1MHN+RmOrcW1tIa1KqURC579LXjWdVc/63G6VeVM9O9umhXF+c yPvFKzk1/ITefqU0GMcGgSGwkUoEiBdt5bEovI+cRUdaDFyOFjGSUFxLvvOTn+P6I1oW/+m9Cb0 6aQy3PmcUCsXkIq0SLXuBerqwrhaEz2SkCp6h2wuS3I9ll0p4QUrrAEUOE8BT17NtbevB+FE5Nj SJDAYZY4bWy+7dT2b0PgP71NA== X-Received: by 2002:a05:600c:c8a:b0:477:79c7:8994 with SMTP id 5b1f17b1804b1-4851989f6e3mr88198745e9.30.1772710793790; Thu, 05 Mar 2026 03:39:53 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 12:39:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2026 11:17, Roger Pau Monné wrote: > On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote: >> On 05.03.2026 09:50, Roger Pau Monné wrote: >>> Since we have the parsing of the ACPI related data done from dom0 it's >>> not only Xen that needs to support the feature, but dom0 also needs to >>> know how to parse it. Or we just assume the driver in dom0 must >>> strictly know how to parse data from the features enabled by Xen. >>> >>> Maybe Xen supported bits should be & with the dom0 ones? So dom0 >>> would set what it can parse, and Xen would AND that with what the >>> cpufreq drivers support? However that would be an ABI change. >> >> What cpufreq drivers are you talking about here? > > I was talking about the Xen cpufreq driver, sorry the context was > confusing. > >> When Xen handles P- >> state transitions, the drivers in Dom0 would preferably not even be >> loaded. That's what the forward-port did. Upstream they may be loaded, >> but they then can't actually do anything (and they may exit early). > > Well, yes, on FreeBSD I simply overtake the native ACPI Processor > driver with a Xen specific one that has higher priority. So the > native ACPI Processor driver doesn't even attach. I think Linux is > slightly different in that it allows the native driver to do the > fetching of the information, and then the Xen driver only does the > uploading. > >> Coordination is necessary only with the ACPI driver(s), and that's what >> this function is about. > > I think Xen also needs coordination with the driver in dom0 that > fetches the information from ACPI? That's what I meant with "ACPI driver(s)". > It's not only Xen that needs to > report what the cpufreq driver support, but also dom0 would need to > expose what it can correctly parse. Hmm, yes, strictly speaking we should tie setting of respective bits to Dom0 having uploaded corresponding data. The order of these operations may, however, be at best undefined (and possibly be well defined in the unhelpful - for us - order). I don't think I see anything we can do about this. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 12:31:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 12:31:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246528.1545665 (Exim 4.92) (envelope-from ) id 1vy7r2-0001yj-Hx; Thu, 05 Mar 2026 12:31:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246528.1545665; Thu, 05 Mar 2026 12:31:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy7r2-0001yc-EE; Thu, 05 Mar 2026 12:31:00 +0000 Received: by outflank-mailman (input) for mailman id 1246528; Thu, 05 Mar 2026 12:30:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy7r1-0001yG-06 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 12:30:59 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 28650ce5-188f-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 13:30:57 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6574.namprd03.prod.outlook.com (2603:10b6:510:b9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 12:30:48 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 12:30:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 28650ce5-188f-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gnPka8K5FSteA72ZHnOsZm+EXKf0l7weB1vSJXD7uKYs5y22j7s9i9luTe/lzGfM+0wVimMu1WjGrZxaBPylgOSwFlkXQk3jz5HVIBOd+xsAVQzEa9Gd/s4i4o1zVxRmjo/+Ul/0Pa+Rswbpkxug0v92gG+flMsFDLNoJsnjkbNtUNfvI5FaEqyU428zhRDhg98PBrpCxvGyZWQROOSfi4pa3Uy6wlm2dgGEs8xB14GjKiUf5wyWx/NQq3NxDHwikVvl6XDDuo/QGs3sQgspeFdQmtv/MXMtL8yyf/yLVFKcTcew5h3KVk7AGWMgqKyySzDnxFQGJlDwyo/gVDyNIg== 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=3ltwjFMFfeRmyH6Gs179sHmeC8jGqbOZYAFzKBCMILY=; b=HeEn90tI3L7Uol/r4jPJCytfAfDlfJ0KL1GQAmobf/QxAksuDzqgaA7xiSMxicDwvN8WAYIMzndaDRDxx51lU8MI6AeMkSMHzhEN1yOg14mJRpRAKkr2Yg4RocKuVmn10nP+PCKJParZmHJ3mB5xmDpHZNU/7McM9Bb/f6HDMWprkuBRI9DUfZTlXNUw8s4uwQvHkzcjsZQQFXJMyfPL60jmIZ4FRBCoiXxAphLK9s+qTLajo9QPOoMypk313uMlIHY5YqNXGFDdT7RF3bRP2At9aBKKdX8grbIXYmjLUs0Y07NClh6W2n4PrSrncTjoC0uHWxAX7d8yHR1Cl1TrlA== 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=3ltwjFMFfeRmyH6Gs179sHmeC8jGqbOZYAFzKBCMILY=; b=bVtA6fof+xZEj4QKQyj216pzPc66/CRN0UKi4sUKhgA7WWRFDb3Df0mzjWXJvOFftCLibwBmcKRnA9T40gVNwwUEAojkL4+s+ZlmMtZbmhTPt+mSDOeDs39HsSDfEfbjMB5FrLDQ1glbpvgKghGmuLOGpYlT73167XXYofFN/DA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 13:30:45 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Message-ID: References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA4P292CA0004.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::10) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6574:EE_ X-MS-Office365-Filtering-Correlation-Id: ea84c95d-8a93-4776-3b9b-08de7ab30800 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: tVc0M3iSaqBNgX8iJyqMrOJWWI8xIWv9+IhUuiNNDibv+oAw6HoemaZDuGimtPpC26cNCYvf7yLrStzeNpn+Q8IZ8A4SHmqejYiLHoFVVdcQ8RNO3QGdoyqRKx+UMNswstrzuAIPG0Yon8o79dXJFG/xgg07OiDYl90wlh0XD/va7ouf3VnahJolyEEHRqF7aXmmutCOg2ILVbzrnjVrLLXabD9h5eM2+qFLfsN5t6q8WCEbtiZ16FlAWmjbo7rbrH+sVaE8GwMNA305K2YfnnWgR9lt8RB6CaP7gla5o+Na9Dlqg2aNWvCdoH1BPom84SXIHgqV++Sk9RpGBe0B8ycq29yILrSTY1d/+ykomA58NcW3QrPa9S7uW23xnBNI6ZeMzDF8ZkNOavfNvky/dSwLHc0UMLNh7LgBVhtTYyofHTRGQOobd468PrDMxvK3iE3j33ZgqDf2MSsfEWKuToxWddGyv/E7thmaDkt12X2D8egSGfhyrZpusAQ0k6n6pE8GNRo9eKChP0bdTSX6p0tmGdc0A1GwgBYM9U2K5kHtqYNSt1FrMuBTPp9Xxa+lnfBDm2rNVYNSpX7LZ9JYKsmgwNWAWfxrcwp2cabrSeNRdkHXXzx1k4I5N4U5tuIOrjGeZGbpbuSlVHBdzFhQb+5TFupd2Oz3k9zD0u8ey880QJU5I6c0JApoK8TBfHSwrw3az+hpQyHQKWqgt38Oxv0uOjKXVMtnuaNlBWAWCsM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QWgyUFJKUDRIZGdoaFJPQnVmZ2kwZFFWVkliZ1FFMHRoZG56VkRDUVFhUEVI?= =?utf-8?B?OUxTZFFGWEUrczZtaFRHKy83c2RRamhoeFRWZGY2eTB3M24zS2NoZXlML1pH?= =?utf-8?B?UzJjQzFla1Fxb0RTcVZZK3dlRjh6NmRRWjlad05hc092dEI5NGpoYkVWTFBu?= =?utf-8?B?cUhocmtsZHBUVHVrcllDR2RVbE40czM3OTRSMy9sMndzcUgzR0YrMUQ0aDNI?= =?utf-8?B?eXM0MkFEcVRuQ0R3VVBaS1hLb25pT09aQklTRk0vOU9SVzFZbjMxbFVmODVP?= =?utf-8?B?d0Frd0NjQUMvVW43M2JrSk96ZGZiUmE3ZDNCTFZzZlJ6blN6OExUVGNZOEhn?= =?utf-8?B?NHhDVVo5Z2hJblZTbDlITjJxMEZzbk1MRm8vUWFpRnQ1QzFJSzNtUjlxYnBL?= =?utf-8?B?U3UrY1FtV2E4RDkxeU1aTDJXdTYyZHFvN3I0MWdrVTRheUtHVE1aOUFkN2Vk?= =?utf-8?B?NTVWSWVnYzFGa2pwQ3g1NGdZZ2M0VmhWdGRjeTRYOWJtQ2tPQnZPL0xDMmsv?= =?utf-8?B?cjVvU0dGU3N4NEtHUDVvQmlIVWt3aEJKRmNFWmZrNlZYdkRZM3p6TG5IeTd4?= =?utf-8?B?M3liUDlkblI4cHdZMjkyTnc0VERWYjQxcXhNMm9DNTdScmVFUjJML3hhdldV?= =?utf-8?B?eDYvaC9GZ1V3SmxiYkExNVAvRUM1MzM3Z0h2Uk5VaWF0Y0NxdGRtc1ZkYndP?= =?utf-8?B?d2ZmcnUxMEtJaDJKU0tpZ3UxMVFWZjNhM1MyeFdqTzJpbzVYM0Jaak1USm5p?= =?utf-8?B?dGRRMXp1VVh1R1g5c05qM1VxVEVINEdJZHNxaUV4QXNNd1kzWVMwSG1qdXMv?= =?utf-8?B?a0xxcnlCT1Njc1BWNC85a1F4UDBZZmdSQkc3d1pxK25JTjhIL0xGeWtkK0ls?= =?utf-8?B?bkJhcFN3WUM4QTN2ODhkdnpmYjQ3eDZJbDlhWEZQQVRxandPQ0JkRHVWTnAx?= =?utf-8?B?Y1lXdGlzVkhWSll3OHNyWHF2eUZjTVJidlVWdEV3MTZYcWN4UzJVSGlwNnp1?= =?utf-8?B?djdFOEtaYzdhNWlReEVpUnlQbmFFR1VoWjljRTFYQjNYYVdQbEZJM3RoUDlG?= =?utf-8?B?Tyt4WGpwS0RuRUdTWEJNM0lpN3QwNTdRdUhMMjhIWFhNd2dXN0hoZDV2UDlt?= =?utf-8?B?QVVHMThZTUFUQzFqRGlUZzRKRU5CMG1rSElCNXhUcGJyT1FKRC9DSm1URklR?= =?utf-8?B?NEVyQnNXVlB5MG5xUkc5eGhKeGZ0aXhPa1pWQkdBMFNMVTRBUVk4alFpUFlR?= =?utf-8?B?ZjVVNC8rbjNGTCtSVUwyZ2EyYk53U0lUZUpiNjdWTThLR0hVV3J5SXN5endU?= =?utf-8?B?K2dOMkNpK0pLdkhKVGxtYXdraURWcm1VM252UGZSMEhRVUFPS1ZFZXY1K0pF?= =?utf-8?B?ajUxOTV4T1BjbnVkejZVbythTzdWMFhydUdYdUtoQm0ybUtnRGhwbUpmNStI?= =?utf-8?B?OE1hV21LNTcxYzhJRUhnOE1Rb2RUaFpuRVFNZEtZbVVXeFovczdvbm52Tnp3?= =?utf-8?B?MUFZMnp4R1FScjliSWRsRVY5SDBMQmpqQVNDL3lEMVFTNzVMa3VBRFFBUlA4?= =?utf-8?B?cS9FQ3RiTzMwZmY4RloyWUtFOEVNUjRNaVo1NWVOY3kxbzFibXZwT2xiaTU1?= =?utf-8?B?bGdSTTBJM1hzYVBWNmNkV0tMTXhtMi92L0hSZVRNcjg2Zmw3bHM0RnpLbFNk?= =?utf-8?B?UGtUWHQwblFKcXdiUWtydHMrOVRINkhjTFIwMXFOd1BJNW9JQVN5MG5nLzRG?= =?utf-8?B?MWdXK3MvV0hTdGNybFJEcEViY2ZoM09aaURwK0wyV21qd252VXc4OXpkeFJL?= =?utf-8?B?TzJxeGM5emxmcU5JSThwaEJOakNlc1cvcC9kODExSW9ySWt0ME9mWUpob1Rk?= =?utf-8?B?NzA0QjVpOGRjS0htam1MWXVDZGg4SDBoVUxSVmUzdVQyTDZHMnlDOHpQcFhn?= =?utf-8?B?aDd4QkpZM1JRMkwwb3M4Wm5PWVlUdTBwcDY4QUpmc2RjVTM3eUJ4ZkptaGpo?= =?utf-8?B?WTRnUzBWeWw0eGk4YlV4cFpWTXhiOGZuajFrUEhKUTlBeVpOR0FpN0NFZnJq?= =?utf-8?B?ZU14R05QS3FpQXV2ZVZ1NmMrd2Yyc0p2RXcwbHZXcXMzYnNHamN3WWlaMEI4?= =?utf-8?B?LzJJNUdRUks4VHJ1VWMzaGhPS25XZmJlMytyNEpnVjlNNjdHNkY3T3p3Uldt?= =?utf-8?B?ZEIzSnFsKzJBOW1FdWZMc0ZFK1I1Zm1RUkRRRWNGVW1ZTExuNDJScVhVQzBp?= =?utf-8?B?WGxscCtFUXFrcXNhdGU2S1JnUUZiazJyUHFST0NKWEFxUTNORjNtTUdhY1Za?= =?utf-8?B?TDduVWJtcHc0WW9WSnRMdnA2bmxlTnovdmhta1pSTzNtNUJiNVBGUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea84c95d-8a93-4776-3b9b-08de7ab30800 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 12:30:48.6796 (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: glhJorzCVFZVBm3OFdnfGtal2Y3RohcVBIE8z0DLN6jv3d8JtqBTKseZWMdNXw9Dl9CoNg6dCzh6YDSAeuvGjg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6574 On Thu, Mar 05, 2026 at 12:39:51PM +0100, Jan Beulich wrote: > On 05.03.2026 11:17, Roger Pau Monné wrote: > > On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote: > >> On 05.03.2026 09:50, Roger Pau Monné wrote: > >>> Since we have the parsing of the ACPI related data done from dom0 it's > >>> not only Xen that needs to support the feature, but dom0 also needs to > >>> know how to parse it. Or we just assume the driver in dom0 must > >>> strictly know how to parse data from the features enabled by Xen. > >>> > >>> Maybe Xen supported bits should be & with the dom0 ones? So dom0 > >>> would set what it can parse, and Xen would AND that with what the > >>> cpufreq drivers support? However that would be an ABI change. > >> > >> What cpufreq drivers are you talking about here? > > > > I was talking about the Xen cpufreq driver, sorry the context was > > confusing. > > > >> When Xen handles P- > >> state transitions, the drivers in Dom0 would preferably not even be > >> loaded. That's what the forward-port did. Upstream they may be loaded, > >> but they then can't actually do anything (and they may exit early). > > > > Well, yes, on FreeBSD I simply overtake the native ACPI Processor > > driver with a Xen specific one that has higher priority. So the > > native ACPI Processor driver doesn't even attach. I think Linux is > > slightly different in that it allows the native driver to do the > > fetching of the information, and then the Xen driver only does the > > uploading. > > > >> Coordination is necessary only with the ACPI driver(s), and that's what > >> this function is about. > > > > I think Xen also needs coordination with the driver in dom0 that > > fetches the information from ACPI? > > That's what I meant with "ACPI driver(s)". > > > It's not only Xen that needs to > > report what the cpufreq driver support, but also dom0 would need to > > expose what it can correctly parse. > > Hmm, yes, strictly speaking we should tie setting of respective bits to > Dom0 having uploaded corresponding data. The order of these operations > may, however, be at best undefined (and possibly be well defined in the > unhelpful - for us - order). I don't think I see anything we can do > about this. I'm afraid it's the other way around, you need to first call _PDC, and then fetch the data. As I've learned the hard way while doing the FreeBSD driver: you must call _PDC before attempting to fetch the data, as ACPI will modulate what gets returned/is present on the Processor objects based on what support the OSPM has specified in the _PDC bits. Anyway, not sure there's much we can do now about any of this, it's too late to change the interface, and what we have seems to kind of work on for the purpose. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 12:38:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 12:38:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246547.1545674 (Exim 4.92) (envelope-from ) id 1vy7y8-0002cC-6m; Thu, 05 Mar 2026 12:38:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246547.1545674; Thu, 05 Mar 2026 12:38:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy7y8-0002c5-3y; Thu, 05 Mar 2026 12:38:20 +0000 Received: by outflank-mailman (input) for mailman id 1246547; Thu, 05 Mar 2026 12:38:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy7y6-0002bN-QS for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 12:38:18 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2e0851d5-1890-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 13:38:16 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by PH0PR03MB6574.namprd03.prod.outlook.com (2603:10b6:510:b9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 12:38:11 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 12:38:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2e0851d5-1890-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=D8ob6+f2u5XpFae7c/Cxv8/zwV2ejGccWY+IlERYNGyiMnrVN6wW10pc1wQrFRLA27W3Ot73LbnNh3Hi+yC5p2X67sQnXKw4W6MERiLPeOCR7Ulgh1TWUvJuwa0fuPoVMXObyMgYENPkEIxa8XQ4jhtmqtLPM61U1NqTXA9V1D/C21jkKJbVDVKlgnNN0C6bBwlQZk8L7IMUDnygEEWyrQF05gfmzkyT8vi1iLk34mRiNyny8GnS8K7Ac0FZh+x6OmcGN3bj28J0aGBajju/x/1V6oo3Bqh+6J50lFfsFmOSXZIv0PHyeAGN+7Xq8KJeK9cZAXXobHmxneZ9OlOr4Q== 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=SOFugAuHG0luGWTzvb5EmgIacu3CrP0wwFuP+xzGE2g=; b=cHajjt4sjGC1LleYljOZOyTzbNN/GV4P7GoIyO3DHajO9pUXwhc4TQJHewo2CZ18zfaOx6WO0JggF2xRoiV1AI8Xg0zAXnczjiTi4EzrpK1y3CKfgostma/ds5zgjufAtolyaHm5yPD4tH13rw9m3aN1rGmiolzn5fIf1NO0WyH0VOKxKGYH7P3SbfTWJ7iCw7YiG/CJ2k4oKTpnaeGkXjQP8zhOGmv3IKhGIjn7N7m7X8vB+4yWq3wAibLUNgxkMKhB+X38cu6YKN+XtbLv9PnV6GNdApd57awRbzIGcTiU/aqOISYwK9XTb3+yuz8koDGc22wnoeLG2ixJDgBvHA== 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=SOFugAuHG0luGWTzvb5EmgIacu3CrP0wwFuP+xzGE2g=; b=0rquEotU4sucWHjl9Ahox8LbLBIgPeU75mkuwqSxgzk1V3SgahznKYPUIxR2aC9PxHuypp+kYTQjfTENncxztS5YNmWC9spqBGyVZXnQQnVFily0UzPX+sq2PBR8JjUiwthJNS1l3b3EPWB3iuV0IpOMX80g22c2l94V5Xy3lpI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 13:38:07 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Bernhard Kaindl Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , "Daniel P. Smith" Subject: Re: [PATCH v4 05/10] xen/domain: Add DOMCTL handler for claiming memory with NUMA awareness Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MR1P264CA0207.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::7) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|PH0PR03MB6574:EE_ X-MS-Office365-Filtering-Correlation-Id: 9651cf4c-e254-438b-9165-08de7ab40f95 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: a634TpC0mRkF7vIq3XAqkK77Ws8xZCmmsXOx7aAMx2tO3BoFiaGNTZ/YDSWcRwsZ7sbb4E9KtKjpH4/pYhHi5Mtj3Nk+EV2ozcBUKMy05Gc/rnd4Ue5IRb5/3AQQNuy6QBjv+yFADuPlEzmcyHw+Hl763AgLEhexpd9YRhxiwPOyx0QFUBqAVHLxkQjZ7WEb1Jn0Wijl1szsLtnqP4zOFu4Zgh2QpyAx8mZ6OHVO1aLofu9qIzYZw2wXsLEBwufiIWCM5nTT70/m03FKViCU5SeJfomRXnrjWfMF5wd8FYM7iBntQOKKWOUv/K3+qH1egRlg3A0Ti3NGgEbLSI6lgay4QSkO4Knw+KaNp6LvXQLJoBnKJ3HSMXZFfMdcWsAZevtXUaifIS9BW//9B7zw2AOlZoSviQUB5FsheBtX4uwfUYX5a30CxN3sVH4wUj8QpzTemrxSS8Pxsueq0bgn6lS29oGgUfRjpOSKKCA3rv8XdCA/b2M9cRN7HmzBq5setr7pEC9Zw8ZufstB1Fc9O07cFR6ETwKEgkgbOnbhTtsvCd/h1f8ThHCqBVMzlkZD+GVDNc6cn/lmisM9984q0Z+T0sYuNq3otlEbIfHEEodBlykQJr26dKO5iVPGfHVyEvWJv6IdMN69NvOB0Ga1mGPZC49AQtM3xpMTBiAzDC2kaHJCiCNV/AaLaQzr0HcA094uaeERBFRHLGOoYU3ohea/ydW5lCQXkWDtewfHOFc= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dVNvTXd2UHQwWVRaU3FXYldtcWtXUmh6aFAyMlE2aDRWZnFSR2tjbm1sMWNn?= =?utf-8?B?alg2R0NzbFhLYnJuRjlxdzJFcmRYcmFCemdrR3dCN01NVTZHM3F4THQyNm9V?= =?utf-8?B?allVemhUSGRzMW9IeDJ5WmZ3NWFQS25BdmtsUUVkckhJbDJaSS9RTEh6L2NL?= =?utf-8?B?RzhlSkZPbXErZjVZeGY5K0Q2NFBJeVBnWGNUelNoMzBSZUNyNmJNZTZxaVYx?= =?utf-8?B?NkU0RmlPUjMvYXR1b3lTamtCeE9LRjd5cGV0b1RsM3h5K3NmbHByNVhJRnNt?= =?utf-8?B?b2xqd0U5SDBFU0locWZNNVZGbkVMREV4NlpXZFUxODdFeFNhTk9HSXBQTXFZ?= =?utf-8?B?K2RKcURDQmNEUHhKSDBWTXE4UHNXUjEzdy81eVJhUVViS0ozaWlqdWlIYWlh?= =?utf-8?B?Z2ttem5kazJqTEdTUVFyZTIvKzBpd2N2eXZRWUEzZ2xzZEFVd2ZRbjMxd3ZI?= =?utf-8?B?RTNLYmxPQjdXZzMxUGZBYXpMT0FGdUxZOWxTR2s3K2k1TE5YR1loMHJyVDA0?= =?utf-8?B?UE9rL01JNjNGRjcxbUh2Snk0ZTM3bVhpeEhOZE1WcElSMk14MDE0Vm1DRE12?= =?utf-8?B?aHE4NCt1T2U2K2puQURhTHoyM0dxZlFJRjY2MHl6WGZ5Y05mbnJXeW0wUEoz?= =?utf-8?B?NzJ6bWRvazJLRkpCOURJNDY4Wll1QVIxOXhnb3lSa1Bha1JxMVNZT3BFMzJi?= =?utf-8?B?SWx6OU9HRFNwSEFTVExpWGJ1OFF1bnBFY1NadTJtUU1od05VdEJXbU0rTnBw?= =?utf-8?B?K0ZvR1dFNkppRFBFd3NJU0Y2TGpuZDJDbjJRUHArcC94Q005SkI4WUpWdjQ4?= =?utf-8?B?M2tSVndwRzlTbGYvQ1ZxaDljZlF3WTgrUDFESi9rbi9iQkVIN3lmN3VQU3pG?= =?utf-8?B?QmFLL2JxaGJpOFY0K25pMk1ZM3M0d20rVk9mWFM2TlFvUFgzcGc2UklnSm80?= =?utf-8?B?MjhWVFFaVzJyRDNCL0VLZWVxY3NLM3FrTjlwNUFiQVZleEZ4MW54NUtWNGFJ?= =?utf-8?B?U1hmaHc2dWhzUWpEeDE0U0JSc1RBajFTTjRTUjljcnYzR05KY3FpOUNGTFJj?= =?utf-8?B?YzI1dmp3eHhCT0FTYjRrYjFvR3g1MUpPdFB4YXFYY1c4MFdObUQ4SFZzRnRo?= =?utf-8?B?Mys4Ym1yUmg5dHJxUXppMVM0czlJRVdISGJHMWxYaUJheUVCOE41ditVTGdJ?= =?utf-8?B?M2NFRE9MdU56cmNubkU2QXVEN2JXaFVXbm8xbytEK2EyUDhSZWtjeVQvbXph?= =?utf-8?B?U2lGL3B6WkhEK3lwMU5hdUVGZUxmMys4Z25HcGFrcmx4UDJsQzIwTW5UV2Zx?= =?utf-8?B?U2Z2Z05xQVQ0R3Y0ZHIyTGFJNmhMbXZZQ2pkS0hGbUVmUzg0bkZEZ0JQcDQ2?= =?utf-8?B?RnNMVFFpOE10bERSOGJBbzNFOStKdk9hcEZCU20wQjQ0SXd1dzk3ZURiK3hM?= =?utf-8?B?TDdoN1hMMVRTMktueFpSLytqTkszNUJldm9mYndSaUtnTmpDV3NsUGo3bmV4?= =?utf-8?B?LzNmaE5WK29LM2pWaXpKMUthZUFYNnlYajZrL0JEdGtGNTY4cERmNHFYQ3lt?= =?utf-8?B?bVo5U2lkK3ArdWt3em9PcUhoV01GR3NPa1pqZTQyUFlQd3BNWFBtamUyRkI5?= =?utf-8?B?NTRRSnFEYUF4aHd0UzhZSGg1bG1RQnlSUHdnODlpK2M4a1RkTlMrWWhKMnF3?= =?utf-8?B?Rk4zbnhmN3ZyaG1FSlNkR2JuL04xT3V6MTZYR2VtZXA1dXl0bTZWMkNJa3VH?= =?utf-8?B?VGZEM2FjN29lbFV6R3F1cTRscW53VzArZk9CR2MyMi9oY2JyUjNGVDdzZ3VZ?= =?utf-8?B?eGRVRHZTNlk4a0l1SEZRUWFBUHpZcFNweWU4dHA5U3VLSlRTM2FIN0hCSkp5?= =?utf-8?B?UnArOGo1Z1BZYkY1L1NTRHc1S0ZqN1U0ZzZYcHNTTVVTS0tFSE1JR0FHbmxR?= =?utf-8?B?YXVabjFvaFJkcDF4a2d3MnFHNUNEcUR5Tm1ZcTBxYWhIRDVBZWVIN1kramxs?= =?utf-8?B?ZDYrVk5JU0liWE5xa1pOZ2xBZ0xJeFhQeFJ1NUFZUlFsbXphNjhBUGxwdUV2?= =?utf-8?B?ZnZ0T0dwUVdSUkp3K0VDdzQ4Z0Vhd1kwcDJHTXBXdHBzUGh3SjNUcjVFc0dZ?= =?utf-8?B?YmJ0WlVlWUhyYVkyNkNITU93Z0F4dHJ3SmdORFFwM0pDQ1RyZG9SUkNVQnVi?= =?utf-8?B?U3VTWG1OeHZ0bDV2VU9XTGhUS0ROMEc5andCdVVtSW1oRlp3UnZobjcwQS9x?= =?utf-8?B?Qm1YLzA3ZWE1dGFudmJObVExQlY0S1NnME5xSndETDRRQThzR1VTb2l0TExS?= =?utf-8?B?U0RqQ1dmd0wvNmpvVmlPOWttWnFnalA0ekFiaWtmUHZNanFZYzBuUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9651cf4c-e254-438b-9165-08de7ab40f95 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 12:38:10.9313 (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: GFafqZjd5Biz66yYg1r1SqRQcNdALqGXuDjLCE2X4Y8EMWUCpMNu9tBwzYgqlRWaMXYIEazxa83Dmi3G+esjhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB6574 On Thu, Feb 26, 2026 at 02:29:19PM +0000, Bernhard Kaindl wrote: > Add a DOMCTL handler for claiming memory with NUMA awareness. It > rejects claims when LLC coloring (does not support claims) is enabled > and translates the public constant to the internal NUMA_NO_NODE. > > The request is forwarded to domain_set_outstanding_pages() for the > actual claim processing. The handler uses the same XSM hook as the > legacy XENMEM_claim_pages hypercall. > > While the underlying infrastructure currently supports only a single > claim, the public hypercall interface is designed to be extensible for > multiple claims in the future without breaking the API. > > Signed-off-by: Bernhard Kaindl > --- > xen/common/domain.c | 29 ++++++++++++++++++++++++++++ > xen/common/domctl.c | 9 +++++++++ > xen/include/public/domctl.h | 38 +++++++++++++++++++++++++++++++++++++ > xen/include/xen/domain.h | 2 ++ > 4 files changed, 78 insertions(+) > > diff --git a/xen/common/domain.c b/xen/common/domain.c > index e7861259a2b3..ac1b091f5574 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -268,6 +268,35 @@ int get_domain_state(struct xen_domctl_get_domain_state *info, struct domain *d, > return rc; > } > > +/* Claim memory for a domain or reset the claim */ > +int claim_memory(struct domain *d, const struct xen_domctl_claim_memory *uinfo) > +{ > + memory_claim_t claim; > + > + /* alloc_color_heap_page() does not handle claims, so reject LLC coloring */ > + if ( llc_coloring_enabled ) > + return -EOPNOTSUPP; > + /* > + * We only support single claims at the moment, and if the domain is > + * dying (d->is_dying is set), its claims have already been released > + */ > + if ( uinfo->pad || uinfo->nr_claims != 1 || d->is_dying ) Iff we can move forward with this single node claim implementation, the return code for uinfo->nr_claims != 1 needs to be -EOPNOTSUPP, to differentiate the hypervisor doesn't support the operation vs there's an error in the input parameters. That check needs to moved into the previous if condition. If the domain is dying we could also return -ESRCH, so that we can differentiate the different error paths from the return code of the hypercall. From xen-devel-bounces@lists.xenproject.org Thu Mar 05 12:40:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 12:40:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246555.1545686 (Exim 4.92) (envelope-from ) id 1vy80C-00045R-JU; Thu, 05 Mar 2026 12:40:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246555.1545686; Thu, 05 Mar 2026 12:40:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy80C-00045K-Fe; Thu, 05 Mar 2026 12:40:28 +0000 Received: by outflank-mailman (input) for mailman id 1246555; Thu, 05 Mar 2026 12:40:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy80B-00044P-M1 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 12:40:27 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7bbb9e62-1890-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 13:40:25 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4834826e5a0so91034215e9.2 for ; Thu, 05 Mar 2026 04:40:25 -0800 (PST) Received: from [10.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-4851fad27e6sm57013955e9.3.2026.03.05.04.40.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 04:40:24 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7bbb9e62-1890-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772714425; x=1773319225; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=fjpoR/vQ/5VemNieu/EoTnYqrKHY2G7PuqHzs+F3a8c=; b=OniBUicpuSc9L1JdWXYYqYsq6Fq/OCNN8Mfa11EXD1WwuVL1DfynbtVfg8e+rbCI78 zlS2/yoS2jO78K4mwNNW5eX7D6XzErI6Wucg5d1v8ly5IaUJxMaO6ppZKzu8kYD/Iy3W b3QSLpttNI4FG2XduHlCyhsmcud6Fhc5DrE7wMVVFMm0FLrvgTTe2skoe1EfPPYm7pJX /k7Yv+4kFR/wyLSTfmGW5S6PUdG5gUhrTDR3VOR7LiMlsedZfMrdTivUW3Z+a9OE6Vgi R2oWXMu27g33hjW8qBexVwIVMHc4NEpxUHZJ96VELeDjW88Pzur4EWO2OXyG+OzQ7/KI fImQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772714425; x=1773319225; h=content-transfer-encoding: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; bh=fjpoR/vQ/5VemNieu/EoTnYqrKHY2G7PuqHzs+F3a8c=; b=A0mfbAWv66tzwgZ5XyEyZ7AMCSknFGmK2sSZiCSSyaTMu9mT3lpwmCJWgvil3reHFT e1BJUAjcJzO60P8TXW1zLDo8gk6jmTSWpBUtqJ8dyElUAZebGK9KNbIa6eOEaFfX0foF mnBy7y7lJlXVv/BuaP0aMjP8QHjqWOzLDATfZGkVpYkmeFzqVWhXUyw+8yBH5+p4TjA0 iROKWzvRB0cI/hOnBzCqz13p6lOv5WuGykIwtFl4iV7P4L24NubpJlDH8d2OpEZ0Rdvh oVKtmb9o1zjo7i1s5gdAMTUvMQAiN0qAK4ZMw1meFjGdmZqLFQBQkx2vdbvxzx5zIr+j +8wg== X-Gm-Message-State: AOJu0YxuTyLBBHJ3iPPKfHHUCVIys4s4dJu8zhoqG1w2LC2qHovGvh5C clVOO2aVgU4u3KsdWsjdoo7wbDXExJKxfrsDDepWMznOS1ZZsMN/MdzajEaRgv1pJg== X-Gm-Gg: ATEYQzwXteTI/1xHvIWkcRy7eevieDib6HyeV7bz/4dhAswzB6HtHvZhpGBd8iRRJxx JLsh+mAuB31zwEvQXC95Sf2LiXchVKFaOROjxcAiKNGjygKVeBqd/ZQfBr1Wpoh8GfeP2RZy9No gzfXtJ5o5qpHBfztRltKpAzgtwB1AwIeZJG0bX0fl8mEw93Tm8CP1EdbuBx0ti0Q5tYN6SEj99T eksh2B2gOpT3uKpfagaszhC9GPqi8ASyP2atc8ceUqJhfFgemn/ycZF3HoZvgmyppsxTI4H9iEH +sYDMUUNdRxjdzLhKaUkoHnaxb0eYUKGCvHcUJRSeZuc9tL35b4nEm1B2I/3k40SYk6g8GCQdIk Pb6ZmsGqyLJKjvf8Mu8KNPKi9HjcFxGSoLp5C/1IE0Wf0/MU0ATreFScq3Ni8H1UBAQkLHVo903 4yeY0uSnKpRZ/crjse56k7Et7KfR1+46qSd7IL8lszks+blir8l/pFqoIB0tKxHch0E+juMmTVu DYcDfRCqVuDNmo= X-Received: by 2002:a05:600c:621b:b0:476:4efc:8ed4 with SMTP id 5b1f17b1804b1-48519854b2emr98746975e9.11.1772714425058; Thu, 05 Mar 2026 04:40:25 -0800 (PST) Message-ID: <4264cd39-00f3-4114-af90-baa29f9a00b9@suse.com> Date: Thu, 5 Mar 2026 13:40:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Jason Andryuk , Penny Zheng References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2026 13:30, Roger Pau Monné wrote: > On Thu, Mar 05, 2026 at 12:39:51PM +0100, Jan Beulich wrote: >> On 05.03.2026 11:17, Roger Pau Monné wrote: >>> On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote: >>>> On 05.03.2026 09:50, Roger Pau Monné wrote: >>>>> Since we have the parsing of the ACPI related data done from dom0 it's >>>>> not only Xen that needs to support the feature, but dom0 also needs to >>>>> know how to parse it. Or we just assume the driver in dom0 must >>>>> strictly know how to parse data from the features enabled by Xen. >>>>> >>>>> Maybe Xen supported bits should be & with the dom0 ones? So dom0 >>>>> would set what it can parse, and Xen would AND that with what the >>>>> cpufreq drivers support? However that would be an ABI change. >>>> >>>> What cpufreq drivers are you talking about here? >>> >>> I was talking about the Xen cpufreq driver, sorry the context was >>> confusing. >>> >>>> When Xen handles P- >>>> state transitions, the drivers in Dom0 would preferably not even be >>>> loaded. That's what the forward-port did. Upstream they may be loaded, >>>> but they then can't actually do anything (and they may exit early). >>> >>> Well, yes, on FreeBSD I simply overtake the native ACPI Processor >>> driver with a Xen specific one that has higher priority. So the >>> native ACPI Processor driver doesn't even attach. I think Linux is >>> slightly different in that it allows the native driver to do the >>> fetching of the information, and then the Xen driver only does the >>> uploading. >>> >>>> Coordination is necessary only with the ACPI driver(s), and that's what >>>> this function is about. >>> >>> I think Xen also needs coordination with the driver in dom0 that >>> fetches the information from ACPI? >> >> That's what I meant with "ACPI driver(s)". >> >>> It's not only Xen that needs to >>> report what the cpufreq driver support, but also dom0 would need to >>> expose what it can correctly parse. >> >> Hmm, yes, strictly speaking we should tie setting of respective bits to >> Dom0 having uploaded corresponding data. The order of these operations >> may, however, be at best undefined (and possibly be well defined in the >> unhelpful - for us - order). I don't think I see anything we can do >> about this. > > I'm afraid it's the other way around, you need to first call _PDC, and > then fetch the data. As I've learned the hard way while doing the > FreeBSD driver: you must call _PDC before attempting to fetch the > data, as ACPI will modulate what gets returned/is present on the > Processor objects based on what support the OSPM has specified in the > _PDC bits. In which case at least for Linux we're okay, as what we need it has always been capable of parsing. > Anyway, not sure there's much we can do now about any of this, it's > too late to change the interface, and what we have seems to kind of > work on for the purpose. Which reads almost(?) like an ack-in-disguise to me ... Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 12:44:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 12:44:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246567.1545696 (Exim 4.92) (envelope-from ) id 1vy84L-0004hy-7F; Thu, 05 Mar 2026 12:44:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246567.1545696; Thu, 05 Mar 2026 12:44:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy84L-0004hr-2f; Thu, 05 Mar 2026 12:44:45 +0000 Received: by outflank-mailman (input) for mailman id 1246567; Thu, 05 Mar 2026 12:44:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy84K-0004hl-EN for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 12:44:44 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 14c654f1-1891-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 13:44:42 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-482f454be5bso82579515e9.0 for ; Thu, 05 Mar 2026 04:44:42 -0800 (PST) Received: from [10.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-4851fafbf9bsm38275965e9.14.2026.03.05.04.44.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 04:44:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 14c654f1-1891-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772714682; x=1773319482; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=Ps30MAUb6AEgAzijJvCP0wKyGWFcZbak+cdz0xP/K4g=; b=ACkfBDjRwVH2Ry7PD9NRwuz2ONkBuxi4SfyQ3wqg9CIXqnHxMZDZue3aGosHsQz0mS TcP5TYjjIlH53io0hWUHbAb1R+yKOyXIA1c23EeP2EX3JZ2C9q/7qiDolQzzJWiIQ80S LS8yb7yr9bXrAGXLJDhZbAdbYDsXsX47qrAB24QYeivD6ogLSrMuVCkJodsK3dkk+MwY fwjhgN6ciVfkYKxPfWr/RbLKBZFcsfyfDFIWREusTGCBmEi6Q4MEyX9v1+ViqdvgXgNw 8ZAl4LP2CrAHJRf5K1DBJK3ZvPgGsH4rCko2QFse8QjO2xx3ucT9McsuH/0Bfj0Sm+19 2s5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772714682; x=1773319482; h=content-transfer-encoding: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; bh=Ps30MAUb6AEgAzijJvCP0wKyGWFcZbak+cdz0xP/K4g=; b=t1R/ZLlVoqtwsD9ltfMtWHPfTO9wK0jwCTXjHdazPVC7MBu6uULZrpzL6D8i6yJOTY 79Ej+5I/bmGonjYS2DuKPVWkfq91Vw7Mf7hREC7tork2Hipz3kjFwuehSyj3/MdDB1/K /Rdg2yyVHwgWPTWMIYis6Im3NDV698LNZ3gdjIA6oYZ9YOsNdCrSpWSWjk3xno2fUL6U PwlPW5bGSp9iCd4/kBsa7sQaJYVkgLC39ke4H9WwcnFna6g/9oZyyMCDsirVka1zVMK6 8cZvz23amzlztT0z78or9VEuDFjbAIJyywyryF43/bbsMUVYgBaNpC3rqjf/KzvYcPUH OOVQ== X-Forwarded-Encrypted: i=1; AJvYcCVgwY08hmhFRmn9TlRETQhXl/f33wULi8W03GxRajdqLO/RiQCsAT+VmEox9UxtvCRYgLpZeBAr7fQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyxC7cIuQ8aX54llJC5llwBzIn3aa85W90kRM0atRTGe+0jAT7l 5kEBH/uAlN1l7VAzeXOIOlJHHobwyjpX4DVC0kjWUR27Y9fv8YpoyHuGrLD26hRYrPPu75T0niF ZIpA= X-Gm-Gg: ATEYQzwSMjcEbgSLybzurdAviaVTHR0wug01GX+hBTNGENtAXtAddNDPJYZK6g7XnZS fizU38z/JnWKB7ANAdhuzdcnrmKet3RX2bp019Y+n8KjUWWyBETCS9Z0+vRRxGzegAzCNbG4KCt NJU1UEDkiQ4sXDqLq24FYWY+d0poI1WY0AZptB/4NBNr9MW5W6uevXrybWEpVYdJkj5VeVw9/M6 FUpSVXAXNtCPecf7gnjHr0f8kxjsW1fI6RwP80weYQ8Ab5dCHpmBCTvveYSsnlWrmOUsUeXkeJK GQRtvAqxTKFJ7iHCB3ythZ4L9WMKNp9nw3hMk7By8bSlVEI5tFlKhdcYJ00yPY337h4LBJGvIG2 f7Zu59OhIppkLvDKvrPrr22/770WAD8d68nUxWWUh8pBSBNW4XlE8roJMdz21Lpb2f1IXnJR35U Y+PfEtR97C29OGihKlnfaGlX01I4nsKSj5omF29O7NyfTmVp9CYFPkLsn1sMnyouKpvZ2fO+cpn VcmJKac3biRGBA= X-Received: by 2002:a05:600c:3f0d:b0:481:a662:b3f3 with SMTP id 5b1f17b1804b1-4851ee854b6mr40429935e9.7.1772714681842; Thu, 05 Mar 2026 04:44:41 -0800 (PST) Message-ID: <79b2e448-fdba-46dc-8b94-b0128cf0f492@suse.com> Date: Thu, 5 Mar 2026 13:44:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 05/10] xen/domain: Add DOMCTL handler for claiming memory with NUMA awareness To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , "Daniel P. Smith" , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -868,6 +868,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > ret = get_domain_state(&op->u.get_domain_state, d, &op->domain); > break; > > + case XEN_DOMCTL_claim_memory: > + /* Use the same XSM hook as XENMEM_claim_pages */ > + ret = xsm_claim_pages(XSM_PRIV, d); > + if ( ret ) > + break; > + > + ret = claim_memory(d, &op->u.claim_memory); > + break; This needs accompanying by a change to xsm/flask/hooks.c:flask_domctl(). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:04:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:04:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246591.1545705 (Exim 4.92) (envelope-from ) id 1vy8Nk-0007hC-Na; Thu, 05 Mar 2026 13:04:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246591.1545705; Thu, 05 Mar 2026 13: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 ) id 1vy8Nk-0007h5-K5; Thu, 05 Mar 2026 13:04:48 +0000 Received: by outflank-mailman (input) for mailman id 1246591; Thu, 05 Mar 2026 13:04:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8Ni-0007gz-PC for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:04:46 +0000 Received: from mail177-30.suw61.mandrillapp.com (mail177-30.suw61.mandrillapp.com [198.2.177.30]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e114a926-1893-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:04:45 +0100 (CET) Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail177-30.suw61.mandrillapp.com (Mailchimp) with ESMTP id 4fRVB30MgxzP0Jwss for ; Thu, 5 Mar 2026 13:04:43 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 95b08eaea145431cae23f4ba27e0cbb9; Thu, 05 Mar 2026 13:04:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e114a926-1893-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772715883; x=1772985883; bh=TrtrGEbMvZfgbcOGMyLdlPsgcFAr6G1EiZiAEmMYYP4=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=Re3g7yp+cFZrYZBzRlxp952Ijf8uZiBvW7E96kl/ktpWgng/+b1R2gZGp6eCYK5hO HPMhEIqiZDV3pkd1Hi1x3qU59qkwisQgLEEZhGNbiityaIYouF+UdVdSFHHxH/pJS5 IvdVJzYopZ6lG0KNRyGaL/2FaS8z8WatA6zns7pg88gXqrCvGauiMnRMKGVU5G6h8V bHCtt1aHsv3TxohmfJ2MXc894Oc0CUakU8mQIb5Hq1SsH7CIE7iCPBuPZXUUPZovZM t3QtUJXLV/6AuqfsqUXn+I1tf4V9ZXLcS4LnH0bYRbd3jP8Jxhr3yqRJkMVXF7oI9N 02W4dvQa0yeZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772715883; x=1772976383; i=julian.vetter@vates.tech; bh=TrtrGEbMvZfgbcOGMyLdlPsgcFAr6G1EiZiAEmMYYP4=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=a0MpJmTCtW+3kw6qc0uZdcYTAMxHkvxZ7UMZ6Z/3e82tKyz+0fv2GAspLYwMjN4c9 LefVaYywEW1DfFisK9f88ZMtwKJF+yQd8OmjvotbaW1wTWJy3V1RA/+Y5rnRI9lpzj crxf1XIZ0aRKXMLXvipzvHTUAhoAfnK1XwYpdR2XJFbuX7UP1pNhscoNqQCwzUV7DL LdiGTRfi47NR5PpfN5uvlkI+23VAQd9ANlnkUqdqcR3Bab7+6IQStGmK9mKaBMFIVw G44wSv3AxZWDACjTRf7nLAUVErFzN6I5T9B4ZXoMCgOpbgTJLZu30C5js2tdsmMtE0 fdR+0XOeZW7xg== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v4=201/2]=20This=20patch=20just=20changes=20indentation,=20to=20make=20the=20next=20patch=20easier=20to=20review.?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772715881758 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Julian Vetter" Message-Id: <20260305130434.635276-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.95b08eaea145431cae23f4ba27e0cbb9?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260305:md Date: Thu, 05 Mar 2026 13:04:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Signed-off-by: Julian Vetter --- Changes in v4: - No changes to this patch --- xen/arch/x86/hvm/ioreq.c | 58 ++++++++++++++++--------------- xen/common/ioreq.c | 74 +++++++++++++++++++++------------------- 2 files changed, 70 insertions(+), 62 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index a5fa97e149..355b2ba12c 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -125,14 +125,16 @@ static void hvm_unmap_ioreq_gfn(struct ioreq_server *s, bool buf) { struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; - if ( gfn_eq(iorp->gfn, INVALID_GFN) ) - return; + { + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) + return; - destroy_ring_for_helper(&iorp->va, iorp->page); - iorp->page = NULL; + destroy_ring_for_helper(&iorp->va, iorp->page); + iorp->page = NULL; - hvm_free_ioreq_gfn(s, iorp->gfn); - iorp->gfn = INVALID_GFN; + hvm_free_ioreq_gfn(s, iorp->gfn); + iorp->gfn = INVALID_GFN; + } } static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf) @@ -141,34 +143,36 @@ static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf) struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; int rc; - if ( iorp->page ) { - /* - * If a page has already been allocated (which will happen on - * demand if ioreq_server_get_frame() is called), then - * mapping a guest frame is not permitted. - */ - if ( gfn_eq(iorp->gfn, INVALID_GFN) ) - return -EPERM; - - return 0; - } + if ( iorp->page ) + { + /* + * If a page has already been allocated (which will happen on + * demand if ioreq_server_get_frame() is called), then + * mapping a guest frame is not permitted. + */ + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) + return -EPERM; + + return 0; + } - if ( d->is_dying ) - return -EINVAL; + if ( d->is_dying ) + return -EINVAL; - iorp->gfn = hvm_alloc_ioreq_gfn(s); + iorp->gfn = hvm_alloc_ioreq_gfn(s); - if ( gfn_eq(iorp->gfn, INVALID_GFN) ) - return -ENOMEM; + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) + return -ENOMEM; - rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page, - &iorp->va); + rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page, + &iorp->va); - if ( rc ) - hvm_unmap_ioreq_gfn(s, buf); + if ( rc ) + hvm_unmap_ioreq_gfn(s, buf); - return rc; + return rc; + } } static void hvm_remove_ioreq_gfn(struct ioreq_server *s, bool buf) diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c index f5fd30ce12..2e284ad26c 100644 --- a/xen/common/ioreq.c +++ b/xen/common/ioreq.c @@ -263,41 +263,43 @@ 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; - if ( iorp->page ) { - /* - * If a guest frame has already been mapped (which may happen - * on demand if ioreq_server_get_info() is called), then - * allocating a page is not permitted. - */ - if ( !gfn_eq(iorp->gfn, INVALID_GFN) ) - return -EPERM; + if ( iorp->page ) + { + /* + * If a guest frame has already been mapped (which may happen + * on demand if ioreq_server_get_info() is called), then + * allocating a page is not permitted. + */ + if ( !gfn_eq(iorp->gfn, INVALID_GFN) ) + return -EPERM; - return 0; - } + 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; + } - iorp->va = __map_domain_page_global(page); - if ( !iorp->va ) - goto fail; + iorp->va = __map_domain_page_global(page); + if ( !iorp->va ) + goto fail; - iorp->page = page; - clear_page(iorp->va); - return 0; + iorp->page = page; + clear_page(iorp->va); + return 0; + } fail: put_page_alloc_ref(page); @@ -311,16 +313,18 @@ 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; - if ( !page ) - return; + { + if ( !page ) + return; - iorp->page = NULL; + iorp->page = NULL; - unmap_domain_page_global(iorp->va); - iorp->va = NULL; + unmap_domain_page_global(iorp->va); + iorp->va = NULL; - put_page_alloc_ref(page); - put_page_and_type(page); + put_page_alloc_ref(page); + put_page_and_type(page); + } } bool is_ioreq_server_page(struct domain *d, const struct page_info *page) -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:04:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:04:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246592.1545715 (Exim 4.92) (envelope-from ) id 1vy8No-0007uf-Te; Thu, 05 Mar 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 1246592.1545715; Thu, 05 Mar 2026 13:04:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8No-0007uY-QA; Thu, 05 Mar 2026 13:04:52 +0000 Received: by outflank-mailman (input) for mailman id 1246592; Thu, 05 Mar 2026 13:04:51 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8Nm-0007uB-S4 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:04:50 +0000 Received: from mail177-30.suw61.mandrillapp.com (mail177-30.suw61.mandrillapp.com [198.2.177.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e11a26bd-1893-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:04:44 +0100 (CET) Received: from pmta14.mandrill.prod.suw01.rsglab.com (localhost [127.0.0.1]) by mail177-30.suw61.mandrillapp.com (Mailchimp) with ESMTP id 4fRVB33T3RzP0K0df for ; Thu, 5 Mar 2026 13:04:43 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 0d585d8382c04640a12e640d66f54b56; Thu, 05 Mar 2026 13:04:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e11a26bd-1893-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772715883; x=1772985883; bh=IXlDfmTfGN+c9jtpxObZGu4U9n4TAcmm6nuDw2iup0I=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=sE/UypS4ZvLj32q1KgN6IBCl0wUTzmRCErAD631xwGm4u8t/L4bEhFl+c6YMSGFjd ZTPFv7j8PTbkg+88dnjkwZEGcl0m9c3XwFw3US8CheP9D032F4T485n0hwOUNiOMsU 31upG5UPYuyxU7wF921okC+yx+ABjQ9ojojCGPY/SJplWlTz/q+vWo7+izmYDaZcVb WS1bU6dw55VJLWkDC4d9gFcgEdlKb2IGJo9ea1TD7QTZrXlP1IIceK11MAvZ+DTKqT oUuBEHALTOVdpB0cpHAY2gkd//8xGtrcHXt11L1s8DlR/URCy+ehDjvI6bmLwy9R1D f8ZZAOnitmK9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772715883; x=1772976383; i=julian.vetter@vates.tech; bh=IXlDfmTfGN+c9jtpxObZGu4U9n4TAcmm6nuDw2iup0I=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=GDpNyJVM0XSqh7QcDOzZFZxIAG4G/BvTQuDUiHEySjChLAGA+P7QohBXdb0OMyAB5 jaae4rwTBEQ3U722yufpNB28Qln3UEwoTViO1bwBySbDODCgfo4qopZXKq0A4H/W8P d8uA76ThPWff4M6wAmXEb+opvzFA/DBmF+ert7CU0dVAgnU45+6M3eW2YyakpyH2Fi frvdU4iBV/GZT2nAopQIURYyqgCTqJjw013/OuW6dJlr4bqzfNmHysSkC0q8BD9/k3 Vr76scOhHRjEga/RvkWay8bHzUkXLsp0tJKZuXSz1ciY57UcJ9mn3uqlBDCB7xCmXw 8iIJsjDEHTMUQ== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v4=202/2]=20x86/ioreq:=20Extend=20ioreq=20server=20to=20support=20multiple=20ioreq=20pages?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772715882225 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , "Julian Vetter" Message-Id: <20260305130434.635276-2-julian.vetter@vates.tech> In-Reply-To: <20260305130434.635276-1-julian.vetter@vates.tech> References: <20260305130434.635276-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.0d585d8382c04640a12e640d66f54b56?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260305:md Date: Thu, 05 Mar 2026 13:04:43 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit A single shared ioreq page provides PAGE_SIZE/sizeof(ioreq_t) = 128 slots, limiting HVM guests to 128 vCPUs. To support more vCPUs, the single struct ioreq_page in the ioreq_server is replaced with an ioreq_t pointer backed by a dynamically sized allocation. For the resource mapping path (XENMEM_acquire_resource), the common ioreq_server_alloc_mfn() allocates nr_ioreq_pages(d) domain heap pages with MEMF_no_refcount and writable type references, then maps them as a single contiguous VA via vmap(). Teardown recovers the pages from the vmap address via vmap_size() and vmap_to_page(). The legacy GFN-mapped path continues to support only a single ioreq page. For domains whose vCPU count exceeds PAGE_SIZE/sizeof(ioreq_t), hvm_map_ioreq_gfn() returns -EOPNOTSUPP. Those domains need to use the resource mapping interface. This also avoids fragmentation when allocating multiple slots from the GFN pool. The GFN path uses vmap() for the Xen-side mapping, consistent with ioreq_server_alloc_mfn(), allowing vmap_to_page() to recover the page during teardown. Signed-off-by: Julian Vetter --- Changes in v4: - Dropped the multi-page support for the legacy GFN-mapped path - When 'nr_ioreq_pages(d) > 1' -> -EOPNOTSUPP - But now also use vmap(), same as in resource mapping path, so new s->ioreq pointer is used in either case - Mirror exactly what prepare_ring_for_helper/destroy_ring_for_helper is doing except the __map_domain_page_global (replaced by vmap/vunmap) - Replaced xvzalloc_array() by xvmalloc_array() -> No need to have mfns array zero'ed - Inverted logic in ioreq_server_alloc_mfn() and ioreq_server_free_mfn() to check for 'if (buf)' (same as in the GFN-mapped path) - Fixed ioreq_server_alloc_mfn -> Correctly call alloc_domheap_page + get_page_and_type - Fixed error handling and teardown path to correctly call put_page_alloc_ref + put_page_and_type just like for the bufioreq - Kept shared_iopage_t so QEMU, varstored, etc. can just reference into it via p->ioreq[cpu_id] -> No modification needed --- xen/arch/x86/hvm/ioreq.c | 153 ++++++++++++++++++++++++++++++++---- xen/common/ioreq.c | 166 ++++++++++++++++++++++++++++++++------- xen/include/xen/ioreq.h | 10 ++- 3 files changed, 286 insertions(+), 43 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index 355b2ba12c..ec4f210768 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -123,9 +124,10 @@ static void hvm_free_ioreq_gfn(struct ioreq_server *s, gfn_t gfn) static void hvm_unmap_ioreq_gfn(struct ioreq_server *s, bool buf) { - struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; - + if ( buf ) { + struct ioreq_page *iorp = &s->bufioreq; + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) return; @@ -134,16 +136,33 @@ static void hvm_unmap_ioreq_gfn(struct ioreq_server *s, bool buf) hvm_free_ioreq_gfn(s, iorp->gfn); iorp->gfn = INVALID_GFN; + return; } + + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) + return; + + put_page_and_type(vmap_to_page((void *)s->ioreq)); + vunmap(s->ioreq); + s->ioreq = NULL; + + hvm_free_ioreq_gfn(s, s->ioreq_gfn); + s->ioreq_gfn = INVALID_GFN; } static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf) { struct domain *d = s->target; - struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; + gfn_t base_gfn; + struct page_info *pg; + p2m_type_t p2mt; + mfn_t mfn; int rc; + if ( buf ) { + struct ioreq_page *iorp = &s->bufioreq; + if ( iorp->page ) { /* @@ -173,35 +192,141 @@ static int hvm_map_ioreq_gfn(struct ioreq_server *s, bool buf) return rc; } + + if ( s->ioreq ) + { + /* + * If pages have already been allocated (which will happen on + * demand if ioreq_server_get_frame() is called), then + * mapping a guest frame is not permitted. + */ + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) + return -EPERM; + return 0; + } + + /* + * The legacy GFN path supports only a single ioreq page. Guests requiring + * more ioreq slots must use the resource mapping interface + * (XENMEM_acquire_resource). + */ + if ( nr_ioreq_pages(d) > 1 ) + return -EOPNOTSUPP; + + if ( d->is_dying ) + return -EINVAL; + + base_gfn = hvm_alloc_ioreq_gfn(s); + + if ( gfn_eq(base_gfn, INVALID_GFN) ) + return -ENOMEM; + + /* + * The page management is the same as prepare_ring_for_helper(), but vmap() + * is used instead of __map_domain_page_global() to be consistent with + * ioreq_server_alloc_mfn(), which uses vmap() to map potentially multiple + * pages. This also allows vmap_to_page() to recover the struct page_info * + * from s->ioreq during teardown. + */ + rc = check_get_page_from_gfn(d, base_gfn, false, &p2mt, &pg); + if ( rc ) + { + if ( rc == -EAGAIN ) + rc = -ENOENT; + goto fail; + } + + if ( !get_page_type(pg, PGT_writable_page) ) + { + put_page(pg); + rc = -EINVAL; + goto fail; + } + + mfn = page_to_mfn(pg); + s->ioreq = vmap(&mfn, 1); + if ( !s->ioreq ) + { + put_page_and_type(pg); + rc = -ENOMEM; + goto fail; + } + + s->ioreq_gfn = base_gfn; + return 0; + + fail: + hvm_free_ioreq_gfn(s, base_gfn); + return rc; } static void hvm_remove_ioreq_gfn(struct ioreq_server *s, bool buf) { struct domain *d = s->target; - struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; + struct page_info *pg; + void *va; + gfn_t gfn; - if ( gfn_eq(iorp->gfn, INVALID_GFN) ) - return; + if ( buf ) + { + struct ioreq_page *iorp = &s->bufioreq; + + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) + return; + + gfn = iorp->gfn; + pg = iorp->page; + va = iorp->va; + } + else + { + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) + return; - if ( p2m_remove_page(d, iorp->gfn, page_to_mfn(iorp->page), 0) ) + gfn = s->ioreq_gfn; + pg = vmap_to_page(s->ioreq); + va = s->ioreq; + } + + if ( p2m_remove_page(d, gfn, page_to_mfn(pg), 0) ) domain_crash(d); - clear_page(iorp->va); + clear_page(va); } static int hvm_add_ioreq_gfn(struct ioreq_server *s, bool buf) { struct domain *d = s->target; - struct ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq; + struct page_info *pg; + void *va; + gfn_t gfn; int rc; - if ( gfn_eq(iorp->gfn, INVALID_GFN) ) - return 0; + if ( buf ) + { + struct ioreq_page *iorp = &s->bufioreq; + + if ( gfn_eq(iorp->gfn, INVALID_GFN) ) + return 0; + + gfn = iorp->gfn; + pg = iorp->page; + va = iorp->va; + } + else + { + if ( gfn_eq(s->ioreq_gfn, INVALID_GFN) ) + return 0; + + gfn = s->ioreq_gfn; + pg = vmap_to_page(s->ioreq); + va = s->ioreq; + } - clear_page(iorp->va); + clear_page(va); - rc = p2m_add_page(d, iorp->gfn, page_to_mfn(iorp->page), 0, p2m_ram_rw); + rc = p2m_add_page(d, gfn, page_to_mfn(pg), 0, p2m_ram_rw); if ( rc == 0 ) - paging_mark_pfn_dirty(d, _pfn(gfn_x(iorp->gfn))); + paging_mark_pfn_dirty(d, _pfn(gfn_x(gfn))); return rc; } diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c index 2e284ad26c..5a09e2ba36 100644 --- a/xen/common/ioreq.c +++ b/xen/common/ioreq.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include @@ -95,12 +97,10 @@ static struct ioreq_server *get_ioreq_server(const struct domain *d, static ioreq_t *get_ioreq(struct ioreq_server *s, struct vcpu *v) { - shared_iopage_t *p = s->ioreq.va; - ASSERT((v == current) || !vcpu_runnable(v)); - ASSERT(p != NULL); + ASSERT(s->ioreq != NULL); - return &p->vcpu_ioreq[v->vcpu_id]; + return &s->ioreq[v->vcpu_id]; } /* @@ -260,10 +260,16 @@ 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; + unsigned int i, nr_pages; + mfn_t *mfns; + int rc; + /* bufioreq: single page allocation */ + if ( buf ) { + struct ioreq_page *iorp = &s->bufioreq; + struct page_info *page; + if ( iorp->page ) { /* @@ -294,26 +300,92 @@ static int ioreq_server_alloc_mfn(struct ioreq_server *s, bool buf) iorp->va = __map_domain_page_global(page); if ( !iorp->va ) - goto fail; + { + put_page_alloc_ref(page); + put_page_and_type(page); + return -ENOMEM; + } iorp->page = page; clear_page(iorp->va); return 0; } - fail: - put_page_alloc_ref(page); - put_page_and_type(page); + /* ioreq: multi-page allocation */ + if ( s->ioreq ) + { + /* + * If a guest frame has already been mapped (which may happen + * on demand if ioreq_server_get_info() is called), then + * allocating a page is not permitted. + */ + if ( !gfn_eq(s->ioreq_gfn, INVALID_GFN) ) + return -EPERM; + + return 0; + } + + nr_pages = nr_ioreq_pages(s->target); + mfns = xvmalloc_array(mfn_t, nr_pages); + + if ( !mfns ) + return -ENOMEM; + + for ( i = 0; i < nr_pages; i++ ) + { + struct page_info *pg = alloc_domheap_page(s->target, + MEMF_no_refcount); + + rc = -ENOMEM; + if ( !pg ) + goto fail_pages; + + if ( !get_page_and_type(pg, 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); + rc = -ENODATA; + goto fail_pages; + } + + mfns[i] = page_to_mfn(pg); + } + + s->ioreq = vmap(mfns, nr_pages); + if ( !s->ioreq ) + { + rc = -ENOMEM; + i = nr_pages; + goto fail_pages; + } + + memset(s->ioreq, 0, nr_pages * PAGE_SIZE); + xvfree(mfns); + return 0; - return -ENOMEM; + fail_pages: + while ( i-- > 0 ) + { + struct page_info *pg = mfn_to_page(mfns[i]); + + put_page_alloc_ref(pg); + put_page_and_type(pg); + } + xvfree(mfns); + return rc; } 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; - + if ( buf ) { + struct ioreq_page *iorp = &s->bufioreq; + struct page_info *page = iorp->page; + if ( !page ) return; @@ -324,6 +396,23 @@ static void ioreq_server_free_mfn(struct ioreq_server *s, bool buf) put_page_alloc_ref(page); put_page_and_type(page); + return; + } + + if ( s->ioreq ) + { + unsigned int i, nr_pages = vmap_size(s->ioreq); + + for ( i = 0; i < nr_pages; i++ ) + { + struct page_info *pg = vmap_to_page((void *)s->ioreq + + i * PAGE_SIZE); + + put_page_alloc_ref(pg); + put_page_and_type(pg); + } + vunmap(s->ioreq); + s->ioreq = NULL; } } @@ -337,11 +426,29 @@ 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->bufioreq.page == page ) { found = true; break; } + + if ( s->ioreq ) + { + unsigned int i; + + for ( i = 0; i < nr_ioreq_pages(d); i++ ) + { + if ( vmap_to_page((char *)s->ioreq + + i * PAGE_SIZE) == page ) + { + found = true; + break; + } + } + + if ( found ) + break; + } } rspin_unlock(&d->ioreq_server.lock); @@ -354,7 +461,7 @@ static void ioreq_server_update_evtchn(struct ioreq_server *s, { ASSERT(spin_is_locked(&s->lock)); - if ( s->ioreq.va != NULL ) + if ( s->ioreq != NULL ) { ioreq_t *p = get_ioreq(s, sv->vcpu); @@ -594,7 +701,7 @@ static int ioreq_server_init(struct ioreq_server *s, INIT_LIST_HEAD(&s->ioreq_vcpu_list); spin_lock_init(&s->bufioreq_lock); - s->ioreq.gfn = INVALID_GFN; + s->ioreq_gfn = INVALID_GFN; s->bufioreq.gfn = INVALID_GFN; rc = ioreq_server_alloc_rangesets(s, id); @@ -773,7 +880,7 @@ static int ioreq_server_get_info(struct domain *d, ioservid_t id, } if ( ioreq_gfn ) - *ioreq_gfn = gfn_x(s->ioreq.gfn); + *ioreq_gfn = gfn_x(s->ioreq_gfn); if ( HANDLE_BUFIOREQ(s) ) { @@ -816,26 +923,29 @@ 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 = page_to_mfn(s->bufioreq.page); rc = 0; - break; - - case XENMEM_resource_ioreq_server_frame_ioreq(0): - *mfn = page_to_mfn(s->ioreq.page); - 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); - default: rc = -EINVAL; - break; + if ( s->ioreq ) + { + *mfn = vmap_to_mfn((void *)s->ioreq + page_idx * PAGE_SIZE); + rc = 0; + } } + else + rc = -EINVAL; out: rspin_unlock(&d->ioreq_server.lock); diff --git a/xen/include/xen/ioreq.h b/xen/include/xen/ioreq.h index e86f0869fa..41650a59ca 100644 --- a/xen/include/xen/ioreq.h +++ b/xen/include/xen/ioreq.h @@ -19,9 +19,16 @@ #ifndef __XEN_IOREQ_H__ #define __XEN_IOREQ_H__ +#include #include #include +#include + +static inline unsigned int nr_ioreq_pages(const struct domain *d) +{ + return DIV_ROUND_UP(d->max_vcpus, PAGE_SIZE / sizeof(ioreq_t)); +} struct ioreq_page { gfn_t gfn; @@ -45,7 +52,8 @@ struct ioreq_server { /* Lock to serialize toolstack modifications */ spinlock_t lock; - struct ioreq_page ioreq; + ioreq_t *ioreq; + gfn_t ioreq_gfn; struct list_head ioreq_vcpu_list; struct ioreq_page bufioreq; -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:12:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:12:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246612.1545725 (Exim 4.92) (envelope-from ) id 1vy8VZ-0001Wq-Pu; Thu, 05 Mar 2026 13:12:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246612.1545725; Thu, 05 Mar 2026 13:12:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8VZ-0001Wj-Lw; Thu, 05 Mar 2026 13:12:53 +0000 Received: by outflank-mailman (input) for mailman id 1246612; Thu, 05 Mar 2026 13:12:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8VZ-0001Wd-3a for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:12:53 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 009e4412-1895-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:12:47 +0100 (CET) Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by LV3PR03MB7431.namprd03.prod.outlook.com (2603:10b6:408:194::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 13:12:42 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%6]) with mapi id 15.20.9678.017; Thu, 5 Mar 2026 13:12:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 009e4412-1895-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h+4q2ul463yB1r+jp0ZXnDCmKvIjfDlBKiYjDv87G7l3ZWesiPatJhMUvLLj/chVb+YHnBjkNIdzIyDztE9tP0KJOGpyxRKYIbJyCHO8PFsVmITdrRgXQmApEZE+NTQWMNzSCIMEY/VaDwQTwI8mC75PBxafkXeCfyWF3yi/X+c0+yJ0o1f08OZb+eldakNkz/JcHePu6y7jbPaLBQjE2fmllyyZnXRGTMnfJbli0U185nlMzrzUEk9xGuoqDCNlSW1aM4jiOfHeiCGAp4a9Yba9jINXBGdj5QPr6DGw4qzt5rQxZ/VyqwRqpd34Rg4jprXjMRs41AtjDbJCAcULFg== 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=YDr9PlBIUI66HZ5WEV0DH5b5E12lb28oTqCBCMj4qtQ=; b=r/ZLF6fcI90ySUjJB5s3kbyiOsisOSaAlR6iYG0/gRwsx3PJg4LNCSoMRPhkxhAyVWMzn6L964Evi4GELpJ+0HqzFVNka/vs7XieKvIRxdqegarMw06+Vs6af/FKbCKpUK5xlc/qFuvwBBbLM7bNt+Db7D/d164kW5TgqVo1QvmMInYvj+NSIGjAnKj3Oj9NfRgh9FQJT3Kubxqwjgx4WCNIuWaUU/c8Rxtj07KKzfNCMZkrL6Qat32liWZN6IqR2N791IAInZJwlvNlnbBOXmr0n6OUmd6I6jpjL22hzaSgXasLOgm8eOe3APHLggpj8q4pgptUma75lGQcEEX94A== 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=YDr9PlBIUI66HZ5WEV0DH5b5E12lb28oTqCBCMj4qtQ=; b=lDFq55BsdHnXO5QoVJhSgGQoTlfLrZVaOwU256S1Kt4ninUrMdF9RwL5wgwSKTxLNqvq5yfCD79G0b+yPNuSYCmegah0HvcR47fo19NTJkXY1AY9vyybTO53xTaSHMbVbuhej5jwAGlZ7sO1r7BSIhxEFfbomvYjjGjBRX8zP+A= From: Bernhard Kaindl To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , Marcus Granado , "xen-devel@lists.xenproject.org" , Alejandro Vallejo Subject: RE: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims Thread-Topic: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims Thread-Index: AQHcpy5A2UpiyJQ97kePD66zF1miC7Wfzj4AgAAAi7A= Date: Thu, 5 Mar 2026 13:12:42 +0000 Message-ID: References: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> In-Reply-To: <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: LV3PR03MB7707:EE_|LV3PR03MB7431:EE_ x-ms-office365-filtering-correlation-id: 28054244-f50a-40b3-f13d-08de7ab8e28a x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: IFoWmQ86kvPNLsr53Co5myGvumCPIDJJ/nVsIAYvPlErrVHxEzd8Y1eNhP6rWCLe9gVOjaSRXH6jf40IRdjy2uZEPUrBw06UhKX5UQpYJg6rDUhzhzPEw1tYOJRepR4NJuDmcOyTNW2ajXWtGxFwg67HP1eFiPo6+T7WDCiSN4vHr0dKupAvX8cgGWI2j4UZ+peh0pnhlAX6kC51t3aTZjFFukUre2DXzw3hqzEHDcVBWpIw0/xr6dygJmUhOfqaGHK1h71aUcOY3OwZVZm1NTagNGVIEoekJSLTDN76U+d67+W5iNwdNNIn9nkVkQHWCeXrta+71tDeARSQcRMVmbBzf+rpFnCw9zuII7SLbrZVeZ8oMGcEHd+HYC4KRMF2k4Gn4TuojWUQaIJGlf/gjXE9/yj21a4ANoj4MIHLRmJ3rOpdZMfKPNHu02nHVixrGVNPkNKbTeUkE7JTn9WNpE6wZBFJSYToBfBp4+TaGGG+Eek6eOykZpTm3qS9iAG1LaiG+QOdNDbN/JQYt7yzCXhQhNZUltgyy1fceAl9AKOelEJduSZnYCczPKeC6ZFpgP9LK29bjduqBS+ntJAK7SK0ROugg4RoiSsI84365cAVHB2crvEc3zGW0swDSsy+BJgiWQ+X90KTQb4rtXJi+7agDeVMdo3fKpz6uUDUd4GKmzhst+7T6qfYQwRqJanGE6rrtLuiC+etkYjmOPOxmXAAKvKPeo6u/9dc6dlLGUjiFoLHEKhQaGw14KKS4mLE x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q29MRlVPWVkycUIwejRlSElJd1RwNW9tNmF1dW94V2RmOGtKbDAzSDdQM080?= =?utf-8?B?UTNGQ2hIT3JNVkk0dVFlUkJLQm51YSt2UjFJWE5oUDBOUFVKVGpDbWRtdWdK?= =?utf-8?B?MllITnVCTldSMHlLSnM0ekk5dE5wMFYvYmtVSkViTWUxYThKSUpyaVRzdEY3?= =?utf-8?B?RXcwaFFwVWlqUW4vcEVSbVBnQ2M4R0krOVB3TnlzMWVaVk9sSTVTUzB2MWc5?= =?utf-8?B?b1h4SThZTHN6clRmRVoxV0VPZUt5T0hVT2hUQ3BaQWVKZEFBUUcxVi9XOWp4?= =?utf-8?B?L04xTmFCMVlFN2Vib3lJZ1pwaHlUczY5MEQ2bEZoTTlRQXMwSGdMbENTU0tL?= =?utf-8?B?eGxwOXNUK3dLUG5CS0NMeHcyMzM3MWVHeThScENaTEVDSmhzVU9EcmVaQnor?= =?utf-8?B?NW8ya2pxb3VOVitlWFVwd1ZjSnpvSnBCbkRsL3VZV1FMczNpc2FJeEFrVWgr?= =?utf-8?B?bE1BdTM3WDhzOEM3eFlaMGd6d3JvTlJhUHlyZm41SitPcHA2cEtVQ2xpS3hw?= =?utf-8?B?dk1zNndHdVhKUlhKbjZlK29TOWdibU9LUW9OOG1UQm1tOFpNRWd6cHpRWUM0?= =?utf-8?B?ME0za3ZRVXUzYm95emw1MXlrS0poNlFhbVkzZTJVVjhGSGkrYk5BSjNKbEtV?= =?utf-8?B?bXBCRHZ5SWJtUjZoUUhmR05sWmJzOFE0dmpHaFA5MjNFdDc5dXU4bU5FY05V?= =?utf-8?B?WklLRGw5cFpveUM2R29VM3loOWd1dktlYUZaQSs2WTNhMmdyNUZQeTFFaFBT?= =?utf-8?B?d2hMY1lwLy83NkViYVRaQ1p4R3d2VGZHY211WmR0UlVmaTQxM1FSZFN5WGE1?= =?utf-8?B?VXRvdExENXhCbmZrUjFTd053NXZzWXh1azlDaFkvTVpCMWozcWVscHpFVlVU?= =?utf-8?B?UXVqL2VBQU1oZURQSzNrZG1RYTNvWXRSbU40RFYwVnN2aWUyeTNvYzF1QmY1?= =?utf-8?B?VkNsVjdtVjFjLzRLdnVlSUkvL3ZJQUFyZ0hYdks5QXdFVnFIT1p6YzBCRjF4?= =?utf-8?B?LzlGYkgwWURicFlRWmdGQjdscGZhOVN1cFpiRHBiV0h1dWZobjEySnN6K0NT?= =?utf-8?B?YlE2dkJQNXV4eXZkQkZqcitHaW90SGVKZnZGY1FCdTJpaFlKaEhkNmUyZFly?= =?utf-8?B?dlNWNk9ONXZBODZEN1pEU1ZmVWQ1VkE1MTJ0Wk5DRXozZ0h5Y2hjK2pCQ0x1?= =?utf-8?B?NGlNZUtVa0hJeFd6UDlla1YxenpCR21QZDEzejZXcG5pelhyRmRncmRpdk9x?= =?utf-8?B?REkwZ0RBcWRoSHZ4Q1pIRy9DbUwyNGEzQnBaVENQb1M1Z2EvV2xvV05ZVnlH?= =?utf-8?B?UCszOHJJNWw4Y2ZhT2hKc2RiR0R3cGFpSHZaYUZvS0orSUNjNGxLT2liWHox?= =?utf-8?B?ZWFwcldYLzR4L3NDOTFvUVFWZUdPZHNMcXNOMnBFTHZacndMNE56SlBRcWZi?= =?utf-8?B?djFpRkpzaVYxSlR4UWJuK0ZBY0hEb2I1NDlsMjd6UWlyc0VqTE9tdGNSeXZH?= =?utf-8?B?TnB3d20venhVaTdkQ1JnUEwzSlU1U3JnZWtoMzQ2UkxwNTV4S3BHaHE1N2sw?= =?utf-8?B?Ly9jY2VVR3M1OXlVUk9CQmE4TVlBdkNFOGdxekpTTndySHdiTmFwRlNrcUI2?= =?utf-8?B?SEZveEhjOUJFbkk4bDNONzhvZ1U5Q2hZS3RlWnZBcExxMWZ3bzRMdjJrUzF4?= =?utf-8?B?M3NGTkhtai8xdW5kS3ZWRWtDZTdSd0Vua1UwUWs0NWIzL3B4ODRMdDcrcXdp?= =?utf-8?B?bnFZZ2RwRVhwc29mZDZUaTdybEZaOUdsaFBYa2RodHJVdE9HNTRaM3ROZW5m?= =?utf-8?B?cldjbzV6ZEExNzNHV3pqdDhGVVk5YnRSY3k1UUlXc0NJRkZxUytlK0g0WEF5?= =?utf-8?B?ZTczVjlSdGRmdHBtTDVyYjhjdVAwKy9kYlNtRStyUnE0TUY2ZWM3Z01xYzc4?= =?utf-8?B?TWxsYUhLV0NGby9hdWFpb2x2TW5HdjdSY2tscGYra2N0OGRPUmg2dE15cTM3?= =?utf-8?B?ZzJLaVZmbk12aFJrMnFNa3BOdlNna0NWYW55QkdZNGNrZGNsMnNhY2N0RU5P?= =?utf-8?B?dVQ4QjhaZ0tPRzJDNHU2UzZyRjZDWGY2d3JKN0dNaVRBNDZyY3BzQyt1REdi?= =?utf-8?B?eWpmN1hDU1ZSZjBEMStOK2VHUE1JWWNkZzVUT1ZSZFFoVC9sb3pzcHMxaFRi?= =?utf-8?B?QWpOWmY2cDFITEduRGhHbUlhVXVhRXFxYkgwZHZHRVZUZ3hwTTJydFZZOTQx?= =?utf-8?B?TEx6bzN5eW5CZ01vQmE4Tm9xQmJlU1dERndXZ1ljaTFCNmtWc2wxTk5ObnNr?= =?utf-8?B?OG94VEk5WTNNa29mVkMydE5UK09uN2xHYTluRjdMYjdUQlpVUkJYdz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28054244-f50a-40b3-f13d-08de7ab8e28a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2026 13:12:42.5947 (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: sBbeDQRxhrljUYdWnjGDRb9I+ky2luITdQLWh5lSm1bvtGhpS4i/JHyzxh/uPMY7CWZ4PZKL+oFmAtEOQ2kFYVownT60yPoJUUsX2/yApxs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR03MB7431 SmFuIEJldWxpY2ggd3JvdGU6DQo+ID4gKyAgICBkLT5jbGFpbV9ub2RlID0gTlVNQV9OT19OT0RF Ow0KPiANCj4gSWYsIGFzIHRoZSBjb3ZlciBsZXR0ZXIgc2F5cywgdGhlIG5ldyBkb21jdGwgaXMg Z29pbmcgdG8gYWxsb3cgY2xhaW1pbmcgZnJvbQ0KPiBtdWx0aXBsZSBub2RlcyBpbiBvbmUgZ28s IHdoeSB3b3VsZCB0aGlzIG5ldyBmaWVsZCBzdGlsbCBiZSBuZWNlc3Nhcnk/DQoNClJvZ2VyIHJl cXVlc3RlZCB0aGUgZG9tY3RsIEFQSSB0byBhbGxvdyBjbGFpbWluZyBmcm9tIG11bHRpcGxlIG5v ZGVzIGluIG9uZSBnbw0KYW5kIGhlIHNwZWNpZmllZCB0aGF0IHdlIHNob3VsZCBmb2N1cyBvbiBn ZXR0aW5nIHRoZSBpbXBsZW1lbnRhdGlvbiBmb3Igb25lDQpub2RlLXNwZWNpZmljIGNsYWltIGRv bmUgZmlyc3QgYmVmb3JlIHdlIGRpdmUgaW50byBtdWx0aS1ub2RlIGNsYWltcyBjb2RlLg0KDQot IEluc3RlYWQgb2YgYWRkaW5nL2xpbmtpbmcgYW4gYXJyYXkgb2YgY2xhaW1zIHRvIHN0cnVjdCBk b21haW4sIHdlIGNhbiBrZWVwDQogIHVzaW5nIGQtPm91dHN0YW5kaW5nX3BhZ2VzIGZvciB0aGUg c2luZ2xlLW5vZGUgY2xhaW0uDQoNCi0gVGhlcmUgYXJlIG51bWVyb3VzIGNvbW1lbnRzIGFuZCBx dWVzdGlvbnMgZm9yIHRoaXMgbWluaW1hbCBpbXBsZW1lbnRhdGlvbi4NCiAgSWYgd2UnZCBhZGQg bXVsdGktbm9kZSBjbGFpbXMgdG8gaXQsIHRoaXMgcmV2aWV3IG1heSBiZWNvbWUgZXZlbiBtb3Jl IGNvbXBsZXguDQoNCi0gVGhlIHNpbmdsZS1ub2RlIGNsYWltcyBiYWNrZW5kIGNvbnRhaW5zIHRo ZSBpbmZyYXN0cnVjdHVyZSBhbmQgbXVsdGktbm9kZQ0KICBjbGFpbXMgd291bGQgYmUgYW4gZXh0 ZW5zaW9uIG9uIHRvcCBvZiB0aGF0IGluZnJhc3RydWN0dXJlLg0KICANCldlJ3ZlIGEgdGhyZWFk IHdoZXJlIEkgYWRkZWQgdGhlIGxpbmtzIHRvIHRoZSBwYXN0IGRpc2N1c3Npb24gaGVyZToNCmh0 dHBzOi8vbGlzdHMueGVucHJvamVjdC5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAyNi0w Mi9tc2cwMTQwMy5odG1sDQoNCj4gPiArc3RhdGljIHVuc2lnbmVkIGxvbmcgbm9kZV9vdXRzdGFu ZGluZ19jbGFpbXNbTUFYX05VTU5PREVTXTsNCj4gDQo+IEhvdyBjb21lIHRoaXMgaXMgYmVpbmcg YWRkZWQsIHJhdGhlciB0aGFuIGl0IHJlcGxhY2luZyBvdXRzdGFuZGluZ19jbGFpbXM/DQoNClRo ZSBnbG9iYWwgb3V0c3RhbmRpbmdfY2xhaW1zIHZhcmlhYmxlIGNvdW50cyB0aGUgaG9zdC1sZXZl bCBjbGFpbWVkIHBhZ2VzLg0KDQpJdCBoYXMgdGhlIHN1bSBvZiBhbGwgaG9zdC1sZXZlbCBjbGFp bXMgdGhhdCBhcmUgbm90IHNwZWNpZmljIHRvIGEgTlVNQSBub2RlDQphbmQgYWxzbyB0aGUgc3Vt IG9mIGFsbCBub2RlLXNwZWNpZmljIGNsYWltcyAoc2VlIG1vcmUgb24gdGhhdCBpbiBhbiBhbnN3 ZXINCnRvIGFub3RoZXIgcXVlc3Rpb24gZnVydGhlciBiZWxvdykuDQoNCklmIHdlIHdlcmUgdG8g cmVwbGFjZSBpdCwgd2UnZCBub3QgaGF2ZSB0aGUgb3V0c3RhbmRpbmdfY2xhaW1zIGNvdW50ZXIs DQp3aGljaCB3b3VsZCByZXN1bHQgaW4gbm90IHN1cHBvcnRpbmcgZ2xvYmFsIGNsYWltcyBhbnlt b3JlIGluIFhlbi4NCg0KSWYgYSB0b29sc3RhY2sgd291bGQgd2FudCB0byBjbGFpbSBtb3JlIG1l bW9yeSB0aGFuIGEgc2luZ2xlIE5VTUEgbm9kZQ0KaGFzLCBzb21lb25lIHdvdWxkIGhhdmUgdG8g Z28gbG9vcCBvdmVyIGFsbCBOVU1BIG5vZGVzIHdpdGggZW5vdWdoIG1lbW9yeQ0KYW5kIHNwbGl0 IHRoZSBjbGFpbSBhY3Jvc3MgYSBudW1iZXIgb3IgcGVyLU5VTUEtbm9kZSBjbGFpbXMuDQoNCi0g VGhpcyB3b3VsZCBiZSBsZXNzIGZsZXhpYmxlIHRoYW4gd2hhdCB3ZSBoYXZlIHdpdGggaXQ6IFdp dGggaXQsIHdlIGNhbg0KICBzdGlsbCBzdXBwb3J0IGhvc3QtbGV2ZWwgY2xhaW1zIHdpdGhvdXQg dGhvc2UgY2xhaW1zIGJlIHBsYWNlZCBvbg0KICBzcGVjaWZpYyBOVU1BIG5vZGVzLg0KDQotIFRo aXMgYWxsb3dzIGZvciBtYW55IGRvbWFpbnMgdG8gYmUgYnVpbHQgaW4gcGFyYWxsZWwgd2hlcmUg c29tZQ0KICBkb21haW5zIGFyZSBidWlsdCB3aXRoIGNsYWltcyBzcGVjaWZpYyB0byBzcGVjaWZp YyBOVU1BIG5vZGVzLCB3aGlsZQ0KICBhbGxvd2luZyB0aGUgb3RoZXIgZG9tYWlucyBhcmUgYnVp bHQgZHluYW1pY2FsbHkgYXQgYWxsb2NhdGlvbiB0aW1lDQogIGZyb20gYW55IHJlbWFpbmluZyBt ZW1vcnkgd2hlcmV2ZXIgdGhhdCBtZW1vcnkgcmVtYWlucyB0byBiZSBhdmFpbGFibGUuDQogIA0K LSBUaGVyZSBhcmUgdXNlIGNhc2VzIHdoZXJlIHRoZSBtZW1vcnkgb2Ygc29tZSBkb21haW5zIHNo YWxsIGJlIHNwcmVhZA0KICBhY3Jvc3MgTlVNQSBub2RlcyB0byBoYXZlIHRoZSBtZW1vcnkgYmFu ZHdpZHRoIG9mIHRob3NlIE5VTUEgbm9kZXMNCiAgYXZhaWxhYmxlIHRvIHRoZSBpbmRpdmlkdWFs IHByb2Nlc3NlcyBpbiB0aGUgZ3Vlc3QgZG9tYWluIGJ1dCBzdGlsbA0KICB3YW50IHRoZSBhc3N1 cmFuY2Ugb2YgaG9zdC1sZXZlbCBjbGFpbXMgZm9yIGNsYWltZWQgbWVtb3J5IHdoZW4NCiAgY29u c3RydWN0aW5nIG9mIG1hbnkgZG9tYWlucyBpbiBwYXJhbGxlbCBvbiBhIGhvc3QuDQoNCj4gPiAr LyogUmV0dXJuIGF2YWlsYWJsZSBwYWdlcyBhZnRlciBzdWJ0cmFjdGluZyBjbGFpbWVkIHBhZ2Vz ICovDQo+ID4gK3N0YXRpYyBpbmxpbmUgdW5zaWduZWQgbG9uZyBhdmFpbGFibGVfYWZ0ZXJfY2xh aW1zKHVuc2lnbmVkIGxvbmcNCj4gYXZhaWxfcGFnZXMsDQo+ID4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2lnbmVkIGxvbmcgY2xhaW1zKQ0K PiA+ICt7DQo+ID4gKyAgICBCVUdfT04oY2xhaW1zID4gYXZhaWxfcGFnZXMpOw0KPiA+ICsgICAg cmV0dXJuIGF2YWlsX3BhZ2VzIC0gY2xhaW1zOyAvKiBEdWUgdG8gdGhlIEJVR19PTiwgaXQgY2Fu bm90IGJlIG5lZ2F0aXZlDQo+ICovDQo+ID4gK30NCj4gDQo+IEEgaGVscGVyIGZvciBhIHNpbXBs ZSBzdWJ0cmFjdGlvbj8NCg0KSXQgaXMgYWJvdXQgbm90IGhhdmluZyB0byByZXBlYXQgdGhlIEJV R19PTihjbGFpbXMgPiBhdmFpbF9wYWdlcykgZXZlcnl3aGVyZS4NCg0KQWxzbywgdGhlIG5hbWUg b2YgdGhlIGhlbHBlciBtYWtlcyBjbGVhciB3aGF0IHRoZSByZXN1bHQgb2YgdGhlIGV4cHJlc3Np b24gaXMsDQpTbyB3aGVuIHVzaW5nIGl0LCB0aGUgZmxvdyBvZiB0aGUgY29kZSBpcyBtb3JlIG5h dHVyYWwgdG8gdW5kZXJzdGFuZC4NCg0KSGF2aW5nIHRvIHJlcGVhdCB0aGUgQlVHX09OKCkgZXZl cnl3aGVyZSB3b3VsZCBtYWtlIHRoZSBjb2RlIGxlc3MgcmVhZGFibGUuDQpUaGUgQlVHX09OKCkg aXMgZ29vZCB3aGVuIHJlZmFjdG9yaW5nIGFzIGEgZ3VhcmRyYWlsIHdoZW4geW91IGJyb2tlIHRo ZSBjb2RlLg0KDQo+ID4gKy8qIEFuc3dlciBpZiBob3N0LWxldmVsIG1lbW9yeSBhbmQgY2xhaW1z IHBlcm1pdCB0aGlzIHJlcXVlc3QgdG8gcHJvY2VlZCAqLw0KPiA+ICtzdGF0aWMgaW5saW5lIGJv b2wgaG9zdF9hbGxvY2F0YWJsZV9yZXF1ZXN0KGNvbnN0IHN0cnVjdCBkb21haW4gKmQsDQo+ID4g KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50 IG1lbWZsYWdzLA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHVuc2lnbmVkIGxvbmcgcmVxdWVzdCkNCj4gPiArew0KPiA+ICsgICAgdW5zaWduZWQgbG9u ZyBhbGxvY2F0YWJsZV9wYWdlczsNCj4gPiArDQo+ID4gKyAgICBBU1NFUlQoc3Bpbl9pc19sb2Nr ZWQoJmhlYXBfbG9jaykpOw0KPiA+ICsNCj4gPiArICAgIGFsbG9jYXRhYmxlX3BhZ2VzID0gYXZh aWxhYmxlX2FmdGVyX2NsYWltcyh0b3RhbF9hdmFpbF9wYWdlcywNCj4gPiArICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvdXRzdGFuZGluZ19jbGFpbXMpOw0K PiA+ICsgICAgaWYgKCBhbGxvY2F0YWJsZV9wYWdlcyA+PSByZXF1ZXN0ICkNCj4gPiArICAgICAg ICByZXR1cm4gdHJ1ZTsgLyogVGhlIG5vdCBjbGFpbWVkIHBhZ2VzIGFyZSBlbm91Z2ggdG8gcHJv Y2VlZCAqLw0KPiA+ICsNCj4gPiArICAgIGlmICggIWQgfHwgKG1lbWZsYWdzICYgTUVNRl9ub19y ZWZjb3VudCkgKQ0KPiA+ICsgICAgICAgIHJldHVybiBmYWxzZTsgLyogQ2xhaW1zIGFyZSBub3Qg YXZhaWxhYmxlIGZvciB0aGlzIGFsbG9jYXRpb24gKi8NCj4gPiArDQo+ID4gKyAgICAvKiBUaGUg ZG9tYWluJ3MgY2xhaW1zIGFyZSBhdmFpbGFibGUsIHJldHVybiB0cnVlIGlmIHN1ZmZpY2llbnQg Ki8NCj4gPiArICAgIHJldHVybiByZXF1ZXN0IDw9IGFsbG9jYXRhYmxlX3BhZ2VzICsgZC0+b3V0 c3RhbmRpbmdfcGFnZXM7DQo+ID4gK30NCj4gDQo+IFRoaXMgb25seSB1c2VzIHZhcmlhYmxlcyB3 aGljaCBleGlzdGVkIGJlZm9yZSwgaS5lLiB0aGVyZSdzIG5vdGhpbmcgTlVNQS1pc2gNCj4gaW4g aGVyZS4gV2hhdCdzIHRoZSBkZWFsPw0KDQpUaGUgZGVhbCBpcyB0aGF0IGZvciB0YWtpbmcgdW5j bGFpbWVkIG1lbW9yeSBiZXlvbmQgdGhlIHJlbWFpbmluZyBjbGFpbXMNCkludG8gYWNjb3VudCBm b3IgZGVjaWRpbmcgdGhhdCB0aGUgaG9zdCBoYXMgdXNhYmxlIG1lbW9yeSBmb3IgYSBkb21haW4g d2l0aA0KYSBjbGFpbSwgdGhlIG5lZWRlZCBpZi1leHByZXNzaW9uIHdvdWxkIGJlIHF1aXRlIGNv bXBsaWNhdGVkIHRvIHVuZGVyc3RhbmQuDQpXaGVuIGZhY3RvcmluZyB0aGlzIGxvZ2ljIGludG8g YW4gaWYgZXhwcmVzc2lvbiB3aXRob3V0IGV4dHJhY3RpbmcgaXQgaW50bw0KYSBmdW5jdGlvbiwg aXQgd291bGQgYmxvYXQgZmxvdyBhbGxvY19oZWFwX3BhZ2VzKCksIGVzcGVjaWFsbHkgaWYgb25l IHdvdWxkDQp3YW50IHRvIGhhdmUgdGhlIGNvbW1lbnRzLiBJJ20gbm90IHN1cmUgaWYgdGhpcyBp cyBhIGdvb2QgaWRlYS4NCg0KPiA+ICsvKiBBbnN3ZXIgaWYgbm9kZS1sZXZlbCBtZW1vcnkgYW5k IGNsYWltcyBwZXJtaXQgdGhpcyByZXF1ZXN0IHRvIHByb2NlZWQgKi8NCj4gPiArc3RhdGljIGlu bGluZSBib29sIG5vZGVfYWxsb2NhdGFibGVfcmVxdWVzdChjb25zdCBzdHJ1Y3QgZG9tYWluICpk LA0KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuc2ln bmVkIGludCBtZW1mbGFncywNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1bnNpZ25lZCBsb25nIHJlcXVlc3QsDQo+ID4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9kZWlkX3Qgbm9kZSkNCj4gPiArew0KPiA+ICsg ICAgdW5zaWduZWQgbG9uZyBhbGxvY2F0YWJsZV9wYWdlczsNCj4gPiArDQo+ID4gKyAgICBBU1NF UlQoc3Bpbl9pc19sb2NrZWQoJmhlYXBfbG9jaykpOw0KPiA+ICsgICAgQVNTRVJUKG5vZGUgPCBN QVhfTlVNTk9ERVMpOw0KPiA+ICsNCj4gPiArICAgIGFsbG9jYXRhYmxlX3BhZ2VzID0gYXZhaWxh YmxlX2FmdGVyX2NsYWltcyhub2RlX2F2YWlsX3BhZ2VzKG5vZGUpLA0KPiA+ICsNCj4gbm9kZV9v dXRzdGFuZGluZ19jbGFpbXMobm9kZSkpOw0KPiA+ICsgICAgaWYgKCBhbGxvY2F0YWJsZV9wYWdl cyA+PSByZXF1ZXN0ICkNCj4gPiArICAgICAgICByZXR1cm4gdHJ1ZTsgLyogVGhlIG5vdCBjbGFp bWVkIHBhZ2VzIGFyZSBlbm91Z2ggdG8gcHJvY2VlZCAqLw0KPiA+ICsNCj4gPiArICAgIGlmICgg IWQgfHwgKG1lbWZsYWdzICYgTUVNRl9ub19yZWZjb3VudCkgfHwgKG5vZGUgIT0gZC0+Y2xhaW1f bm9kZSkgKQ0KPiA+ICsgICAgICAgIHJldHVybiBmYWxzZTsgLyogQ2xhaW1zIGFyZSBub3QgYXZh aWxhYmxlIGZvciB0aGlzIGFsbG9jYXRpb24gKi8NCj4gPiArDQo+ID4gKyAgICAvKiBUaGUgZG9t YWluJ3MgY2xhaW1zIGFyZSBhdmFpbGFibGUsIHJldHVybiB0cnVlIGlmIHN1ZmZpY2llbnQgKi8N Cj4gPiArICAgIHJldHVybiByZXF1ZXN0IDw9IGFsbG9jYXRhYmxlX3BhZ2VzICsgZC0+b3V0c3Rh bmRpbmdfcGFnZXM7DQo+ID4gK30NCj4gDQo+IEFuZCB0aGlzIGlzIHRoZSBOVU1BIGNvdW50ZXJw YXJ0LCBhbG1vc3QgaWRlbnRpY2FsIGluIHRoZSBiYXNpYyBsb2dpYy4gSWYNCg0KWWVzLCBhbmQg dGhpcyBpcyBpbnRlbnRpb25hbDogVGhlIHNhbWUgc2ltcGxlIGNoZWNrIGp1c3Qgd2l0aCBwZXIt bm9kZSBjbGFpbXMuDQoNCj4gKGZvciB3aGF0ZXZlciByZWFzb24pIGJvdGggYXJlIHJlYWxseSBu ZWVkZWQsIEkgdGhpbmsgaXQgc2hvdWxkIGF0IGxlYXN0IGJlDQoNClRoZSByZWFzb24gaXMgdGhh dCBzdGFraW5nIGNsYWltcyBpcyB0aGUgZWFzeSBwYXJ0LiBQcm90ZWN0aW5nIGNsYWltcyBpcyB0 aGUNCihhIGJpdCkgdHJpY2t5IHBhcnQsIHdoaWNoIGlzIHdoYXQgc3VjaCBmdW5jdGlvbnMgYXJl IGhlbHBpbmcgd2l0aC4NCg0KPiBjb25zaWRlcmVkIHRvIGZvbGQgdGhlbSAod2l0aCBOVU1BX05P X05PREUgaW5kaWNhdGluZyB0aGUgbm9uLU5VTUEgaW50ZW50KS4NCj4gSW4gZmFjdCB0aGUgbm9k ZSAhPSBkLT5jbGFpbV9ub2RlIHdvdWxkIHByb2JhYmx5IGFsc28gYXBwbHkgdG8gdGhlIG5vbi1O VU1BDQo+IHZhcmlhbnQgKGFzIGQtPmNsYWltX25vZGUgIT0gTlVNQV9OT19OT0RFKS4NCiANClRo YXQncyBub3QgdHJ1ZTogVGhlIHN1bSBvZiBhbGwgbm9kZS1zcGVjaWZpYyBjbGFpbXMgc2hvdWxk IGFsc28gYmUgcGFydA0Kb2YgdGhlIGdsb2JhbCBob3N0LWxldmVsIG91dHN0YW5kaW5nX2NsYWlt cyBjb3VudGVyIHNvIHRoZSBob3N0LWxldmVsIGNoZWNrDQpvZiBhbiBhbGxvY2F0aW9uIG1heSBw cm9jZWVkIHJlZ2FyZGluZyBjbGFpbXMgaW5jb3Jwb3JhdGVzIHRoZSBjaGVjayBpZg0Kbm9kZS1z cGVjaWZpYyBjbGFpbXMgd291bGQgKGluIHRoZW9yeSkgYWxsb3cgYSBob3N0LWxldmVsIGFsbG9j IHRvIHByb2NlZWQuDQoNClRoYXQgbWVhbnMgdGhhdCBmb3IgdGhlIGhvc3QtbGV2ZWwgY2xhaW1z IHByb3RlY3Rpb24gY2hlY2sgZm9yIGEgZG9tYWluLA0KdGhlIGNsYWltcyBvZiB0aGUgZG9tYWlu IG11c3QgYmUgYWNjb3VudGVkLCBldmVuIGlmIHRoZXkgYXJlIG5vZGUtc3BlY2lmaWMuDQoNClRo dXMsIGBub2RlICE9IGQtPmNsYWltX25vZGVgIGRvZXMgbm90IGFwcGx5IGlmIGBub2RlICE9IE5V TUFfTk9fTk9ERWAsDQpZZXMsIEkgc2hvdWxkIG1lcmdlIHRoZSBmdW5jdGlvbnMsIGJ1dCB0aGlz IGNoZWNrIGlzIG9ubHkgZm9yIG5vZGUtY2xhaW1zLg0KDQo+IEFzIHRvIHRoZSBjb21tZW50cyBp biBib3RoIGZ1bmN0aW9ucywgcGVyc29uYWxseSBJIHRoaW5rDQo+IHMvbm90IGNsYWltZWQvdW5j bGFpbWVkLyB3b3VsZCBiZSBzbGlnaHRseSBtb3JlIGxvZ2ljYWwgdG8gZm9sbG93Lg0KPiANCj4g SW4gYW55IGV2ZW50LCB0aGUgZmlyc3Qgb2YgdGhlc2UgZnVuY3Rpb24gbG9va3MgbGlrZSBpdCBj b3VsZCBiZSBzcGxpdCBvdXQNCj4gaW4gYSBzZXBhcmF0ZSwgZWFybGllciBwYXRjaC4gVGhlbiAo YXMgcGVyIGFib3ZlKSBpZGVhbGx5IGhlcmUgdGhhdCBmdW5jdGlvbg0KPiB3b3VsZCBzaW1wbHkg YmUgZXh0ZW5kZWQgdG8gYmVjb21lIE5VTUEtY2FwYWJsZS4NCg0KWWVzIGluZGVlZCwgR29vZC4N Cg0KPiA+ICsgICAgaWYgKCBkLT5vdXRzdGFuZGluZ19wYWdlcyA9PSAwICkNCj4gPiArICAgICAg ICBkLT5jbGFpbV9ub2RlID0gTlVNQV9OT19OT0RFOyAvKiBDbGVhciBpZiBubyBvdXRzdGFuZGlu ZyBwYWdlcyBsZWZ0DQo+IA0KPiBJIGZlYXIgSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMuIElmIHRo ZSBkb21haW4gaGFzIGNsYWltcyBvbiBvdGhlciBub2RlcywNCj4gd2h5IHdvdWxkIHdvdWxkIGl0 IGJlIHN3aXRjaGVkIGJhY2sgdG8gbm9uLU5VTUEgY2xhaW1zPw0KDQooIGQtPm91dHN0YW5kaW5n X3BhZ2VzID09IDAgKSBtZWFucyBkIGhhcyBubyBjbGFpbSBsZWZ0OiBOb25lLWF0LWFsbC4NCkFz IHRoZXJlIGlzIG5vbmUgbGVmdCwgbm90aW5nIGlzIHN3aXRjaGVkLCBjbGFpbXMgYXJlIHJlc2V0 IHRvIHRoZSBuby1jbGFpbSBzdGF0ZS4NCg0KPiA+IEBAIC01NjQsMTQgKzY0Miw0MSBAQCB2b2lk IGNvbnN1bWVfb3V0c3RhbmRpbmdfY2xhaW1zKHN0cnVjdCBkb21haW4gKmQsDQo+IHVuc2lnbmVk IGxvbmcgYWxsb2NhdGlvbikNCj4gPg0KPiA+ICAgICAgLyogT2YgY291cnNlLCB0aGUgZG9tYWlu IGNhbiBvbmx5IHJlbGVhc2UgdXAgaXRzIG91dHN0YW5kaW5nIGNsYWltcyAqLw0KPiA+ICAgICAg YWxsb2NhdGlvbiA9IG1pbihhbGxvY2F0aW9uLCBkLT5vdXRzdGFuZGluZ19wYWdlcyArIDBVTCk7 DQo+ID4gKw0KPiA+ICsgICAgaWYgKCBkLT5jbGFpbV9ub2RlICE9IE5VTUFfTk9fTk9ERSAmJiBk LT5jbGFpbV9ub2RlICE9IGFsbG9jX25vZGUgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIC8q DQo+ID4gKyAgICAgICAgICogVGhlIGRvbWFpbiBoYXMgYSBjbGFpbSBvbiBhIG5vZGUsIGJ1dCB0 aGUgYWxsb2MgaXMgb24gYSBkaWZmZXJlbnQNCj4gPiArICAgICAgICAgKiBub2RlLiBJZiBpdCB3 b3VsZCBleGNlZWQgdGhlIGRvbWFpbidzIG1heF9wYWdlcywgcmVkdWNlIHRoZSBjbGFpbQ0KPiA+ ICsgICAgICAgICAqIHVwIHRvIHRoZSBleGNlc3Mgb3ZlciBtYXhfcGFnZXMgc28gd2UgZG9uJ3Qg cmVkdWNlIHRoZSBjbGFpbSBtb3JlDQo+ID4gKyAgICAgICAgICogdGhhbiB3ZSBoYXZlIHRvIHRv IGhvbm9yIHRoZSBtYXhfcGFnZXMgbGltaXQuDQo+ID4gKyAgICAgICAgICovDQo+ID4gKyAgICAg ICAgdW5zaWduZWQgbG9uZyBib29rZWRfcGFnZXMgPSBkb21haW5fdG90X3BhZ2VzKGQpICsgYWxs b2NhdGlvbiArDQo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkLT5v dXRzdGFuZGluZ19wYWdlczsNCj4gPiArICAgICAgICBpZiAoIGJvb2tlZF9wYWdlcyA8PSBkLT5t YXhfcGFnZXMgKQ0KPiA+ICsgICAgICAgICAgICByZXR1cm47IC8qIGJvb2tlZCBpcyB3aXRoaW4g bWF4X3BhZ2VzLCBubyBleGNlc3MsIGtlZXAgdGhlIGNsYWltDQo+ICovDQo+ID4gKw0KPiA+ICsg ICAgICAgIC8qIEV4Y2VzcyBkZXRlY3RlZCwgcmVsZWFzZSB0aGUgZXhjZWVkaW5nIHBhZ2VzIGZy b20gdGhlIGNsYWltZWQNCj4gbm9kZSAqLw0KPiA+ICsgICAgICAgIGFsbG9jYXRpb24gPSBtaW4o YWxsb2NhdGlvbiwgYm9va2VkX3BhZ2VzIC0gZC0+bWF4X3BhZ2VzKTsNCj4gPiArICAgIH0NCj4g PiAgICAgIHJlbGVhc2Vfb3V0c3RhbmRpbmdfY2xhaW1zKGQsIGFsbG9jYXRpb24pOw0KPiANCj4g UGxlYXNlIGNhbiB0aGVyZSBiZSBhbm90aGVyIGJsYW5rIGxpbmUgYWJvdmUgdGhpcyBvbmU/DQo+ IA0KPiBXaHkgaXMgdGhlIGFkanVzdG1lbnQgbWFkZSBleGNsdWRlZCBmb3IgdGhlIE5VTUFfTk9f Tk9ERSBjYXNlPyBUaGF0J3Mgb2RkIGluDQoNCldoZW4gdGhlIGRvbWFpbidzIGNsYWltIGlzIGds b2JhbCwgdGhlIGFsbG9jYXRpb24ganVzdCBjb25zdW1lIGZyb20gdGhpcyBjbGFpbS4NCg0KPiBp dHNlbGYsIGJ1dCBwYXJ0aWN1bGFybHkgd2l0aCByZWxlYXNlX291dHN0YW5kaW5nX2NsYWltcygp IHBvc3NpYmx5IHN3aXRjaGluZyBhDQo+IGRvbWFpbiB0byBOVU1BX05PX05PREUuDQogDQpDb21t ZW50ZWQgYWJvdmUsIGl0cyBub3Qgc3dpdGNoaW5nIHdpdGggemVybyBjbGFpbXMsIGl0IGp1c3Qg cmVzZXRzIHRoZSBzdGF0ZS4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICBQbHVzIHRoZSBj YWxsZXIgbG9va3MgdG8gYmUgcGFzc2luZyBpbiB0aGUgYWN0dWFsIG5vZGUNCj4gbWVtb3J5IHdh cyB0YWtlbiBmcm9tLCBub3Qgd2hhdCB0aGUgb3JpZ2luYWwgcmVxdWVzdCBzYWlkICh3aGljaCBp cw0KPiBzcGVjaWZpY2FsbHkgcmVsZXZhbnQgd2hlbiB0aGUgcmVxdWVzdCBuYW1lZCBubyBwYXJ0 aWN1bGFyIG5vZGUpLg0KDQpGb3IgdGhpcyBjaGVjaywgdGhlIHRhcmdldCBvZiB0aGUgaW5pdGlh bCBhbGxvY2F0aW9uIHJlcXVlc3QgZG9lcyBub3QgbWF0dGVyLg0KV2hhdCBtYXR0ZXJzIGhlcmUg aXMgdGhhdCBmb3Igd2hhdGV2ZXIgcmVhc29uIHdoZW4gYW4gYWxsb2NhdGlvbiBlbmRzIHVwIG5v dA0KYmVpbmcgbWFkZSBvbiBhIE5VTUEgbm9kZSB0aGUgZG9tYWluIGhhcyBhIG5vZGUtc3BlY2lm aWMgY2xhaW0gb24sIGFuZCB0aGlzDQphbGxvY2F0aW9uIHdvdWxkIGV4Y2VlZCB0aGUgY2xhaW1l ZCArIGFsbG9jYXRlZCBtZW1vcnkgYmV5b25kIGQtPm1heF9wYWdlcywgd2UNCnNob3VsZCByZWxl YXNlIGFuZCBjb25zdW1lIHRoZSBzaXplIG9mIGNsYWltcyB0aGF0IHdvdWxkIGV4Y2VlZCBkLT5t YXhfcGFnZXMuDQoNClRoZXJlIGlzIGEgYnVnIGhlcmUgdGhhdCBJIGFscmVhZHkgZml4IGluIG15 IGRyYWZ0IGZvciBhIHY1IHNlcmllczogSXQgbmVlZHMgdG8NClVzZSB0aGUgc2l6ZSBvZiB0aGUg ZnVsbCBhbGxvY2F0aW9uIHRvIGNhbGN1bGF0ZSB0aGUgZXhjZXNzIGJleW9uZCBkLT5tYXhfcGFn ZXMsDQpub3QgdGhlIG1pbigpIG9mIHRoZSBhbGxvY2F0aW9uIHNpemUgYW5kIGQtPm91dHN0YW5k aW5nX2NsYWltcy4gV2lsbCBiZSBmaXhlZC4NCg0KPiA+ICsgLyogV2hlbiByZWxlYXNpbmcgYSBj bGFpbSwgdGhlIG5vZGUgbXVzdCBiZSBOVU1BX05PX05PREUgKGl0IGlzIG5vdCB1c2VkKSAqLw0K PiANCj4gV2h5IHdvdWxkIHRoaXMgYmU/DQoNCkkgbmVlZCB0byBmaXggdGhlIGNvbW1lbnQ6IEl0 IHNob3VsZCBzYXkgInJlc2V0dGluZyIuIFdoZW4gcmVzZXR0aW5nIGNsYWltcyB0byAwLA0Kd2hp Y2ggaXMgZG9uZSBieSBsaWJ4ZW5ndWVzdCBhZnRlciBpdCBoYXMgY29tcGxldGVkIHBvcHVsYXRp bmcgdGhlIGd1ZXN0IG1lbW9yeSwNCndlIGFyZSBub3QgcGFzc2luZyBhIE5VTUEgbm9kZSBhbmQg YXMgdGhpcyBmdW5jdGlvbiByZWplY3RzIGFueSB1cGRhdGVzIG9mIGFuDQpleGlzdGluZyBjbGFp bSBiZXNpZGVzIHJlc2V0dGluZyBpdCB1c2luZyAwLCB0aGUgcmVzZXQgc2hhbGwgYWx3YXlzIGFw cGx5IHRvIGFsbA0KY2xhaW1zIG9mIHRoZSBkb21haW4sIGluZGVwZW5kZW50IHdoaWNoIGNsYWlt cyBpdCBoYXMgKGV2ZW4gbXVsdGktbm9kZSBjbGFpbXMpLg0KUm9nZXIgYWRkZWQgdGhpcyBjaGVj ayB0byBtYWtlIGl0IGNsZWFyIHRoYXQgd2UgZXhwZWN0IE5VTUFfTk9fTk9ERSB3aXRoIHRoaXMg Y2FsbC4NCg0KPiA+ICAgICAgICAgIGlmICggKG1lbWZsYWdzICYgTUVNRl9leGFjdF9ub2RlKSAm JiByZXFfbm9kZSAhPSBOVU1BX05PX05PREUgKQ0KPiA+ICAgICAgICAgICAgICByZXR1cm4gTlVM TDsNCj4gDQo+IEFzIHBlciB0aGlzLCAuLi4NCj4gDQo+ID4gQEAgLTEwNDIsMTMgKzExNjQsOCBA QCBzdGF0aWMgc3RydWN0IHBhZ2VfaW5mbyAqYWxsb2NfaGVhcF9wYWdlcygNCj4gPg0KPiA+ICAg ICAgc3Bpbl9sb2NrKCZoZWFwX2xvY2spOw0KPiA+DQo+ID4gLSAgICAvKg0KPiA+IC0gICAgICog Q2xhaW1lZCBtZW1vcnkgaXMgY29uc2lkZXJlZCB1bmF2YWlsYWJsZSB1bmxlc3MgdGhlIHJlcXVl c3QNCj4gPiAtICAgICAqIGlzIG1hZGUgYnkgYSBkb21haW4gd2l0aCBzdWZmaWNpZW50IHVuY2xh aW1lZCBwYWdlcy4NCj4gPiAtICAgICAqLw0KPiA+IC0gICAgaWYgKCAob3V0c3RhbmRpbmdfY2xh aW1zICsgcmVxdWVzdCA+IHRvdGFsX2F2YWlsX3BhZ2VzKSAmJg0KPiA+IC0gICAgICAgICAgKCht ZW1mbGFncyAmIE1FTUZfbm9fcmVmY291bnQpIHx8DQo+ID4gLSAgICAgICAgICAgIWQgfHwgZC0+ b3V0c3RhbmRpbmdfcGFnZXMgPCByZXF1ZXN0KSApDQo+ID4gKyAgICAvKiBQcm9jZWVkIGlmIGhv c3QtbGV2ZWwgbWVtb3J5IGFuZCBjbGFpbXMgcGVybWl0IHRoaXMgcmVxdWVzdCB0bw0KPiBwcm9j ZWVkICovDQo+ID4gKyAgICBpZiAoICFob3N0X2FsbG9jYXRhYmxlX3JlcXVlc3QoZCwgbWVtZmxh Z3MsIHJlcXVlc3QpICkNCj4gDQo+IC4uLiBpbiB0aGUgTUVNRl9leGFjdF9ub2RlIGNhc2UgSSBz ZWUgbGl0dGxlIHJlYXNvbiB0byBjaGVjayB0aGUgZ2xvYmFsIHZhbHVlIGhlcmUuDQoNCkFjaywg aWYgKG1lbWZsYWdzICYgTUVNRl9leGFjdF9ub2RlKSwgd2UgY2FuIHNraXAgdGhlIGhvc3Qtd2lk ZSBjaGVjayBpbmRlZWQsDQp3aGljaCB3b3VsZCBiZSBhbiBvcHRpbWlzYXRpb24gYXMgd2UnZCBu b3QgaGF2ZSB0byBsb29rIGF0IHRoZSBob3N0LWxldmVsIGNvdW50ZXJzLg0KDQo+IEphbg0KDQpU aGFua3MgZm9yIHRoaXMgcmV2aWV3LCBJJ2xsIGFwcGx5IHRob3NlIGNoYW5nZXMhDQpCZXJuaGFy ZA0K From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:17:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:17:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246622.1545735 (Exim 4.92) (envelope-from ) id 1vy8Zs-000254-88; Thu, 05 Mar 2026 13:17:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246622.1545735; Thu, 05 Mar 2026 13:17:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8Zs-00024x-5N; Thu, 05 Mar 2026 13:17:20 +0000 Received: by outflank-mailman (input) for mailman id 1246622; Thu, 05 Mar 2026 13:17:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8Zr-00024r-4Y for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:17:19 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a1c965f1-1895-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:17:17 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4837907f535so73166405e9.3 for ; Thu, 05 Mar 2026 05:17:17 -0800 (PST) Received: from [10.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-4851ad02eeesm31850625e9.19.2026.03.05.05.17.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 05:17:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a1c965f1-1895-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772716636; x=1773321436; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=qK3hnvp7XcWP7iJlZoXczRJnMIQA61rlvrgs0O3Qjro=; b=gKKqwp+mOabgy4sSe+9qrU1Hbao1myN/FSO2a0dOGXI9e5oxy/kPsvNRX7UvYsq2jW /WbSCqv42WD8j7B190uLbKvKy/KQnYJqj9E4Rtfcu8iAcZo7mockcUNVgdbqjN/e+Hu6 sX1kU6vtoS/pKjrYPW7SFNDR6DxGD/IrnDcOibdL4OGqPywefhlMz/7WluMK0sXJcMOv 04Ob0Vv/dUpmweeZii5WD18fSJy7a7/58zRZA5Wh3HFDmLpphuhr4lpSSum7zyElB37C SquYnH6st+JwPVrG3YulAjiVPs7mp7V/Vv43Wx+VbZvD5V5nFkdZ3CCIO+jeaQzgsL+9 Ppjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772716636; x=1773321436; h=content-transfer-encoding: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; bh=qK3hnvp7XcWP7iJlZoXczRJnMIQA61rlvrgs0O3Qjro=; b=oIy14jx2G2dGL7eGjGXdNDYCqNuMQBCNGTFFNFqrZfi7SiwhIWfMqthLIXk5rnE2ce tsNrx/r/+05bhXf8+iDHof0DzRV/v3FXS2l+wTzW2hxB9KyqtTN6tYqqagdUtiw28Ae7 omd0SfoVKF2XGxW6/iJdzmSd10myXiUoZ3UZFirDpkVbVjuRLkaZNG/dhDiEtT6J8faq U558MtmEjaEGKx9gUAValHS+YpWQ/W8gVbcC63JcUXVLxX7XPKu0M+tDuy11aU8OMcLb Po4uHTbDfLkwkbEqmjpOXHcStq12U0VoNLhoUCqmriBlHY3VvD1Sky64mmjr4jzu7/Nz vi9g== X-Forwarded-Encrypted: i=1; AJvYcCUFYxTghbtCH1bWZlZ7AZSFTKrgt0XSQPQLEpSIvtGydSwS1uiEjPW8L9e1cXB19BurTbSzfIhxvi8=@lists.xenproject.org X-Gm-Message-State: AOJu0YyVO8glfxs5xlJ22JHo6RYj5qzUdP7nwchNJ7+X2lL2uq8SUVnK 2Rl3A7z9vdbuDDK1Xn/kvIswJQ1ArgF7HbmhvlMUtEvjy791MBTb1Hx1l/yEi40PGg== X-Gm-Gg: ATEYQzx+lZTdcVh5R05ibQT1E+Khbn0bSJe4Yuq0f7jwZRhsueIb5LKkvclOrTKKqg4 UYMXrg64NT5FDKkiW92qhNeRXglBRBUuCrnFrgwvORuKIfdBGvXSRzzNm5Tp7BKkqHW5Gm12ijx y7SjqquMu5mODulT5lZyJNRx27b0XjcWhTlkq1uuesvONnNUBc7UWZvLRwygRjOxqc15sbBjju6 ioBltWTRVrO6QAQH3g7od956RWBFAqXmBFXc3oxRRlJSmGYkoTaHCCEuh/Pyp1Uo2KZdBX+Ttvb WKswct5iWmuP0GFGU11QK5G23ippuEDR3im7L1YTzdUxAfvEOjQccX8NAkRbYGNZVe/ZxLzdoot hTK5bkttnJeBkF27Q5AdottaxfBchA8lK9jsW/IwCL8RSznE17mg4oR9AmYlakGcPwX4Y5FduaQ gpU+VMPAeJXWGcQXzLCTj24WxB1k3Jx2eEgsuPFIedolejVWcK+epKs0ikq3Hb++NBp6ID7h+jN CujDyazZVT7ydUySbSMcnozCw== X-Received: by 2002:a05:600c:6098:b0:483:7f4e:fef6 with SMTP id 5b1f17b1804b1-485198899f3mr92595195e9.26.1772716636352; Thu, 05 Mar 2026 05:17:16 -0800 (PST) Message-ID: <6db8d016-974e-4772-b0b5-ff5dd24ba6ba@suse.com> Date: Thu, 5 Mar 2026 14:17:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] This patch just changes indentation, to make the next patch easier to review. To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260305130434.635276-1-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2026 14:04, Julian Vetter wrote: > Signed-off-by: Julian Vetter > --- > Changes in v4: > - No changes to this patch Not quite. The original subject (which already wasn't great) has disappeared, and what previously was the description is now the title. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:36:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:36:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246640.1545748 (Exim 4.92) (envelope-from ) id 1vy8sE-00055a-RP; Thu, 05 Mar 2026 13:36:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246640.1545748; Thu, 05 Mar 2026 13:36:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8sE-00055T-Ni; Thu, 05 Mar 2026 13:36:18 +0000 Received: by outflank-mailman (input) for mailman id 1246640; Thu, 05 Mar 2026 13:36:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8sD-00055N-7Y for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:36:17 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 475ac266-1898-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:36:13 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48374014a77so97281095e9.3 for ; Thu, 05 Mar 2026 05:36:13 -0800 (PST) Received: from [10.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-4851fae5dbdsm41110415e9.8.2026.03.05.05.36.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 05:36:12 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 475ac266-1898-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772717773; x=1773322573; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TeN15VvfRLf2TeAbtoLUEDpP2YthgE2+O/U8siRzkGs=; b=H3m7VAItWJzBeTRQthVOiVkZ2Vxq8uRJDYtcEmGDwR0eJekc++kzpzlLRkBPPQ1KcT mrV366aYhWmU3ttLQ2rrAd9SAnkfMqVDGuD1qwhP/vOqa1ur5+L8D6fwwCmDH2uY92kk Xov/yJ6aCKNUDyBgUkgthnA+lnkWQKIFD2PeRXjmIiqLVpaMrKArs2Kd5lfeXCnD8nJg EnLK5Svv+b6/93xhaqfPB8y0OK1BDMLBdkxewJCaxdS2B7t/leH/IzkAx+2TWiFeOMzO Qp1NyVUfquwgvSV8AeVNRu45LJhKseMAAFpdMAN01BEbnmo3zIJ3beeLSQvz1w5w3I7J GFPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772717773; x=1773322573; h=content-transfer-encoding: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; bh=TeN15VvfRLf2TeAbtoLUEDpP2YthgE2+O/U8siRzkGs=; b=vxEjIuD/eNyw+bYUIIznloyv10hLsfFvPjyrk5PBSqQyfZQ1HJtqCSfaCa8sFBotl8 q8Mq5Vl4sy3rdOLzRSeUiDMqlp8DhWMsGgRkhgNEffTeSpyNx6/Og+78ugzXE3kLQtSv fMCxD9mKDA25U/9h1lJl5ymmy7zh++9WpEvCIqjBb3h6OjaoobLf7ouETj7ksnje58w4 1DVsJYoOq1xwkuvVAZy2H5lkmK2QxJqMK5uZgOo06fnF9gqKIWXIaKyfsXQ/baq6r8Il ghTFaDyZbmQtzjAQ/TKQwFwKrsNSLGooShvk8GsjUmPbZscgs2cemnd1Z9gqvin5Tt/W kceg== X-Forwarded-Encrypted: i=1; AJvYcCVN+g/AQXjeZ32leUNBGsdbGJ2k8hP1lVwkj75XI2hec3vSI3jSZ8I/aWsSiHOK2oJ9hToH3cUqLUY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzUf2JWpI3OF7mwzbZ2E0og5KCWAtjKO2HZvFtBdYRP+sFub1pA p8eV30v8UiqtrFsZwXLCrOKMWVWajuhUyYgI1ijWwe/juL9bkCcDXXgmmNjrOwhstw== X-Gm-Gg: ATEYQzxWktgOvytHlS7OLSmlUMnk1OBzMwjMm1AwAIXSCpIntK93QDoYYV6EXi8eNQR V+jIRqWORb7VtJYSabDPlnx1Ul9sP80WsVQaM8J/v3xSZDvPqov2pJ+vSxLAGoIxByZ0sfanidd Zs1xMoilKYM6eS6xR9140uWRO/9OAiPjo2YsaKBD6+4P5rXNol0XQGHWcOGRk9EbWqFTDD5swzi UPtyHAjdkP+Kl6VuMFx3kl1fmkq96Q4ZHoMXepiqZxF2PYedNmwEW41YsWUGs6LsPl+PQb+m+Ru XbKSgfqsQhvo9I3X0XRPOEFvQZpO+C2GmLfyKfmUIjzdKrtFhwlDmN028Wtkq0nnXGj2e61w9xN 4lWr8QtzTchbxfqhpc201oFnd2zpLqrB1WeGLc/0NtHXYUoEVL10jkaXHN3TFVSk9PUi1coNmvp RxKrXMVBr1A48LNd+X2eYwZm9pgIqMGFieq/FcwDZVjdy5NlZVIUlAlOH0yPTtYeBnMu/mg3ZAp M2QBgaVThPvvfd2Y5YeOgA5+w== X-Received: by 2002:a05:600c:8b01:b0:477:7bca:8b2b with SMTP id 5b1f17b1804b1-485198554c3mr102428345e9.15.1772717773045; Thu, 05 Mar 2026 05:36:13 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 14:36:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , Marcus Granado , "xen-devel@lists.xenproject.org" , Alejandro Vallejo References: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2026 14:12, Bernhard Kaindl wrote: > Jan Beulich wrote: >>> + d->claim_node = NUMA_NO_NODE; >> >> If, as the cover letter says, the new domctl is going to allow claiming from >> multiple nodes in one go, why would this new field still be necessary? > > Roger requested the domctl API to allow claiming from multiple nodes in one go > and he specified that we should focus on getting the implementation for one > node-specific claim done first before we dive into multi-node claims code. > > - Instead of adding/linking an array of claims to struct domain, we can keep > using d->outstanding_pages for the single-node claim. > > - There are numerous comments and questions for this minimal implementation. > If we'd add multi-node claims to it, this review may become even more complex. > > - The single-node claims backend contains the infrastructure and multi-node > claims would be an extension on top of that infrastructure. What is at the very least needed is an outline of how multi-node claims are intended to work. This is because what you do here needs to fit that scheme. Which in turn I think is going to be difficult when for a domain more memory is needed than any single node can supply. Hence why I think that you may not be able to get away with just single-node claims, no matter that this of course complicates things. It's also not quite clear to me how multiple successive claims against distinct nodes would work (which isn't all that different from a multi-node claim). Thinking of it, interaction with the existing mem-op also wants clarifying. Imo only one of the two ought to be usable on a single domain. >>> +static unsigned long node_outstanding_claims[MAX_NUMNODES]; >> >> How come this is being added, rather than it replacing outstanding_claims? > > The global outstanding_claims variable counts the host-level claimed pages. > > It has the sum of all host-level claims that are not specific to a NUMA node > and also the sum of all node-specific claims (see more on that in an answer > to another question further below). > > If we were to replace it, we'd not have the outstanding_claims counter, > which would result in not supporting global claims anymore in Xen. > > If a toolstack would want to claim more memory than a single NUMA node > has, someone would have to go loop over all NUMA nodes with enough memory > and split the claim across a number or per-NUMA-node claims. > > - This would be less flexible than what we have with it: With it, we can > still support host-level claims without those claims be placed on > specific NUMA nodes. > > - This allows for many domains to be built in parallel where some > domains are built with claims specific to specific NUMA nodes, while > allowing the other domains are built dynamically at allocation time > from any remaining memory wherever that memory remains to be available. > > - There are use cases where the memory of some domains shall be spread > across NUMA nodes to have the memory bandwidth of those NUMA nodes > available to the individual processes in the guest domain but still > want the assurance of host-level claims for claimed memory when > constructing of many domains in parallel on a host. All fine, but why is this written down only in a reply to review comments, rather than right in the patch description? >>> +/* Return available pages after subtracting claimed pages */ >>> +static inline unsigned long available_after_claims(unsigned long >> avail_pages, >>> + unsigned long claims) >>> +{ >>> + BUG_ON(claims > avail_pages); >>> + return avail_pages - claims; /* Due to the BUG_ON, it cannot be negative >> */ >>> +} >> >> A helper for a simple subtraction? > > It is about not having to repeat the BUG_ON(claims > avail_pages) everywhere. Which in turn I should have said I question. Imo this is supposed to be an ASSERT(), not a BUG_ON(). > Also, the name of the helper makes clear what the result of the expression is, > So when using it, the flow of the code is more natural to understand. > > Having to repeat the BUG_ON() everywhere would make the code less readable. > The BUG_ON() is good when refactoring as a guardrail when you broke the code. I'm not quite sure there. >>> +/* Answer if host-level memory and claims permit this request to proceed */ >>> +static inline bool host_allocatable_request(const struct domain *d, >>> + unsigned int memflags, >>> + unsigned long request) >>> +{ >>> + unsigned long allocatable_pages; >>> + >>> + ASSERT(spin_is_locked(&heap_lock)); >>> + >>> + allocatable_pages = available_after_claims(total_avail_pages, >>> + outstanding_claims); >>> + if ( allocatable_pages >= request ) >>> + return true; /* The not claimed pages are enough to proceed */ >>> + >>> + if ( !d || (memflags & MEMF_no_refcount) ) >>> + return false; /* Claims are not available for this allocation */ >>> + >>> + /* The domain's claims are available, return true if sufficient */ >>> + return request <= allocatable_pages + d->outstanding_pages; >>> +} >> >> This only uses variables which existed before, i.e. there's nothing NUMA-ish >> in here. What's the deal? > > The deal is that for taking unclaimed memory beyond the remaining claims > Into account for deciding that the host has usable memory for a domain with > a claim, the needed if-expression would be quite complicated to understand. > When factoring this logic into an if expression without extracting it into > a function, it would bloat flow alloc_heap_pages(), especially if one would > want to have the comments. I'm not sure if this is a good idea. I guess I don't really follow: Right here all you do is transform a complex if() into one that calls this function, with no functional difference. This function isn't changed by subsequent patches. Hence what's the concern? That said, I don't mind breaking it out, but as said - as a separate change, and then with its NUMA counterpart preferably folded in. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:42:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:42:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246653.1545759 (Exim 4.92) (envelope-from ) id 1vy8xz-0006hC-E3; Thu, 05 Mar 2026 13:42:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246653.1545759; Thu, 05 Mar 2026 13: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 ) id 1vy8xz-0006h5-AO; Thu, 05 Mar 2026 13:42:15 +0000 Received: by outflank-mailman (input) for mailman id 1246653; Thu, 05 Mar 2026 13:42:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy8xx-0006gz-Rh for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:42:13 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1d1ff0f1-1899-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:42:12 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-439b9cf8cb5so3993530f8f.0 for ; Thu, 05 Mar 2026 05:42:12 -0800 (PST) Received: from [10.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-439af926c53sm44193969f8f.8.2026.03.05.05.42.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 05:42:11 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1d1ff0f1-1899-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772718132; x=1773322932; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=MGPu7Ut75IVW+faT5wPACbbODt9XdGXp1pSw46SMeG4=; b=A6UdqnmGGsrZP8Ukug9IqyIT80cZFxi2Rcqo9u+HCFFopA4swdpwkJrIZYsgwaJ2wd g3XY+t4mvzB84yHKyQMSyLfmsm3hgK/h6fWAnwpSvzHSjc9061bECG+vIhKA4AxoENkx j4nJYo+gkdnY2l/zFTfapCkq6mzkU9eDwPyCjY/dCVDImXYxw6Mrxb6NZkxyA+jiLGfQ F6ZttSsXzvZBuVmU2KVkA97IKnyOPq023gFdb5xywirPBN2nLzes8Sgs+BD0cxY0MzRq pbqzmi3uXxKOkNydAJpL8ZNprhBS7Ooai+AF1bQPyaiPBYAcFwRnJ4aqG2uJTCGmzur7 /Cuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772718132; x=1773322932; h=content-transfer-encoding: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; bh=MGPu7Ut75IVW+faT5wPACbbODt9XdGXp1pSw46SMeG4=; b=tFXNXe1LRqMg/Qba4dC6qwGpBXTivkwB5ycaGQts0FgFLyCXEtoQsNt7BHsh67peyU sKvtuqJgUTuvGCoPl2s03ZQFm3aJMPCRCU49irGs92acl0AwN3rAQNxFYgdLYJizPgRq N2ipJR35CPWEs6Kc3ijIONN8vklYs2p5N4XjBHVr7jpmLsoWlDBKgw4WxfjsMEAVzfY+ I9PSDjbUGT2/ReooB4iZ1aK3xtRvMhH89fsWC4jz2fmdErbZWTqXa7BDDraxsx7vd9LS z8ZIbF+VtBuxoLihwf0F1J+OM3+It9+EMfiONpV1nmQKlc2bneB3ZXdRp5uNj5dowCJt sopA== X-Forwarded-Encrypted: i=1; AJvYcCW2zXtoVmRESbqmjQYN29IPATzAOaRy+9zK3cHdQyMO0Qq0ApE3qm6klI2tLqcRh013obRA7o33zV0=@lists.xenproject.org X-Gm-Message-State: AOJu0YzDz7ustER49mZ7i6nNUMHJ5+Iim5WBEs9d0B0w9Tx2jrsh8esn LObhRgLzbq1F1osJxXXRyuKJt8QlkLqRVJ1bU15wrhJn5RAP9TZXnSd+JiyqERW6EA== X-Gm-Gg: ATEYQzwH/ENbnLPY9zkBlpEYdZrpLFMMepnzCRiUWUqilK7TfLTM5CwUsskWAZZUAEB 4mAEBBK/wZ+ofbsKheSoz1VpTPFCb0WF0TvFIelAmVzNi9knJSQEn45nEi0sSgqppQG3YYcxuFb k/voTOYoErazuH6Gx/oycum8UTxRUh8GN0Gq6Ls9BJaCdWMsQLZp9eMIVKmL65EasMsUritm2lJ L/y3fKpy7LypKnDlWDmsl2jsRKV0UyFvNgwFvf5NmM597gT/1IHIbWHAjt8spQx/dqpGVehzvyY EvqSwYQoPckyMTtKl9S6tLGzJ70bvIsfUrTyaQzfWsXQlk5lMlGAYag2ktGzT9u1bX2TxyEmdQC v8JhyIbiMuj6YLb2NCXzZXXDnCvw+IL+GvMG9oEu78ijvgbnXhyW6AbMJMqIITrz8FMn/bSjN6C COW/YKvjju5eXQ4VIAq0ZzAevnVInMdEkBFZlW0k0O2bZtcBkD7xjfeRHxK4g4zjRGUI1Pfp7+f RAvzcQ9KwA/+4w= X-Received: by 2002:a05:6000:2404:b0:439:bce5:64fb with SMTP id ffacd0b85a97d-439c7fae131mr10442482f8f.23.1772718131557; Thu, 05 Mar 2026 05:42:11 -0800 (PST) Message-ID: <2662bcd2-2403-4e43-92c9-a51b17c938f2@suse.com> Date: Thu, 5 Mar 2026 14:42:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 06/10] xsm/flask: Add XEN_DOMCTL_claim_memory to flask To: Bernhard Kaindl Cc: "Daniel P. Smith" , Anthony PERARD , xen-devel@lists.xenproject.org References: <8e5680575f37ce67a81a4c712e5409ccb3f6f612.1772098423.git.bernhard.kaindl@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <8e5680575f37ce67a81a4c712e5409ccb3f6f612.1772098423.git.bernhard.kaindl@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 26.02.2026 15:29, Bernhard Kaindl wrote: > Add a Flask security policy for the new XEN_DOMCTL_claim_memory hypercall > introduced in the previous commit. When Flask is enabled, this permission > controls whether a domain can stake memory claims for another domain. > > The permission is granted to: > - dom0_t: Dom0 needs this to claim memory for guest domains > - create_domain_common: Domain builders need this during domain creation > > Signed-off-by: Bernhard Kaindl > --- > tools/flask/policy/modules/dom0.te | 1 + > tools/flask/policy/modules/xen.if | 1 + > xen/xsm/flask/hooks.c | 3 +++ > xen/xsm/flask/policy/access_vectors | 2 ++ > 4 files changed, 7 insertions(+) Oh, here's the missing XSM/Flask change. First - this cannot come after the introduction of the sub-op. If it can be split and come first, fine. Else it needs to be folded in. > --- a/xen/xsm/flask/hooks.c > +++ b/xen/xsm/flask/hooks.c > @@ -820,6 +820,9 @@ static int cf_check flask_domctl(struct domain *d, unsigned int cmd, > case XEN_DOMCTL_set_llc_colors: > return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SET_LLC_COLORS); > > + case XEN_DOMCTL_claim_memory: > + return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__CLAIM_MEMORY); You don't need two XSM checks, I don't think. As you use xsm_claim_pages(), all you need to do here should be to add a case label to the "These have individual XSM hooks (common/domctl.c)" block. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246664.1545768 (Exim 4.92) (envelope-from ) id 1vy97f-0008N3-7s; Thu, 05 Mar 2026 13:52:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246664.1545768; Thu, 05 Mar 2026 13:52:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97f-0008Mw-4f; Thu, 05 Mar 2026 13:52:15 +0000 Received: by outflank-mailman (input) for mailman id 1246664; Thu, 05 Mar 2026 13:52:13 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97c-0008Mq-W3 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:13 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 820ae696-189a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:52:11 +0100 (CET) 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 6414C3F904; Thu, 5 Mar 2026 13:52:10 +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 3A6DC3EA68; Thu, 5 Mar 2026 13:52:10 +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 pHcFDYqKqWlKTgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 820ae696-189a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718730; 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=x/tKo6sO/yEl7rIclC8Ou/RxLmCoSVX2S0UQLahfY5Y=; b=W8Njhtr8phGTTkrM/iWOk5nQ1OdpnM8IfavIGp92qr8ObGu4rpQJ/w6Ox0t7RK/Nkdl+Ku OjOsm8qme8KAc81wZk3rG5EkzEVOK36uO0X+Ar41yoDvxHVqR9BF0BsPERcLRkrLUtCZMK RhaB1iGTPJS1VAsnFa5jaLFPPTJilvU= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718730; 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=x/tKo6sO/yEl7rIclC8Ou/RxLmCoSVX2S0UQLahfY5Y=; b=W8Njhtr8phGTTkrM/iWOk5nQ1OdpnM8IfavIGp92qr8ObGu4rpQJ/w6Ox0t7RK/Nkdl+Ku OjOsm8qme8KAc81wZk3rG5EkzEVOK36uO0X+Ar41yoDvxHVqR9BF0BsPERcLRkrLUtCZMK RhaB1iGTPJS1VAsnFa5jaLFPPTJilvU= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD , Nick Rosbrook , George Dunlap Subject: [PATCH 00/11] tools: add support for per-domain xenstore quota Date: Thu, 5 Mar 2026 14:51:57 +0100 Message-ID: <20260305135208.2208663-1-jgross@suse.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.79 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.974]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FUZZY_RATELIMITED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: This series is adding support for per-domain Xenstore quota to: - xenstored - libxenstore - libxl - xl With this it is possible to e.g. allow larger limits for driver domains. Juergen Gross (11): tools/libs/store: add get- and set-quota related functions tools/xenstored: add central quota check functions tools/xenstored: rework hard_quotas and soft_quotas arrays tools/xenstored: add GLOBAL_QUOTA_DATA record for live update tools/xenstored: split acc[] array in struct domain tools/xenstored: add infrastructure for per-domain quotas tools/xenstored: implement the GET/SET_QUOTA commands tools/libxl: add functions for retrieving and setting xenstore quota tools/libxl: add support for xenstore quota in domain_config tools/xl: add xl commands for xenstore quota operations tools/xl: add support for xenstore quota setting via domain config docs/man/xl.cfg.5.pod.in | 13 + tools/golang/xenlight/helpers.gen.go | 84 +++++ tools/golang/xenlight/types.gen.go | 10 + tools/include/libxl.h | 20 ++ tools/include/xenstore.h | 19 ++ tools/libs/light/Makefile | 1 + tools/libs/light/libxl_dom.c | 8 + tools/libs/light/libxl_domain.c | 10 + tools/libs/light/libxl_types.idl | 10 + tools/libs/light/libxl_xsquota.c | 102 ++++++ tools/libs/store/Makefile | 2 +- tools/libs/store/libxenstore.map | 8 + tools/libs/store/xs.c | 111 +++++++ tools/xenstored/control.c | 24 +- tools/xenstored/core.c | 41 ++- tools/xenstored/domain.c | 457 +++++++++++++++++++++------ tools/xenstored/domain.h | 32 +- tools/xenstored/lu.c | 6 + tools/xenstored/transaction.c | 2 +- tools/xenstored/watch.c | 4 +- tools/xl/Makefile | 1 + tools/xl/xl.h | 2 + tools/xl/xl_cmdtable.c | 10 + tools/xl/xl_parse.c | 48 ++- tools/xl/xl_parse.h | 1 + tools/xl/xl_xsquota.c | 88 ++++++ 26 files changed, 972 insertions(+), 142 deletions(-) create mode 100644 tools/libs/light/libxl_xsquota.c create mode 100644 tools/xl/xl_xsquota.c -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246665.1545777 (Exim 4.92) (envelope-from ) id 1vy97j-00009H-E3; Thu, 05 Mar 2026 13:52:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246665.1545777; Thu, 05 Mar 2026 13: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 ) id 1vy97j-00009A-BL; Thu, 05 Mar 2026 13:52:19 +0000 Received: by outflank-mailman (input) for mailman id 1246665; Thu, 05 Mar 2026 13:52:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97i-00008m-DD for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:18 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 85022a56-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:52:16 +0100 (CET) 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 D1AC93F8EE; Thu, 5 Mar 2026 13:52:15 +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 B19693EA68; Thu, 5 Mar 2026 13:52:15 +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 bx85Ko+KqWlTTgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85022a56-189a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718735; 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=naD83YlbZGL27ewgtMQ3AW6P3o75RusmiaznD0RxnhM=; b=VygA5v6MXLuua+lePOlwuediEZc3tkLnBhqqXs+sgQuVO8Bg2/VeOUKNjocjGp+y9+ZaDj 5D4XhXoAMIOz535DM0Q58UpbWbl1AHxlXSzNfaDG0NvLVJQfN3v5HwGBwrHLpqmGWpNGjv vnQzk2Xt1G6ZoyZ0B6ZV/s1xsZLJD4s= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718735; 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=naD83YlbZGL27ewgtMQ3AW6P3o75RusmiaznD0RxnhM=; b=VygA5v6MXLuua+lePOlwuediEZc3tkLnBhqqXs+sgQuVO8Bg2/VeOUKNjocjGp+y9+ZaDj 5D4XhXoAMIOz535DM0Q58UpbWbl1AHxlXSzNfaDG0NvLVJQfN3v5HwGBwrHLpqmGWpNGjv vnQzk2Xt1G6ZoyZ0B6ZV/s1xsZLJD4s= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 01/11] tools/libs/store: add get- and set-quota related functions Date: Thu, 5 Mar 2026 14:51:58 +0100 Message-ID: <20260305135208.2208663-2-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.78 X-Spam-Level: X-Spamd-Result: default: False [-6.78 / 50.00]; REPLY(-4.00)[]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.18)[-0.884]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO Add functions for getting and setting Xenstore quota to libxenstore: xs_get_quota_names(): get the names of the supported quota. xs_get_global_quota(): get the value of one global quota. xs_set_global_quota(): set the value of one global quota. xs_get_domain_quota(): get the value of one quota of a domain. xs_set_domain_quota(): set the value of one quota of a domain. Signed-off-by: Juergen Gross --- tools/include/xenstore.h | 19 ++++++ tools/libs/store/Makefile | 2 +- tools/libs/store/libxenstore.map | 8 +++ tools/libs/store/xs.c | 111 +++++++++++++++++++++++++++++++ 4 files changed, 139 insertions(+), 1 deletion(-) diff --git a/tools/include/xenstore.h b/tools/include/xenstore.h index 423422dc50..6b661e5895 100644 --- a/tools/include/xenstore.h +++ b/tools/include/xenstore.h @@ -277,6 +277,25 @@ bool xs_get_features_domain(struct xs_handle *h, unsigned int domid, bool xs_set_features_domain(struct xs_handle *h, unsigned int domid, unsigned int features); +/* Get names of supported quota. */ +char **xs_get_quota_names(struct xs_handle *h, unsigned int *num); + +/* Get the value of one global quota. */ +bool xs_get_global_quota(struct xs_handle *h, char *quota, + unsigned int *value); + +/* Set the value of one global quota. */ +bool xs_set_global_quota(struct xs_handle *h, char *quota, + unsigned int value); + +/* Get the value of one domain quota. */ +bool xs_get_domain_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int *value); + +/* Set the value of one domain quota. */ +bool xs_set_domain_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int value); + char *xs_control_command(struct xs_handle *h, const char *cmd, void *data, unsigned int len); /* Deprecated: use xs_control_command() instead. */ diff --git a/tools/libs/store/Makefile b/tools/libs/store/Makefile index fed43b0008..b52d1f35ad 100644 --- a/tools/libs/store/Makefile +++ b/tools/libs/store/Makefile @@ -2,7 +2,7 @@ XEN_ROOT=$(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk MAJOR = 4 -MINOR = 1 +MINOR = 2 version-script := libxenstore.map ifeq ($(CONFIG_Linux),y) diff --git a/tools/libs/store/libxenstore.map b/tools/libs/store/libxenstore.map index cd9df86749..a08ddd549f 100644 --- a/tools/libs/store/libxenstore.map +++ b/tools/libs/store/libxenstore.map @@ -45,3 +45,11 @@ VERS_4.1 { xs_get_features_domain; xs_set_features_domain; } VERS_4.0; +VERS_4.2 { + global: + xs_get_quota_names; + xs_get_global_quota; + xs_set_global_quota; + xs_get_domain_quota; + xs_set_domain_quota; +} VERS_4.1; diff --git a/tools/libs/store/xs.c b/tools/libs/store/xs.c index 8f4b90a3cf..dda37f7526 100644 --- a/tools/libs/store/xs.c +++ b/tools/libs/store/xs.c @@ -1456,6 +1456,117 @@ bool xs_set_features_domain(struct xs_handle *h, unsigned int domid, return xs_bool(xs_talkv(h, iov, ARRAY_SIZE(iov), NULL)); } +char **xs_get_quota_names(struct xs_handle *h, unsigned int *num) +{ + struct xsd_sockmsg msg = { .type = XS_GET_QUOTA }; + struct iovec iov[1]; + char **quota; + char *reply; + char *c; + unsigned int i; + + iov[0].iov_base = &msg; + iov[0].iov_len = sizeof(msg); + + reply = xs_talkv(h, iov, ARRAY_SIZE(iov), NULL); + if (!reply) + return NULL; + + *num = 1; + for (c = reply; *c; c++) + if (*c == ' ') + (*num)++; + + quota = malloc(*num * sizeof(char *) + strlen(reply) + 1); + c = (char *)(quota + *num); + strcpy(c, reply); + for (i = 0; i < *num; i++) { + quota[i] = c; + c = strchr(c, ' '); + if (c) { + *c = 0; + c++; + } + } + + return quota; +} + +bool xs_get_global_quota(struct xs_handle *h, char *quota, + unsigned int *value) +{ + struct xsd_sockmsg msg = { .type = XS_GET_QUOTA }; + struct iovec iov[2]; + + iov[0].iov_base = &msg; + iov[0].iov_len = sizeof(msg); + iov[1].iov_base = quota; + iov[1].iov_len = strlen(quota) + 1; + + return xs_uint(xs_talkv(h, iov, ARRAY_SIZE(iov), NULL), value); +} + +bool xs_set_global_quota(struct xs_handle *h, char *quota, + unsigned int value) +{ + struct xsd_sockmsg msg = { .type = XS_SET_QUOTA }; + char val_str[MAX_STRLEN(value)]; + struct iovec iov[3]; + + snprintf(val_str, sizeof(val_str), "%u", value); + + iov[0].iov_base = &msg; + iov[0].iov_len = sizeof(msg); + iov[1].iov_base = quota; + iov[1].iov_len = strlen(quota) + 1; + iov[2].iov_base = val_str; + iov[2].iov_len = strlen(val_str) + 1; + + return xs_bool(xs_talkv(h, iov, ARRAY_SIZE(iov), NULL)); +} + +bool xs_get_domain_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int *value) +{ + struct xsd_sockmsg msg = { .type = XS_GET_QUOTA }; + char domid_str[MAX_STRLEN(domid)]; + struct iovec iov[3]; + + snprintf(domid_str, sizeof(domid_str), "%u", domid); + + iov[0].iov_base = &msg; + iov[0].iov_len = sizeof(msg); + iov[1].iov_base = domid_str; + iov[1].iov_len = strlen(domid_str) + 1; + iov[2].iov_base = quota; + iov[2].iov_len = strlen(quota) + 1; + + return xs_uint(xs_talkv(h, iov, ARRAY_SIZE(iov), NULL), value); +} + +bool xs_set_domain_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int value) +{ + struct xsd_sockmsg msg = { .type = XS_SET_QUOTA }; + char domid_str[MAX_STRLEN(domid)]; + char val_str[MAX_STRLEN(value)]; + struct iovec iov[4]; + + snprintf(domid_str, sizeof(domid_str), "%u", domid); + snprintf(val_str, sizeof(val_str), "%u", value); + + iov[0].iov_base = &msg; + iov[0].iov_len = sizeof(msg); + iov[1].iov_base = domid_str; + iov[1].iov_len = strlen(domid_str) + 1; + iov[2].iov_base = quota; + iov[2].iov_len = strlen(quota) + 1; + iov[3].iov_base = val_str; + iov[3].iov_len = strlen(val_str) + 1; + + return xs_bool(xs_talkv(h, iov, ARRAY_SIZE(iov), NULL)); +} + char *xs_control_command(struct xs_handle *h, const char *cmd, void *data, unsigned int len) { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246666.1545788 (Exim 4.92) (envelope-from ) id 1vy97o-0000Rd-Q1; Thu, 05 Mar 2026 13:52:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246666.1545788; Thu, 05 Mar 2026 13:52:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97o-0000RL-Lp; Thu, 05 Mar 2026 13:52:24 +0000 Received: by outflank-mailman (input) for mailman id 1246666; Thu, 05 Mar 2026 13:52:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97n-00008m-IK for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:23 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8833b762-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:52:21 +0100 (CET) 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 48E335BD8E; Thu, 5 Mar 2026 13:52: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 25A873EA68; Thu, 5 Mar 2026 13:52:21 +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 qiwdCJWKqWlYTgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8833b762-189a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718741; 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=g9IGAHWgEG6DCdCIzvkRdi4JDcDDT2+/4tidv+QAPpw=; b=GXk2ra0R2l0UyNGcqR1QsOjJOSvLHndSoaFtUNeNGDQVuPbluI6ANqX3N3c9hQzNG5kzxq LIn/mbbxy4VQlEJmnG49TBOry1E5/gw8tSYRUugBK4J9I1hi5Lwj2y8oubOzQ9JsIkFWsx OB0k8MKFzhWhcFoOGsmDu1HRbxcmqyg= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718741; 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=g9IGAHWgEG6DCdCIzvkRdi4JDcDDT2+/4tidv+QAPpw=; b=GXk2ra0R2l0UyNGcqR1QsOjJOSvLHndSoaFtUNeNGDQVuPbluI6ANqX3N3c9hQzNG5kzxq LIn/mbbxy4VQlEJmnG49TBOry1E5/gw8tSYRUugBK4J9I1hi5Lwj2y8oubOzQ9JsIkFWsx OB0k8MKFzhWhcFoOGsmDu1HRbxcmqyg= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 02/11] tools/xenstored: add central quota check functions Date: Thu, 5 Mar 2026 14:51:59 +0100 Message-ID: <20260305135208.2208663-3-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.962]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -6.79 X-Spam-Level: Add central functions for checking a value (either an absolute one or the current domain value plus an offset) against a specific quota. This is in preparation of introducing per-domain quota. The required changes allow to drop the "update" parameter from domain_nbentry_fix(). Signed-off-by: Juergen Gross --- tools/xenstored/core.c | 4 +- tools/xenstored/domain.c | 74 +++++++++++++++++------------------ tools/xenstored/domain.h | 7 ++-- tools/xenstored/transaction.c | 2 +- tools/xenstored/watch.c | 4 +- 5 files changed, 43 insertions(+), 48 deletions(-) diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c index d509736c32..5a4bf3e302 100644 --- a/tools/xenstored/core.c +++ b/tools/xenstored/core.c @@ -1538,7 +1538,7 @@ static struct node *create_node(struct connection *conn, const void *ctx, for (i = node; i; i = i->parent) { /* i->parent is set for each new node, so check quota. */ if (i->parent && - domain_nbentry(conn) >= hard_quotas[ACC_NODES].val) { + domain_check_quota_add(conn->domain, ACC_NODES, 1)) { ret = ENOSPC; goto err; } @@ -2320,7 +2320,7 @@ void setup_structure(bool live_update) manual_node("/tool/xenstored", NULL); manual_node("@releaseDomain", NULL); manual_node("@introduceDomain", NULL); - domain_nbentry_fix(priv_domid, 5, true); + domain_nbentry_fix(priv_domid, 5); } } diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index e453b3061f..1df9265ad5 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -389,6 +389,25 @@ void wrl_apply_debit_trans_commit(struct connection *conn) wrl_apply_debit_actual(conn->domain); } +static bool domain_check_quota_val(struct domain *d, enum accitem what, + unsigned int val) +{ + unsigned int quota = hard_quotas[what].val; + + if (!quota || !domid_is_unprivileged(d->domid)) + return false; + + return val >= quota; +} + +bool domain_check_quota_add(struct domain *d, enum accitem what, int add) +{ + if (add < 0 || !d) + return false; + + return domain_check_quota_val(d, what, d->acc[what].val + add); +} + static bool check_indexes(XENSTORE_RING_IDX cons, XENSTORE_RING_IDX prod) { return ((prod - cons) <= XENSTORE_RING_SIZE); @@ -490,10 +509,9 @@ static bool domain_can_read(struct connection *conn) if (domain_is_unprivileged(conn)) { if (domain->wrl_credit < 0) return false; - if (domain->acc[ACC_OUTST].val >= hard_quotas[ACC_OUTST].val) + if (domain_check_quota_add(domain, ACC_OUTST, 0)) return false; - if (domain->acc[ACC_MEM].val >= hard_quotas[ACC_MEM].val && - hard_quotas[ACC_MEM].val) + if (domain_check_quota_add(domain, ACC_MEM, 0)) return false; } @@ -904,16 +922,20 @@ do { \ int acc_fix_domains(struct list_head *head, bool chk_quota, bool update) { + struct domain *d; struct changed_domain *cd; - int cnt; list_for_each_entry(cd, head, list) { - cnt = domain_nbentry_fix(cd->domid, cd->acc[ACC_NODES], update); - if (!update) { - if (chk_quota && cnt >= hard_quotas[ACC_NODES].val) - return ENOSPC; - if (cnt < 0) + if (update) { + domain_nbentry_fix(cd->domid, cd->acc[ACC_NODES]); + } else if (chk_quota) { + d = find_or_alloc_existing_domain(cd->domid); + + if (!d) return ENOMEM; + if (domain_check_quota_add(d, ACC_NODES, + cd->acc[ACC_NODES])) + return ENOSPC; } } @@ -1732,7 +1754,7 @@ bool domain_max_chk(const struct connection *conn, enum accitem what, if (!conn || !conn->domain) return false; - if (domain_is_unprivileged(conn) && val > hard_quotas[what].val) + if (domain_check_quota_val(conn->domain, what, val)) return true; domain_acc_valid_max(conn->domain, what, val); @@ -1752,21 +1774,9 @@ int domain_nbentry_dec(struct connection *conn, unsigned int domid) ? errno : 0; } -int domain_nbentry_fix(unsigned int domid, int num, bool update) -{ - int ret; - - ret = domain_acc_add(NULL, domid, ACC_NODES, update ? num : 0, update); - if (ret < 0 || update) - return ret; - - return domid_is_unprivileged(domid) ? ret + num : 0; -} - -unsigned int domain_nbentry(struct connection *conn) +int domain_nbentry_fix(unsigned int domid, int num) { - return domain_is_unprivileged(conn) - ? domain_acc_add(conn, conn->id, ACC_NODES, 0, true) : 0; + return domain_acc_add(NULL, domid, ACC_NODES, num, true); } static bool domain_chk_quota(struct connection *conn, unsigned int mem) @@ -1781,7 +1791,7 @@ static bool domain_chk_quota(struct connection *conn, unsigned int mem) domain = conn->domain; now = time(NULL); - if (mem >= hard_quotas[ACC_MEM].val && hard_quotas[ACC_MEM].val) { + if (domain_check_quota_val(domain, ACC_MEM, mem)) { if (domain->hard_quota_reported) return true; syslog(LOG_ERR, "Domain %u exceeds hard memory quota, Xenstore interface to domain stalled\n", @@ -1857,13 +1867,6 @@ void domain_watch_dec(struct connection *conn) domain_acc_add(conn, conn->id, ACC_WATCH, -1, true); } -int domain_watch(struct connection *conn) -{ - return (domain_is_unprivileged(conn)) - ? domain_acc_add(conn, conn->id, ACC_WATCH, 0, true) - : 0; -} - void domain_outstanding_inc(struct connection *conn) { domain_acc_add(conn, conn->id, ACC_OUTST, 1, true); @@ -1884,13 +1887,6 @@ void domain_transaction_dec(struct connection *conn) domain_acc_add(conn, conn->id, ACC_TRANS, -1, true); } -unsigned int domain_transaction_get(struct connection *conn) -{ - return (domain_is_unprivileged(conn)) - ? domain_acc_add(conn, conn->id, ACC_TRANS, 0, true) - : 0; -} - const char *dump_state_connections(FILE *fp) { const char *ret = NULL; diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h index 28186ccac0..b229f6f4e0 100644 --- a/tools/xenstored/domain.h +++ b/tools/xenstored/domain.h @@ -113,8 +113,7 @@ int domain_alloc_permrefs(struct node_perms *perms); /* Quota manipulation */ int domain_nbentry_inc(struct connection *conn, unsigned int domid); int domain_nbentry_dec(struct connection *conn, unsigned int domid); -int domain_nbentry_fix(unsigned int domid, int num, bool update); -unsigned int domain_nbentry(struct connection *conn); +int domain_nbentry_fix(unsigned int domid, int num); int domain_memory_add(struct connection *conn, unsigned int domid, int mem, bool no_quota_check); @@ -141,12 +140,10 @@ static inline void domain_memory_add_nochk(struct connection *conn, } void domain_watch_inc(struct connection *conn); void domain_watch_dec(struct connection *conn); -int domain_watch(struct connection *conn); void domain_outstanding_inc(struct connection *conn); void domain_outstanding_dec(struct connection *conn, unsigned int domid); void domain_transaction_inc(struct connection *conn); void domain_transaction_dec(struct connection *conn); -unsigned int domain_transaction_get(struct connection *conn); int domain_get_quota(const void *ctx, struct connection *conn, unsigned int domid); @@ -161,6 +158,8 @@ int domain_max_global_acc(const void *ctx, struct connection *conn); void domain_reset_global_acc(void); bool domain_max_chk(const struct connection *conn, enum accitem what, unsigned int val); +bool domain_check_quota_add(struct domain *d, enum accitem what, + int add); extern long wrl_ntransactions; diff --git a/tools/xenstored/transaction.c b/tools/xenstored/transaction.c index 167cd597fd..ccf93a1132 100644 --- a/tools/xenstored/transaction.c +++ b/tools/xenstored/transaction.c @@ -470,7 +470,7 @@ int do_transaction_start(const void *ctx, struct connection *conn, if (conn->transaction) return EBUSY; - if (domain_transaction_get(conn) > hard_quotas[ACC_TRANS].val) + if (domain_check_quota_add(conn->domain, ACC_TRANS, 1)) return ENOSPC; /* Attach transaction to ctx for autofree until it's complete */ diff --git a/tools/xenstored/watch.c b/tools/xenstored/watch.c index b66a9f1a39..36e4d33f22 100644 --- a/tools/xenstored/watch.c +++ b/tools/xenstored/watch.c @@ -220,8 +220,8 @@ int do_watch(const void *ctx, struct connection *conn, struct buffered_data *in) return EEXIST; } - if (domain_watch(conn) > hard_quotas[ACC_WATCH].val) - return E2BIG; + if (domain_check_quota_add(conn->domain, ACC_WATCH, 1)) + return ENOSPC; watch = add_watch(conn, vec[0], vec[1], relative, false); if (!watch) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246668.1545797 (Exim 4.92) (envelope-from ) id 1vy97t-0000kL-VL; Thu, 05 Mar 2026 13:52:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246668.1545797; Thu, 05 Mar 2026 13: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 ) id 1vy97t-0000kE-ST; Thu, 05 Mar 2026 13:52:29 +0000 Received: by outflank-mailman (input) for mailman id 1246668; Thu, 05 Mar 2026 13:52:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97s-0008Mq-Hu for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:28 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8bc0ae45-189a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:52:27 +0100 (CET) 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 B596E3F81C; Thu, 5 Mar 2026 13:52:26 +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 942643EA76; Thu, 5 Mar 2026 13:52:26 +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 ihr/IpqKqWlwTgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8bc0ae45-189a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718747; 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=jjwrLXJ76lcdkEfVRZ/NYlU2XuS/dX5LsghDgLcjKFI=; b=WW5hCUJF2RbKUTrdp2XBfBvlZD2C+g7/HirdVoXWthwOXuyv9WRF2c0ZO+YVwGifjsDPVT 5mBsCYIb5uwbWelmDYzTAPfzD1VkZqy+shM/tHsvnR6Hupo6vVATSYH/M465w6D4CXwyDH V+8bWa+x2Q1pmi/UwGQwy/blGQOV7BU= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718746; 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=jjwrLXJ76lcdkEfVRZ/NYlU2XuS/dX5LsghDgLcjKFI=; b=B/fb8AgINJwxqJ7DX8HAqVCjEjPowW5GiuHwhbxHf+bquF1jQH/3f1ueHNLfAWzmcGorTk b5KT17AsBdPluqaprR5WtwUOc7xtm5ek93qAawrFXgbFM9dWhqVq+c0Uh71toYkLQ0bGis YrTJcvbQfFebmrUS+R/HN8He2QK27Ss= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 03/11] tools/xenstored: rework hard_quotas and soft_quotas arrays Date: Thu, 5 Mar 2026 14:52:00 +0100 Message-ID: <20260305135208.2208663-4-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.963]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.com:mid,suse.com:email]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -6.79 X-Spam-Level: Instead of having one array for hard quotas and one for soft quotas, split them differently: have one array with the quota names and descriptions, and one with the quota values (soft and hard) and the maximum value so far. This is in preparation of supporting per-domain quotas, as the layout of the second array elements will be reused in the domain data. While at it add an accessor for getting a soft quota value, as this will be needed for per-domain quotas, too. Signed-off-by: Juergen Gross --- tools/xenstored/control.c | 24 ++++++++------- tools/xenstored/core.c | 33 +++++++++++--------- tools/xenstored/domain.c | 65 +++++++++++++++++++++------------------ tools/xenstored/domain.h | 15 +++++---- 4 files changed, 76 insertions(+), 61 deletions(-) diff --git a/tools/xenstored/control.c b/tools/xenstored/control.c index 2611a6fade..ca59d30d05 100644 --- a/tools/xenstored/control.c +++ b/tools/xenstored/control.c @@ -101,7 +101,7 @@ static int do_control_log(const void *ctx, struct connection *conn, } static int quota_show_current(const void *ctx, struct connection *conn, - const struct quota *quotas) + unsigned int idx) { char *resp; unsigned int i; @@ -111,11 +111,12 @@ static int quota_show_current(const void *ctx, struct connection *conn, return ENOMEM; for (i = 0; i < ACC_N; i++) { - if (!quotas[i].name) + if (!quota_adm[i].name || quotas[i].val[idx] == Q_VAL_DISABLED) continue; resp = talloc_asprintf_append(resp, "%-17s: %8d %s\n", - quotas[i].name, quotas[i].val, - quotas[i].descr); + quota_adm[i].name, + quotas[i].val[idx], + quota_adm[i].descr); if (!resp) return ENOMEM; } @@ -126,7 +127,7 @@ static int quota_show_current(const void *ctx, struct connection *conn, } static int quota_set(const void *ctx, struct connection *conn, - const char **vec, int num, struct quota *quotas) + const char **vec, int num, unsigned int idx) { unsigned int i; int val; @@ -139,8 +140,9 @@ static int quota_set(const void *ctx, struct connection *conn, return EINVAL; for (i = 0; i < ACC_N; i++) { - if (quotas[i].name && !strcmp(vec[0], quotas[i].name)) { - quotas[i].val = val; + if (quota_adm[i].name && !strcmp(vec[0], quota_adm[i].name) && + quotas[i].val[idx] != Q_VAL_DISABLED) { + quotas[i].val[idx] = val; send_ack(conn, XS_CONTROL); return 0; } @@ -178,10 +180,10 @@ static int do_control_quota(const void *ctx, struct connection *conn, const char **vec, int num) { if (num == 0) - return quota_show_current(ctx, conn, hard_quotas); + return quota_show_current(ctx, conn, Q_IDX_HARD); if (!strcmp(vec[0], "set")) - return quota_set(ctx, conn, vec + 1, num - 1, hard_quotas); + return quota_set(ctx, conn, vec + 1, num - 1, Q_IDX_HARD); if (!strcmp(vec[0], "max")) return quota_max(ctx, conn, vec + 1, num - 1); @@ -193,10 +195,10 @@ static int do_control_quota_s(const void *ctx, struct connection *conn, const char **vec, int num) { if (num == 0) - return quota_show_current(ctx, conn, soft_quotas); + return quota_show_current(ctx, conn, Q_IDX_SOFT); if (!strcmp(vec[0], "set")) - return quota_set(ctx, conn, vec + 1, num - 1, soft_quotas); + return quota_set(ctx, conn, vec + 1, num - 1, Q_IDX_SOFT); return EINVAL; } diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c index 5a4bf3e302..8a06b35808 100644 --- a/tools/xenstored/core.c +++ b/tools/xenstored/core.c @@ -2613,10 +2613,9 @@ static void set_timeout(const char *arg) barf("unknown timeout \"%s\"\n", arg); } -static void set_quota(const char *arg, bool soft) +static void set_quota(const char *arg, unsigned int idx) { const char *eq = strchr(arg, '='); - struct quota *q = soft ? soft_quotas : hard_quotas; unsigned int val; unsigned int i; @@ -2625,8 +2624,9 @@ static void set_quota(const char *arg, bool soft) val = get_optval_uint(eq + 1); for (i = 0; i < ACC_N; i++) { - if (what_matches(arg, q[i].name)) { - q[i].val = val; + if (what_matches(arg, quota_adm[i].name) && + quotas[i].val[idx] != Q_VAL_DISABLED) { + quotas[i].val[idx] = val; return; } } @@ -2634,6 +2634,11 @@ static void set_quota(const char *arg, bool soft) barf("unknown quota \"%s\"\n", arg); } +static void set_one_quota(const char *arg, unsigned int idx, enum accitem what) +{ + quotas[what].val[idx] = get_optval_uint(arg); +} + /* Sorted by bit values of TRACE_* flags. Flag is (1u << index). */ const char *const trace_switches[] = { "obj", "io", "wrl", "acc", "tdb", @@ -2687,7 +2692,7 @@ int main(int argc, char *argv[]) options, NULL)) != -1) { switch (opt) { case 'E': - hard_quotas[ACC_NODES].val = get_optval_uint(optarg); + set_one_quota(optarg, Q_IDX_HARD, ACC_NODES); break; case 'F': pidfile = optarg; @@ -2699,10 +2704,10 @@ int main(int argc, char *argv[]) dofork = false; break; case 'S': - hard_quotas[ACC_NODESZ].val = get_optval_uint(optarg); + set_one_quota(optarg, Q_IDX_HARD, ACC_NODESZ); break; case 't': - hard_quotas[ACC_TRANS].val = get_optval_uint(optarg); + set_one_quota(optarg, Q_IDX_HARD, ACC_TRANS); break; case 'T': tracefile = optarg; @@ -2715,22 +2720,22 @@ int main(int argc, char *argv[]) keep_orphans = true; break; case 'W': - hard_quotas[ACC_WATCH].val = get_optval_uint(optarg); + set_one_quota(optarg, Q_IDX_HARD, ACC_WATCH); break; case 'A': - hard_quotas[ACC_NPERM].val = get_optval_uint(optarg); + set_one_quota(optarg, Q_IDX_HARD, ACC_NPERM); break; case 'M': - hard_quotas[ACC_PATHLEN].val = get_optval_uint(optarg); - hard_quotas[ACC_PATHLEN].val = + set_one_quota(optarg, Q_IDX_HARD, ACC_PATHLEN); + quotas[ACC_PATHLEN].val[Q_IDX_HARD] = min((unsigned int)XENSTORE_REL_PATH_MAX, - hard_quotas[ACC_PATHLEN].val); + quotas[ACC_PATHLEN].val[Q_IDX_HARD]); break; case 'Q': - set_quota(optarg, false); + set_quota(optarg, Q_IDX_HARD); break; case 'q': - set_quota(optarg, true); + set_quota(optarg, Q_IDX_SOFT); break; case 'w': set_timeout(optarg); diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 1df9265ad5..acdcaa769e 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -51,60 +51,60 @@ static evtchn_port_t virq_port; xenevtchn_handle *xce_handle = NULL; -struct quota hard_quotas[ACC_N] = { +struct quotaadm quota_adm[ACC_N] = { [ACC_NODES] = { .name = "nodes", .descr = "Nodes per domain", - .val = 1000, }, [ACC_WATCH] = { .name = "watches", .descr = "Watches per domain", - .val = 128, }, [ACC_OUTST] = { .name = "outstanding", .descr = "Outstanding requests per domain", - .val = 20, }, [ACC_MEM] = { .name = "memory", - .descr = "Total Xenstore memory per domain (error level)", - .val = 2 * 1024 * 1024 + 512 * 1024, /* 2.5 MB */ + .descr = "Total Xenstore memory per domain", }, [ACC_TRANS] = { .name = "transactions", .descr = "Active transactions per domain", - .val = 10, }, [ACC_TRANSNODES] = { .name = "transaction-nodes", .descr = "Max. number of accessed nodes per transaction", - .val = 1024, }, [ACC_NPERM] = { .name = "node-permissions", .descr = "Max. number of permissions per node", - .val = 5, }, [ACC_PATHLEN] = { .name = "path-max", .descr = "Max. length of a node path", - .val = XENSTORE_REL_PATH_MAX, }, [ACC_NODESZ] = { .name = "node-size", .descr = "Max. size of a node", - .val = 2048, }, }; -struct quota soft_quotas[ACC_N] = { - [ACC_MEM] = { - .name = "memory", - .descr = "Total Xenstore memory per domain (warning level)", - .val = 2 * 1024 * 1024, /* 2.0 MB */ +struct quota quotas[ACC_N] = { + [ACC_NODES] = { .val = { 1000, Q_VAL_DISABLED }, }, + [ACC_WATCH] = { .val = { 128, Q_VAL_DISABLED }, }, + [ACC_OUTST] = { .val = { 20, Q_VAL_DISABLED }, }, + [ACC_MEM] = { + .val = { 2 * 1024 * 1024 + 512 * 1024, /* 2.5 MB */ + 2 * 1024 * 1024 /* 2.0 MB */ }, }, + [ACC_TRANS] = { .val = { 10, Q_VAL_DISABLED }, }, + [ACC_TRANSNODES] = { .val = { 1024, Q_VAL_DISABLED }, }, + [ACC_NPERM] = { .val = { 5, Q_VAL_DISABLED }, }, + [ACC_PATHLEN] = { + .val = { XENSTORE_REL_PATH_MAX, Q_VAL_DISABLED }, + }, + [ACC_NODESZ] = { .val = { 2048, Q_VAL_DISABLED }, }, }; typedef int32_t wrl_creditt; @@ -389,10 +389,15 @@ void wrl_apply_debit_trans_commit(struct connection *conn) wrl_apply_debit_actual(conn->domain); } +static unsigned int domain_get_soft_quota(struct domain *d, enum accitem what) +{ + return quotas[what].val[Q_IDX_SOFT]; +} + static bool domain_check_quota_val(struct domain *d, enum accitem what, unsigned int val) { - unsigned int quota = hard_quotas[what].val; + unsigned int quota = quotas[what].val[Q_IDX_HARD]; if (!quota || !domid_is_unprivileged(d->domid)) return false; @@ -765,10 +770,10 @@ int domain_get_quota(const void *ctx, struct connection *conn, return ENOMEM; for (i = 0; i < ACC_N; i++) { - if (!hard_quotas[i].name) + if (!quota_adm[i].name) continue; resp = talloc_asprintf_append(resp, "%-17s: %8u (max %8u)\n", - hard_quotas[i].name, + quota_adm[i].name, d->acc[i].val, d->acc[i].max); if (!resp) return ENOMEM; @@ -789,11 +794,10 @@ int domain_max_global_acc(const void *ctx, struct connection *conn) return ENOMEM; for (i = 0; i < ACC_N; i++) { - if (!hard_quotas[i].name) + if (!quota_adm[i].name) continue; resp = talloc_asprintf_append(resp, "%-17s: %8u\n", - hard_quotas[i].name, - hard_quotas[i].max); + quota_adm[i].name, quotas[i].max); if (!resp) return ENOMEM; } @@ -1600,12 +1604,12 @@ static void domain_acc_valid_max(struct domain *d, enum accitem what, unsigned int val) { assert(what < ARRAY_SIZE(d->acc)); - assert(what < ARRAY_SIZE(hard_quotas)); + assert(what < ARRAY_SIZE(quotas)); if (val > d->acc[what].max) d->acc[what].max = val; - if (val > hard_quotas[what].max && domid_is_unprivileged(d->domid)) - hard_quotas[what].max = val; + if (val > quotas[what].max && domid_is_unprivileged(d->domid)) + quotas[what].max = val; } static int domain_acc_add_valid(struct domain *d, enum accitem what, int add) @@ -1742,7 +1746,7 @@ void domain_reset_global_acc(void) unsigned int i; for (i = 0; i < ACC_N; i++) - hard_quotas[i].max = 0; + quotas[i].max = 0; /* Set current max values seen. */ hashtable_iterate(domhash, domain_reset_global_acc_sub, NULL); @@ -1802,21 +1806,22 @@ static bool domain_chk_quota(struct connection *conn, unsigned int mem) } if (now - domain->mem_last_msg >= MEM_WARN_MINTIME_SEC) { + unsigned int soft_mem = domain_get_soft_quota(domain, ACC_MEM); + if (domain->hard_quota_reported) { domain->mem_last_msg = now; domain->hard_quota_reported = false; syslog(LOG_INFO, "Domain %u below hard memory quota again\n", domain->domid); } - if (mem >= soft_quotas[ACC_MEM].val && - soft_quotas[ACC_MEM].val && !domain->soft_quota_reported) { + if (mem >= soft_mem && soft_mem && + !domain->soft_quota_reported) { domain->mem_last_msg = now; domain->soft_quota_reported = true; syslog(LOG_WARNING, "Domain %u exceeds soft memory quota\n", domain->domid); } - if (mem < soft_quotas[ACC_MEM].val && - domain->soft_quota_reported) { + if (mem < soft_mem && domain->soft_quota_reported) { domain->mem_last_msg = now; domain->soft_quota_reported = false; syslog(LOG_INFO, "Domain %u below soft memory quota again\n", diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h index b229f6f4e0..a6db358fdc 100644 --- a/tools/xenstored/domain.h +++ b/tools/xenstored/domain.h @@ -40,15 +40,18 @@ enum accitem { ACC_N, /* Number of elements per domain. */ }; -struct quota { +extern struct quotaadm { const char *name; const char *descr; - unsigned int val; - unsigned int max; -}; +} quota_adm[ACC_N]; -extern struct quota hard_quotas[ACC_N]; -extern struct quota soft_quotas[ACC_N]; +extern struct quota { + unsigned int val[2]; +#define Q_IDX_HARD 0 +#define Q_IDX_SOFT 1 +#define Q_VAL_DISABLED UINT_MAX + unsigned int max; +} quotas[ACC_N]; void handle_event(void); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246672.1545808 (Exim 4.92) (envelope-from ) id 1vy97z-00016n-7f; Thu, 05 Mar 2026 13:52:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246672.1545808; Thu, 05 Mar 2026 13: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 ) id 1vy97z-00016c-2d; Thu, 05 Mar 2026 13:52:35 +0000 Received: by outflank-mailman (input) for mailman id 1246672; Thu, 05 Mar 2026 13:52:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy97x-0008Mq-Di for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:33 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8eb9b55a-189a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:52:32 +0100 (CET) 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 2D7F03ED7C; Thu, 5 Mar 2026 13:52:32 +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 0D11D3EA68; Thu, 5 Mar 2026 13:52:32 +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 UhAgAqCKqWl0TgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8eb9b55a-189a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718752; 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=Qd6amYjyhOJLEFPf+RpsHO3ExuRDdjesrhezg6H1Mlk=; b=BUNgof1yRMbXZPLtFr0mlbJ4W+odssS1nSsOsSdr9HWD54zQjx/twYgJACUW7C+J9NVv0/ 3tpZNRqR/+w/2Z+FEV5BJRlOtpE/zXiDzsPYVHAmyeFAUefpxyqOAgZbnMRiawMlWoevD0 phu2C9hM4VCXPdPQ3bM0ocuE5763JCo= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718752; 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=Qd6amYjyhOJLEFPf+RpsHO3ExuRDdjesrhezg6H1Mlk=; b=BUNgof1yRMbXZPLtFr0mlbJ4W+odssS1nSsOsSdr9HWD54zQjx/twYgJACUW7C+J9NVv0/ 3tpZNRqR/+w/2Z+FEV5BJRlOtpE/zXiDzsPYVHAmyeFAUefpxyqOAgZbnMRiawMlWoevD0 phu2C9hM4VCXPdPQ3bM0ocuE5763JCo= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 04/11] tools/xenstored: add GLOBAL_QUOTA_DATA record for live update Date: Thu, 5 Mar 2026 14:52:01 +0100 Message-ID: <20260305135208.2208663-5-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Score: -6.79 X-Spam-Level: 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.963]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FUZZY_RATELIMITED(0.00)[rspamd.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo] X-Spam-Flag: NO Communicate the global quota settings via the GLOBAL_QUOTA_DATA record to the new Xenstore instance. This avoids to lose global quota settings done via xenstore-control. In theory it would be possible to drop any quota related command line parameters in the live update case, but they don't do any harm, as the record data is applied on top of the command line data. For soft-quota just prepend "soft-" to the quota name. Use sub-functions for building and analyzing the quota part of the migration stream, as they will be reused for per-domain quotas. Signed-off-by: Juergen Gross --- tools/xenstored/domain.c | 123 +++++++++++++++++++++++++++++++++++++++ tools/xenstored/domain.h | 2 + tools/xenstored/lu.c | 6 ++ 3 files changed, 131 insertions(+) diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index acdcaa769e..694ae58973 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -1332,6 +1332,27 @@ int do_set_feature(const void *ctx, struct connection *conn, return 0; } +static bool parse_quota_name(const char *name, unsigned int *qidx, + unsigned int *idx) +{ + unsigned int q; + + if (strncmp(name, "soft-", 5)) { + *idx = Q_IDX_HARD; + } else { + *idx = Q_IDX_SOFT; + name += 5; + } + for (q = 0; q < ACC_N; q++) { + if (quota_adm[q].name && !strcmp(quota_adm[q].name, name)) { + *qidx = q; + return false; + } + } + + return true; +} + static int close_xgt_handle(void *_handle) { xengnttab_close(*(xengnttab_handle **)_handle); @@ -2001,6 +2022,61 @@ void read_state_connection(const void *ctx, const void *state) } } +static unsigned int get_quota_size(struct quota *quota, unsigned int *len) +{ + unsigned int q; + unsigned int n = 0; + + for (q = 0; q < ACC_N; q++) { + if (!quota_adm[q].name) + continue; + if (quota[q].val[Q_IDX_HARD] != Q_VAL_DISABLED) { + n++; + *len += strlen(quota_adm[q].name) + 1; + } + if (quota[q].val[Q_IDX_SOFT] != Q_VAL_DISABLED) { + n++; + *len += strlen(quota_adm[q].name) + 5 + 1; + } + } + + return n; +} + +static void build_quota_data(struct quota *quota, uint32_t *val, char *name) +{ + unsigned int q; + unsigned int n = 0; + + for (q = 0; q < ACC_N; q++) { + if (!quota_adm[q].name) + continue; + if (quota[q].val[Q_IDX_HARD] != Q_VAL_DISABLED) { + val[n++] = quota[q].val[Q_IDX_HARD]; + strcpy(name, quota_adm[q].name); + name += strlen(name) + 1; + } + if (quota[q].val[Q_IDX_SOFT] != Q_VAL_DISABLED) { + val[n++] = quota[q].val[Q_IDX_SOFT]; + strcpy(name, "soft-"); + strcpy(name + 5, quota_adm[q].name); + name += strlen(name) + 1; + } + } +} + +static void parse_quota_data(const uint32_t *val, const char *name, + unsigned int n, struct quota *quota) +{ + unsigned int i, q, idx; + + for (i = 0; i < n; i++) { + if (!parse_quota_name(name, &q, &idx)) + quota[q].val[idx] = val[i]; + name += strlen(name) + 1; + } +} + static int dump_state_domain(const void *k, void *v, void *arg) { struct domain *domain = v; @@ -2049,6 +2125,53 @@ void read_state_domain(const void *ctx, const void *state, unsigned int version) domain->features = sd->features; } +const char *dump_state_glb_quota(FILE *fp) +{ + struct xs_state_record_header *head; + struct xs_state_glb_quota *glb; + void *record; + unsigned int n_quota; + unsigned int len = sizeof(*glb); + size_t ret; + + n_quota = get_quota_size(quotas, &len); + len += n_quota * sizeof(glb->quota_val[0]); + len = ROUNDUP(len, 3); + + record = talloc_size(NULL, len + sizeof(*head)); + if (!record) + return "Dump global quota allocation error"; + + head = record; + head->type = XS_STATE_TYPE_GLB_QUOTA; + head->length = len; + + glb = (struct xs_state_glb_quota *)(head + 1); + glb->n_dom_quota = n_quota; + glb->n_glob_quota = 0; + + build_quota_data(quotas, glb->quota_val, + (char *)(glb->quota_val + n_quota)); + + ret = fwrite(record, len + sizeof(*head), 1, fp); + + talloc_free(record); + + if (ret != 1 || dump_state_align(fp)) + return "Dump global quota error"; + + return NULL; +} + +void read_state_glb_quota(const void *ctx, const void *state) +{ + const struct xs_state_glb_quota *glb = state; + unsigned int n_quota = glb->n_dom_quota + glb->n_glob_quota; + const char *name = (const char *)(glb->quota_val + n_quota); + + parse_quota_data(glb->quota_val, name, n_quota, quotas); +} + struct domain_acc { unsigned int domid; int nodes; diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h index a6db358fdc..62ce3b3166 100644 --- a/tools/xenstored/domain.h +++ b/tools/xenstored/domain.h @@ -173,10 +173,12 @@ void wrl_apply_debit_trans_commit(struct connection *conn); const char *dump_state_connections(FILE *fp); const char *dump_state_domains(FILE *fp); +const char *dump_state_glb_quota(FILE *fp); void read_state_connection(const void *ctx, const void *state); void read_state_domain(const void *ctx, const void *state, unsigned int version); +void read_state_glb_quota(const void *ctx, const void *state); struct hashtable *domain_check_acc_init(void); void domain_check_acc_add(const struct node *node, struct hashtable *domains); diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c index fa8395eb1e..eaffdbc69e 100644 --- a/tools/xenstored/lu.c +++ b/tools/xenstored/lu.c @@ -192,6 +192,9 @@ void lu_read_state(void) case XS_STATE_TYPE_DOMAIN: read_state_domain(ctx, state.buf, version); break; + case XS_STATE_TYPE_GLB_QUOTA: + read_state_glb_quota(ctx, state.buf); + break; default: xprintf("live-update: unknown state record %08x\n", head.type); @@ -319,6 +322,9 @@ static const char *lu_dump_state(const void *ctx, struct connection *conn) } ret = dump_state_global(fp); + if (ret) + goto out; + ret = dump_state_glb_quota(fp); if (ret) goto out; ret = dump_state_connections(fp); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246681.1545818 (Exim 4.92) (envelope-from ) id 1vy984-0001aH-KE; Thu, 05 Mar 2026 13:52:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246681.1545818; Thu, 05 Mar 2026 13:52:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy984-0001ZW-Fu; Thu, 05 Mar 2026 13:52:40 +0000 Received: by outflank-mailman (input) for mailman id 1246681; Thu, 05 Mar 2026 13:52:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy983-00008m-Dt for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:39 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 91e25457-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:52:37 +0100 (CET) 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 958FC3ED7C; Thu, 5 Mar 2026 13:52:37 +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 756F13EA68; Thu, 5 Mar 2026 13:52:37 +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 TT6VG6WKqWmETgAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 91e25457-189a-11f1-9ccf-f158ae23cfc8 Authentication-Results: smtp-out1.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 05/11] tools/xenstored: split acc[] array in struct domain Date: Thu, 5 Mar 2026 14:52:02 +0100 Message-ID: <20260305135208.2208663-6-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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-Rspamd-Queue-Id: 958FC3ED7C X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Score: -4.00 X-Spam-Level: X-Spam-Flag: NO X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org Prepare using per-domain quota by splitting the acc[] array in struct domain into an array with the current accounting data, and an array of type struct quota for the per-domain quota and the seen max value of the domain. Signed-off-by: Juergen Gross --- tools/xenstored/domain.c | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 694ae58973..9bd3ac7aca 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -140,10 +140,8 @@ struct domain bool introduced; /* Accounting data for this domain. */ - struct acc { - unsigned int val; - unsigned int max; - } acc[ACC_N]; + unsigned int acc_val[ACC_N]; + struct quota acc[ACC_N]; /* Memory quota data for this domain. */ bool soft_quota_reported; @@ -410,7 +408,7 @@ bool domain_check_quota_add(struct domain *d, enum accitem what, int add) if (add < 0 || !d) return false; - return domain_check_quota_val(d, what, d->acc[what].val + add); + return domain_check_quota_val(d, what, d->acc_val[what] + add); } static bool check_indexes(XENSTORE_RING_IDX cons, XENSTORE_RING_IDX prod) @@ -582,7 +580,7 @@ static int domain_tree_remove_sub(const void *ctx, struct connection *conn, ret = WALK_TREE_SKIP_CHILDREN; } - return domain->acc[ACC_NODES].val ? ret : WALK_TREE_SUCCESS_STOP; + return domain->acc_val[ACC_NODES] ? ret : WALK_TREE_SUCCESS_STOP; } static void domain_tree_remove(struct domain *domain) @@ -590,7 +588,7 @@ static void domain_tree_remove(struct domain *domain) int ret; struct walk_funcs walkfuncs = { .enter = domain_tree_remove_sub }; - if (domain->acc[ACC_NODES].val) { + if (domain->acc_val[ACC_NODES]) { ret = walk_node_tree(domain, NULL, "/", &walkfuncs, domain); if (ret == WALK_TREE_ERROR_STOP) syslog(LOG_ERR, @@ -774,7 +772,7 @@ int domain_get_quota(const void *ctx, struct connection *conn, continue; resp = talloc_asprintf_append(resp, "%-17s: %8u (max %8u)\n", quota_adm[i].name, - d->acc[i].val, d->acc[i].max); + d->acc_val[i], d->acc[i].max); if (!resp) return ENOMEM; } @@ -1637,10 +1635,10 @@ static int domain_acc_add_valid(struct domain *d, enum accitem what, int add) { unsigned int val; - assert(what < ARRAY_SIZE(d->acc)); + assert(what < ARRAY_SIZE(d->acc_val)); - if ((add < 0 && -add > d->acc[what].val) || - (add > 0 && (INT_MAX - d->acc[what].val) < add)) { + if ((add < 0 && -add > d->acc_val[what]) || + (add > 0 && (INT_MAX - d->acc_val[what]) < add)) { /* * In a transaction when a node is being added/removed AND the * same node has been added/removed outside the transaction in @@ -1651,7 +1649,7 @@ static int domain_acc_add_valid(struct domain *d, enum accitem what, int add) return (add < 0) ? 0 : INT_MAX; } - val = d->acc[what].val + add; + val = d->acc_val[what] + add; domain_acc_valid_max(d, what, val); return val; @@ -1710,10 +1708,10 @@ static int domain_acc_add(struct connection *conn, unsigned int domid, } trace_acc("global change domid %u: what=%u %u add %d\n", domid, what, - d->acc[what].val, add); - d->acc[what].val = domain_acc_add_valid(d, what, add); + d->acc_val[what], add); + d->acc_val[what] = domain_acc_add_valid(d, what, add); - return d->acc[what].val; + return d->acc_val[what]; } void acc_drop(struct connection *conn) @@ -1757,7 +1755,7 @@ static int domain_reset_global_acc_sub(const void *k, void *v, void *arg) unsigned int i; for (i = 0; i < ACC_N; i++) - d->acc[i].max = d->acc[i].val; + d->acc[i].max = d->acc_val[i]; return 0; } @@ -2193,7 +2191,7 @@ static int domain_check_acc_init_sub(const void *k, void *v, void *arg) * If everything is correct incrementing the value for each node will * result in dom->nodes being 0 at the end. */ - dom->nodes = -d->acc[ACC_NODES].val; + dom->nodes = -d->acc_val[ACC_NODES]; if (hashtable_add(domains, &dom->domid, dom)) { talloc_free(dom); @@ -2248,7 +2246,7 @@ static int domain_check_acc_cb(const void *k, void *v, void *arg) if (!d) return 0; - d->acc[ACC_NODES].val += dom->nodes; + d->acc_val[ACC_NODES] += dom->nodes; return 0; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:52:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246687.1545827 (Exim 4.92) (envelope-from ) id 1vy988-00023M-R6; Thu, 05 Mar 2026 13:52:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246687.1545827; Thu, 05 Mar 2026 13:52:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy988-00023B-Nh; Thu, 05 Mar 2026 13:52:44 +0000 Received: by outflank-mailman (input) for mailman id 1246687; Thu, 05 Mar 2026 13:52:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy988-0008Mq-1F for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:44 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [2a07:de40:b251:101:10:150:64:1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 95177d18-189a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:52:43 +0100 (CET) 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 0C8B83F925; Thu, 5 Mar 2026 13:52:43 +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 DF2243EA68; Thu, 5 Mar 2026 13:52:42 +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 QQRMNaqKqWkITwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95177d18-189a-11f1-b164-2bf370ae4941 Authentication-Results: smtp-out1.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 06/11] tools/xenstored: add infrastructure for per-domain quotas Date: Thu, 5 Mar 2026 14:52:03 +0100 Message-ID: <20260305135208.2208663-7-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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-Rspamd-Queue-Id: 0C8B83F925 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Score: -4.00 X-Spam-Level: X-Spam-Flag: NO X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org Add the needed structures and helper functions for supporting quotas per domain. Signed-off-by: Juergen Gross --- tools/xenstored/domain.c | 59 ++++++++++++++++++++++++++++++---------- 1 file changed, 44 insertions(+), 15 deletions(-) diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 9bd3ac7aca..8e52351695 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -389,6 +389,9 @@ void wrl_apply_debit_trans_commit(struct connection *conn) static unsigned int domain_get_soft_quota(struct domain *d, enum accitem what) { + if (d && d->acc[what].val[Q_IDX_SOFT] != Q_VAL_DISABLED) + return d->acc[what].val[Q_IDX_SOFT]; + return quotas[what].val[Q_IDX_SOFT]; } @@ -397,6 +400,9 @@ static bool domain_check_quota_val(struct domain *d, enum accitem what, { unsigned int quota = quotas[what].val[Q_IDX_HARD]; + if (d->acc[what].val[Q_IDX_HARD] != Q_VAL_DISABLED) + quota = d->acc[what].val[Q_IDX_HARD]; + if (!quota || !domid_is_unprivileged(d->domid)) return false; @@ -809,6 +815,7 @@ static struct domain *alloc_domain(const void *context, unsigned int domid, uint64_t unique_id) { struct domain *domain; + unsigned int q; domain = talloc_zero(context, struct domain); if (!domain) { @@ -822,6 +829,11 @@ static struct domain *alloc_domain(const void *context, unsigned int domid, domain->introduced = false; domain->features = XENSTORE_FEATURES; + for (q = 0; q < ACC_N; q++) { + domain->acc[q].val[Q_IDX_HARD] = quotas[q].val[Q_IDX_HARD]; + domain->acc[q].val[Q_IDX_SOFT] = quotas[q].val[Q_IDX_SOFT]; + } + if (hashtable_add(domhash, &domain->domid, domain)) { talloc_free(domain); errno = ENOMEM; @@ -2079,25 +2091,38 @@ static int dump_state_domain(const void *k, void *v, void *arg) { struct domain *domain = v; FILE *fp = arg; - struct xs_state_domain sd; - struct xs_state_record_header head; - - head.type = XS_STATE_TYPE_DOMAIN; - head.length = sizeof(sd); - memset(&sd, 0, sizeof(sd)); - sd.domain_id = domain->domid; + struct xs_state_domain *sd; + struct xs_state_record_header *head; + void *record; + unsigned int n_quota; + unsigned int len = sizeof(*sd); + size_t ret; - if (lu_status->version > 1) - sd.features = domain->features; + n_quota = get_quota_size(domain->acc, &len); + len += n_quota * sizeof(sd->quota_val[0]); + len = ROUNDUP(len, 3); - if (fwrite(&head, sizeof(head), 1, fp) != 1) - return 1; - if (fwrite(&sd, sizeof(sd), 1, fp) != 1) - return 1; - if (dump_state_align(fp)) + record = talloc_size(NULL, len + sizeof(*head)); + if (!record) return 1; - return 0; + head = record; + head->type = XS_STATE_TYPE_DOMAIN; + head->length = len; + + sd = (struct xs_state_domain *)(head + 1); + sd->domain_id = domain->domid; + sd->n_quota = n_quota; + sd->features = (lu_status->version > 1) ? domain->features : 0; + + build_quota_data(domain->acc, sd->quota_val, + (char *)(sd->quota_val + n_quota)); + + ret = fwrite(record, len + sizeof(*head), 1, fp); + + talloc_free(record); + + return (ret != 1 || dump_state_align(fp)) ? 1 : 0; } const char *dump_state_domains(FILE *fp) @@ -2114,6 +2139,8 @@ void read_state_domain(const void *ctx, const void *state, unsigned int version) { const struct xs_state_domain *sd = state; struct domain *domain; + unsigned int n_quota = sd->n_quota; + const char *name = (const char *)(sd->quota_val + n_quota); domain = find_domain_struct(sd->domain_id); if (!domain) @@ -2121,6 +2148,8 @@ void read_state_domain(const void *ctx, const void *state, unsigned int version) if (version > 1) domain->features = sd->features; + + parse_quota_data(sd->quota_val, name, n_quota, domain->acc); } const char *dump_state_glb_quota(FILE *fp) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:56:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:56:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246722.1545839 (Exim 4.92) (envelope-from ) id 1vy9Bv-0003Yi-Cx; Thu, 05 Mar 2026 13:56:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246722.1545839; Thu, 05 Mar 2026 13: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 ) id 1vy9Bv-0003Yb-8Q; Thu, 05 Mar 2026 13:56:39 +0000 Received: by outflank-mailman (input) for mailman id 1246722; Thu, 05 Mar 2026 13:56:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy9Bt-0003YV-Sw for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:56:37 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1f99a60b-189b-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:56:35 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439c56e822eso2346811f8f.2 for ; Thu, 05 Mar 2026 05:56:35 -0800 (PST) Received: from [10.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-439b34b6252sm34182860f8f.10.2026.03.05.05.56.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 05:56:34 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1f99a60b-189b-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772718995; x=1773323795; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=FendGPAIk98VHbhLv0gYNMJLU5gwi51eXUlXYQkH8iQ=; b=ASEqV2L22YaEDPXUJDkhx/3EU1EckgsISGb+B9H3YZhUQZxStpf8pY2RtQf7V0J3zD lso5rL74oh2VXaJjQfABpx/tkCazG3Gt7/ERkg2tSw1R2bbWtdHaXnAQYicMKkiloh5j wqIadoyQVYJ0oZZ1O8RS6s3PsYpo9SsdGtqUlRMhg/JJIi5Pol/cQ86HUx/V9ZvRAK9y htVJ5Sy/wxfF39ZKDmsjl+wB2YZpssksiRChs9rhBTBKYq0XUxR0vPowJ1l5l5dUJwkA 4EBYPAKYzsUPV0oWPdscfzkRCtijtdxWiC2lwvr2/zbmKvpoay9Sude4gCrJJ0GXBzny NoQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772718995; x=1773323795; h=content-transfer-encoding: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; bh=FendGPAIk98VHbhLv0gYNMJLU5gwi51eXUlXYQkH8iQ=; b=sjETGAjL1Fh37Emc99rgjW5dJuT1N2Irq+bdyp41MYXjoHm7Y6Kucx5OZ0OXhNedDo tGz1VcFx8vJanBjd6pFpVfZk5Wls5sDNLj3fZ/plfmMbbl20cBc3Q67K24hucsqGFZmK NPyBMKg5DEjlUOo+KQnTkwgU0vwSy6/boOdvGYOnEguZMfstfwtbzMQZsYn8kwU0fjDi 5mfnZcQxorHkqu8GXm1gmza1nfxvwGh46pZmEutMzUzYYwi3Rc6OqwxdRI5640GoHCgV vST561ZW0Bi6Z++5/U0VlVJGrMvIE4VS0MV0WFkICjxB0TzkdOSnMfwexYDCV2ko48cj Fg8w== X-Gm-Message-State: AOJu0YwvBbgnMcwCfRE7r1GyGKwmyBA+DrxcsG8piXQLRUeLnxE+TQTP RM3YJVBT3yyQ+TrymW78Ga4/vkOhJkvurXa/xIVmDJ+z5XhdW8w671Cj9zG8ywMp9hPRlGB5+72 h+1M= X-Gm-Gg: ATEYQzxrj+oH6bpePzWc1UzZbJUdY31ZoEg0H1sJz8X23Jx8/emFcTRhXf8ZxbwJB9/ 4DOrj9NXAwg8Y9jfqvFaradE/onkInLsBkCpx86QpaQyappvl+z8DHbCGnyFzMTzuX83SP9/jlH WU8IzOzYHTkogUv1HUkQo1p8pll5XkCtgnf8xqbD+MXWz4RVYK/MDSD9/tCrqmMZNCc8aZEPRQq YORsLgEkgQR2fe2TabJqOxiaEzyRDAjt+uegVCvFWqYfgeTX6I2dxHC+0Cnyqp6OLtGtphjfELA xBhgnp8wzTOPZHd7ZCUzwEcNlifHbgsSFcuXUZPJ6IGIFLGRscx2YoRN+xQSvTETwgZhfM031PI 9KWuHNiWWtfWlvi60tReASbAbij3YPgCeZjw+M/qdOrXdcInfPQnn/QNtZeB9FZl0hFeluu0svr tCpd20utDZBLIn/vec4AtBPE3noEZIIrUz/q3M/L0CDHTx/mWq/wLMFDAcfVACaa7MsyQbJUtZD N+86u4yKFKd/Xo= X-Received: by 2002:a5d:5f83:0:b0:439:be78:e1e9 with SMTP id ffacd0b85a97d-439c7fadc99mr10784072f8f.14.1772718994779; Thu, 05 Mar 2026 05:56:34 -0800 (PST) Message-ID: <689dae19-f83d-463f-95d9-c39c15a4e45c@suse.com> Date: Thu, 5 Mar 2026 14:56:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: "xen-devel@lists.xenproject.org" Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stewart Hildebrand From: Jan Beulich Subject: [PATCH v6] vPCI: re-init extended-capabilities when MMCFG availability changed Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 When Dom0 informs us about MMCFG usability, this may change whether extended capabilities are available (accessible) for devices. Zap what might be on record, and re-initialize things. No synchronization is added for the case where devices may already be in use. That'll need sorting when (a) DomU support was added and (b) DomU-s may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). vpci_cleanup_capabilities() also shouldn't have used pci_find_ext_capability(), as already when the function was introduced extended config space may not have been (properly) accessible anymore, no matter whether it was during init. Extended capability cleanup hooks need to cope with being called when the respective capability doesn't exist (and hence the corresponding ->init() hook was never called). Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") Signed-off-by: Jan Beulich --- v6: Add comment in physdev_check_pci_extcfg(), while dropping the logging of a(nother) message there. Drop hwdom restriction from vpci_cleanup_capabilities(). In the re-init case don't bail early from vpci_init_capabilities(). Simplify assertion and re-order actions in vpci_reinit_ext_capabilities(). v5: Don't use pci_find_ext_capability() in vpci_cleanup_capabilities(). Add assertion in vpci_reinit_ext_capabilities(). v4: Make sure ->cleanup() and ->init() are invoked. v3: New. --- a/xen/arch/x86/physdev.c +++ b/xen/arch/x86/physdev.c @@ -8,6 +8,8 @@ #include #include #include +#include + #include #include #include @@ -169,8 +171,19 @@ int cf_check physdev_check_pci_extcfg(st ASSERT(pdev->seg == info->segment); if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) + { pci_check_extcfg(pdev); + /* + * The re-init failing doesn't mean the device becomes entirely non- + * functional. In case of failure, a message was already logged. + * Hence don't otherwise act upon failure. + * + * FIXME: Re-visit when DomU support is added to vPCI. + */ + vpci_reinit_ext_capabilities(pdev); + } + return 0; } #endif /* COMPAT */ --- a/xen/drivers/vpci/cap.c +++ b/xen/drivers/vpci/cap.c @@ -285,13 +285,16 @@ static int vpci_init_ext_capability_list return 0; } -int vpci_init_capabilities(struct pci_dev *pdev) +int vpci_init_capabilities(struct pci_dev *pdev, bool ext_only) { - int rc; + int rc, accum_rc = 0; - rc = vpci_init_capability_list(pdev); - if ( rc ) - return rc; + if ( !ext_only ) + { + rc = vpci_init_capability_list(pdev); + if ( rc ) + return rc; + } rc = vpci_init_ext_capability_list(pdev); if ( rc ) @@ -305,7 +308,7 @@ int vpci_init_capabilities(struct pci_de unsigned int pos = 0; if ( !is_ext ) - pos = pci_find_cap_offset(pdev->sbdf, cap); + pos = !ext_only ? pci_find_cap_offset(pdev->sbdf, cap) : 0; else if ( is_hardware_domain(pdev->domain) ) pos = pci_find_ext_capability(pdev, cap); @@ -341,30 +344,40 @@ int vpci_init_capabilities(struct pci_de { printk(XENLOG_ERR "%pd %pp: hide %s cap %u fail rc=%d\n", pdev->domain, &pdev->sbdf, type, cap, rc); - return rc; + + /* Best effort for the re-init case. */ + if ( !ext_only ) + return rc; + + if ( !accum_rc ) + accum_rc = rc; } } } - return 0; + return accum_rc; } -void vpci_cleanup_capabilities(struct pci_dev *pdev) +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only) { for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ ) { const vpci_capability_t *capability = &__start_vpci_array[i]; const unsigned int cap = capability->id; - unsigned int pos = 0; if ( !capability->cleanup ) continue; - if ( !capability->is_ext ) - pos = pci_find_cap_offset(pdev->sbdf, cap); - else if ( is_hardware_domain(pdev->domain) ) - pos = pci_find_ext_capability(pdev, cap); - if ( pos ) + /* + * Cannot call pci_find_ext_capability() here, as extended config space + * may (no longer) be accessible. As a result, extended capability + * ->cleanup() handlers need to cope with being called despite ->init() + * never having been called. Which in turn allows calling them even + * for DomU-s, no matter that vpci_init_capabilities() excludes them + * there for now. + */ + if ( capability->is_ext + || (!ext_only && pci_find_cap_offset(pdev->sbdf, cap)) ) { int rc = capability->cleanup(pdev, false); @@ -376,6 +389,27 @@ void vpci_cleanup_capabilities(struct pc } } +int vpci_reinit_ext_capabilities(struct pci_dev *pdev) +{ + if ( !pdev->vpci ) + return 0; + + /* + * FIXME: DomU support is missing. For already running domains we may + * need to pause them around the entire re-evaluation of extended config + * space accessibility. + */ + ASSERT(pdev->domain == hardware_domain); + + if ( vpci_remove_registers(pdev->vpci, PCI_CFG_SPACE_SIZE, + PCI_CFG_SPACE_EXP_SIZE - PCI_CFG_SPACE_SIZE) ) + ASSERT_UNREACHABLE(); + + vpci_cleanup_capabilities(pdev, true); + + return vpci_init_capabilities(pdev, true); +} + /* * Local variables: * mode: C --- a/xen/drivers/vpci/private.h +++ b/xen/drivers/vpci/private.h @@ -46,8 +46,8 @@ typedef struct { int __must_check vpci_init_header(struct pci_dev *pdev); -int vpci_init_capabilities(struct pci_dev *pdev); -void vpci_cleanup_capabilities(struct pci_dev *pdev); +int vpci_init_capabilities(struct pci_dev *pdev, bool ext_only); +void vpci_cleanup_capabilities(struct pci_dev *pdev, bool ext_only); /* Add/remove a register handler. */ int __must_check vpci_add_register_mask(struct vpci *vpci, --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -102,7 +102,7 @@ void vpci_deassign_device(struct pci_dev &pdev->domain->vpci_dev_assigned_map); #endif - vpci_cleanup_capabilities(pdev); + vpci_cleanup_capabilities(pdev, false); spin_lock(&pdev->vpci->lock); while ( !list_empty(&pdev->vpci->handlers) ) @@ -159,7 +159,7 @@ int vpci_assign_device(struct pci_dev *p if ( rc ) goto out; - rc = vpci_init_capabilities(pdev); + rc = vpci_init_capabilities(pdev, false); out: if ( rc ) --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -25,6 +25,8 @@ int __must_check vpci_assign_device(stru /* Remove all handlers and free vpci related structures. */ void vpci_deassign_device(struct pci_dev *pdev); +int vpci_reinit_ext_capabilities(struct pci_dev *pdev); + /* Generic read/write handlers for the PCI config space. */ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size); void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size, @@ -202,6 +204,11 @@ bool vpci_ecam_read(pci_sbdf_t sbdf, uns #else /* !CONFIG_HAS_VPCI */ struct vpci_vcpu {}; +static inline int vpci_reinit_ext_capabilities(struct pci_dev *pdev) +{ + return 0; +} + static inline int vpci_assign_device(struct pci_dev *pdev) { return 0; From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:57:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:57:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246734.1545847 (Exim 4.92) (envelope-from ) id 1vy9Cs-00049t-LP; Thu, 05 Mar 2026 13:57:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246734.1545847; Thu, 05 Mar 2026 13:57:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy9Cs-00049m-I7; Thu, 05 Mar 2026 13:57:38 +0000 Received: by outflank-mailman (input) for mailman id 1246734; Thu, 05 Mar 2026 13:57:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy98F-00008m-5J for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:51 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 98646d41-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:52:48 +0100 (CET) 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 748E75BEC7; Thu, 5 Mar 2026 13:52:48 +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 54D0A3EA76; Thu, 5 Mar 2026 13:52:48 +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 n8KnE7CKqWkMTwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 98646d41-189a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718768; 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=r+4ZO/KspblmGGLhGlNMkeWiLuNQLDCEDNiLJzLmjPY=; b=foug50Oxl/72LzeH5fthq6evZ/egSmCWIwtKH48ES5xxykx8PW6vFp7YvV9Mk5NBiS9sHD F5t+nvvLv8VTVuuis5HKMRGA1ne++NR0kV7fF4xsW49Erk9v25T3ITR9kxMCy/FKdwT1PN hJ0HsStVaIIJo4y2pRJUcrQrHmg4Wd4= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718768; 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=r+4ZO/KspblmGGLhGlNMkeWiLuNQLDCEDNiLJzLmjPY=; b=foug50Oxl/72LzeH5fthq6evZ/egSmCWIwtKH48ES5xxykx8PW6vFp7YvV9Mk5NBiS9sHD F5t+nvvLv8VTVuuis5HKMRGA1ne++NR0kV7fF4xsW49Erk9v25T3ITR9kxMCy/FKdwT1PN hJ0HsStVaIIJo4y2pRJUcrQrHmg4Wd4= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Julien Grall , Anthony PERARD Subject: [PATCH 07/11] tools/xenstored: implement the GET/SET_QUOTA commands Date: Thu, 5 Mar 2026 14:52:04 +0100 Message-ID: <20260305135208.2208663-8-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.964]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -6.79 X-Spam-Level: Add the implementation of the GET_QUOTA and SET_QUOTA wire commands. Signed-off-by: Juergen Gross --- tools/xenstored/core.c | 4 ++ tools/xenstored/domain.c | 106 +++++++++++++++++++++++++++++++++++++++ tools/xenstored/domain.h | 8 +++ 3 files changed, 118 insertions(+) diff --git a/tools/xenstored/core.c b/tools/xenstored/core.c index 8a06b35808..e283d47184 100644 --- a/tools/xenstored/core.c +++ b/tools/xenstored/core.c @@ -2034,6 +2034,10 @@ static struct { { "GET_FEATURE", do_get_feature, XS_FLAG_PRIV }, [XS_SET_FEATURE] = { "SET_FEATURE", do_set_feature, XS_FLAG_PRIV }, + [XS_GET_QUOTA] = + { "GET_QUOTA", do_get_quota, XS_FLAG_PRIV }, + [XS_SET_QUOTA] = + { "SET_QUOTA", do_set_quota, XS_FLAG_PRIV }, }; static const char *sockmsg_string(enum xsd_sockmsg_type type) diff --git a/tools/xenstored/domain.c b/tools/xenstored/domain.c index 8e52351695..c0bc8a3eb7 100644 --- a/tools/xenstored/domain.c +++ b/tools/xenstored/domain.c @@ -1363,6 +1363,112 @@ static bool parse_quota_name(const char *name, unsigned int *qidx, return true; } +int do_get_quota(const void *ctx, struct connection *conn, + struct buffered_data *in) +{ + const char *vec[2]; + unsigned int n_pars; + unsigned int domid; + unsigned int q; + unsigned int idx; + char *resp; + const char *name; + const struct quota *quota; + const struct domain *domain; + + n_pars = get_strings(in, vec, ARRAY_SIZE(vec)); + + if (n_pars > 2) + return EINVAL; + + if (n_pars == 0) { + resp = talloc_asprintf(ctx, "%s", ""); + if (!resp) + return ENOMEM; + for (q = 0; q < ACC_N; q++) { + if (!quota_adm[q].name) + continue; + if (quotas[q].val[Q_IDX_HARD] != Q_VAL_DISABLED) { + resp = talloc_asprintf_append(resp, "%s%s", + *resp ? " " : "", quota_adm[q].name); + if (!resp) + return ENOMEM; + } + if (quotas[q].val[Q_IDX_SOFT] != Q_VAL_DISABLED) { + resp = talloc_asprintf_append(resp, "%ssoft-%s", + *resp ? " " : "", quota_adm[q].name); + if (!resp) + return ENOMEM; + } + } + } else { + if (n_pars == 1) { + quota = quotas; + name = vec[0]; + } else { + domid = atoi(vec[0]); + domain = find_or_alloc_existing_domain(domid); + if (!domain) + return ENOENT; + quota = domain->acc; + name = vec[1]; + } + + if (parse_quota_name(name, &q, &idx)) + return EINVAL; + + resp = talloc_asprintf(ctx, "%u", quota[q].val[idx]); + if (!resp) + return ENOMEM; + } + + send_reply(conn, XS_GET_QUOTA, resp, strlen(resp) + 1); + + return 0; +} + +int do_set_quota(const void *ctx, struct connection *conn, + struct buffered_data *in) +{ + const char *vec[3]; + unsigned int n_pars; + unsigned int domid; + unsigned int q; + unsigned int idx; + const char *name; + unsigned int val; + struct quota *quota; + struct domain *domain; + + n_pars = get_strings(in, vec, ARRAY_SIZE(vec)); + + if (n_pars < 2 || n_pars > 3) + return EINVAL; + + if (n_pars == 2) { + quota = quotas; + name = vec[0]; + val = atoi(vec[1]); + } else { + domid = atoi(vec[0]); + domain = find_or_alloc_existing_domain(domid); + if (!domain) + return ENOENT; + quota = domain->acc; + name = vec[1]; + val = atoi(vec[2]); + } + + if (parse_quota_name(name, &q, &idx)) + return EINVAL; + + quota[q].val[idx] = val; + + send_ack(conn, XS_SET_QUOTA); + + return 0; +} + static int close_xgt_handle(void *_handle) { xengnttab_close(*(xengnttab_handle **)_handle); diff --git a/tools/xenstored/domain.h b/tools/xenstored/domain.h index 62ce3b3166..6a06b0d1af 100644 --- a/tools/xenstored/domain.h +++ b/tools/xenstored/domain.h @@ -93,6 +93,14 @@ int do_get_feature(const void *ctx, struct connection *conn, int do_set_feature(const void *ctx, struct connection *conn, struct buffered_data *in); +/* Get quota names or value */ +int do_get_quota(const void *ctx, struct connection *conn, + struct buffered_data *in); + +/* Set quota value */ +int do_set_quota(const void *ctx, struct connection *conn, + struct buffered_data *in); + void domain_early_init(void); void domain_init(int evtfd); void init_domains(bool live_update); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:58:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:58:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246746.1545858 (Exim 4.92) (envelope-from ) id 1vy9DJ-0004l1-Vv; Thu, 05 Mar 2026 13:58:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246746.1545858; Thu, 05 Mar 2026 13: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 ) id 1vy9DJ-0004ks-TD; Thu, 05 Mar 2026 13:58:05 +0000 Received: by outflank-mailman (input) for mailman id 1246746; Thu, 05 Mar 2026 13:58:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy98P-0008Mq-P5 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:53:01 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9f7a8dd3-189a-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 14:53:00 +0100 (CET) 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 5CC845BDE2; Thu, 5 Mar 2026 13:52:59 +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 3790B3EA68; Thu, 5 Mar 2026 13:52:59 +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 AX2ADLuKqWkdTwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f7a8dd3-189a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718779; 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=+0vTnaLiNIbBDWIqxe6qxu0BI40b3mH2UzHvF/8/7sk=; b=klfusZ5eK/BCbJuwI8jkcOy1FBZfH3lLFFtXZ5cbMAIDCTV/fZ+HaE4DXwFtf6rfrk7mSW tY86rV0uUs+vbKeXv9rwhwHnlQn8kK6cIzwH+RjPXqK0Ar3Isc/qmA11M47kNVxMExrjeo cOfQPCSdK0HTgKIcZBzhYfrUi/Jnj4s= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718779; 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=+0vTnaLiNIbBDWIqxe6qxu0BI40b3mH2UzHvF/8/7sk=; b=klfusZ5eK/BCbJuwI8jkcOy1FBZfH3lLFFtXZ5cbMAIDCTV/fZ+HaE4DXwFtf6rfrk7mSW tY86rV0uUs+vbKeXv9rwhwHnlQn8kK6cIzwH+RjPXqK0Ar3Isc/qmA11M47kNVxMExrjeo cOfQPCSdK0HTgKIcZBzhYfrUi/Jnj4s= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Nick Rosbrook , George Dunlap , Anthony PERARD Subject: [PATCH 09/11] tools/libxl: add support for xenstore quota in domain_config Date: Thu, 5 Mar 2026 14:52:06 +0100 Message-ID: <20260305135208.2208663-10-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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)[99.99%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.967]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_FIVE(0.00)[5]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -6.79 X-Spam-Level: Add support for xenstore quota in the struct domain_config. Initially it will be used only for migration of a domain. Signed-off-by: Juergen Gross --- tools/golang/xenlight/helpers.gen.go | 6 ++++++ tools/golang/xenlight/types.gen.go | 1 + tools/libs/light/libxl_dom.c | 8 ++++++++ tools/libs/light/libxl_domain.c | 10 ++++++++++ tools/libs/light/libxl_types.idl | 1 + 5 files changed, 26 insertions(+) diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 6c9af904c5..416c2d3e07 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -1286,6 +1286,9 @@ if err := x.TrapUnmappedAccesses.fromC(&xc.trap_unmapped_accesses);err != nil { return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err) } x.XenstoreFeatureMask = uint32(xc.xenstore_feature_mask) +if err := x.XenstoreQuota.fromC(&xc.xenstore_quota);err != nil { +return fmt.Errorf("converting field XenstoreQuota: %v", err) +} return nil} @@ -1825,6 +1828,9 @@ if err := x.TrapUnmappedAccesses.toC(&xc.trap_unmapped_accesses); err != nil { return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err) } xc.xenstore_feature_mask = C.uint32_t(x.XenstoreFeatureMask) +if err := x.XenstoreQuota.toC(&xc.xenstore_quota); err != nil { +return fmt.Errorf("converting field XenstoreQuota: %v", err) +} return nil } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index 5393277190..7e7292cf70 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -629,6 +629,7 @@ VmtraceBufKb int Vpmu Defbool TrapUnmappedAccesses Defbool XenstoreFeatureMask uint32 +XenstoreQuota XsQuotaSet } type DomainBuildInfoTypeUnion interface { diff --git a/tools/libs/light/libxl_dom.c b/tools/libs/light/libxl_dom.c index 05ebc69534..1c0689d7ff 100644 --- a/tools/libs/light/libxl_dom.c +++ b/tools/libs/light/libxl_dom.c @@ -509,6 +509,14 @@ retry_transaction: xs_introduce_domain(ctx->xsh, domid, state->store_mfn, state->store_port); + if (info->xenstore_quota.num_quota) { + rc = libxl_xsquota_domain_set(ctx, domid, &info->xenstore_quota); + if (rc) { + LOGED(ERROR, domid, "Failed to set Xenstore quota"); + goto out; + } + } + out: free(vm_path); return rc; diff --git a/tools/libs/light/libxl_domain.c b/tools/libs/light/libxl_domain.c index 5be47f687f..86e43e7133 100644 --- a/tools/libs/light/libxl_domain.c +++ b/tools/libs/light/libxl_domain.c @@ -2533,6 +2533,16 @@ static void retrieve_domain_configuration_end(libxl__egc *egc, } } + /* Xenstore quota */ + { + libxl_xs_quota_set_dispose(&d_config->b_info.xenstore_quota); + rc = libxl_xsquota_domain_get(CTX, domid, &d_config->b_info.xenstore_quota); + if (rc) { + LOGD(ERROR, domid, "Fail to get xenstore quota"); + goto out; + } + } + /* Devices: disk, nic, vtpm, pcidev etc. */ /* The MERGE macro implements following logic: diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index c5ddc40f35..ee8f89e462 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -760,6 +760,7 @@ libxl_domain_build_info = Struct("domain_build_info",[ ("vpmu", libxl_defbool), ("trap_unmapped_accesses", libxl_defbool), ("xenstore_feature_mask", uint32, {'init_val': '~0U'}), + ("xenstore_quota", libxl_xs_quota_set), ], dir=DIR_IN, copy_deprecated_fn="libxl__domain_build_info_copy_deprecated", -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:58:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:58:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246747.1545863 (Exim 4.92) (envelope-from ) id 1vy9DK-0004mk-9N; Thu, 05 Mar 2026 13:58:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246747.1545863; Thu, 05 Mar 2026 13: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 ) id 1vy9DK-0004ln-3X; Thu, 05 Mar 2026 13:58:06 +0000 Received: by outflank-mailman (input) for mailman id 1246747; Thu, 05 Mar 2026 13:58:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy98K-00008m-OP for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:52:57 +0000 Received: from smtp-out1.suse.de (smtp-out1.suse.de [2a07:de40:b251:101:10:150:64:1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9bbd47c8-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:52:54 +0100 (CET) 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 E26253F8B7; Thu, 5 Mar 2026 13:52:53 +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 BD3CA3EA68; Thu, 5 Mar 2026 13:52:53 +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 jhIiLbWKqWkWTwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:52:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9bbd47c8-189a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718774; 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=OVzJ3vkzk9Kd/2UKnmB2k8cly65avjJkTaC6JZd+bg8=; b=iKGXaH4Yp+kB1FiF6PRKGT2+/U1JBirZdLjmovQ8VwqOXgUSAPvePz1hqJ/UmwX53A0wfo cc8MYRfeXMocMiiSMH6DQNZnpNKAQr3eH/UXAtKe5Bz+sklgRvztjHfxqVlYcmiHz6MHAf xXkvIen6QoIVh2dIVwiGWgKWkoWAjAs= Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772718773; 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=OVzJ3vkzk9Kd/2UKnmB2k8cly65avjJkTaC6JZd+bg8=; b=U+3yZC/uzXKjWhzK8thLKyTThh9gbe3VUgm/crOtHn49WnU6SlfsqSuXs4zWhbdI4d5Bkg 5E7mTdTRdJBAMHxM/sESqw/kvWlT5NGPcKq6bfLxKiM82/x+SIiGLawDUL1hXJCtG6mjwG RfX7PD9+RxFFkgh7YFXc8RRLry9O1L4= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Nick Rosbrook , George Dunlap , Anthony PERARD Subject: [PATCH 08/11] tools/libxl: add functions for retrieving and setting xenstore quota Date: Thu, 5 Mar 2026 14:52:05 +0100 Message-ID: <20260305135208.2208663-9-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.19)[-0.940]; 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)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCPT_COUNT_FIVE(0.00)[5]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,suse.com:email,imap1.dmz-prg2.suse.org:helo]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -6.79 X-Spam-Level: Add some functions allowing to retrieve and set Xenstore quota (either global or domain specific). Signed-off-by: Juergen Gross --- tools/golang/xenlight/helpers.gen.go | 78 ++++++++++++++++++++ tools/golang/xenlight/types.gen.go | 9 +++ tools/include/libxl.h | 20 ++++++ tools/libs/light/Makefile | 1 + tools/libs/light/libxl_types.idl | 9 +++ tools/libs/light/libxl_xsquota.c | 102 +++++++++++++++++++++++++++ 6 files changed, 219 insertions(+) create mode 100644 tools/libs/light/libxl_xsquota.c diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 8909fe8a1b..6c9af904c5 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -998,6 +998,84 @@ xc.policy = C.libxl_rdm_reserve_policy(x.Policy) return nil } +// NewXsQuotaItem returns an instance of XsQuotaItem initialized with defaults. +func NewXsQuotaItem() (*XsQuotaItem, error) { +var ( +x XsQuotaItem +xc C.libxl_xs_quota_item) + +C.libxl_xs_quota_item_init(&xc) +defer C.libxl_xs_quota_item_dispose(&xc) + +if err := x.fromC(&xc); err != nil { +return nil, err } + +return &x, nil} + +func (x *XsQuotaItem) fromC(xc *C.libxl_xs_quota_item) error { + x.Name = C.GoString(xc.name) +x.Val = uint32(xc.val) + + return nil} + +func (x *XsQuotaItem) toC(xc *C.libxl_xs_quota_item) (err error){defer func(){ +if err != nil{ +C.libxl_xs_quota_item_dispose(xc)} +}() + +if x.Name != "" { +xc.name = C.CString(x.Name)} +xc.val = C.uint32_t(x.Val) + + return nil + } + +// NewXsQuotaSet returns an instance of XsQuotaSet initialized with defaults. +func NewXsQuotaSet() (*XsQuotaSet, error) { +var ( +x XsQuotaSet +xc C.libxl_xs_quota_set) + +C.libxl_xs_quota_set_init(&xc) +defer C.libxl_xs_quota_set_dispose(&xc) + +if err := x.fromC(&xc); err != nil { +return nil, err } + +return &x, nil} + +func (x *XsQuotaSet) fromC(xc *C.libxl_xs_quota_set) error { + x.Quota = nil +if n := int(xc.num_quota); n > 0 { +cQuota := (*[1<<28]C.libxl_xs_quota_item)(unsafe.Pointer(xc.quota))[:n:n] +x.Quota = make([]XsQuotaItem, n) +for i, v := range cQuota { +if err := x.Quota[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Quota: %v", err) } +} +} + + return nil} + +func (x *XsQuotaSet) toC(xc *C.libxl_xs_quota_set) (err error){defer func(){ +if err != nil{ +C.libxl_xs_quota_set_dispose(xc)} +}() + +if numQuota := len(x.Quota); numQuota > 0 { +xc.quota = (*C.libxl_xs_quota_item)(C.malloc(C.ulong(numQuota)*C.sizeof_libxl_xs_quota_item)) +xc.num_quota = C.int(numQuota) +cQuota := (*[1<<28]C.libxl_xs_quota_item)(unsafe.Pointer(xc.quota))[:numQuota:numQuota] +for i,v := range x.Quota { +if err := v.toC(&cQuota[i]); err != nil { +return fmt.Errorf("converting field Quota: %v", err) +} +} +} + + return nil + } + // NewDomainBuildInfo returns an instance of DomainBuildInfo initialized with defaults. func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) { var ( diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index ab9d4ca7b4..5393277190 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -543,6 +543,15 @@ Altp2MModeExternal Altp2MMode = 2 Altp2MModeLimited Altp2MMode = 3 ) +type XsQuotaItem struct { +Name string +Val uint32 +} + +type XsQuotaSet struct { +Quota []XsQuotaItem +} + type DomainBuildInfo struct { MaxVcpus int AvailVcpus Bitmap diff --git a/tools/include/libxl.h b/tools/include/libxl.h index bc35e412da..a70d9d347f 100644 --- a/tools/include/libxl.h +++ b/tools/include/libxl.h @@ -1537,6 +1537,18 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, const libxl_mac *src); */ #define LIBXL_HAVE_XEN_PLATFORM_PCI_BAR_UC +/* + * LIBXL_HAVE_XENSTORE_QUOTA + * + * If this is defined the Xenstore quota related functions + * libxl_xsquota_global_get() + * libxl_xsquota_global_set() + * libxl_xsquota_domain_get() + * libxl_xsquota_domain_set() + * are available. + */ +#define LIBXL_HAVE_XENSTORE_QUOTA + typedef char **libxl_string_list; void libxl_string_list_dispose(libxl_string_list *sl); int libxl_string_list_length(const libxl_string_list *sl); @@ -3011,6 +3023,14 @@ static inline int libxl_qemu_monitor_command_0x041200(libxl_ctx *ctx, #define libxl_qemu_monitor_command libxl_qemu_monitor_command_0x041200 #endif +/* Get/set global and per-domain Xenstore quota. */ +int libxl_xsquota_global_get(libxl_ctx *ctx, libxl_xs_quota_set *q); +int libxl_xsquota_global_set(libxl_ctx *ctx, libxl_xs_quota_set *q); +int libxl_xsquota_domain_get(libxl_ctx *ctx, uint32_t domid, + libxl_xs_quota_set *q); +int libxl_xsquota_domain_set(libxl_ctx *ctx, uint32_t domid, + libxl_xs_quota_set *q); + #include /* diff --git a/tools/libs/light/Makefile b/tools/libs/light/Makefile index bc60c46558..ca22a40c6c 100644 --- a/tools/libs/light/Makefile +++ b/tools/libs/light/Makefile @@ -106,6 +106,7 @@ OBJS-y += libxl_pvcalls.o OBJS-y += libxl_vsnd.o OBJS-y += libxl_vkb.o OBJS-y += libxl_virtio.o +OBJS-y += libxl_xsquota.o OBJS-y += libxl_genid.o OBJS-y += _libxl_types.o OBJS-y += libxl_flask.o diff --git a/tools/libs/light/libxl_types.idl b/tools/libs/light/libxl_types.idl index d64a573ff3..c5ddc40f35 100644 --- a/tools/libs/light/libxl_types.idl +++ b/tools/libs/light/libxl_types.idl @@ -574,6 +574,15 @@ libxl_altp2m_mode = Enumeration("altp2m_mode", [ (3, "limited"), ], init_val = "LIBXL_ALTP2M_MODE_DISABLED") +libxl_xs_quota_item = Struct("xs_quota_item", [ + ("name", string), + ("val", uint32), + ]) + +libxl_xs_quota_set = Struct("xs_quota_set", [ + ("quota", Array(libxl_xs_quota_item, "num_quota")) + ]) + libxl_domain_build_info = Struct("domain_build_info",[ ("max_vcpus", integer), ("avail_vcpus", libxl_bitmap), diff --git a/tools/libs/light/libxl_xsquota.c b/tools/libs/light/libxl_xsquota.c new file mode 100644 index 0000000000..b9afa1c914 --- /dev/null +++ b/tools/libs/light/libxl_xsquota.c @@ -0,0 +1,102 @@ +/* SPDX-License-Identifier: LGPL-2.1-only */ + +/* Xenstore quota handling functions. */ + +#include "libxl_internal.h" + +static int get_quota(libxl_ctx *ctx, unsigned int domid, libxl_xs_quota_set *q, + bool (func)(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int *value)) +{ + char **names; + unsigned int num, i; + int rc = 0; + GC_INIT(ctx); + + names = xs_get_quota_names(ctx->xsh, &num); + if (!names) { + /* Xenstore quota support is optional! */ + if (errno != ENOSYS) + rc = ERROR_FAIL; + q->num_quota = 0; + goto out; + } + + q->num_quota = num; + q->quota = libxl__calloc(NOGC, num, sizeof(*q->quota)); + for (i = 0; i < num; i++) { + q->quota[i].name = libxl__strdup(NOGC, names[i]); + if (!func(ctx->xsh, domid, q->quota[i].name, &q->quota[i].val)) { + libxl_xs_quota_set_dispose(q); + rc = ERROR_FAIL; + break; + } + } + + free(names); + + out: + GC_FREE; + return rc; +} + +static int set_quota(libxl_ctx *ctx, unsigned int domid, libxl_xs_quota_set *q, + bool (func)(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int value)) +{ + unsigned int i; + int rc = 0; + GC_INIT(ctx); + + for (i = 0; i < q->num_quota; i++) { + if (!func(ctx->xsh, domid, q->quota[i].name, q->quota[i].val)) { + rc = ERROR_FAIL; + break; + } + } + + GC_FREE; + return rc; +} + +static bool get_global_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int *value) +{ + return xs_get_global_quota(h, quota, value); +} + +int libxl_xsquota_global_get(libxl_ctx *ctx, libxl_xs_quota_set *q) +{ + return get_quota(ctx, 0, q, get_global_quota); +} + +static bool set_global_quota(struct xs_handle *h, unsigned int domid, + char *quota, unsigned int value) +{ + return xs_set_global_quota(h, quota, value); +} + +int libxl_xsquota_global_set(libxl_ctx *ctx, libxl_xs_quota_set *q) +{ + return set_quota(ctx, 0, q, set_global_quota);; +} + +int libxl_xsquota_domain_get(libxl_ctx *ctx, uint32_t domid, + libxl_xs_quota_set *q) +{ + return get_quota(ctx, domid, q, xs_get_domain_quota); +} + +int libxl_xsquota_domain_set(libxl_ctx *ctx, uint32_t domid, + libxl_xs_quota_set *q) +{ + return set_quota(ctx, domid, q, xs_set_domain_quota); +} + +/* + * Local variables: + * mode: C + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:58:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:58:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246748.1545868 (Exim 4.92) (envelope-from ) id 1vy9DK-0004t4-Hw; Thu, 05 Mar 2026 13:58:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246748.1545868; Thu, 05 Mar 2026 13: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 ) id 1vy9DK-0004rp-Cg; Thu, 05 Mar 2026 13:58:06 +0000 Received: by outflank-mailman (input) for mailman id 1246748; Thu, 05 Mar 2026 13:58:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy98U-00008m-Nz for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:53:06 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a217b1b9-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:53:05 +0100 (CET) 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 C4B155BDE2; Thu, 5 Mar 2026 13:53:04 +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 A8D5B3EA68; Thu, 5 Mar 2026 13:53:04 +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 Dg0lKMCKqWkmTwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:53:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a217b1b9-189a-11f1-9ccf-f158ae23cfc8 Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH 10/11] tools/xl: add xl commands for xenstore quota operations Date: Thu, 5 Mar 2026 14:52:07 +0100 Message-ID: <20260305135208.2208663-11-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: C4B155BDE2 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-Spam-Level: Add "xl xenstore-quota-get" and "xl xenstore-quota-set" commands for retrieving and setting global and per-domain Xenstore quota. Signed-off-by: Juergen Gross --- tools/xl/Makefile | 1 + tools/xl/xl.h | 2 + tools/xl/xl_cmdtable.c | 10 +++++ tools/xl/xl_parse.c | 25 ++++++++++++ tools/xl/xl_parse.h | 1 + tools/xl/xl_xsquota.c | 88 ++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 127 insertions(+) create mode 100644 tools/xl/xl_xsquota.c diff --git a/tools/xl/Makefile b/tools/xl/Makefile index 973ff0e1a2..e4eed8be13 100644 --- a/tools/xl/Makefile +++ b/tools/xl/Makefile @@ -24,6 +24,7 @@ XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o XL_OBJS += xl_info.o xl_console.o xl_misc.o XL_OBJS += xl_vmcontrol.o xl_saverestore.o xl_migrate.o XL_OBJS += xl_vdispl.o xl_vsnd.o xl_vkb.o +XL_OBJS += xl_xsquota.o $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog) $(XL_OBJS): CFLAGS += $(CFLAGS_XL) diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 9000df00de..0efc07a6ba 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -217,6 +217,8 @@ int main_psr_mba_set(int argc, char **argv); int main_psr_mba_show(int argc, char **argv); #endif int main_qemu_monitor_command(int argc, char **argv); +int main_xsquota_get(int argc, char **argv); +int main_xsquota_set(int argc, char **argv); void help(const char *command); diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 06a0039718..3de12b12ae 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -649,6 +649,16 @@ const struct cmd_spec cmd_table[] = { "-h print this help\n" }, #endif + { "xenstore-quota-get", + &main_xsquota_get, 0, 0, + "List global or domain specific Xenstore quota data", + "|-g", + }, + { "xenstore-quota-set", + &main_xsquota_set, 0, 1, + "Set global or domain specific Xenstore quota data", + "|-g =...", + }, }; const int cmdtable_len = ARRAY_SIZE(cmd_table); diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 1a2ea8b5d5..934ad4eeef 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1314,6 +1314,31 @@ out: return ret; } +int parse_xsquota_item(const char *buf, struct libxl_xs_quota_item *item) +{ + const char *eq; + char *endptr; + + eq = strchr(buf, '='); + if (!eq) { + fprintf(stderr, "Quota specification \"%s\" lacks \"=\".\n", buf); + return ERROR_INVAL; + } + errno = 0; + item->name = strndup(buf, eq - buf); + if (!item->name) + return ERROR_NOMEM; + item->val = strtoul(eq + 1, &endptr, 0); + if (errno || !eq[1] || *endptr) { + fprintf(stderr, + "Quota specification \"%s\" uses illegal value \"%s\".\n", + buf, eq); + return ERROR_INVAL; + } + + return 0; +} + void parse_config_data(const char *config_source, const char *config_data, int config_len, diff --git a/tools/xl/xl_parse.h b/tools/xl/xl_parse.h index fe0d586cdd..57bb43a067 100644 --- a/tools/xl/xl_parse.h +++ b/tools/xl/xl_parse.h @@ -36,6 +36,7 @@ int parse_nic_config(libxl_device_nic *nic, XLU_Config **config, char *token); int parse_vdispl_config(libxl_device_vdispl *vdispl, char *token); int parse_vsnd_item(libxl_device_vsnd *vsnd, const char *spec); int parse_vkb_config(libxl_device_vkb *vkb, char *token); +int parse_xsquota_item(const char *buf, struct libxl_xs_quota_item *item); int match_option_size(const char *prefix, size_t len, char *arg, char **argopt); diff --git a/tools/xl/xl_xsquota.c b/tools/xl/xl_xsquota.c new file mode 100644 index 0000000000..eaf19feac8 --- /dev/null +++ b/tools/xl/xl_xsquota.c @@ -0,0 +1,88 @@ +/* SPDX-License-Identifier: LGPL-2.1-only */ + +#include +#include +#include +#include + +#include "xl.h" +#include "xl_utils.h" +#include "xl_parse.h" + +int main_xsquota_get(int argc, char **argv) +{ + libxl_xs_quota_set q; + unsigned int i; + int rc; + + if (argc != 2) { + fprintf(stderr, "Domain or \"-g\" must be specified.\n"); + return EXIT_FAILURE; + } + + if (!strcmp(argv[1], "-g")) { + rc = libxl_xsquota_global_get(ctx, &q); + } else { + uint32_t domid = find_domain(argv[1]); + + rc = libxl_xsquota_domain_get(ctx, domid, &q); + } + + if (rc) { + fprintf(stderr, "Quota could not be obtained.\n"); + return EXIT_FAILURE; + } + + printf("Quota name Quota value\n"); + printf("--------------------------------\n"); + for (i = 0; i < q.num_quota; i++) + printf("%-20s %8u\n", q.quota[i].name, q.quota[i].val); + + libxl_xs_quota_set_dispose(&q); + + return EXIT_SUCCESS; +} + +int main_xsquota_set(int argc, char **argv) +{ + unsigned int i; + libxl_xs_quota_set q; + int rc = EXIT_FAILURE; + + if (argc < 3) { + fprintf(stderr, "Not enough parameters.\n"); + return EXIT_FAILURE; + } + + q.num_quota = argc - 2; + q.quota = calloc(q.num_quota, sizeof(*q.quota)); + if (!q.quota) { + fprintf(stderr, "Memory allocation failure!\n"); + goto err; + } + + for (i = 2; i < argc; i++) { + if (parse_xsquota_item(argv[i], q.quota + i - 2)) + goto err; + } + + if (!strcmp(argv[1], "-g")) { + rc = libxl_xsquota_global_set(ctx, &q); + } else { + uint32_t domid = find_domain(argv[1]); + + rc = libxl_xsquota_domain_set(ctx, domid, &q); + } + + if (rc) { + fprintf(stderr, "Quota could not be set.\n"); + rc = EXIT_FAILURE; + } else { + rc = EXIT_SUCCESS; + } + + err: + libxl_xs_quota_set_dispose(&q); + + return rc; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 13:58:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 13:58:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246751.1545888 (Exim 4.92) (envelope-from ) id 1vy9DL-0005QS-VK; Thu, 05 Mar 2026 13:58:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246751.1545888; Thu, 05 Mar 2026 13:58:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy9DL-0005PX-Pz; Thu, 05 Mar 2026 13:58:07 +0000 Received: by outflank-mailman (input) for mailman id 1246751; Thu, 05 Mar 2026 13:58:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy98a-00008m-2A for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 13:53:12 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [2a07:de40:b251:101:10:150:64:2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a554fb30-189a-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 14:53:10 +0100 (CET) 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 37CAA5BD98; Thu, 5 Mar 2026 13:53:10 +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 1BB9B3EA68; Thu, 5 Mar 2026 13:53:10 +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 qQ2hBcaKqWktTwAAD6G6ig (envelope-from ); Thu, 05 Mar 2026 13:53:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a554fb30-189a-11f1-9ccf-f158ae23cfc8 Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH 11/11] tools/xl: add support for xenstore quota setting via domain config Date: Thu, 5 Mar 2026 14:52:08 +0100 Message-ID: <20260305135208.2208663-12-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305135208.2208663-1-jgross@suse.com> References: <20260305135208.2208663-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-Rspamd-Queue-Id: 37CAA5BD98 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Score: -4.00 X-Spam-Level: X-Spam-Flag: NO X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org Add a new "xenstore-quota" domain config parameter for setting the Xenstore quota of a new domain via a list of = items. Signed-off-by: Juergen Gross --- docs/man/xl.cfg.5.pod.in | 13 +++++++++++++ tools/xl/xl_parse.c | 23 ++++++++++++++++++++++- 2 files changed, 35 insertions(+), 1 deletion(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 27c455210b..3aac0bc4fb 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -748,6 +748,19 @@ via the B command in dom0. The default value is B<0xffffffff>, meaning that all possible Xenstore features are visible by the guest. +=item B + +Specifies Xenstore quota values of the domain, overriding the default +values of Xenstore. + +Each B is a B=B specification. The supported +B identifiers can be obtained by the B +command. B is a non-negative integer. + +As per-domain Xenstore quota are an optional Xenstore feature, the +B config parameter may not be supported by all Xenstore +implementations. + =back =head2 Devices diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 934ad4eeef..06a5b60736 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1351,7 +1351,7 @@ void parse_config_data(const char *config_source, XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms, *usbctrls, *usbdevs, *p9devs, *vdispls, *pvcallsifs_devs; XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs, - *mca_caps, *smbios, *llc_colors; + *mca_caps, *smbios, *llc_colors, *xs_quota; int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian, num_mca_caps; int num_smbios; int pci_power_mgmt = 0; @@ -1360,6 +1360,7 @@ void parse_config_data(const char *config_source, int pci_seize = 0; int i, e; int num_llc_colors; + int num_xs_quota; char *kernel_basename; libxl_domain_create_info *c_info = &d_config->c_info; @@ -1467,6 +1468,26 @@ void parse_config_data(const char *config_source, if (!xlu_cfg_get_long (config, "xenstore_feature_mask", &l, 0)) b_info->xenstore_feature_mask = l; + if (!xlu_cfg_get_list(config, "xenstore_quota", &xs_quota, &num_xs_quota, 0)) { + b_info->xenstore_quota.num_quota = num_xs_quota; + b_info->xenstore_quota.quota = calloc(num_xs_quota, sizeof(* b_info->xenstore_quota.quota)); + if (b_info->xenstore_quota.quota == NULL) { + fprintf(stderr, "unable to allocate memory for xenstore_quota\n"); + exit(-1); + } + + for (i = 0; i < num_xs_quota; i++) { + buf = xlu_cfg_get_listitem(xs_quota, i); + if (!buf) { + fprintf(stderr, + "xl: Can't get element %d in Xenstore quota list\n", i); + exit(1); + } + if (parse_xsquota_item(buf, b_info->xenstore_quota.quota + i)) + exit(1); + } + } + libxl_domain_build_info_init_type(b_info, c_info->type); if (b_info->type == LIBXL_DOMAIN_TYPE_PVH) { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 14:35:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 14:35:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246831.1545898 (Exim 4.92) (envelope-from ) id 1vy9nd-0003eW-N8; Thu, 05 Mar 2026 14:35:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246831.1545898; Thu, 05 Mar 2026 14:35:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy9nd-0003eP-KE; Thu, 05 Mar 2026 14:35:37 +0000 Received: by outflank-mailman (input) for mailman id 1246831; Thu, 05 Mar 2026 14:35:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vy9nc-0003eJ-TM for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 14:35:37 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 912783aa-18a0-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 15:35:34 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fRXBr2gGDz1XLMvF for ; Thu, 5 Mar 2026 14:35:32 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 13efca2423ce456a8fffcf306fd88959; Thu, 05 Mar 2026 14:35:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 912783aa-18a0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1772721332; x=1772991332; bh=bjjglNVu4C0tfbhCkLt2PLAJ8HDOll2Ntt8/ixuBhH0=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=zXfHRxp+TrxQO5hhELYzBehD2iWfAkQ0DIPxDo7h8rzlod5nABEUdCh0SeP0z2TDg 7qX6G8LE5KCue0U9Is4AveKsLmNpHc8+Ym8544m4kgy6uC+FaxgD90awHbUsnrqkBB r0XUw/L2RSyA1E1eCYzl8JyaSvsrRbJJadA/Yd7dGNzDQ13jTSLU+tnDx97sjUyR7x 1bK02eVxhdg87/ZvtHKo57D8Dfl3gntmYs8JwLfEzDv02jB6Xi0obTO3mI73xq79Du YLIrMAy1BbuxlixnpZZ0BpvcUksAHrHpcFbmOsEGQGGFgdMTDUmlL/8X5Za+3IfeJ6 E4/2ufMoXj7Tw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1772721332; x=1772981832; i=teddy.astie@vates.tech; bh=bjjglNVu4C0tfbhCkLt2PLAJ8HDOll2Ntt8/ixuBhH0=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=ThKiC8+JBioN8O+ChwxU+6Ucuj2UmP1MslB9Jj+uNp64bB4CXCOSV9M6yH2KghWvB qWx1PpoN/efiNH3VT0rmZvRrhllZ8Lm5bEYS/xberN8w3Xzsv+3vV/wW07axvlQBDh z6U/UKAA5+RzX1CCpF9g9U1XsiOkmAIpsT2EN6t5nyqCbj8YUAto0ONrnAoMr3hgWg oL3WLyFP/uR1LrdolNM8dMv91DA+Xf/BsT0PVADXjJcEHmFQp4MhXfGG+deTMAKM61 ZnPeg32WoaKT14kqpI7kbELQLDTqMnUJYAFtUnD2tK6Tj5hPLBp1C/SBXPfaOs8+qr LTytyFv3ub6yg== From: "Teddy Astie" Subject: =?utf-8?Q?Re:=20RFC:=20unmap=5Fpage=5Frange=20optimisation=20(avoiding=20emulation=20faults=20during=20VM=20migration)?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1772721331310 Message-Id: <42bc5972-ecd0-4a3c-9ff7-0a5246f4bd6b@vates.tech> To: "Edwin Torok" , Xen-devel Cc: "Ross Lagerwall" , "Juergen Gross" References: <16133EFF-88FF-467F-B78F-E96EB148C3A5@citrix.com> In-Reply-To: <16133EFF-88FF-467F-B78F-E96EB148C3A5@citrix.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.13efca2423ce456a8fffcf306fd88959?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260305:md Date: Thu, 05 Mar 2026 14:35:32 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adding Juergen Le 12/02/2026 =C3=A0 18:50, Edwin Torok a =C3=A9crit=C2=A0: > Hi, > > When profiling a VM migration I noticed that on the sender side a signifi= cant (~45%) time is spent in PV Dom0 Linux taking an emulation fault in unm= ap_page_range [1]: > > The call comes from zap_pte_range (pgtable_64.h, inlined): > ptent =3D ptep_get_and_clear_full(mm, addr, pte, tlb->fullmm); > > This has 2 implementations: native and a generic one where pte_clear is i= mplemented using set_pte_at with a Xen pvop. > > As a proof of concept I=E2=80=99ve deleted the native implementation [2],= which makes it fall back to the generic implementation [3]. > This is not necessarily safe on SMP (it reads and clears as 2 separate st= eps), but shows that a paravirt op is faster than emulation. > > To fix this we may need to partially revert https://git.kernel.org/pub/s= cm/linux/kernel/git/torvalds/linux.git/commit/?id=3D4cdd9c8931767e1c56a51a1= 078d33a8c340f4405 > > To test this more easily I=E2=80=99ve written a small test program that m= aps/unmaps pages from a domain in Dom0 [4]. > Before: 3.26932 +- 0.00503 seconds time elapsed ( +- 0.15% ) > After: 0.75642 +- 0.00202 seconds time elapsed ( +- 0.27% ) > > It is more than 4x faster to use the paravirt ops than trapping and emula= ting. > From a functional point of view the above commit is correct, Xen doesn= =E2=80=99t need a dedicated PV operation: trap and emulation works. > But from a performance point of view I=E2=80=99d say that Xen does need i= t. This is a hot-path during migration, and it=E2=80=99d be worthwhile to o= ptimise it. > > Just deleting the native implementation is probably not the solution, sin= ce we also want a value returned, and the existing PV operation is void. > It probably needs a new PV operation (re)introduced with the desired sema= ntics? > I can't find a MMUEXT hypercall which does roughly xchg on the pagetable. You can write a entry through MMU_NORMAL_PT_UPDATE, but not reading it before writing it atomically (xchg). Maybe there is a way to achieve it, but otherwise, it would need a new dedicated hypercall and related code for Linux. > Best regards, > --Edwin > > [1]: https://cdn.jsdelivr.net/gh/edwintorok/xen@pmustack-coverletter/docs= /tmp/migrate-send.svg?x=3D950.6&y=3D2197 > > [2]: > diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtabl= e.h > index 690c0307afed..ab6318bb5676 100644 > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -1097,13 +1097,9 @@ extern int ptep_test_and_clear_young(struct vm_are= a_struct *vma, > extern int ptep_clear_flush_young(struct vm_area_struct *vma, > unsigned long address, pte_t *ptep); > > -#define __HAVE_ARCH_PTEP_GET_AND_CLEAR > -static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned lo= ng addr, > - pte_t *ptep) > -{ > - pte_t pte =3D native_ptep_get_and_clear(ptep); > - return pte; > -} > +static inline pte_t ptep_get_and_clear(struct mm_struct *mm, > + unsigned long address, > + pte_t *ptep); > > #define __HAVE_ARCH_PTEP_GET_AND_CLEAR_FULL > static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, > > [3]: > #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) > { > pte_t pte =3D *ptep; > pte_clear(mm, address, ptep); > return pte; > } > #endif > static inline void pte_clear(struct mm_struct *mm, unsigned long addr, pt= e_t *ptep) { set_pte_at(mm, addr, ptep, __pte(0)); } > > [4]: > $ cat >main.c < #include > #include > #include > #include > #include > #include > > int main(int argc, char *argv[]) { > if (argc !=3D 3) { > fprintf(stderr, "Usage: %s \n", argv[0]); > return 1; > } > uint32_t domid =3D atoi(argv[1]); > uint32_t batch_size =3D atoi(argv[2]); > > if (!domid || !batch_size) { > fprintf(stderr, "Invalid arguments, expected 2 integers"); > return 2; > } > > xenforeignmemory_handle *handle =3D xenforeignmemory_open(NULL, 0); > if (!handle) > return 3; > > xc_interface *xc =3D xc_interface_open(NULL, NULL, 0); > if (!xc) > return 4; > > xen_pfn_t nr_pfns; > if (xc_domain_nr_gpfns(xc, domid, &nr_pfns) < 0) > return 5; > > unsigned mappings_size =3D nr_pfns / batch_size + 1; > void **mappings =3D calloc(mappings_size, sizeof(void *)); > if (!mappings) { > perror("calloc"); > return 6; > } > > for (xen_pfn_t i =3D 0; i < nr_pfns; i +=3D batch_size) { > xen_pfn_t arr[batch_size]; > int err[batch_size]; > > for (unsigned j =3D 0; j < batch_size; j++) > arr[j] =3D i + j; > > unsigned long idx =3D i / batch_size; > assert(idx < mappings_size); > mappings[idx] =3D xenforeignmemory_map( > handle, domid, PROT_READ, sizeof(arr) / sizeof(arr[0]), arr, err= ); > if (!mappings[idx]) > return 7; > } > > for (xen_pfn_t i =3D 0; i < nr_pfns; i +=3D batch_size) { > unsigned long idx =3D i / batch_size; > assert(idx < mappings_size); > if (xenforeignmemory_unmap(handle, mappings[idx], batch_size)) > return 8; > } > > free(mappings); > xc_interface_close(xc); > xenforeignmemory_close(handle); > > return EXIT_SUCCESS; > } > EOF > > $ cat >meson.build < project('xfm_scale', 'c', default_options:['c_std=3Dgnu11']) > xfm =3D dependency('xenforeignmemory') > xc =3D dependency('xencontrol=E2=80=99) > executable('xfm_scale', 'main.c', dependencies: [xfm, xc]) > EOF Teddy -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Thu Mar 05 14:54:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 14:54:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246857.1545908 (Exim 4.92) (envelope-from ) id 1vyA5d-0006Xr-6a; Thu, 05 Mar 2026 14:54:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246857.1545908; Thu, 05 Mar 2026 14:54:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyA5d-0006Xk-3b; Thu, 05 Mar 2026 14:54:13 +0000 Received: by outflank-mailman (input) for mailman id 1246857; Thu, 05 Mar 2026 14:54:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyA5b-0006Xe-SZ for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 14:54:12 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 275b65d6-18a3-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 15:54:05 +0100 (CET) Received: from LV3PR03MB7707.namprd03.prod.outlook.com (2603:10b6:408:28b::21) by SA2PR03MB5705.namprd03.prod.outlook.com (2603:10b6:806:11a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 14:54:00 +0000 Received: from LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf]) by LV3PR03MB7707.namprd03.prod.outlook.com ([fe80::97e8:ef9c:9031:e2bf%6]) with mapi id 15.20.9678.017; Thu, 5 Mar 2026 14:54:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 275b65d6-18a3-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QLGYOTuPxTXNjoHvjehz8eGfFds28qDl1YkIeh4Ve2ifJ1TDFk1BwsUyojsbokAg57GobS0XFNkVJeoPLlP4puS8QWLbH0OBK4fOmlGbWnUX23VXM+dge8tE0qkjSPpYz7dOYfTD61Yd9dMbEurDt5dwOB+wr1CL5scD6SPs0Xf81lYx/HFdNCgnw3pO1RAg8fedBMTWpMkNzhnmAcQXuvigL7PyfaEloc7d1Rq4MIMkDdgNCthvmNe29Moq3zBnOGtnMsEqk3HH+UymtslkI1AAb/Vp6yoseLjinerqpDkX0yEMw0TqoadvBCPVaHSW+iJx/V3b18QO2mAFMUmnww== 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=Cs5pfM9ZmzxU3q409GwwHFrbDnNPoBv2RjcPlMzcoNk=; b=mqlNifuFfUG00+lRtrV4WJ3EtGnAdnAdHfH4xZyzgoLcU6vtb8qOGBL1zfBOr0206Ad5PP7jnt3UDQP7d095Clds2LGZkSH1o5cR1VA9zd4T0Z7/vioXs5Hd8ybZfXyX+3o84ZShpLv4MD/gPLC0jF8+zDOmKYnMwxxaAn1NrKAWk+BquHIEQBeO5bYWTF8Pd8XtzQQYaFl02gDrDnYuO4FFeZtmRFbrDB/y75kOGaHJM+GsAGaXawsAOko00SZIBvIktw4KKgShs6eneGgtW5xA9WDWRTfLdBzCBbqzF2IhDBOlb/uHm9TljQGq0WPk1L0J0Hprj/RkMGESL3C4Ug== 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=Cs5pfM9ZmzxU3q409GwwHFrbDnNPoBv2RjcPlMzcoNk=; b=mw9jJsF9eRhwZDJhvAE0+LV4FbIKESpEE/GJkK1z0938FF7RV+tnaHNFHW1zhUfgErrV2fwz8o1ovvAjxnW2JuCRFXKjNgXT8tQo5v4/x1vZMfPZOeWoZ/LbsGb9O/lYcDUSKrd5N0EGk8QlxA5RwrgdLEBZN6qgxYohLVbBxCY= From: Bernhard Kaindl To: Jan Beulich CC: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , Marcus Granado , "xen-devel@lists.xenproject.org" , Alejandro Vallejo Subject: RE: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims Thread-Topic: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims Thread-Index: AQHcpy5A2UpiyJQ97kePD66zF1miC7Wfzj4AgAAAi7CAACzoAIAAAbjQ Date: Thu, 5 Mar 2026 14:54:00 +0000 Message-ID: References: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: LV3PR03MB7707:EE_|SA2PR03MB5705:EE_ x-ms-office365-filtering-correlation-id: 744287d1-963e-4688-844b-08de7ac708fd x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021; x-microsoft-antispam-message-info: xwJWhFjslBkDv2fehZpBWb5WVuUa85sXLww5jUov19SXaLrBtggvQstxwEtGIWb6rzo250g+bEyyD1yyU63XiSk2DlscY0FqZv0lR7a1sI92D0ojHrofBIRrSuQwAX/xUtY9vVW3XDU0wwoxsQeR/lvv7dfPYsraVMg4ZMoDHxtqoKhe7hf9Mn2TOFHPRrYjMiSr+VPvK4ciGcj961rBBBBBUs4ZoiUBGGfYmLQnmry06MUHAViYX361GgLSgI8/xXh9P81t5g6iURP+Ah98H+XvKLB+tZlctfE53paSo9D6Hc71O/Uo1FGBY+muzz+bBdnRdarfnQWjLOw2jqKDZVHeL1O4oBy5YPRFifVv4HTeJOAEyC+iJJmkHXlYbA492yao3TPV/ncE416ihV3DJeUOHp7WMCXTAvmL6ktsQCfMzSd7L0Mcbbh4v23ZGLi/5/UT1Y2lTztE42lhc42e2oD/2KUtuzt20caPDv/HD23yeyKageA1t/a3A9kS7sdf+1cnxx8XmSmCXa1UlYPdEYCqG/1q2vtiUCMidu6H//fnE8iGpUTlKXYnNU5R8RCyshs8UHy1oMJJzvMmZvn6YAzLx6tOx0FxAme/funfc2ICAYJ0pK940x5fKc0fsYLPAvZBTfR7BeheeRfl5qXeRzWIdIaq/7KZGe88R83DHZGacacmhchkzlbX+00UMNTGMD3j62fK8zSYw18OEhsQ5zm6BeznOq4znov8sEzPoYs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR03MB7707.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZjNxTm5OR0JQWXMvVVhkMWY4VTBKaGpPcDdRb2pXaGRnMFdOT1FjS0pSVWZC?= =?utf-8?B?d3k0dTVCSFo4Q2Q1RWhMTzZXN2MxWmlvMEpJTzFYek82NzJ6azhRMU5aMUlS?= =?utf-8?B?azF3MzduTzBQTmhxc3loRFBaNExMb0dERFpqKzlkYUFGVGxDRmlMSG9lVmhn?= =?utf-8?B?N1BEeDE2aUNEM0JaYXVqZ3hLeHB2WHZQNWlnaytaU2l2ME56L3VDZ3ZiWnRn?= =?utf-8?B?TFp0Rkw5L1NWNnFIckgyK1lsWHpSMXBremNKNWk1M0RSa0EybUpIUExjdm1L?= =?utf-8?B?VkNRZkVXcHlWU0ZIMHhFRVhkSlpkY1h5Rlo4NTVxcHBpRGMwK3FNakluRkQ0?= =?utf-8?B?RCtub1lOcUZOQ244SVlQUnZGT0R6SERQRkcxaERZb0M4SlI0Y3Jra1B4QUpK?= =?utf-8?B?ejFBODZmV3VYK1RpSitWODRHci9hSy9FaTB0L3VqYWdIQnAyNjRSemhVN05J?= =?utf-8?B?OGJ2T0drUTdqRnIyVG14ZGVMQUIvSEc1aGRzUC8zcVZLczY1bDFUaEgwSkNw?= =?utf-8?B?TXhacmtNT3N1T1U3OFhEV2NDTkg4Y0J0UVdsVGJ6Q1R1N202dVYrSHJRSHRi?= =?utf-8?B?NTJrLzRXdm1NM0FjSjdLQ0VjNjlCYmd2cUI4RkxJejM5NDBpWTJ3djdRTlpZ?= =?utf-8?B?SzQxLzA4Sk1tTXRkUUFiTnFYYkQ3aWxpT1dBaElGbmtWNGV3L1dWWEI2MENP?= =?utf-8?B?ZUVzOUc4UTYzTVBydSsyeVJ4SCtpTExWMExxUTRxaFBVVlE4bWhpb0tMd2VN?= =?utf-8?B?N2s0dDMxZEd1OHhDM0F6RlBDOGhERC92RmpjbzlETXkxaDdXLzFLOHJQMXl3?= =?utf-8?B?Vmt2ZmRQazMvUk1oSkQ3azRLYmNDNmNVQ2xQSkxOb3IvUitvU3JCZHJHT01N?= =?utf-8?B?Sk5oKzJHVGhlVTlMMy9LbFFTVDNmcFdyQmVsY1JhRG9KT2ZPRzlZc3lZeXRI?= =?utf-8?B?cUllTkQwNlZkcHR1bmVaZmVtWHhlL3p0T3lwODRMaEptZmVGT1FrTzZqY0tl?= =?utf-8?B?YnF2UmpHL0tQejhCc0pReDh3eFNHRUcyZElJRXZRRnBNeVNFbDc1TjAvcFJp?= =?utf-8?B?dzVKeHFTYllxSHRrd3QwVWd1V2x0YmFNSTFOcENwd1dab1ltK3FGcmFZMDEw?= =?utf-8?B?R0NRMmIzNWx6b3lPUHQ5MkN6S1lzTXlnWHVVWXp1THFkUVhlTWpqUnlXaGNa?= =?utf-8?B?TFg1SXMzZWZUWmFXUzVQRGVDZThRajJIaW4vQWVKSWoyeDFaTUpvTEdkY3hK?= =?utf-8?B?YVkvK1Y4Rk4yVEFCUm44VmpFNkIxQlRuN3c4ZjlYVWZ3Vy9YWHgvTFJGelli?= =?utf-8?B?RzFMVTRYVkZMK1VCK3JFM25ucVNjaFVNYmFGS1FpMmpzRm52YjRkaUVNL0Z6?= =?utf-8?B?QXpFUzIxYmNMQlJWUWNlZDBpZ2NHYnBjVDZ6YlkwTVJQeVhTK1Y4MEF2NzlJ?= =?utf-8?B?N0hESTd3SEMwV1kxaVlhdjFmd296bVJKME45bllGemYvci85WUxFdkZXTEF4?= =?utf-8?B?VXYwVHpWTHI4L2tpYlBXTnVjSWRuWEpHekZodWF2enZlZS9PUkE2SUlUbGdn?= =?utf-8?B?MC9DeG50NlgyZGpHTDl6a2xqaW92UVI5UVVXeFRVMzFBaWVrSlM0Zm5BaTE1?= =?utf-8?B?UmVwYVVzellTT3JNenJwMnh2YWxTSnhNWUhxbW91YVFpQmxDTjJ5ZVB0RHNy?= =?utf-8?B?M245dkQxLzBUeldCZGZsKzhyMitDQTMvWkVvd1NMTDV6ZS8wcUVlQkk3NWI4?= =?utf-8?B?VllSY21zaTZYa3JkRDEvSW1GVVBXTWNVVGNDRFFEalVZbTczRGhkZlp4RDht?= =?utf-8?B?U0ZIYzI5MDg5SWxNeUlEM1QrZG8yVXJ4R2dUUkNZR0FCL00xbmdqK0JxRmxN?= =?utf-8?B?YjFXa3JDbXJuTldNZXA3RERPY3NUUFh4SWFRMXFKbnZBZjhPNWIvVmtKMnlI?= =?utf-8?B?d2RGbFFKNksrdFo3bnFJNGx4bWVyc0pSMU94ODU1T2ViT2ZVL0hTQjI1Z1Ev?= =?utf-8?B?dHJZVEdhWFdoSktlKzZiWUFIcE1lQnhJVk16SEhXZ0szQkhpRzI4dCs2REpy?= =?utf-8?B?OUxYYTc3NGVjcmpxUlhmV012TStFOTI2bXBkRkp5K2kxcy9Sa3R0cFZZT2Ix?= =?utf-8?B?YXdtOUVoSG01RktUclpwL3ZSYjhqYzlHV29rWWRzMHd2UUkrbjMxbzBsMHVz?= =?utf-8?B?eWYrRDdwNTZldzNuallXUzNJZTE2a0FYN3d4alh6ck1ENER6QXR4WDkwbjgy?= =?utf-8?B?K3lMbHl2MFdleXNkSVVTVktlMExOMEZJbFRRVUVQYnh1WFZpRzBUQ2NvUS8r?= =?utf-8?B?RDZ4d0xQYnczK1EraXE1SkhkVlU3QTk5dXlmbXh0L2lxajRtaUlXUT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV3PR03MB7707.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 744287d1-963e-4688-844b-08de7ac708fd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2026 14:54:00.0689 (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: ZkKpPBDWRV8OTQA9iEBs1wZ/Y6neb0RHVFZIAJWAAJ2wW98Ynm79CGMXzLljmxHR7EQaEwnvG6Bdigl9UhnSZ01pSJ+3sXpd7HWbQwNA7qI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5705 SmFuIEJldWxpY2ggd3JvdGU6DQo+IE9uIDA1LjAzLjIwMjYgMTQ6MTIsIEJlcm5oYXJkIEthaW5k bCB3cm90ZToNCj4gPg0KPiA+IFJvZ2VyIHJlcXVlc3RlZCB0aGUgZG9tY3RsIEFQSSB0byBhbGxv dyBjbGFpbWluZyBmcm9tIG11bHRpcGxlIG5vZGVzIGluIG9uZSBnbw0KPiA+IGFuZCBoZSBzcGVj aWZpZWQgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gZ2V0dGluZyB0aGUgaW1wbGVtZW50YXRpb24g Zm9yIG9uZQ0KPiA+IG5vZGUtc3BlY2lmaWMgY2xhaW0gZG9uZSBmaXJzdCBiZWZvcmUgd2UgZGl2 ZSBpbnRvIG11bHRpLW5vZGUgY2xhaW1zIGNvZGUuDQo+ID4NCj4gPiAtIEluc3RlYWQgb2YgYWRk aW5nL2xpbmtpbmcgYW4gYXJyYXkgb2YgY2xhaW1zIHRvIHN0cnVjdCBkb21haW4sIHdlIGNhbiBr ZWVwDQo+ID4gICB1c2luZyBkLT5vdXRzdGFuZGluZ19wYWdlcyBmb3IgdGhlIHNpbmdsZS1ub2Rl IGNsYWltLg0KPiA+DQo+ID4gLSBUaGVyZSBhcmUgbnVtZXJvdXMgY29tbWVudHMgYW5kIHF1ZXN0 aW9ucyBmb3IgdGhpcyBtaW5pbWFsIGltcGxlbWVudGF0aW9uLg0KPiA+ICAgSWYgd2UnZCBhZGQg bXVsdGktbm9kZSBjbGFpbXMgdG8gaXQsIHRoaXMgcmV2aWV3IG1heSBiZWNvbWUgZXZlbiBtb3Jl IGNvbXBsZXguDQo+ID4NCj4gPiAtIFRoZSBzaW5nbGUtbm9kZSBjbGFpbXMgYmFja2VuZCBjb250 YWlucyB0aGUgaW5mcmFzdHJ1Y3R1cmUgYW5kIG11bHRpLW5vZGUNCj4gPiAgIGNsYWltcyB3b3Vs ZCBiZSBhbiBleHRlbnNpb24gb24gdG9wIG9mIHRoYXQgaW5mcmFzdHJ1Y3R1cmUuDQo+IA0KPiBX aGF0IGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IG5lZWRlZCBpcyBhbiBvdXRsaW5lIG9mIGhvdyBtdWx0 aS1ub2RlIGNsYWltcyBhcmUNCj4gaW50ZW5kZWQgdG8gd29yay4gVGhpcyBpcyBiZWNhdXNlIHdo YXQgeW91IGRvIGhlcmUgbmVlZHMgdG8gZml0IHRoYXQgc2NoZW1lLg0KPiBXaGljaCBpbiB0dXJu IEkgdGhpbmsgaXMgZ29pbmcgdG8gYmUgZGlmZmljdWx0IHdoZW4gZm9yIGEgZG9tYWluIG1vcmUg bWVtb3J5DQo+IGlzIG5lZWRlZCB0aGFuIGFueSBzaW5nbGUgbm9kZSBjYW4gc3VwcGx5LiBIZW5j ZSB3aHkgSSB0aGluayB0aGF0IHlvdSBtYXkNCj4gbm90IGJlIGFibGUgdG8gZ2V0IGF3YXkgd2l0 aCBqdXN0IHNpbmdsZS1ub2RlIGNsYWltcywgbm8gbWF0dGVyIHRoYXQgdGhpcw0KPiBvZiBjb3Vy c2UgY29tcGxpY2F0ZXMgdGhpbmdzLg0KPiANCj4gSXQncyBhbHNvIG5vdCBxdWl0ZSBjbGVhciB0 byBtZSBob3cgbXVsdGlwbGUgc3VjY2Vzc2l2ZSBjbGFpbXMgYWdhaW5zdA0KPiBkaXN0aW5jdCBu b2RlcyB3b3VsZCB3b3JrICh3aGljaCBpc24ndCBhbGwgdGhhdCBkaWZmZXJlbnQgZnJvbSBhIG11 bHRpLW5vZGUNCj4gY2xhaW0pLg0KPiANCj4gVGhpbmtpbmcgb2YgaXQsIGludGVyYWN0aW9uIHdp dGggdGhlIGV4aXN0aW5nIG1lbS1vcCBhbHNvIHdhbnRzIGNsYXJpZnlpbmcuDQo+IEltbyBvbmx5 IG9uZSBvZiB0aGUgdHdvIG91Z2h0IHRvIGJlIHVzYWJsZSBvbiBhIHNpbmdsZSBkb21haW4uDQoN ClllcywgY29ycmVjdC4gQXMgaW1wbGVtZW50ZWQgYnkgWGVuIGluIGRvbWFpbl9zZXRfb3V0c3Rh bmRpbmdfY2xhaW1zKCksDQpYZW4gY2xhaW1zIHdvcmsgdmVyeSBkaWZmZXJlbnQgZnJvbSBzb21l dGhpbmcgbGlrZSBhbiBhbGxvY2F0aW9uOg0KDQpGb3IgZXhhbXBsZSwgd2hlbiB5b3UgYWxsb2Nh dGUsIHlvdSBnZXQgbWVtb3J5LCBhbmQgd2hlbiB5b3UgcmVwZWF0LA0KeW91IGhhdmUgYSBiaWdn ZXIgYWxsb2NhdGlvbi4NCg0KQnV0IFhlbiBjbGFpbXMgaW4gZG9tYWluX3NldF9vdXRzdGFuZGlu Z19jbGFpbXMoKSBkb24ndCB3b3JrIGxpa2UgdGhhdDoNCg0KLSBXaGVuIGEgZG9tYWluIGhhcyBh IGNsYWltLCBkb21haW5fc2V0X291dHN0YW5kaW5nX2NsYWltcygpIG9ubHkgYWxsb3dzDQogIHRv IHJlc2V0IHRoZSBjbGFpbSB0byAwLCBub3RoaW5nIGVsc2UuIEEgc2Vjb25kLCBvciBjaGFuZ2Vk IGNsYWltIGlzIG5vdA0KICBwb3NzaWJsZS4gSSB0aGluayB0aGlzIHdhcyBpbnRlbnRpb25hbDoN Cg0KICAtIGRvbWFpbl9zZXRfb3V0c3RhbmRpbmdfY2xhaW1zKCkgcmVqZWN0cyBpbmNyZWFzaW5n L3JlZHVjaW5nIGEgY2xhaW06DQoNCiAgICBBIGNsYWltIGlzIGRlc2lnbmVkIHRvIGJlIG1hZGUg YnkgZG9tYWluIGJ1aWxkIHdoZW4gdGhlIHNpemUgb2YgdGhlDQogICAgZG9tYWluIGlzIGtub3du LiBUaGVyZSBpcyBubyB0d2Vha2luZyBpdCBhZnRlcndhcmRzOiBUaGUgbmVlZGVkIHBhZ2VzDQog ICAgc2hhbGwgYmUgY2xhaW1lZCBieSB0aGUgZG9tYWluIGJ1aWxkZXIgYmVmb3JlIHRoZSBkb21h aW4gaXMgYnVpbHQuDQogICAgDQogICAgTm90ZTogVGhlIGNsYWltcyBhcmUgbm90IG9ubHkgY29u c3VtZWQgd2hlbiBwb3B1bGF0aW5nIGd1ZXN0IG1lbW9yeToNCiAgICBDbGFpbXMgYXJlIGFsc28g KGF0IGxlYXN0IGF0dGVtcHRlZCB0byBiZSkgY29uc3VtZWQgd2hlbiBYZW4gbmVlZHMgdG8NCiAg ICBhbGxvY2F0ZSBtZW1vcnkgZm9yIG90aGVyIHJlc291cmNlcyBvZiB0aGUgZG9tYWluLiBGb3Ig dGhpcyByZWFzb24sDQogICAgdGhlIGRvbWFpbiBidWlsZGVyIG5lZWRzIHRvIGFkZCBzb21lIGhl YWRyb29tIGZvciBhbGxvY2F0aW9ucyBkb25lIGJ5DQogICAgWGVuIGZvciBjcmVhdGluZyB0aGUg ZG9tYWluLg0KDQogICAgV2hlbiB0aGUgZG9tYWluIGJ1aWxkZXIgaGFzIGZpbmlzaGVkIGJ1aWxk aW5nIHRoZSBkb21haW4sIGl0IGlzIGV4cGVjdGVkDQogICAgdG8gcmVzZXQgdGhlIGNsYWltIHRv IHJlbGVhc2UgYW55IG5vdCBjb25zdW1lZCBoZWFkcm9vbSBpdCBhZGRlZC4NCg0KICAtIElmIGEg ZG9tYWluIGFscmVhZHkgaGFzIG1lbW9yeSB3aGVuIHRoZSBkb21haW4gYnVpbGRlciBzdGFrZXMg YSBjbGFpbQ0KICAgIGZvciBjb21wbGV0aW5nIHRoZSBidWlsZCBvZiB0aGUgZG9tYWluLCB0aGUg b3V0c3RhbmRpbmdfY2xhaW1zIGFyZSBzZXQNCiAgICB0byB0aGUgdGFyZ2V0IHZhbHVlIG9mIHRo ZSBjbGFpbSBjYWxsLCBtaW51cyBkb21haW5fdG90X3BhZ2VzKGQpLCBzbw0KICAgIGFscmVhZHkg YWxsb2NhdGVkIG1lbW9yeSBkb2VzIG5vdCBjb250cmlidXRlIHRvIGEgYmlnZ2VyIHRvdGFsIGJv b2tpbmcuDQoNCkZvciBOVU1BIGNsYWltcyBhbmQgZ2xvYmFsIGhvc3QtbGV2ZWwgY2xhaW1zLCBp dCBpcyBzaW1pbGFyOg0KDQpBIE5VTUEgbm9kZS1zcGVjaWZpYyBjbGFpbSBpcyBpbXBsaWNpdGx5 IGFsc28gYWRkZWQgdG8gdGhlIGdsb2JhbA0KaG9zdC1sZXZlbCBvdXRzdGFuZGluZ19jbGFpbXMg b2YgdGhlIGhvc3QsIGFzIGEgTm9kZS1zcGVjaWZpYyBtZW1vcnkNCmlzIGFsc28gcGFydCBvZiB0 aGUgaG9zdCdzIG1lbW9yeSwgc28gdGhlIGhvc3QtbGV2ZWwgY2xhaW1zIHByb3RlY3Rpb24NCmRv ZXMgbm90IGhhdmUgdG8gYWxzbyBjaGVjayBmb3Igbm9kZS1zcGVjaWZpYyBjbGFpbXM6DQoNClRo ZSBlZmZlY3Qgb2YgaG9zdC1sZXZlbCBjbGFpbSBpcyBhbHNvIGdpdmVuIHdoZW4geW91IG1ha2Ug YSBub2RlLWxldmVsIGNsYWltLg0KDQpXaGVuIGEgZG9tYWluIG9uZSBraW5kIG9mIGNsYWltLCBp dCBkb2VzIG5vdCBtYWtlIGEgbG90IG9mIHNlbnNlIHRvIHRoZW4NCmxhdGVyIGFkZCBhIGRpZmZl cmVudGx5IHNpemVkIGNsYWltIGZvciBhbm90aGVyIHRhcmdldC4gTGlrZSBkZXNjcmliZWQgaW4N CmhvdyBkb21haW5fc2V0X291dHN0YW5kaW5nX2NsYWltcygpIGlzIGltcGxlbWVudGVkLCBhIGRv bWFpbiBidWlsZGVyIHN0YWtlcw0KYSBjbGFpbSBvbmNlLCB0aGVuIGJ1aWxkcyB0aGUgZG9tYWlu LCB0aGVuIHJlc2V0cyBpdCwgYW5kIHRoYXQncyBhbGwgdG8gaXQuDQoNCkZvciBleGFtcGxlLCBY YXBpIHRvb2xzdGFjayBhbmQgbGlieGVuZ3Vlc3QgaGF2ZSBjYWxscyB0byBjbGFpbSBtZW1vcnks DQpidXQgaW4gYW55IGdpdmVuIGNvbmZpZ3VyYXRpb24sIG9ubHkgdGhlIGZpcnN0IGFjdG9yIHRv IGNsYWltIG1lbW9yeSBmb3INCmEgZG9tYWluIGlzIHRoZSBvbmUgd2hvIGRlZmluZXMgdGhlIGNs YWltOiBObyBtaXhpbmcsIGNoYW5naW5nLCB1cGRhdGluZy4NCkl0IG1ha2VzIHRoaW5ncyBjbGVh ciB0aGF0IHRoZSBpbml0aWFsIGNyZWF0b3IgZGlkIG1ha2UgdGhlIGNsYWltLg0KDQpTaW1pbGFy IGZvciBtdWx0aS1ub2RlIGNsYWltczoNCg0KUm9nZXIgZGVzY3JpYmVkIGhvdyBoZSB3YW50cyB0 aGlzIEFQSSBkbyB3b3JrIGhlcmU6DQpodHRwczovL2xpc3RzLnhlbnByb2plY3Qub3JnL2FyY2hp dmVzL2h0bWwveGVuLWRldmVsLzIwMjUtMDYvbXNnMDA0ODQuaHRtbA0KDQooQmVmb3JlLCBoZSBz YWlkIHRoYXQgd2l0aCBtdWx0aXBsZSBjYWxscywgaXQgd291bGQgYmUgYXdrd2FyZCwgd2l0aCBw YXJ0aWFsDQogY2xhaW1zIGFuZCByb2xsYmFjaywgYW5kIEkgd2FudCB0byBhZGQgdGhhdCB3b3Vs ZCBiZSBkaWFtZXRyaWNhbGx5IGNvdW50ZXINCiB0aGUgb3JpZ2luYWwgY2xhaW1zIGRlc2lnbiBv ZiBub3QgYWxsb3dpbmcgbXVsdGlwbGUgY2FsbHMpDQogDQo+IElkZWFsbHksIHdlIHdvdWxkIG5l ZWQgdG8gaW50cm9kdWNlIGEgbmV3IGh5cGVyY2FsbCB0aGF0IGFsbG93cyBtYWtpbmcNCj4gY2xh aW1zIGZyb20gbXVsdGlwbGUgbm9kZXMgaW4gYSBzaW5nbGUgbG9ja2VkIHJlZ2lvbiwgYXMgdG8g ZW5zdXJlDQo+IHN1Y2Nlc3Mgb3IgZmFpbHVyZSBpbiBhbiBhdG9taWMgd2F5Lg0KDQpJbiB0aGUg bG9ja2VkIHJlZ2lvbiAoaW5zaWRlIGhlYXBfbG9jayksIHdlIGNhbiBjaGVjayB0aGUgY2xhaW1z IHJlcXVlc3RzDQphZ2FpbnN0IGV4aXN0aW5nIGNsYWltcyBhbmQgbWVtb3J5IG9mIHRoZSBhZmZl Y3RlZCBub2RlcyBhbmQgZGV0ZXJtaW5lIGlmDQp0aGUgY2xhaW0gY2FsbCBpcyBhIGdvIG9yIGEg bm8tZ28uIElmIGl0IGlzIGEgZ28sIHdlIHVwZGF0ZSBhbGwgY291bnRlcnMNCndoaWNoIGFyZSBh bGwgcHJvdGVjdGVkIGJ5IHRoZSBoZWFwX2xvY2sgYW5kIGFyZSBkb25lLg0KDQpUaGVyZSBpcyBu byBwYXJ0aWFsIHN1Y2Nlc3Mgb3IgZmFpbHVyZS4gSXQgd2lsbCBiZSBhdG9taWMsIGxpa2UgUm9n ZXIgYXNrZWQuDQoNCldpdGggdGhpcywgYXMgSSB1bmRlcnN0YW5kIHRoaW5rIEkgc2hvdWxkIGNy ZWF0ZSBhIGRlc2lnbiBzcGVjaWZpY2F0aW9uDQpmb3IgaG93IGNsYWltcyBhcmUgZGVzaWduZWQg aW4gWGVuIGFuZCBob3cgdGhlIGNsYWltcyBkZXNpZ24gY2FuIGJlDQpleHRlbmRlZCB0byBzdXBw b3J0IGF0b21pYyBtdWx0aS1ub2RlIGNsYWltcyAod2l0aG91dCByb2xsYmFja3MvY29uY3VycmVu Y3kNCmlzc3VlcykuDQoNCkkgc3RhcnRlZCBkZXNjcmliaW5nIGhvdyBYZW4gaW1wbGVtZW50cyBj bGFpbXMgaW4gL2RvY3MvaHlwZXJ2aXNvci1ndWlkZSBoZXJlOg0KaHR0cHM6Ly9iZXJuaGFyZGst eGVuLXJldmlldy5yZWFkdGhlZG9jcy5pby9ub2RlLWNsYWltcy9oeXBlcnZpc29yLWd1aWRlL21t L2NsYWltcy5odG1sDQoNCkknZCBhZGQgdGhlc2UgbmV3IGNsYXJpZmljYXRpb25zIHRvIHRoaXMg ZGVzY3JpcHRpb24gdGhlbiwgSSB0aGluay4NCg0KVG8gY29tbXVuaWNhdGUgdGhlIHBsYW4gb2Yg aG93IG11bHRpLW5vZGUgY2xhaW1zIHdvdWxkIHdvcmssDQphcyBkZXNjcmliZWQgYnkgUm9nZXIs IEknZCBzdWdnZXN0IEknZCBhZGQgYSBkZXNpZ24gZG9jdW1lbnQNCmZvciBtdWx0aS1ub2RlIGNs YWltcywgbW9kZWxsZWQgYWZ0ZXIgdGhlIEh5cGVybGF1bmNoIGRlc2lnbg0KZG9jdW1lbnQgZm91 bmQgaW4gdGhlIGRvY3MuDQoNCk9uY2UgdGhhdCBkZXNpZ24gaXMgYXBwcm92ZWQsIHdlIHNob3Vs ZCBoYXZlIGEgY2xlYXIgc2hhcmVkDQp1bmRlcnN0YW5kaW5nIG9mIHRoZW0gYmVmb3JlIHdlJ2Qg YmUgbG9va2luZyBhdCBpbXBsZW1lbnRhdGlvbi4NCiANCiAgIEJlcm5oYXJkDQo= From xen-devel-bounces@lists.xenproject.org Thu Mar 05 17:00:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 17:00:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1246953.1545922 (Exim 4.92) (envelope-from ) id 1vyC3m-0005Xl-60; Thu, 05 Mar 2026 17:00:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1246953.1545922; Thu, 05 Mar 2026 17:00:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyC3m-0005Xe-2D; Thu, 05 Mar 2026 17:00:26 +0000 Received: by outflank-mailman (input) for mailman id 1246953; Thu, 05 Mar 2026 17:00:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyC3l-0005XY-0g for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 17:00:25 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cc32c4f5-18b4-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 18:00:22 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-48371119eacso98317175e9.2 for ; Thu, 05 Mar 2026 09:00:22 -0800 (PST) Received: from [10.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-4851ad09c92sm37214925e9.23.2026.03.05.09.00.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2026 09:00:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cc32c4f5-18b4-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772730022; x=1773334822; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=ESjQyTkxKE/5heZSTnPhxduSDIvNR2PSNgyuNvp6b3w=; b=XSPzmspQ4UFB9nzWSKYoj0sLNGioeN3kDzggHj6Waadt4ja3X25IcD/fs4ONmuKy2u 4eZEB3ldK7dXmo+q7vR5kEtwiRP2DedZBYhr3MORgO3DwuIW00c8Ytm6shrpKzSG/Jx2 HsKSbk7IwGzsKXuYeYXu6rBfWaXfnv/xTHQ/Xk6h8t2r4g2jT/FPJJzoBY38hj4UKK+K tJ1rZAYzW1kdt8+32hdtPk5DfgIomzxt5HYOPFvbG4v9GAPqQK/j4R/4zfpUtO51aqG8 U9tr1s93WOCtQ6yUPgpYIAEMc6XC6pWRVuouGNBawdqcVnAyDii5i+iGImoIc81rtLT5 KdyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772730022; x=1773334822; h=content-transfer-encoding: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; bh=ESjQyTkxKE/5heZSTnPhxduSDIvNR2PSNgyuNvp6b3w=; b=wFqwDaMhTrBwtTWlDmCpEy+ie36KS0x4hc6MB5BKQ0QTLcPjGjWNgumY4gnYB51Z9u pvdTgG/2jvcQVit7JRgj7hdBUyOpSjomHWSK6VbSRVVNQvmyT766tAnKeRjgejW8ka8r uwg9QT1/SdfQ26Fzq01TehtTF+N3NaQkSBYEbabfv7Evo8ZLiquTwdB4Rvw0+BB+BtSZ fr6kF6zAwnem5+Ceow/CxaLOTZ6I+Hj4igGd4XxwP/wTm45dU/K5BXGHNMQCioc9GN4U a/Jpo7VqLtLoYA9lTe83i2pQKq6KI24BYHqgxNa38KVFuMd5TMsR3MLrzz6cmkR7m5So wOFA== X-Forwarded-Encrypted: i=1; AJvYcCXbieC3hPa/BMLvRA+Jo8neWvXeVZm2a6ggPzDnRcWelvKMQTiBMUKr+UE1z/L7okYnoF6IjP0pEIY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzh7Hx2KAqEWVWeNZKv5A0B3/r7Z2pwUe3VG/9JcsMmqtfOGC6j GtZRJ2D2JUSsEONlKaqFI3MkAt+poyxUJvg9J2c+FT3BWfkQTBexaF6j58hRQojTkg== X-Gm-Gg: ATEYQzwJZEIeF0EsDUaY4WvmLc/sIk5Syct7CxarYLh5+kDgUJ4iTJkQy1Jk1xUmPAP O27HGlByHX6YSdFgquQcKli1oSmB4HkxFnnvEehgsLeeOwq8q6eE4gwHcCQkOW0N84wctdyWZrs oR7Ez2d8eaEC71QlGqVs/JCo2LyWcncrXU5m5ZHDlfDxJNNoyQC/SIAcPVpoZYg83Wc9ZooyMWL 9tcoXhzU/nxPvuWqcp3yAr5twfkJE6EJ1zBM0ghzCLJZWBcnMYKakvtrjQirZeayrd1nEP+YUyk S+yO4n92Kj7D53q+E4nI3Ly5qUiul0mkhaWMpxN/NaTmPsy0Pj5nCBRLACX8H2G1pwVofBoT0Q9 nkGEbRQLWMXF4RdYTkl3IMG4Z+yIJNrog7wcluY4Gb32poND2kqKAO5mpC6S1uiTMrKP8gHpoXs Nuact3unCsqacb00GHM0Ka2K5XH/utBt2NxKfWsVgxumvJoMaTSXGmwjqPaAv0IeiKMp41Vj3YH rgZ+e2UAIFUJpU= X-Received: by 2002:a05:600c:828d:b0:483:c35d:367f with SMTP id 5b1f17b1804b1-485235f13dbmr2364115e9.21.1772730021839; Thu, 05 Mar 2026 09:00:21 -0800 (PST) Message-ID: Date: Thu, 5 Mar 2026 18:00:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 03/10] xen/page_alloc: Implement NUMA-node-specific claims To: Bernhard Kaindl Cc: Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , Roger Pau Monne , Stefano Stabellini , Marcus Granado , "xen-devel@lists.xenproject.org" , Alejandro Vallejo References: <6927e45bf7c2ce56b8849c16a2024edb86034358.1772098423.git.bernhard.kaindl@citrix.com> <1497b37d-f47a-41c6-8037-a00a555d13a0@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2026 15:54, Bernhard Kaindl wrote: > Jan Beulich wrote: >> On 05.03.2026 14:12, Bernhard Kaindl wrote: >>> >>> Roger requested the domctl API to allow claiming from multiple nodes in one go >>> and he specified that we should focus on getting the implementation for one >>> node-specific claim done first before we dive into multi-node claims code. >>> >>> - Instead of adding/linking an array of claims to struct domain, we can keep >>> using d->outstanding_pages for the single-node claim. >>> >>> - There are numerous comments and questions for this minimal implementation. >>> If we'd add multi-node claims to it, this review may become even more complex. >>> >>> - The single-node claims backend contains the infrastructure and multi-node >>> claims would be an extension on top of that infrastructure. >> >> What is at the very least needed is an outline of how multi-node claims are >> intended to work. This is because what you do here needs to fit that scheme. >> Which in turn I think is going to be difficult when for a domain more memory >> is needed than any single node can supply. Hence why I think that you may >> not be able to get away with just single-node claims, no matter that this >> of course complicates things. >> >> It's also not quite clear to me how multiple successive claims against >> distinct nodes would work (which isn't all that different from a multi-node >> claim). >> >> Thinking of it, interaction with the existing mem-op also wants clarifying. >> Imo only one of the two ought to be usable on a single domain. > > Yes, correct. As implemented by Xen in domain_set_outstanding_claims(), > Xen claims work very different from something like an allocation: > > For example, when you allocate, you get memory, and when you repeat, > you have a bigger allocation. > > But Xen claims in domain_set_outstanding_claims() don't work like that: > > - When a domain has a claim, domain_set_outstanding_claims() only allows > to reset the claim to 0, nothing else. A second, or changed claim is not > possible. I think this was intentional: > > - domain_set_outstanding_claims() rejects increasing/reducing a claim: > > A claim is designed to be made by domain build when the size of the > domain is known. There is no tweaking it afterwards: The needed pages > shall be claimed by the domain builder before the domain is built. > > Note: The claims are not only consumed when populating guest memory: > Claims are also (at least attempted to be) consumed when Xen needs to > allocate memory for other resources of the domain. For this reason, > the domain builder needs to add some headroom for allocations done by > Xen for creating the domain. > > When the domain builder has finished building the domain, it is expected > to reset the claim to release any not consumed headroom it added. > > - If a domain already has memory when the domain builder stakes a claim > for completing the build of the domain, the outstanding_claims are set > to the target value of the claim call, minus domain_tot_pages(d), so > already allocated memory does not contribute to a bigger total booking. > > For NUMA claims and global host-level claims, it is similar: > > A NUMA node-specific claim is implicitly also added to the global > host-level outstanding_claims of the host, as a Node-specific memory > is also part of the host's memory, so the host-level claims protection > does not have to also check for node-specific claims: > > The effect of host-level claim is also given when you make a node-level claim. > > When a domain one kind of claim, it does not make a lot of sense to then > later add a differently sized claim for another target. Like described in > how domain_set_outstanding_claims() is implemented, a domain builder stakes > a claim once, then builds the domain, then resets it, and that's all to it. > > For example, Xapi toolstack and libxenguest have calls to claim memory, > but in any given configuration, only the first actor to claim memory for > a domain is the one who defines the claim: No mixing, changing, updating. > It makes things clear that the initial creator did make the claim. > > Similar for multi-node claims: > > Roger described how he wants this API do work here: > https://lists.xenproject.org/archives/html/xen-devel/2025-06/msg00484.html Fits my understanding, but doesn't fit you limiting the new sub-op to a single node. As said, if you introduce the new sub-op this way, I'd still expect for a single domain to have claims across multiple nodes, and that (preferably) whatever the caller does to achieve that will continue to work once the restriction is lifted. Yet I can't see you describe such claims-on-multiple-nodes use case in of your reply above. And indeed to achieve that you'd need data layout changes, in particular there then couldn't be any single d->claim_node. >> Ideally, we would need to introduce a new hypercall that allows making >> claims from multiple nodes in a single locked region, as to ensure >> success or failure in an atomic way. > > In the locked region (inside heap_lock), we can check the claims requests > against existing claims and memory of the affected nodes and determine if > the claim call is a go or a no-go. If it is a go, we update all counters > which are all protected by the heap_lock and are done. Yet as per above, afaics you don't even have the needed data layout to record two (or more) claims against distinct nodes. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:18:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247048.1545952 (Exim 4.92) (envelope-from ) id 1vyEDM-0004Nf-W8; Thu, 05 Mar 2026 19:18:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247048.1545952; Thu, 05 Mar 2026 19:18:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDM-0004NW-Si; Thu, 05 Mar 2026 19:18:28 +0000 Received: by outflank-mailman (input) for mailman id 1247048; Thu, 05 Mar 2026 19:18:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDM-00048o-5F for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:18:28 +0000 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [2607:f8b0:4864:20::644]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 160136eb-18c8-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 20:18:27 +0100 (CET) Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-2ad617d5b80so55057095ad.1 for ; Thu, 05 Mar 2026 11:18:27 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae4d3113e0sm142965715ad.79.2026.03.05.11.18.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 11:18:25 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 160136eb-18c8-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772738305; x=1773343105; 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; bh=R1/nQgfr9Bh0trNj7y8yRO+57dFcCvGHPGgpaYkXq6U=; b=HJdbkhe1wjVAeM7agCKt8K8Dyt6hz6N2q5WGlfh5ra09qoRDIW532Exl+npy6NlsSy PyYqlrN1XXbtGY0G/PsQMKsNbKU3ZyCftNP7o8+iCRBd6Sj//dvzBTjF5ChO3Xs36YVs J5nDmtiYpY2tE2tkoWtnOHEFnkAa+MGcA1HkpEKZOmrAeGEcXG+6FMwZVtQT3Z0I8lCt MTGQrDGYUx2CqTtY51aIhvjDORvabOfVk27ltHR9dikLVfPgeYTJhOtJ2oHuo7vRCTA5 VkF4nsSNJfv9OhWBwuYb3nSQls5U5CZAv6jEWH0HQeMhnUX85mLo3JzcpkXTAEpBOmaA TA4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772738305; x=1773343105; 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; bh=R1/nQgfr9Bh0trNj7y8yRO+57dFcCvGHPGgpaYkXq6U=; b=fAnY12wsSfKh+enJ66gCkxL0nCvs3qZhJjFv0wGbZShv6eUQI+yJymCjmHjiXCycSe B0f71Zy3sIruTGlk8xeL6tk4o1O8u3/9HgLaqTk2xBw7HN037f6sHWQ6WToHlCiqCBDO FHiVQ2qKK3lDRS536sf19mB5GObptcdOhRgBIxFp15F3126Wz4KQw28ekyGkIREevHvT mkGRJBZUq6jeIqwRIxK5gexbq+n04kdXc+cy+KRTbhc9s5tMO/pCoT3g6ORhYjER7C5y QWwvONerZAJXWLv5CesD9JshsPW0cNOhhd1IQPuCa2qWX5IOR9+yJKcNSxhSSS2t/0BN W07Q== X-Gm-Message-State: AOJu0YwIGdFrpCGaPkOwAmHyOxIKtAtfS69U9yP/dzcubGCh6sby/3/0 nEMOe5tUbAdeePqD1vq2HETCZOIL0w5ibK2KTs2mCaRiYmPnOgHatAhEss5jFQ4/ X-Gm-Gg: ATEYQzwOXqemoK7gp5t3NNtiZCDxzl0UQxczI0HI/X+i57+MNUgqdDDliDJI47tN2zR yu/h4x59zpszsACObBP5IoNPidc/pnS2UfVLe+KVkimf4TDrsM/Sdxn0SZIC0/3BGGt8HkCploQ PWaXymf1d/9WtM58qg/T1iHwXv0p8dmC8ad0YXdgC4Ks8yzzQEpoT+qR0iW6zj4JQxCDEHbP0HH 9y64Ee5Y5FMDUA3Y2PJI4Ibgv6zb4kI2GGEkFxhCSI3q+sC1jU53Yl/cuVwmw8ZEXQNdSr6z6oD sCpcJPQVBqbTL0fOqsWKxYTFNc3NKgO7I6KYKgLWnsGgSKRgLAO3fULn/JX2CL3jUNY6RwIAiJi sEfrVEiuZnli/g7kIDVn5P1fD9Q0u55/RT0g1GIRAwBbk9tPlOBUnvww24eKcJ7h2oEnAEcsyI+ PxflHBJfp0FO9/SEyN3zx7GXmJiuuQor/3v7a8/Y/l6w9NgPWupzLaJbyRLkfhbRi814BqLQB3V 0C9JzMmygcnVGQ3fMBFJC9frphY+nUrBFxuNPICOlbLmCfbbEotqVdb/nDQRCVsuMj0qahddA== X-Received: by 2002:a17:903:2a86:b0:2ae:6887:5c13 with SMTP id d9443c01a7336-2ae6ab408dfmr64671365ad.48.1772738305562; Thu, 05 Mar 2026 11:18:25 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code Date: Fri, 6 Mar 2026 00:48:09 +0530 Message-ID: <20260305191810.31033-3-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Now that BGRT images are preserved during EFI boot (via EfiACPIReclaimMemory allocation), the invalidation code in acpi_parse_bgrt() is no longer needed. The BGRT table remains valid throughout boot. This removes the code that was marking BGRT invalid when the image memory was detected as unavailable, which was causing ACPI warnings in Linux dom0. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/acpi/boot.c | 23 ----------------------- 1 file changed, 23 deletions(-) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index 1ca2360e00..fc88b559e6 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -327,27 +327,6 @@ static int __init cf_check acpi_parse_hpet(struct acpi_table_header *table) return 0; } -static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_header *table) -{ - struct acpi_table_bgrt *bgrt_tbl = - container_of(table, struct acpi_table_bgrt, header); - - if (table->length < sizeof(*bgrt_tbl)) - return -1; - - if (bgrt_tbl->version == 1 && bgrt_tbl->image_address - && !page_is_ram_type(PFN_DOWN(bgrt_tbl->image_address), - RAM_TYPE_CONVENTIONAL)) - return 0; - - printk(KERN_INFO PREFIX "BGRT: invalidating v%d image at %#"PRIx64"\n", - bgrt_tbl->version, bgrt_tbl->image_address); - bgrt_tbl->image_address = 0; - bgrt_tbl->status &= ~1; - - return 0; -} - #define acpi_fadt_copy_address(dst, src, len) do { \ if (fadt->header.revision >= FADT2_REVISION_ID && \ fadt->header.length >= ACPI_FADT_V2_SIZE) \ @@ -752,7 +731,5 @@ int __init acpi_boot_init(void) acpi_hest_init(); - acpi_table_parse(ACPI_SIG_BGRT, acpi_invalidate_bgrt); - return 0; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:18:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247046.1545932 (Exim 4.92) (envelope-from ) id 1vyEDH-0003wC-EM; Thu, 05 Mar 2026 19:18:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247046.1545932; Thu, 05 Mar 2026 19:18:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDH-0003w5-BC; Thu, 05 Mar 2026 19:18:23 +0000 Received: by outflank-mailman (input) for mailman id 1247046; Thu, 05 Mar 2026 19:18:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDF-0003vz-WC for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:18:22 +0000 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [2607:f8b0:4864:20::644]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 114163f7-18c8-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 20:18:19 +0100 (CET) Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-2ab232cc803so39855035ad.3 for ; Thu, 05 Mar 2026 11:18:19 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae4d3113e0sm142965715ad.79.2026.03.05.11.18.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 11:18:16 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 114163f7-18c8-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772738298; x=1773343098; 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; bh=SMJgdGHu5uiPPqH6dZaegUtOqViHvmyYFz9sYq0PX0M=; b=m0PHjkOQTPmUTaTHrokGZRS/IlQwA58nJ5wc0wLkmToMCa1HURjYIfTERJZaB6OzyM az6wfZgVFw1U5Q1jBeQ7RP7qpMu8zBqRvTZCFKfuOhbe/1mBI+tK7LMwjexLxEvHGSFN erS99jmMgcmwg2qP2hB/ctXQHTL3vWkQIvArA6XpsqIB1/V6lW4NrLosmsshpqixLEIF 7HPlp3o2UGmr/1oGJ9VXQD7L+Yp0BsDEyfetwaCB4K7GsvALTWYUjj/cDEEUjF4PvWru JtRFHd4INTzQJ67AfD21uqhfmUPU0JcWMAx+btOyqRMEed/kEcpQt5Hay22fEECu8Cf8 n1Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772738298; x=1773343098; 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; bh=SMJgdGHu5uiPPqH6dZaegUtOqViHvmyYFz9sYq0PX0M=; b=FK567KuwmZflvFbqd89jEjABq/G1SSMoQafwaLVxZHh1VM7eDK/Sp579TIMz5HsUQE gMg0yn/2Q1CoqaclWopmA3NZVf4/mytCcaVH9urC0qrH3UL9pzWD5gYjTIK455QayLge oteF3flQ3raVMDvEGkYGccoFogfGD4DA1Wv/bURz4yvxF2CxHHbNW5kS8kUbbTOHwihy mVpva7VS4wQ0sPM7SsuHaGvm81yUfTgfph5SXUT+GYviZXhieBQrlq02GXpWGC5nHgyD xpW/2tJpyeWbR6GkoK0bRDfGnDcMFNVQ5vrvTtfJ8w2u6XnF2l+7+sSpgjTY6LL/0Say k4RQ== X-Gm-Message-State: AOJu0Yyn4BFw3qRjOJgTL0f/RMbwQtM9ejzow9IyJrqp7126UP11GtJO pGfLUX5QSYNLymx9nqw2Am3Aw7kN5RpjFAJXCzOCNfNXRgQzDD1PYzASE8ntZDfK X-Gm-Gg: ATEYQzwvzKiLdtOofJ+Ss+y6KtRR+AM5Bi6IBfJyL89G/dX4gn1HfJe+vFK50ZiD+qs KNrl8cPwdX5RcbzB6PxVJdhCmCRkc6AyeNBonPXFTiwwGr/+Folhzs6igWCWRZTj8iNh/TZDNIw qW/yr6DXb+YDhONUMvdzWKMDEwf2tfIIr5oaQ54nrr3Y1gEn8yELX2jWRBKQbVDxwQd2sozoLXG d/ZW6mpZYGLe0prTHwYkI4HHs7i02NRAzsJkUwaTw53WTsR9gQlc9g3O+bEPYRXxR72FLwSXDmR AZr2nmgINv3EM9IJqONdojbzYm2dWf3RQFDQRWhhrIHgzc+qEtCQt5zK1Suzi66WkaA+sQsxhvM QwQ3cSfbkLB0mMsvKktuxIzHg24l2E/zbaB5u/Oscje5/hDO6pNBzs7/tWDa1BH/fQXDvBI0RsR u9SyznWY2/yQNTePLqj8W2IhKHomJ6X1j5Y5kXg7bJMuOovb/ooc9wSP9wIraP5C8mdI+XMoZDV WvA2BZINvBu1BZbY7srOnCeVA/JWixL69nrVrtWEJqRQQXqJZvwFdT+8SuibFnwvlWBfh7/Ig== X-Received: by 2002:a17:902:e88c:b0:2ae:59a9:639d with SMTP id d9443c01a7336-2ae6a9cc515mr71087265ad.4.1772738297481; Thu, 05 Mar 2026 11:18:17 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH 0/3] Fixing ACPI BGRT (Boot Graphics Resource Table) corruption Date: Fri, 6 Mar 2026 00:48:07 +0530 Message-ID: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series fixes ACPI BGRT (Boot Graphics Resource Table) corruption, that occured when Xen reuses the memory containing the boot logo image before dom0 is able to parse ACPI tables. The BGRT table contains a pointer to a BMP image stored in BootServicesData memory. When Xen reclaims this memory early in boot, the pointer becomes invalid, causing Linux dom0 to report: Xen: `(XEN) ACPI: BGRT: invalidating v1 image at 0x47cc2018` Linux (dom0): `ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0xF9, should be 0xB4 (20250807/utcksum-58)` This series: 1. Adds BGRT image preservation during EFI boot (similar to ESRT) 2. Removes the now-unnecessary invalidation code 3. Provides an opt-out mechanism (efi=no-bgrt) for servers The preservation is enabled by default to fix the corruption for all users, with minimal overhead (~1MB). Also, servers that don't need boot graphics can disable it using the "efi=no-bgrt" option. Testing: - Verified on Intel UEFI system with Fedora 43 dom0 - Before: ACPI checksum errors in dom0 - After: Clean boot, no ACPI warnings - Memory overhead: ~972 KB (preserved image size) Signed-off-by: Soumyajyotii Ssarkar Soumyajyotii Ssarkar (3): x86/efi: Add BGRT image preservation during boot x86/acpi: Remove BGRT invalidation code x86/efi: Add opt-out mechanism for BGRT preservation xen/arch/x86/acpi/boot.c | 23 ----- xen/arch/x86/efi/efi-boot.h | 2 + xen/common/efi/boot.c | 199 ++++++++++++++++++++++++++++++++++++ 3 files changed, 201 insertions(+), 23 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:18:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247049.1545962 (Exim 4.92) (envelope-from ) id 1vyEDR-0004eY-7M; Thu, 05 Mar 2026 19:18:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247049.1545962; Thu, 05 Mar 2026 19:18:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDR-0004eK-3y; Thu, 05 Mar 2026 19:18:33 +0000 Received: by outflank-mailman (input) for mailman id 1247049; Thu, 05 Mar 2026 19:18:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDQ-00048o-7N for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:18:32 +0000 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [2607:f8b0:4864:20::642]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 18753e3d-18c8-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 20:18:31 +0100 (CET) Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-2ad21f437eeso59682495ad.0 for ; Thu, 05 Mar 2026 11:18:31 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae4d3113e0sm142965715ad.79.2026.03.05.11.18.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 11:18:29 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 18753e3d-18c8-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772738310; x=1773343110; 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; bh=++GELJavQDbG9JYk0zJHLyDpXIOV9aBooWUi6D+W/MA=; b=ZywURYfyu9jtd0HY/U+AMVN1oYScCM8ieiP9SoBXhR3jUC8XZQqqrwbrZe48NQvahw meuprx9ZWNPE+nAD8CHiw2voqFWrs4PRd5sUIW8R+w2iuUsIF+F8+xEoQobzx+MMkkcb 5alIDhKYqfTZoDM/NRb1J6+VxGbAD4z8meHijbS8zJoWyTvvTJglF6taF2DUb5sytTon 5BsmMNm11Vh9sKgijWgdcvcCiSjB0F/BaxTvyjZm4sDyDnELAZhf+x4htYJSCDWyvKrI /zcbzpc6kBZfxu+5h7b1DKbVUWCYn1jTItSNSWXNWBdobc1+hbVAy7fvY+FStNBYrR+K apag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772738310; x=1773343110; 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; bh=++GELJavQDbG9JYk0zJHLyDpXIOV9aBooWUi6D+W/MA=; b=hdl893RlzgGeMycWDwNGmRQPOAMYIE3T+V/WgHRhbvWZ2YOlRu4BAzwLm6DrNC1ym8 ff6SvrZDqc7yyh5Oe5IytA+Fo0L8u2ZmTfW/jQOvnv2FPw+sLxK5HXVvNGPNpRoKsPix do5ab84VQms3St+dfJlIvCojaJwgX5+sT20yGOHB+6QYlzwqOkrz9PRoaeJRgsFVFpn1 WbfpVX4RIunRnF8is8m8yrCFSEE25FOyKo5Uodwm1ujVch+5lozBxM7jGYSrh6E9C71B mxraFRdtgnvJOqfY0BihQ97RzR1WIJWFKnDSTPjroAAhXUZbBQdX4RzOVBsZBEp4J7mB zwCQ== X-Gm-Message-State: AOJu0YwD86CtXyJlFlEoUI/tbz3CGuX9KyLFJzVKghdPcgdefqcI99hr ZMHiXADhHQbGnhyQyfXwKX7dlYrtFzHdnqZ+1qGEaDxfu677qT41RrUq0BL3k4TI X-Gm-Gg: ATEYQzzcZoXd9vNLL/CCU2MHf5XiF9YleQ2WGmnH8ek2DfrLC57yuKzMF+omyQo1fPw I6tr8TCUq3KIFpHI/oZIrCyyKWA7gbDJxy13VQhYCkUZso6628tc+XFkFFYO2VqSPkpV54v50W3 XIkB3SG7n9Ebvp+XBYRDj1eEnvraGkbRiS5HPgQkGJeWhCcDdTIJ0NbAWfi5z7gMkwM9nf+plJI iOBne8t0aLDRTZk/i3BRbGyC8TDC0UaQ5dfeO4TmVDeYC2M+QNfl0yS0KfvTB7qCQtKx+79BJvp TFC+Y+NPTA6UjZyHFe27JBjj9+VfTpAimMl25vfj4+oymUG5w7t9L8vpdbd6htzhN/BvMtazGgG eEbgjvcj8tKWcwtgh3AKumIJ0OMrhNvEI+MtWQU7662zaCWykfJLCUcYi73mrgSxWdTibUzqU4e uhVD4aG/u7LuErxW4QJZ0b1QsQ7kJHTlv/tmLGl/s0IC0221/ow8jbJmQPdxsXtBPobkdPll3eq aeVHbgSVNoXcgYW86t/WOnRlVPQuRicGd5PQZPLpCraS+Cq61L0Txi6brfo7YLq5AU3Q4sgkFXN sCcvQcun X-Received: by 2002:a17:903:1b6f:b0:2ae:7f15:7a4c with SMTP id d9443c01a7336-2ae7f157a85mr12680975ad.18.1772738309652; Thu, 05 Mar 2026 11:18:29 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Date: Fri, 6 Mar 2026 00:48:10 +0530 Message-ID: <20260305191810.31033-4-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As described in the task, BGRT preservation is now enabled by default to fix ACPI corruption for desktop/workstation systems (similar to ESRT). Add an opt-out parameter 'efi=no-bgrt' to allow disabling BGRT preservation on systems where the ~1MB memory overhead is not desired. The parameter is parsed during normal Xen boot (not during EFI phase), so it only affects diagnostic logging. The opt-out flag is checked at the start of efi_preserve_bgrt_img(). Usage: Default: BGRT preserved automatically Opt-out: Add 'efi=no-bgrt' in Xen command line Signed-off-by: Soumyajyotii Ssarkar --- xen/common/efi/boot.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 1e3489e902..b735eac6b2 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -167,6 +167,7 @@ static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdErr; static UINT32 __initdata mdesc_ver; static bool __initdata map_bs; +static bool __initdata opt_bgrt_disabled = false; static struct file __initdata cfg; static struct file __initdata kernel; @@ -868,6 +869,9 @@ static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) bgrt_debug_info.preserved = false; bgrt_debug_info.failure_reason = NULL; + if ( opt_bgrt_disabled ) + return; + bgrt = find_bgrt_table(SystemTable); if ( !bgrt ) { @@ -1873,6 +1877,10 @@ static int __init cf_check parse_efi_param(const char *s) else __clear_bit(EFI_RS, &efi_flags); } + else if ( (ss - s) == 7 && !memcmp(s, "no-bgrt", 7) ) + { + opt_bgrt_disabled = true; + } else if ( (ss - s) > 5 && !memcmp(s, "attr=", 5) ) { if ( !cmdline_strcmp(s + 5, "uc") ) @@ -1968,7 +1976,11 @@ void __init efi_init_memory(void) if ( !efi_enabled(EFI_BOOT) ) return; - if ( bgrt_debug_info.preserved ) + if ( opt_bgrt_disabled ) + { + printk(XENLOG_INFO "EFI: BGRT preservation disabled\n"); + } + else if ( bgrt_debug_info.preserved ) { printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", bgrt_debug_info.size / 1024); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:18:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:18:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247047.1545941 (Exim 4.92) (envelope-from ) id 1vyEDJ-00049O-LQ; Thu, 05 Mar 2026 19:18:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247047.1545941; Thu, 05 Mar 2026 19: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 ) id 1vyEDJ-00049H-Ic; Thu, 05 Mar 2026 19:18:25 +0000 Received: by outflank-mailman (input) for mailman id 1247047; Thu, 05 Mar 2026 19:18:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEDI-00048o-Ks for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:18:24 +0000 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [2607:f8b0:4864:20::641]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 13a29844-18c8-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 20:18:23 +0100 (CET) Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-2addb31945aso61081585ad.1 for ; Thu, 05 Mar 2026 11:18:23 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae4d3113e0sm142965715ad.79.2026.03.05.11.18.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 11:18:21 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 13a29844-18c8-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772738301; x=1773343101; 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; bh=OwGP8ee4LidY7BRMCtYUVmJPzJVamR1lF04CTiEUcS8=; b=mVj/HPLH59ySa0qeybCGo8aweuZ9xWgK7HiIqoTHs93KCxnD/2VkGlS8lvHcxLk7Jq MvAim8d3kAKxrDDEM8oS703uzFhNrO3S6zJ+hYENZJTMvtHUm6yrbiBcKJ7ybzTrl+rf fDtkaAiNJMrtxtQzRMI0YQ9VhSgKQ6UZE8uGlzumoYjiQX1SXeeRcM3IjrA1nc8sTkB7 P6NZMbEPQTNG+6BbysgdfyhS2NEltH1KSGL2EhWQRaX6VU+nLRQsJgyUibDNWDKpZm12 O7FrexFPwr2vAaseBoHsQsn0NDyIpHa+qJSUmOH742te63LIa93+X71cPKLkg2Z5oQ++ BAsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772738301; x=1773343101; 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; bh=OwGP8ee4LidY7BRMCtYUVmJPzJVamR1lF04CTiEUcS8=; b=K6FSGe94V8qADGoMhrOFMAKHRZEN9qwjqwgpisG1vNRQIgDFiODRCRbIZXTAE73ghr vqxN3XsJAqCj5NfBL2Zxky1c2uFMwHAimMFwQBnjd66BQG/rPqOznd7Zau96/gGJ0Gjf qdb3qVRRTOfCXu//LPZq8zsitV6OXGOGmu94qQa3bUH8lif3s4MQ0NufWxKXjI3ysrnY QPYPQccvy6r/fSjgE2ejBIl12FwgDZmeSQKsuSy5mj8VyRYs4uafBaUEY1pZNVAbTSaT ofeEVnnwyBgZ1Z2gyuoeqdjpu/CyBtIesslQS/WFLC4ddgtoQTNrPUeByCrM4i2T8tSg 0rTw== X-Gm-Message-State: AOJu0Yz3VEP/emR705QWaDHelpsjbbDwYlm97xYud3HzC+I+0i7y4kDz ON1yXoW88rMy3FB0V8JITM9jK3EkRVshWBtuB0eHFliwqb+ttDlCBwaCH1Vn845y X-Gm-Gg: ATEYQzztpCTLf0LcoIHOLgJbCn3B+iJrStgzicq/A8wY6oq4xXHN00b1kST5hD0zOCf mZLh3x8nrar7Rn8Wd14+eRKrJPx8JMMm4hHFdG5PgjOGB3fCvCpcUrBMNJx9ydjdez0Y0n14AnF cMbXUNu1TV8Kv+WJ0dPfmgd9w6S/DSqmDZjPudw/klt2F+zvab/Yoqt0ABhMG9TUZr/dY1GtKeG jKNF2LrXHtrOCoD/9d4SSjPviwM+rQIayMgXVKUIQgvPJybu7hSU/oi5OPbCRRYCUBm+Qs/BBXx MlT+oK04aF1YDbcq5KmzrkqJY8gxssbE0hWfu2Gk3nTrpouBocgBznxZH30KPNuE1iyu1zQo0Lv vN+QOIE47+W4wRJj87h7K51UuVul7UUmeon2gg0UqcLppbbQAULYGNe+Nhkr16Inz14UfGQljVp 3S8DJhVzJtvfG5+CkGlTnwRs4PF7z7u6h6q/qci/IrVEGbgCxRBksS7FzmR1QuHzhy6L9w+vvLs HL7DactnZfDDbOgk38lzFAAt/LHmb3ioZzm8NDjTa8MJ8a678grpX0zUlJi+c1C1NCX9wTHMw== X-Received: by 2002:a17:903:2445:b0:2ae:588a:f3e5 with SMTP id d9443c01a7336-2ae6aaae636mr70140825ad.30.1772738301473; Thu, 05 Mar 2026 11:18:21 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot Date: Fri, 6 Mar 2026 00:48:08 +0530 Message-ID: <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The ACPI BGRT (Boot Graphics Resource Table) contains a pointer to a boot logo image stored in BootServicesData memory. When Xen reclaims this memory during boot, the image is lost and the BGRT table becomes invalid, causing Linux dom0 to report ACPI checksum errors. Add preservation logic similar to ESRT table handling: - Locate BGRT table via XSDT during EFI boot services phase - Validate BMP image signature and size (max 16 MB) - Copy image to EfiACPIReclaimMemory (safe from reclamation) - Update BGRT table with new image address - Recalculate ACPI table checksum The preservation runs automatically during efi_exit_boot() before Boot Services are terminated. This ensures the image remains accessible to dom0. Open coded ACPI parsing is used because Xen's ACPI subsystem is not available during the EFI boot phase. The RSDP is obtained from the EFI System Table, and the XSDT is walked manually to find BGRT. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/efi/efi-boot.h | 2 + xen/common/efi/boot.c | 187 ++++++++++++++++++++++++++++++++++++ 2 files changed, 189 insertions(+) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 42a2c46b5e..27792a56ff 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -910,6 +910,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, efi_relocate_esrt(SystemTable); + efi_preserve_bgrt_img(SystemTable); + efi_exit_boot(ImageHandle, SystemTable); } diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 967094994d..1e3489e902 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; static struct file __initdata xsm; static const CHAR16 __initconst newline[] = L"\r\n"; +static __initdata struct { + bool preserved; + uint64_t old_addr; + uint64_t new_addr; + uint32_t size; + const char *failure_reason; +} bgrt_debug_info; + static void __init PrintStr(const CHAR16 *s) { StdOut->OutputString(StdOut, (CHAR16 *)s ); @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) efi_bs->FreePool(memory_map); } +struct bmp_header { + uint16_t signature; + uint32_t file_size; + uint16_t reserved_1; + uint16_t reserved_2; + uint32_t data_offset; +} __attribute__((packed)); + +/* + * ACPI Structures - defined locally, + * since we cannot include acpi headers + * in EFI Context. + */ + +struct acpi_rsdp { + char signature[8]; + uint8_t checksum; + char oem_id[6]; + uint8_t revision; + uint32_t rsdt_physical_address; + uint32_t length; + uint64_t xsdt_physical_address; + uint8_t extended_checksum; + uint8_t reserved[3]; +} __attribute__((packed)); + +struct acpi_table_header { + char signature[4]; + uint32_t length; + uint8_t revision; + uint8_t checksum; + char oem_id[6]; + char oem_table_id[8]; + uint32_t oem_revision; + uint32_t asl_compiler_id; + uint32_t asl_compiler_revision; +} __attribute__((packed)); + +struct acpi_xsdt { + struct acpi_table_header header; + uint64_t table_offset_entry[1]; /* Variable array length */ +} __attribute__((packed)); + +struct acpi_bgrt { + struct acpi_table_header header; + uint16_t version; + uint8_t status; + uint8_t image_type; + uint64_t image_address; + uint32_t image_offset_x; + uint32_t image_offset_y; +} __attribute__((packed)); + +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE *SystemTable) +{ + EFI_GUID acpi2_guid = ACPI_20_TABLE_GUID; + struct acpi_rsdp *rsdp = NULL; + struct acpi_xsdt *xsdt; + struct acpi_bgrt *bgrt; + uint32_t entry_count, actual_size; + unsigned int i; + + for ( i = 0; i < SystemTable->NumberOfTableEntries; i++ ) + { + if ( match_guid(&acpi2_guid, &SystemTable->ConfigurationTable[i].VendorGuid) ) + { + rsdp = SystemTable->ConfigurationTable[i].VendorTable; + break; + } + } + + if ( !rsdp || !rsdp->xsdt_physical_address ) + return NULL; + + xsdt = (struct acpi_xsdt *)rsdp->xsdt_physical_address; + if ( !xsdt ) + return NULL; + + actual_size = (xsdt->header.length - sizeof(struct acpi_table_header)); + entry_count = (actual_size / sizeof(uint64_t)); + + for ( i = 0; i < entry_count; i++ ) + { + struct acpi_table_header *header = (struct acpi_table_header *)xsdt->table_offset_entry[i]; + + if ( header->signature[0] == 'B' + && header->signature[1] == 'G' + && header->signature[2] == 'R' + && header->signature[3] == 'T' ) + { + bgrt = (struct acpi_bgrt *)header; + return bgrt; + } + } + return NULL; +} + +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject if bigger */ + +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) +{ + struct acpi_bgrt *bgrt; + struct bmp_header *bmp; + void *old_image, *new_image; + uint32_t image_size; + EFI_STATUS status; + uint8_t checksum; + unsigned int i; + + bgrt_debug_info.preserved = false; + bgrt_debug_info.failure_reason = NULL; + + bgrt = find_bgrt_table(SystemTable); + if ( !bgrt ) + { + bgrt_debug_info.failure_reason = "BGRT table not found in XSDT"; + return; + } + + if ( !bgrt->image_address ) + { + bgrt_debug_info.failure_reason = "BGRT image_address is NULL"; + return; + } + + old_image = (void *)bgrt->image_address; + bmp = (struct bmp_header *)old_image; + + if ( bmp->signature != 0x4D42 ) + { + bgrt_debug_info.failure_reason = "Invalid BMP signature"; + return; + } + + image_size = bmp->file_size; + if ( !image_size || image_size > MAX_IMAGE_SIZE ) + { + bgrt_debug_info.failure_reason = "Invalid image size"; + return; + } + + status = efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &new_image); + if ( status != EFI_SUCCESS || !new_image ) + { + bgrt_debug_info.failure_reason = "Memory allocation failed"; + return; + } + + memcpy(new_image, old_image, image_size); + + bgrt->image_address = (uint64_t)new_image; + bgrt->status |= 0x01; + + bgrt->header.checksum = 0; + checksum = 0; + for ( i = 0; i < bgrt->header.length; i++ ) + checksum += ((uint8_t *)bgrt)[i]; + bgrt->header.checksum = (uint8_t)(0 - checksum); + + bgrt_debug_info.preserved = true; + bgrt_debug_info.old_addr = (uint64_t)old_image; + bgrt_debug_info.new_addr = (uint64_t)new_image; + bgrt_debug_info.size = image_size; +} + /* * Include architecture specific implementation here, which references the * static globals defined above. @@ -1794,6 +1968,19 @@ void __init efi_init_memory(void) if ( !efi_enabled(EFI_BOOT) ) return; + if ( bgrt_debug_info.preserved ) + { + printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", + bgrt_debug_info.size / 1024); + printk(XENLOG_INFO "EFI: BGRT relocated from %#" PRIx64 " to %#" PRIx64 "\n", + bgrt_debug_info.old_addr, bgrt_debug_info.new_addr); + } + else if ( bgrt_debug_info.failure_reason ) + { + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n", + bgrt_debug_info.failure_reason); + } + printk(XENLOG_DEBUG "EFI memory map:%s\n", map_bs ? " (mapping BootServices)" : ""); for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:44:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:44:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247091.1545972 (Exim 4.92) (envelope-from ) id 1vyEcN-00012h-5p; Thu, 05 Mar 2026 19:44:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247091.1545972; Thu, 05 Mar 2026 19:44:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEcN-00012a-36; Thu, 05 Mar 2026 19:44:19 +0000 Received: by outflank-mailman (input) for mailman id 1247091; Thu, 05 Mar 2026 19:44:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEcK-00011h-RZ for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:44:17 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b09bb82f-18cb-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 20:44:14 +0100 (CET) Received: from BL1P223CA0036.NAMP223.PROD.OUTLOOK.COM (2603:10b6:208:5b6::18) by DM4PR12MB6325.namprd12.prod.outlook.com (2603:10b6:8:a4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 19:44:08 +0000 Received: from BL02EPF0001A0F9.namprd03.prod.outlook.com (2603:10b6:208:5b6:cafe::ea) by BL1P223CA0036.outlook.office365.com (2603:10b6:208:5b6::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 19:44:08 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by BL02EPF0001A0F9.mail.protection.outlook.com (10.167.242.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 19:44:07 +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.17; Thu, 5 Mar 2026 13:44:07 -0600 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 5 Mar 2026 13:44:06 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b09bb82f-18cb-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ygCc+P3S/NQ8T9z9+hCwE2uKUx3hn5jKjxKFvdYq6iTfY0towwtHDSreh7F4lpAJAAsDCpspD007DQoPgRlr/EyttubNIToF08a9kV5iosQimxLckj1mAnDarZNrGVoKeIiMXXTopXMuol5jn5KVwPTA7qB48YE+KsQWmrh7c5VMOVgx2q81Nq+TezUCaRLEz+XhcKVsOLWiBPfpUrAKSr1/PeCPOPQKHOPAgSOJx+HQaUHWhnw2TeYHpjeV0is+1ZbRx8lJhFdz2YYHAjvYetL+hmXRYH0ja87yjc/g8ROCaEmlXfebt+3RWxFs6zq8/r50sp7ZLSzLwAoAcwKIUg== 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=1C9rMu+hKSXbM2T3s0AbPGeJ1AJKoa1R2N+QJToS5B0=; b=ThNWkQSksf/62DdSHd4HUD6M5cvLDIDTcdmobqM/lbOIoG4PwkaTWD1qrcvD8td/KAUBXjp3q4shQkmP9I5qr8dX10n6DoWug2clY5K4JhnIxUNW0whnM4wDEh8SV24W1zwtUY/sMl5nUiTgeEGMlZbgSMTqqveLVwsXwNpWlJUm/ER/0EvWeQfzGOglFQwTx0qOKlIeEGcGovhbyHgI7Dsc2dxkSLFvoSk80Gt64tlRL/g6I+uXRRq4xyJyBg8A9g3h1HvrXLbc3ZDMTN6+bs7mpYng3VkITZzCroitgQw0N/mgj2nFpiplD/9T+0CCeHReTawQXM94BJ8ESxJtmA== 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=1C9rMu+hKSXbM2T3s0AbPGeJ1AJKoa1R2N+QJToS5B0=; b=3ZhRcLQUz29S1pDn0dxfAHqeU8NX9rGdJm41Z8xKIVS+ZrlQWQ2hoD6RhrTy8cdREVgqmxRAUvd/Ro6MXbU53LZl9NT3BdkKZ1XBfeCsm15St15Cshqxg6Nz4FzIS1XcKsS2PrG8CBmw5lUGJmkeWL6O3PCykNZnNzZHBNHd7hc= 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 To: CC: Ayan Kumar Halder , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS Date: Thu, 5 Mar 2026 19:43:58 +0000 Message-ID: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A0F9:EE_|DM4PR12MB6325:EE_ X-MS-Office365-Filtering-Correlation-Id: d367120a-247b-43e1-17bd-08de7aef90c2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|82310400026; X-Microsoft-Antispam-Message-Info: KvIAc8BL5NLRh6k07DYrPE9Hr656zkG29PwS2b9Ie8x1TgzxHGiuuUh7jyGAe2waBkiUssYhJQTU+H3+lJxobKc4Wd6pSS1ZLgDveTRDNftS9mWVjZmSkX5MZl7ELNL0dDcrckIEKnlAlw8F+e7BTZK5kncTx2JkzXf7whoALhlaYPoTh+5lGV4x8fB3lILteAzPqVdhkpePWUTxjVRV6oyp0U5pBa6oxkHAxMlPKdnPsAfyc9e1mIOkVrppeHFZ1qKq3JHwubWE8UaMLrL4NkknKeLJM2AT7jyNC2ofSxC0itLMSo0qIoGVBkCFAUV5/Y9fCcfRXhYcByGK2Jjb4XKk5beO3I+cIHmtm9rlIr2QcvabJQJqSe+J3mjyEDX++kjQrykDhFiZ0r6gbsB/JfAYP/IGOEHWgdZl6bc86bZPfZr01u2semcZONGQo15KGw2nqp0CrYtuKKl6TQiUB++wfvtMqN8HL2ShZG/KU7R8bU/LrVOiuFcIPqcWG3Gc1Y/czw3r7TBGNohg44a92qAJE4BsfLOKJt5FY4OvkwLfIPdPpuY3KABVirG7ugH7iEgEzksEjXcemWWHzXeh7kbv/P5DFwMM6l3ZYBKGmZHEXtxYZ08ydiG6qMquzEEZOkrn9fAVnSX3prnSxeWq9THt9wJRAPHpZD2LI84BU7WHMcohFRIar5D2iKHb3EbLZTeko20obSNA7gta1XO16PTfhUgXp0JnhUgXF3oM0saIHOK84gzYebkSIhrMKRtyp/PuNYKrlX/zJd3dq8h/ww== 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)(82310400026);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ottV+oYcwRT4Fb9fh5IfNOXPqFpsJyWRpe+TS1KoxCFNaxeJhDbwzY2lYsjskRzCKuE13RLk10AGGY9iDjB6E5jNKGr6F+/zpPuLNOtu/3QZl3BAa0J9lKLOA9PXemvhXlIaNao9Ie7uCKUbqTdf/s9M09hr8w0/7ovUzMqvcs6YBPpc2NHz+6SR7mS/3kk8K1p446SGf566sQRr2a9QBH7grDPTJCuS4bVZMc/+CPDCQ/E2xLC9Uw9HbQ0KxXj9J1iXfMJyzWfVRJkUnBfmW5lHZ/TSJd1LaT10qYS5X+/mNaFoNbdqLX4JY4R6cOpUH0vMpvAmxb4MdM+l4kdB/oic3A2RrxEUnIALIf6GZLI6tw94ulNX/1lRwTBM/xCtDaIrFc90JKQcrt3LHqxUZF9xCXjZLuM1jIzwWf7DmZk/DQt8K5kPqrax0RdURj3+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 19:44:07.7164 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d367120a-247b-43e1-17bd-08de7aef90c2 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: BL02EPF0001A0F9.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6325 Set GICV3_NR_LRS as per the number of list registers in the supported hardware. This ensures: 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. This ensures that if the hardware does not support more than 4 LRs (for example), the code accessing LR 4-15 is never reached. The compiler can eliminate the unsupported cases as the switch case uses a constant conditional. 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can justify that the unsupported LRs (4-15) will never be reached as Xen will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some compiler can eliminate the code accessing LR 4-15. In this situation, using panic() is better than accessing a list register which is not present in the hardware 3. Whenever GICV3_NR_LRS is defined, the default condition and the related BUG() cannot be reached at all. As part of functional safety effort, we are trying to enable system integrator to configure Xen for a specific platform with a predefind set of GICv3 list registers. So that we can minimize the chance of runtime issues and reduce the codesize that will execute. Signed-off-by: Ayan Kumar Halder Signed-off-by: Michal Orzel --- xen/arch/arm/Kconfig | 9 +++++++++ xen/arch/arm/gic-v3.c | 12 ++++++++++-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 2f2b501fda..6540013f97 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH endmenu +config GICV3_NR_LRS + int "Number of GICv3 Link Registers supported" if EXPERT + depends on GICV3 + range 0 16 + default 0 + help + Controls the number of Link registers to be accessed. + Keep it set to 0 to use a value obtained from a hardware register. + menu "ARM errata workaround via the alternative framework" depends on HAS_ALTERNATIVE diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index bc07f97c16..fb2985fd52 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); #define GICD (gicv3.map_dbase) #define GICD_RDIST_BASE (this_cpu(rbase)) #define GICD_RDIST_SGI_BASE (GICD_RDIST_BASE + SZ_64K) +#define lrs (CONFIG_GICV3_NR_LRS ?: \ + gicv3_info.nr_lrs) /* * Saves all 16(Max) LR registers. Though number of LRs implemented @@ -59,7 +61,7 @@ static DEFINE_PER_CPU(void __iomem*, rbase); static inline void gicv3_save_lrs(struct vcpu *v) { /* Fall through for all the cases */ - switch ( gicv3_info.nr_lrs ) + switch ( lrs ) { case 16: v->arch.gic.v3.lr[15] = READ_SYSREG_LR(15); @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) static inline void gicv3_restore_lrs(const struct vcpu *v) { /* Fall through for all the cases */ - switch ( gicv3_info.nr_lrs ) + switch ( lrs ) { case 16: WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const struct vcpu *v) static uint64_t gicv3_ich_read_lr(int lr) { + if ( lr >= lrs ) + panic("Unsupported number of LRs\n"); + switch ( lr ) { case 0: return READ_SYSREG_LR(0); @@ -203,6 +208,9 @@ static uint64_t gicv3_ich_read_lr(int lr) static void gicv3_ich_write_lr(int lr, uint64_t val) { + if ( lr >= lrs ) + panic("Unsupported number of LRs\n"); + switch ( lr ) { case 0: -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 19:58:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 19:58:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247109.1545982 (Exim 4.92) (envelope-from ) id 1vyEpg-0002rb-BP; Thu, 05 Mar 2026 19:58:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247109.1545982; Thu, 05 Mar 2026 19:58:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEpg-0002rU-8M; Thu, 05 Mar 2026 19:58:04 +0000 Received: by outflank-mailman (input) for mailman id 1247109; Thu, 05 Mar 2026 19:58:03 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyEpf-0002rO-1a for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 19:58:03 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9c9bec9c-18cd-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 20:58:01 +0100 (CET) Received: from CH0PR03CA0250.namprd03.prod.outlook.com (2603:10b6:610:e5::15) by CY8PR12MB7147.namprd12.prod.outlook.com (2603:10b6:930:5d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 19:57:55 +0000 Received: from DS2PEPF000061C2.namprd02.prod.outlook.com (2603:10b6:610:e5:cafe::97) by CH0PR03CA0250.outlook.office365.com (2603:10b6:610:e5::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 19:57:52 +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.20.9678.18 via Frontend Transport; Thu, 5 Mar 2026 19:57:54 +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.17; Thu, 5 Mar 2026 13:57:53 -0600 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.17; Thu, 5 Mar 2026 11:57:53 -0800 Received: from xcbayankuma40.xilinx.com (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 5 Mar 2026 13:57:52 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c9bec9c-18cd-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nolg8v7daoe5QcxkD66iNmJAbVR4nYekC6JxGpPXvNKp5hjSFrCQlMwOLQYA569GcI/dTI8034BelXlXVqhzMThXjpAK8NCj9vnvLGpOzqfKbBv5j4yQjQ7FUGsW4JQZf8gbmzp7MUoz2n43QX3wg67eCiphsHHFmUEpQBpmCcv3Xtt5p3XtjqKi+CBM4NAgpyDeHkFif44qHJevHLXGjsKRmyrh500kmTKy/rGL0Efn46yTm/YWkxVJeiHrxHcNh50YFVpuwvrhMqoMc3cxiee9LEiVU67ygS4vGhYq9mL/kT4CytT4OzIhnvqxHkW2P/ZlYAGTQG3pSLjaPRVuYQ== 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=uKWjP4xtpZIn1PAPpYWKkBRR1vEVbVaqpTc5je+0qvs=; b=mcocFVi/mYZZfIkWE6fTrn6SKPOxhRhDu5fuSSO7K8dMdwjPPxjj5ajqhCKxikQ2g05Wxl9Swu82kzaCFn4wb12d8J12m3qLTdRqretT0qkPisngc6/GuGlG0SxXEl3iNH2cJLjTq3sAFAVehufFdFkagDGQEIbqCN37P3ZxCP61woYa4FQ3+ogT1bv4xCJbVIqgFDdWfFqLqCVWMkn9EfmUJAqyBdLZTgXn6Gg+VDIt/N59q9HpB+8Q0diiNaqXvYwVeFotw8jU81tHYapFrI6Vx0H3rT5jRlE9qNyp4YXq30618xSnchiq+UC09OjHSZXm20456sS3CKYL+1OQ1Q== 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=uKWjP4xtpZIn1PAPpYWKkBRR1vEVbVaqpTc5je+0qvs=; b=453Tf1evMXzHcqDvXsoyYKnxIdPOaCQTxU9kiabn3GrCL+coUGa6+oUmBuZ2PRq0ePw+sXvoLeS6buBnLQdkvWviGmskoexvIZL4BY3drW8ZWp0zdmgbo8QbHTkJju+4+B9l/4lpPyFv8riDUhjg2EiKSJFYBMTZjrJjBjuiogc= 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 To: CC: Ayan Kumar Halder , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" Subject: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version Date: Thu, 5 Mar 2026 19:57:45 +0000 Message-ID: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS2PEPF000061C2:EE_|CY8PR12MB7147:EE_ X-MS-Office365-Filtering-Correlation-Id: bb110e49-fcda-40f9-6829-08de7af17d72 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|1800799024|376014; X-Microsoft-Antispam-Message-Info: v3UqDZJi1M8iJOFUpmwfwZzXXIxdPnZ6CeuBmCk/8VZCpxZ8gwaDpnN+SQtTBvlY3JmkaHhuku+aq6palZ5ZDlv/75k6xhgKVVZ3cefgoJKrGdL0bizwwhWLXQ/Y18ZkxbpuUEGeW9ACaw47PhEii8ywGJSIoFe8hIAIK9rBi8ypTA0/bio3y+bLmHWeGW21Je5+dYLzuY/trPSorMe6liVV8rI6Ma26x2nlL0qMsH9H1wGvHVHifUQcAAmj5btM/AsuCshkOm9fhaP/iqMiAypr2htL0d0N8e6FYPvt4iXN106EHij16PHEhmKfO6baxI3g1BEJLK3BdZb1/eZMajL8vl3tXPJwFCeIDO476bdxCsptiT36NYEysUY7ZBGK7/j4T1+EFLvUzkCWqlThhPiFEdBH9iL8aD33QKU8H6e0qYYQebWJ7SNbnrSiVMIepfoC37z5cVSwNIxr+fm1aUGK2NHMZ7VKjD/oAHKchqjAhcLDpg3o3krwsk/ac4EJ04sAqmr6jvHs+5eOmNAq2RVm+kgWsCeHKCuRZN2YCEB4r9KQA5d0hD0mdvAdRoXnL1adHQ/mqq9cQ15pnPgOXBI5O1ebbkA9bk4+ogpSPY8zf+VCz2gK2V3FytNg3cA5fUhagVI6FDWP98CACGlvrh2OV8HVTwi9Hxf6QRMgSVaKsv+Mxn4VZmSPgSncXqZgT2liW+8Wbz63YG9OTCZGBIQsG7iwqUljj+mPY9MiXZU1gXF7JxPQ3XF0Ruc4+oK3/B5zYSSqWCgS6u7/Myp9bQ== 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)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: zyGQvV2s029w33hLtBvqWeJrKPFl4gdF75idS15b+b6kUMmMZbPEf73yHaXJkF0000KFg0ig/864Bkpy04wl2ixt+YjgZW5biAVRIi+p0cD7CSY/T3R5w/yjI0JgA5ANBXZJaAAGDhnkyevPMvDxcye8hLMbpHeoTy0FyNDZKyBNypdatUwGo9ZCCPFJ3BeIa0OtFX1yk4yEkWbAIHWUAzeqcz9cYWC0r/6sK45MZEhvluAVSUDtcPhY2+AF7nkdDsbwJtwG/Q6mqY9DiRfJ7xc+UNmJai6b3n7BBjHKCBMpIHeoxgV8gm9BKejmEwKppOMIt+bjO+owYrUr6mN8tRFblLOOx7wWWRpVOKzG4yl9dLynf9/jkFRVqRqiQwDiTDT1lOWKx+QMLzDm1BLkegWPfZeFN30EKnBWC+RzYsrBEKvEokK+dneU4ZM0mCkS X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 19:57:54.2826 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bb110e49-fcda-40f9-6829-08de7af17d72 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: CY8PR12MB7147 The lr_mask bitmap tracks which List Registers (LRs) are in use for virtual interrupt injection. Previously, lr_mask always used uint64_t (8 bytes) to support the maximum number of LRs across both GIC versions. However, GICv2 and GICv3 have different hardware limits: - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) This patch introduces conditional compilation to optimize lr_mask size: - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() cannot have a value > 15. Thus, it should not possible to hit the BUG() in the default case. Signed-off-by: Ayan Kumar Halder --- xen/arch/arm/gic-vgic.c | 11 ++++++++++- xen/arch/arm/gic.c | 10 +++++++++- xen/arch/arm/include/asm/domain.h | 4 ++++ xen/arch/arm/include/asm/gic.h | 8 ++++++++ 4 files changed, 31 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c index ea48c5375a..80d3beb225 100644 --- a/xen/arch/arm/gic-vgic.c +++ b/xen/arch/arm/gic-vgic.c @@ -16,8 +16,13 @@ #include #include +#ifdef CONFIG_GICV3 #define lr_all_full() \ - (this_cpu(lr_mask) == (-1ULL >> (64 - gic_get_nr_lrs()))) + (this_cpu(lr_mask) == ((uint16_t)-1 >> (16 - gic_get_nr_lrs()))) +#else +#define lr_all_full() \ + (this_cpu(lr_mask) == ((uint64_t)-1 >> (64 - gic_get_nr_lrs()))) +#endif #undef GIC_DEBUG @@ -102,7 +107,11 @@ static unsigned int gic_find_unused_lr(struct vcpu *v, struct pending_irq *p, unsigned int lr) { +#ifdef CONFIG_GICV3 + uint16_t *lr_mask = &this_cpu(lr_mask); +#else uint64_t *lr_mask = &this_cpu(lr_mask); +#endif ASSERT(spin_is_locked(&v->arch.vgic.lock)); diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index ee75258fc3..e1121a5bb3 100644 --- a/xen/arch/arm/gic.c +++ b/xen/arch/arm/gic.c @@ -29,7 +29,11 @@ #include #include +#ifdef CONFIG_GICV3 +DEFINE_PER_CPU(uint16_t, lr_mask); +#else DEFINE_PER_CPU(uint64_t, lr_mask); +#endif #undef GIC_DEBUG @@ -48,7 +52,7 @@ void register_gic_ops(const struct gic_hw_operations *ops) static void clear_cpu_lr_mask(void) { - this_cpu(lr_mask) = 0ULL; + this_cpu(lr_mask) = 0; } enum gic_version gic_hw_version(void) @@ -382,7 +386,11 @@ static void maintenance_interrupt(int irq, void *dev_id) void gic_dump_info(struct vcpu *v) { +#ifdef CONFIG_GICV3 + printk("GICH_LRs (vcpu %d) mask=%"PRIx16"\n", v->vcpu_id, v->arch.lr_mask); +#else printk("GICH_LRs (vcpu %d) mask=%"PRIx64"\n", v->vcpu_id, v->arch.lr_mask); +#endif gic_hw_ops->dump_state(v); } diff --git a/xen/arch/arm/include/asm/domain.h b/xen/arch/arm/include/asm/domain.h index 758ad807e4..8654ef89ef 100644 --- a/xen/arch/arm/include/asm/domain.h +++ b/xen/arch/arm/include/asm/domain.h @@ -228,7 +228,11 @@ struct arch_vcpu /* Holds gic context data */ union gic_state_data gic; +#ifdef CONFIG_GICV3 + uint16_t lr_mask; +#else uint64_t lr_mask; +#endif struct vgic_cpu vgic; diff --git a/xen/arch/arm/include/asm/gic.h b/xen/arch/arm/include/asm/gic.h index 8e713aa477..e1559ec98c 100644 --- a/xen/arch/arm/include/asm/gic.h +++ b/xen/arch/arm/include/asm/gic.h @@ -237,7 +237,15 @@ enum gic_version { GIC_V3, }; +/* + * GICv3 supports up to 16 LRs (4 bits in ICH_VTR_EL2), can use uint16_t + * GICv2 supports up to 64 LRs (6 bits in GICH_VTR), requires uint64_t + */ +#ifdef CONFIG_GICV3 +DECLARE_PER_CPU(uint16_t, lr_mask); +#else DECLARE_PER_CPU(uint64_t, lr_mask); +#endif extern enum gic_version gic_hw_version(void); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 05 20:25:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 20:25:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247123.1545993 (Exim 4.92) (envelope-from ) id 1vyFFv-0006t3-Eq; Thu, 05 Mar 2026 20:25:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247123.1545993; Thu, 05 Mar 2026 20:25:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyFFv-0006sv-An; Thu, 05 Mar 2026 20:25:11 +0000 Received: by outflank-mailman (input) for mailman id 1247123; Thu, 05 Mar 2026 20:25:09 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyFFt-0006sp-Rx for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 20:25:09 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 66adbf56-18d1-11f1-b164-2bf370ae4941; Thu, 05 Mar 2026 21:25:08 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SJ0PR03MB6470.namprd03.prod.outlook.com (2603:10b6:a03:396::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 20:25:03 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 20:25:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 66adbf56-18d1-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=aWOg0cpRru4auTsFsubdKbZ/UDipjtWMwjKLeXEQuG5w3IataLrAeH8jSj4uJcALW9Qyj+QtFUkZ0RW+sRBXQGbZBR/cvhgX4Yg7r/PrJ593lxP0eEa2ZfCS5ivskpBNr72RK0H98/q6dkfz7eLeyKNa5IcwfA84Iw3CQf2k6jr2u1j2mzQfz0EnJCf14oHL+JssnqZj/E6wNz52N0rGcUVqvotsqW2eq7AqZWWO0ZT5ZlUmySLIXN/fVGarEDzlnXHaZbYkq//ywUxPPcyxpQ671EZQZRo0GBGxrfqIoQSKWxPMI1B4QHx6EAalabHyedY31arT/L+W6YLIPXAULQ== 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=EwSb0AQsqbBm3g9wEJyMQTvkXvqq3aGJzRJL7F+bE04=; b=hNXwzqCBL1w+lHHiwntXhsJB9K3648m6b21nNbHCEvzA0A18lxy/ouGMBuAbgdkoxGZjQSzLyF+hd1CrFj3pHRzF5YExRFB1P0xgW6qptQzsX/gEB4tf3sURQ9vv3Y+bCeZTAbBJETz8mLMGfKVh3IHGq0AIA/qdcgfWL8Pb2oUCRyDmkoKME5PUMiqPwkW/uDFs0xdm2Feavn7mKU6lBK2kU2ovNSTNB7fJbo/dZzcrXW9WEtLfhwdqlGuUdo2DXbaqH4tu1NVyKg/DfbFkwzKcXEVCSDBKh3DwJ8BJuoVmRsFFEyCb8geAGGgKsSo+RZmFNRGsULBDjOawF0+8Iw== 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=EwSb0AQsqbBm3g9wEJyMQTvkXvqq3aGJzRJL7F+bE04=; b=MI+vAFbIFmO5WNuXZsaRGVpunwuSUPgIQq0j/ZIJ1oJnxeajnsRe5Q13abM/2fvVdEmrOnlgKVKpEe1i1J9O3YD4ayMmjUSazM7nitBQDYMoirPGYHaUCwAb0FUcvNCNYwWIMeh0dmc1Xxt4NpGOMLpREfvC7LQVLXAYxTGSYKc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 5 Mar 2026 21:25:00 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich , Jason Andryuk , Penny Zheng , Alejandro Vallejo , Stefano Stabellini Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper Subject: Re: [PATCH] x86/ACPI: _PDC bits vs HWP/CPPC Message-ID: References: <3449aaf7-b221-4c45-9d22-54e340167b3f@suse.com> <73dd0000-4044-486a-915d-6381d0820cf6@suse.com> <4264cd39-00f3-4114-af90-baa29f9a00b9@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4264cd39-00f3-4114-af90-baa29f9a00b9@suse.com> X-ClientProxiedBy: MA2P292CA0020.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::10) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SJ0PR03MB6470:EE_ X-MS-Office365-Filtering-Correlation-Id: 5794cf8f-3437-422a-c7a5-08de7af5486f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: DKYWa59wWJPK6pycVf1rKDA8YqIyjTlY8FKe+PC6LoXKwzgzao6VCWN9Vk4y+8iF1+IkEcwHGfPOL7JO9+ITa3B4G0NYaIvO/WfQAUNyj6SMBnb55CXLOFHWBrQpKUh97c8JD1PTvoKLBHx3LYQIxCZuJSpv4angpV9Ef99NMRzz3aXtv43W+NEciS3bHCE1e3Cz2tfaarnU3HQHhyqlO7AmQYGQUcdgUYJyGr2niFNTAuOZljgJic6309/1hZwtXsg9XHkp9B90Nzg52mI+UGWIDP5NRIUMImXGE76oTvZod5hed1gwwabqTc2iAwwvoB2YqML7SSVu2qxpdWJqQz833CB2L/7se/Q7mU3bgoZzDO6wZc/zjLAB6dpetRgTgXDD/9jOANcxMPYWwc1cXiwNH7ntg26/n+8UqH0E+IYUzaeHWeOdWV3/uh//H/5erf6OBgI9CzMISHi3phH3phGKNTiNMOMWB9pFn6ZiiGnhQ9wKIhuU3ofJhrXSZvAv5jly8gxc7+oRTU4MmIIZ3nazmA8Km2TsLV3N9pgDGM8309dtuS6Q4UqVFGEMI9GhiykayPjAsaPE/oJriQCmeOB/kzxZwLW+mstghnibQjWfGZ/aRPqKbx6VSEeG9Dwaw54xyxNg3oLoxBFBKyLEnYioFll+yLsEuoXR6sobyA6iziqOKPGCylIgr1yBroaNKi57/psKzgLhtMi8uutKqOFDHT5UhJXw3bjL5sTDL/8= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZnhITUFLQWloTFJERUJQL25WQmNQT0dhMXZFWmhQemxKNzlFUEVJdE9PZWlj?= =?utf-8?B?U3J1cHlmSUl6L1VldWxnb2ZDZTZxeXVKbXhxcjRQbEJCZFdwZWF6MUdDYnZ5?= =?utf-8?B?L0RNYmh6U200Z2ZzWDdhcW9JM3EyUUYvV1lIYU1aNnhLSlZHUVIzQXdTNFpv?= =?utf-8?B?elJMWWhwTER2dnRuM3NsdFpOcTJxZnhESkZBeDcrRjNtTjF6b1RQTlNsZnNI?= =?utf-8?B?eUJwWklXVVdRSlFDVXVzZmZ6UkFoSlZnUkNnQ1Nua1RBQ0Z3T2RzcnlFTHpN?= =?utf-8?B?b2lPWHFJWFQydFdrL3dlUW1hbGg3UllRYVRZWEowOXV4Vlp0SGZPMzZjQVVj?= =?utf-8?B?MGt6MlQ0cWJERjE1NFBaUzhneXNaaFJvNThucit4L0pBdG54YzFxeGJzaktK?= =?utf-8?B?TXl6R3hqSTNBNzFWY2t0akJmeVY1V3RHa3IyRXZxRzVqVFJUdUJyeDB5UlYw?= =?utf-8?B?cjFNdVBOR0tkVVdId3Zuc25rR3BOOSswYlkvdTBkRjMvLzloaU1mNTZGTkRj?= =?utf-8?B?a3UrbjNYaDRGNzF2TG9aNjBFK215SWpoZEp4U0YwM2R5ZnpGNFIraStSZUhJ?= =?utf-8?B?WmNFQzVCL0NWZncxVGtzRHFJd3h2REVySXhSaUYvOFdDQ1M1WUZZRmJoSWpK?= =?utf-8?B?RlFVL0hlQ2pMdCs5MllLbEw2Y3MyQ0w2OHV4aVhmL0FUVWFqZ3hjcnUwQkVn?= =?utf-8?B?RHB1R0duYllnTEVla0c1QUM4Z1BjV2p5UnRDeXh2TGZCNzdZdkZXOWhBcFNM?= =?utf-8?B?bEc4U0ZRbnQ2dytEV1NZWmU5aTlKeE5XeVlIOVowVlliU0R4Yy9YanZUMkhY?= =?utf-8?B?UmVkbkw5STZDMnQvL1hBWlE1THNLTkhNRkNjc25MNWwxQ2RJYTFyOHMxd2Yr?= =?utf-8?B?RTRBNFpOZjNmQWVwakh2L1EvRXl3bnFla1J0bXlVVEY0cjV4dXFGb2xmakVX?= =?utf-8?B?OWIzN2ZLVnR5SjdNRlNvU2o3WHFxM2toV0pJMEw3TUc1OUxiam13MDh1WXl6?= =?utf-8?B?cFNHbC8zS3k1aEZNcnByNXc5QXlLeHhhU0FWNDdFdDROZjFuUHNNN085cnNK?= =?utf-8?B?QWN6cmRyaGxnU2ZkeUZHN2Nvd2l5RFAya09HOFBMNHdTcDhHVHY4RENVNWoz?= =?utf-8?B?YmJqZHgvNVdVaDFCdjdxMUczQVg2a2lib1NXRDgvZUw1L05vR0pzYzVXT09N?= =?utf-8?B?Y05yQ3BRc3hHbENOTDlLbEJlUHIzY1J6b3pXc0kvbDcybTIwWk5LL3VJeVcr?= =?utf-8?B?TWNxTVlUS3F3ZWFPcXExdGVvWGVwdURQQXAyVXIxQk9CYWp4d0VpUHF5Qjh4?= =?utf-8?B?TEwyVXlocWtaN09iREttdGI5aDFjMGlDZncwandJMEJ5Sk9ldHh6QytpZ0VF?= =?utf-8?B?aE5qU0RPWkMvcEoxZG8vUGNpT2k4RU9lWEhjb0QwMkp4UkhYMURQdHpNdkZq?= =?utf-8?B?dVhicWRlRWR2SDNQQW1CWTg5QlFmVnVRK3RkcUozUE5ucUZVUnM3cVF3U0hV?= =?utf-8?B?YXhWcE8wUjYzMk9icGFmQlAxMHMzY2FxajNkbHlKVk1Wd1pyN3RkUTRGRDMw?= =?utf-8?B?a1RCRDk3VnNYeW1kY2tUbE93clNnNkxCWlZ0bm9FeTBESVl3WGEvbllLMDZP?= =?utf-8?B?OWE2MG9UUFpSQ3N1U1NzaGp0dDhiM0k1WE9TdElzM01FekQzM1NzVFZOZmZo?= =?utf-8?B?aWIyVzFISFc2bXl6bC9QYklnOGxDSEhCdUtFTE1va2hENzVMWGVORFNoajZP?= =?utf-8?B?RFVpSnc4VFNPNW1lMzBMYVNuTWI1b3RyQnNEdFZveHQ2MUtZcXZiWE1oOUlw?= =?utf-8?B?Nnk5Rjk3MWsvVmJpRzA5c0V6NjRuRlRWRThQdUg5Q0tpWXNVUEMxNStjY3lJ?= =?utf-8?B?QktTRSthSkE5UCtMck44QStWWnNtWWh4VzUyRmFra2pWa21qUzBNRHRycHlx?= =?utf-8?B?bVZLUGxiaVlBOHg1UzNLQThKVVdCYjFnN3BxZVNMVkxwZ2laNVNjaThkZEdD?= =?utf-8?B?UXpqdTJyQmdIb2FKdGJNOTQ2c1NTbnU2ZUs2bVpjbHlmemk1bm00eldLc25C?= =?utf-8?B?Qlk2a0ExN3lKS2t3UmtFenpUWUd4U0kwcHFybVhMTTR3eGFyRG9JMHJhMS8w?= =?utf-8?B?ZjBNU1RqTEpJWDRSWG1IeXlOekJFSHJ5aytmTDNlaDVJUkNKbVkwMnJKU3RE?= =?utf-8?B?S0drdjl6bm1mRmdVNWtoOUhOOWFCblhBTnh1Vld3bVJGQVp2ZmgwK2pnUng5?= =?utf-8?B?c2ZhQTNtd1NCYWNCdk5YYVhYRmtWVVpoZElOSm9PQktyc0NiSmNaOFZURnJq?= =?utf-8?B?NnIzM1BicUoxeDRXWTkrR3g5b1poU1hjT0w1dUdLMnBucWxTS0dxZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5794cf8f-3437-422a-c7a5-08de7af5486f X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 20:25:03.6566 (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: iqP5gh6I5jxvVCCudR4+OLPcGzRQJatEf5HtWVsHB7R51rGBRn7s2dNnWBQhQOzHdOWCb26escayWG8KwcGLXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB6470 On Thu, Mar 05, 2026 at 01:40:23PM +0100, Jan Beulich wrote: > On 05.03.2026 13:30, Roger Pau Monné wrote: > > On Thu, Mar 05, 2026 at 12:39:51PM +0100, Jan Beulich wrote: > >> On 05.03.2026 11:17, Roger Pau Monné wrote: > >>> On Thu, Mar 05, 2026 at 10:20:02AM +0100, Jan Beulich wrote: > >>>> On 05.03.2026 09:50, Roger Pau Monné wrote: > >>>>> Since we have the parsing of the ACPI related data done from dom0 it's > >>>>> not only Xen that needs to support the feature, but dom0 also needs to > >>>>> know how to parse it. Or we just assume the driver in dom0 must > >>>>> strictly know how to parse data from the features enabled by Xen. > >>>>> > >>>>> Maybe Xen supported bits should be & with the dom0 ones? So dom0 > >>>>> would set what it can parse, and Xen would AND that with what the > >>>>> cpufreq drivers support? However that would be an ABI change. > >>>> > >>>> What cpufreq drivers are you talking about here? > >>> > >>> I was talking about the Xen cpufreq driver, sorry the context was > >>> confusing. > >>> > >>>> When Xen handles P- > >>>> state transitions, the drivers in Dom0 would preferably not even be > >>>> loaded. That's what the forward-port did. Upstream they may be loaded, > >>>> but they then can't actually do anything (and they may exit early). > >>> > >>> Well, yes, on FreeBSD I simply overtake the native ACPI Processor > >>> driver with a Xen specific one that has higher priority. So the > >>> native ACPI Processor driver doesn't even attach. I think Linux is > >>> slightly different in that it allows the native driver to do the > >>> fetching of the information, and then the Xen driver only does the > >>> uploading. > >>> > >>>> Coordination is necessary only with the ACPI driver(s), and that's what > >>>> this function is about. > >>> > >>> I think Xen also needs coordination with the driver in dom0 that > >>> fetches the information from ACPI? > >> > >> That's what I meant with "ACPI driver(s)". > >> > >>> It's not only Xen that needs to > >>> report what the cpufreq driver support, but also dom0 would need to > >>> expose what it can correctly parse. > >> > >> Hmm, yes, strictly speaking we should tie setting of respective bits to > >> Dom0 having uploaded corresponding data. The order of these operations > >> may, however, be at best undefined (and possibly be well defined in the > >> unhelpful - for us - order). I don't think I see anything we can do > >> about this. > > > > I'm afraid it's the other way around, you need to first call _PDC, and > > then fetch the data. As I've learned the hard way while doing the > > FreeBSD driver: you must call _PDC before attempting to fetch the > > data, as ACPI will modulate what gets returned/is present on the > > Processor objects based on what support the OSPM has specified in the > > _PDC bits. > > In which case at least for Linux we're okay, as what we need it has always > been capable of parsing. > > > Anyway, not sure there's much we can do now about any of this, it's > > too late to change the interface, and what we have seems to kind of > > work on for the purpose. > > Which reads almost(?) like an ack-in-disguise to me ... Possibly, I'm just a bit hesitant because I'm unsure about what CPPC requires to be set in the _PDC. Right now we would allow any P-related bits set by dom0 to be propagated into _PDC when using CPPC driver. With this change we would mask any P-related bits from _PDC when using CPPC. I think this is likely fine, but would like to get confirmation from AMD. Maybe I'm overthinking it. Penny, Jason, Alejandro, Stefano: do you know which/if there's any _PDC/_OSC bits defined on AMD Processor Objects, or is it just supposed to be always empty? It would be good to get some clarification there about which bits if any are supposed to be meaningful when using CPPC. Also, on a related tangent, \_SB._OSC seems to also define some vendor-agnostic bits related to CPPC [0]. Should the CPPC cpufreq driver force any of those to be set? "CPPC {2} Support" bits seem like they should be set when Xen is using the CPPC cpufreq driver? Thanks, Roger. [0] https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration/Device_Configuration.html#osc-operating-system-capabilities From xen-devel-bounces@lists.xenproject.org Thu Mar 05 21:47:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 21:47:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247176.1546003 (Exim 4.92) (envelope-from ) id 1vyGXX-00086U-4g; Thu, 05 Mar 2026 21:47:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247176.1546003; Thu, 05 Mar 2026 21:47:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyGXW-00086M-VE; Thu, 05 Mar 2026 21:47:26 +0000 Received: by outflank-mailman (input) for mailman id 1247176; Thu, 05 Mar 2026 21:47:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyGXV-00086G-U9 for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 21:47:26 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e43a4258-18dc-11f1-9ccf-f158ae23cfc8; Thu, 05 Mar 2026 22:47:23 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id CD1896011F; Thu, 5 Mar 2026 21:47:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DA1CC116C6; Thu, 5 Mar 2026 21:47:21 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e43a4258-18dc-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772747241; bh=u0gj4H2h3Emn6PHCQ3NTJ6S3USkiCu4juy7VLJs6MK8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oyoG2yF5B15y9Q5opzbe48/xqw/zEN/T6mwkbwIrHuNF/42yYeHMyAjl5ywJZXbgG 4EZUKXvDRtMKjoAtHPGx3L9Nr8Y/rTzM4wJT9MldC7zoNLCst4XHv4NJZsp2DNZFyZ D1MHbqJG+BL/VExFOdNCTK9uSAKtDVz7abBLO/rDR8lLv/3iismgy95mI6m6DeSpyo oxDbb99Ib4gNDkpEsMj6AWSHxilPpBZpBooEQiWSUGxSs5K1fzA9OYoGp57sAr5dU5 fmzFvUyNtrpdK8gfpJzTO7otOCU7TtXcPqH/6btO+MCDk18AjGmYBjF/CPzxr/Wt4W o0AY+HjRydIXA== Date: Thu, 5 Mar 2026 15:47:20 -0600 From: Rob Herring To: Vijayanand Jitta Cc: Marc Zyngier , Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v9 1/3] of: Add convenience wrappers for of_map_id() Message-ID: <20260305214720.GA317432-robh@kernel.org> References: <20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com> <20260301-parse_iommu_cells-v9-1-4d1bceecc5e1@oss.qualcomm.com> <86342janlx.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Mar 04, 2026 at 03:02:14PM +0530, Vijayanand Jitta wrote: > > > On 3/1/2026 3:16 PM, Marc Zyngier wrote: > > On Sun, 01 Mar 2026 08:34:19 +0000, > > Vijayanand Jitta wrote: > >> > >> From: Robin Murphy > >> > >> Since we now have quite a few users parsing "iommu-map" and "msi-map" > >> properties, give them some wrappers to conveniently encapsulate the > >> appropriate sets of property names. This will also make it easier to > >> then change of_map_id() to correctly account for specifier cells. > >> > >> Reviewed-by: Rob Herring (Arm) > >> Reviewed-by: Frank Li > >> Signed-off-by: Robin Murphy > >> Signed-off-by: Vijayanand Jitta > >> --- > >> drivers/cdx/cdx_msi.c | 3 +-- > >> drivers/iommu/of_iommu.c | 4 +--- > >> drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- > >> drivers/of/irq.c | 3 +-- > >> drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- > >> drivers/pci/controller/pcie-apple.c | 3 +-- > >> drivers/xen/grant-dma-ops.c | 3 +-- > >> include/linux/of.h | 14 ++++++++++++++ > >> 8 files changed, 22 insertions(+), 16 deletions(-) > >> > >> diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c > >> index 91b95422b263..63b3544ec997 100644 > >> --- a/drivers/cdx/cdx_msi.c > >> +++ b/drivers/cdx/cdx_msi.c > >> @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > >> int ret; > >> > >> /* Retrieve device ID from requestor ID using parent device */ > >> - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", > >> - NULL, &dev_id); > >> + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); > >> if (ret) { > >> dev_err(dev, "of_map_id failed for MSI: %d\n", ret); > >> return ret; > >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > >> index 6b989a62def2..a511ecf21fcd 100644 > >> --- a/drivers/iommu/of_iommu.c > >> +++ b/drivers/iommu/of_iommu.c > >> @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > >> struct of_phandle_args iommu_spec = { .args_count = 1 }; > >> int err; > >> > >> - err = of_map_id(master_np, *id, "iommu-map", > >> - "iommu-map-mask", &iommu_spec.np, > >> - iommu_spec.args); > >> + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > >> if (err) > >> return err; > >> > >> diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c > >> index d36b278ae66c..b63343a227a9 100644 > >> --- a/drivers/irqchip/irq-gic-its-msi-parent.c > >> +++ b/drivers/irqchip/irq-gic-its-msi-parent.c > >> @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u > >> > >> struct device_node *msi_ctrl __free(device_node) = NULL; > >> > >> - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); > >> + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); > >> } > >> > >> static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > >> diff --git a/drivers/of/irq.c b/drivers/of/irq.c > >> index 6367c67732d2..e37c1b3f8736 100644 > >> --- a/drivers/of/irq.c > >> +++ b/drivers/of/irq.c > >> @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) > >> * "msi-map" or an "msi-parent" property. > >> */ > >> for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { > >> - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", > >> - "msi-map-mask", msi_np, &id_out)) > >> + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) > >> break; > >> if (!of_check_msi_parent(parent_dev->of_node, msi_np)) > >> break; > >> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c > >> index a5b8d0b71677..bff8289f804a 100644 > >> --- a/drivers/pci/controller/dwc/pci-imx6.c > >> +++ b/drivers/pci/controller/dwc/pci-imx6.c > >> @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > >> u32 sid = 0; > >> > >> target = NULL; > >> - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", > >> - &target, &sid_i); > >> + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); > >> if (target) { > >> of_node_put(target); > >> } else { > >> @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) > >> } > >> > >> target = NULL; > >> - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", > >> - &target, &sid_m); > >> + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); > >> > >> /* > >> * err_m target > >> diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c > >> index 2d92fc79f6dd..a0937b7b3c4d 100644 > >> --- a/drivers/pci/controller/pcie-apple.c > >> +++ b/drivers/pci/controller/pcie-apple.c > >> @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d > >> dev_dbg(&pdev->dev, "added to bus %s, index %d\n", > >> pci_name(pdev->bus->self), port->idx); > >> > >> - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", > >> - "iommu-map-mask", NULL, &sid); > >> + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); > >> if (err) > >> return err; > >> > >> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c > >> index c2603e700178..1b7696b2d762 100644 > >> --- a/drivers/xen/grant-dma-ops.c > >> +++ b/drivers/xen/grant-dma-ops.c > >> @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, > >> struct pci_dev *pdev = to_pci_dev(dev); > >> u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); > >> > >> - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, > >> - iommu_spec.args)) { > >> + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { > >> dev_dbg(dev, "Cannot translate ID\n"); > >> return -ESRCH; > >> } > >> diff --git a/include/linux/of.h b/include/linux/of.h > >> index be6ec4916adf..824649867810 100644 > >> --- a/include/linux/of.h > >> +++ b/include/linux/of.h > >> @@ -1457,6 +1457,20 @@ static inline int of_property_read_s32(const struct device_node *np, > >> return of_property_read_u32(np, propname, (u32*) out_value); > >> } > >> > >> +static inline int of_map_iommu_id(const struct device_node *np, u32 id, > >> + struct device_node **target, u32 *id_out) > >> +{ > >> + return of_map_id(np, id, "iommu-map", "iommu-map-mask", > >> + target, id_out); > >> +} > >> + > >> +static inline int of_map_msi_id(const struct device_node *np, u32 id, > >> + struct device_node **target, u32 *id_out) > >> +{ > >> + return of_map_id(np, id, "msi-map", "msi-map-mask", > >> + target, id_out); > >> +} > >> + > > > > Any particular reason why this is made inline instead of out of line > > in of/base.c? Also, some documentation would be helpful for the > > aspiring hackers dipping into this. > > > > Other than that, > > > > Acked-by: Marc Zyngier > > > > M. > > > > Thanks Marc. > > I made them static inline mainly because they’re just trivial wrappers > around of_map_id(), so keeping them in include/linux/of.h avoids adding > new global symbols/exports and keeps the callsites simple (similar to > the existing of_property_read_*() inline wrappers). > > That said, I don’t have a strong preference—if you’d rather have > out-of-line helpers in drivers/of/base.c, I’m happy to respin accordingly. The downside is we get N copies of the string args for N callers assuming the callers are in different compilation units. It's not performance critical either. Rob From xen-devel-bounces@lists.xenproject.org Thu Mar 05 23:01:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 23:01:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247219.1546013 (Exim 4.92) (envelope-from ) id 1vyHhD-0000tN-4R; Thu, 05 Mar 2026 23:01:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247219.1546013; Thu, 05 Mar 2026 23:01:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyHhD-0000tG-0L; Thu, 05 Mar 2026 23:01:31 +0000 Received: by outflank-mailman (input) for mailman id 1247219; Thu, 05 Mar 2026 23:01:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyHhB-0000t9-Ne for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 23:01:29 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d60c875-18e7-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 00:01:28 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by BY1PR03MB7993.namprd03.prod.outlook.com (2603:10b6:a03:5b4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Thu, 5 Mar 2026 23:01:24 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 23:01:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d60c875-18e7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Htp9lVvbe6xRNsKER0lw1KeL5eaVXlxsSolh+Cac9O/1DntTYwPjlMZ2uVFxS+l6IDFgK6wrR/DFODiSYKOOnLuHRqLHrcbpi9EG69qMCeSGzCfBN3oGJFSc/WnwZW5q6U0QZQRKYw3yLbXuB8Dqb2bPMhTi+BXCBOqMobyExvrcilFzbwCVQd9fBzaqS8zHjo5jDlJ0ks2h3f7XoL7fZKAvs1S+MIAE3H+fJCjDubgmpRpXHavODe0T+fOVEXHwhLdW/N0yKemK8L/wWI7f5zNpj5ANBp5KXV5agTFxqsr+/TDG2XzKeckckmChUOjVp3ZeC5XOKvBtaOz7S29vww== 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=tdB1xUBS8xTu12mJFI7HIru34MteWtqhpTTfhnCbXiE=; b=hbpQJliuMFeKqG0tho+mLbtFpPa6gcXMPlozG12XEnBP4yhfr3fDIDELVmV2puMxL0sfOWsy7fa835IKxyzupStZUag1RhBtxmzJ1hHimVnRFzQAz9Dusa6xB3LLoyi3O+mFYXQy2GZxlFUxbUm0oCQcfjQwfkEfVWjtLMsvZ+9zBy6bXEpyP/tNJcOH528TqSLdR9NWikVrowup/AxXM5Ak+QTjd02kQ8uUCFt5hRAaJHKIyQwxamfdJuy5L5GH+jBIv5qHQpJ2WxKBq6ejMuVEKL2CMCFLMWEUA0gi5aquQMHKO3CaH/EImG7B1Q3C6wK+obaHeUKA2y58EMXG/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=tdB1xUBS8xTu12mJFI7HIru34MteWtqhpTTfhnCbXiE=; b=IRdQTwzVNW+B1tX/xcZALeHdP/HMZt8bGbj4joQNw+9B6QRniWPPQkdrSfigP13uvgnyZGObFMmtCsitYbC1f5TEYLL+ait/22VlAFaW1qP8ZyJAqoR6MQ9Ddjb+JU0g6/kmFmrV6s1pCMLyFcSRkLONq2l4g5zQDl2eLjPCwyA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Date: Thu, 5 Mar 2026 23:01:20 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Ayan Kumar Halder , xen-devel@lists.xenproject.org References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0503.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::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_|BY1PR03MB7993:EE_ X-MS-Office365-Filtering-Correlation-Id: 0ce1defe-1ca3-4e3f-ba95-08de7b0b1f95 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7053199007; X-Microsoft-Antispam-Message-Info: JK2bv818fgjsnkDwYNOELaC3TxvoMgzD7QnEhKgvbJ1Yj8DHbLP21kdtJ0hgpibwwiSaXB0HWa8D3kGQdNpelIfi7UuCeZS4KQ1aRMSVJz27mXn9KXHmKKbt+5GpWAbjh4vQ5fqgWWTKn8O81yTqGbYlipc0ApsshFAmKa2xYGAGKl/dOyfODPJSQSqAjycZQDXv9M34s7L4ETwOVOb1aRkzPtRHeebgXjc5G0K7Eu0Zu2PTGVNM5fOBBDwVoOcF4q27aDtoZ3mhYdx8G3J2S0GYrIVERkY35MWkOM3+Z8Y/3XwR2asVEqGmiV+JGUSMJzQYYNNPTE0B+9Ni8df+1OvB7uD1WG4hhNC4muZZ9v322G/1hHG5M/WvF5xc3/q0Kjr2KWkPsruggJawB/Mvv2h6/Tvkhtk7wseFstug9IOgGRcReeTYFg0UjWHKWb1hqN1F7Lx9WlM67XCzVcDqRjlHCiDNiCxzZXxIzY41eVtJ1bjKTMSztm+xJsJ+PvKzQr20jDArpj6urutfjqjNfpkm8iRA+qRXXMf0HYcdOhLJPQI3YUA+5zKCYzWnQk/YkGn9XUPZHFHm89PRcVHtAl/5di6zhmYZEeIqj27w6inya5QrlfxZpO9D8TkfYhh2+ttxR5N6PeUQU02d1CkwSShec6dB4LnvK+LmAlWSMx2qsTg/gx+fcmxUCnwaxE9oaKqb/GM1mFGel3/M1Tgtb5p0RSB30Q0y+mN+kl8lqw4= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3NQSjhNeWg1S296Q3VEZ2FTVitkZFQ4cTdiK0NPVVZGSHp3N293c0xuSjI1?= =?utf-8?B?NldMVW5OVi8ya0hLMVo5eWNNSlhYb2o3Q2srY25pMVBCSXZ2UlZWeVp6MlEr?= =?utf-8?B?d1o0TGt6TlJ0ZnE2Y2RFSlZRVjBEZDJDTjJ2dXAvbUZPeHJMOC9MaDZlSzFS?= =?utf-8?B?R1NUcXRiYklOZVBOUG5VM0dqNjhXWnVSa01rTjRMaEJMYlhheHcxTHQ2UWY3?= =?utf-8?B?UlBCSzVhU291LzJVNFlsVkdwendkRCtCeHJwa0VyR0NlZlZGcHVGY29wZUVN?= =?utf-8?B?SDhMMG5FQ3Y0d2JxOFhJRHB4SXpZbXErK0JTRTBqZHovYmF1T081UjRsWnRl?= =?utf-8?B?ZEI3VnpXd3JqcHc2Zjh3V2NmMFVYVkovSXBYejFsVzVSYW5iRWU3eUhhcG93?= =?utf-8?B?TWFvbFBGVmtMcEVmYUZmSkVKQ2hHOGFIU0gzOHpVV1J2VDh5SXE2WXZCajdF?= =?utf-8?B?Z3RBY1poTGdzTTR1WmdLbGo4VEdBN2pJbmgzamJxYjJaSDcxRTVLZy9OZWF5?= =?utf-8?B?cXBlWDRXdHR2VStOaGhEM2tMTnRGMnl0bGN0SDh5dm5TdXNRakc4djJacjdu?= =?utf-8?B?dUpIN3JBajBBUDBEdmluWG1IUEUyNm4ySGFjMFcwNENHUm1TV0pOZFBNVWo3?= =?utf-8?B?eXlSUSsxOGpsLzdOUWZiejg5Z1pZVFRVMFpIa0JDVXdUUTlTY1h5NmluMU9S?= =?utf-8?B?NXNBem54USt1RmpkS3M5SFcwU1l4S3M1aytaRGZEU3lFUlZneEtFYTRYaFlS?= =?utf-8?B?SWhzd003a0ZDNTFMOW9aakpBQlBxOTRGVUFhOXJVWkRMK3F3NnJ6UXJPYWhm?= =?utf-8?B?ZkR4V0x0ZFdZVktwdXlvd1p6SU9vaXcrMjd2RE0wSTM0TlF5TWRVMFdLZmlO?= =?utf-8?B?V0NCNi9tOWt6cG5oL3dVUk9WOTBMQVR0OHRhbTNUTFVlK0czYmdEZ3FGSWdY?= =?utf-8?B?NDZhcEd4N1hyWlhhUnJQV1NMalV2d3U3ZE8zc294SlMzM0FRRG5NL0NkNkdo?= =?utf-8?B?WFZNQjdId0VpQVBmUDFLN0VpWDhXSkQ5c0tTYkRJRno5cyswdDRiUnVZWGxE?= =?utf-8?B?ajViQkhYYTFmVjVEazFHZ3RUL3BidWhMSjdmZStjQ1M3RlBQQ2JwS2tzaEdD?= =?utf-8?B?clQ1MzFWRmZpaUxzVzk0VDlmeDRsRWpMY3RRajNnNDZiMTFsRUZTeitmVUlm?= =?utf-8?B?WGxDdXkrUFNwRkJZS3N4amFiOFJ4ckNzU1N6b1hISS9NK2w3VEsrSkZwZ3Uv?= =?utf-8?B?QVlLMjhmYXpFUmJZNGNoTHQ2bUJmM3pwMzVEWG5UTDB0VnQ5aXQ1WVNGTzA0?= =?utf-8?B?YU1qQ1IzK1F5RUNsaVhXcEtJM2UzRVlqZlFTOWxYSTRzMmFlYldaZ2JmbFNR?= =?utf-8?B?RnRjY3c2dGxsZUl6b3Y4K2FDU3lxOFEwWFl5SG5oc0N2VklSVFRua2lDaURL?= =?utf-8?B?VlVac012QjdIOWkrelFWQmZwUGtlQWpCajFZT1padnd2ajhYalNxMkVjRWxh?= =?utf-8?B?VlBCSmhEUkpodTU4WUFEOHRORnZ0RkJGT29zS04rQU4rZ1BiMzRRV0YwMDhY?= =?utf-8?B?Mk9oeW4va3AwMXRkRVkwS2pPMzFST2FKZlpEWjYwRkVmSnJ4akVpa0tZWDVp?= =?utf-8?B?S0xObGkvdlpDVGlYWC9kVGNYSFl6TThqRGh0SHM0MGxIUlY0aE81QUttUmV5?= =?utf-8?B?aVU5R2Y2RkJGQys4eFQwSUoxajlnMkg0WmV4TUtpSGtiTW1ITUZtRUxEU21J?= =?utf-8?B?WGNZWXp2TEZaMzUxd1JvT2JWUGdWRzk1ckNnWmJ4Q3NLNEE3ek9NTThwdTF2?= =?utf-8?B?c1FnK3VHNVBMbWdiL2NIbkpwdklrUXpYcSsyYTV6bUYzSFJoQXhWTytGQ2Jq?= =?utf-8?B?T3g5S1BwekIydldVbGhFNkRlVk41MnU2TnpEWWxhNjU3YjRFUWhnZlI0TzB1?= =?utf-8?B?MThFU0YwampOakpCVFlDQzU4NDNWTUFHMjRIUk5LTzRSUmtVOG40aXIrR3Bj?= =?utf-8?B?b0FITU1SUitUUmtRNUgwUXVqZTRMaUtpRmR2RDZCTjVEUUVhTHlJa3VObE5r?= =?utf-8?B?bnU3N1NQZHVSVUVES1MxQTBlVDBZMCt1cEkvV1J1S1dNSHYvZjlsUmFtcHJa?= =?utf-8?B?UndtTVA1b0Q3TDNVUzQ1SExBbjlXZGFxUGw3U0dBRlNEaHh0bXBabVRHUW1Y?= =?utf-8?B?aStuODJqdTlxR2RYRGRkRjlaNXk1R0dFSkgrbkRhTlBqUTFIcDhqaGsxWE9H?= =?utf-8?B?TVZlaFdIZnh2ZzNtbmdlZEVyTnF1bXJZTVdHaWVhMkpBeng5NVJaTnM2QkIr?= =?utf-8?B?T0ZtN3kzV3lHZTliemIvN0tJeEN3RGs1T3pmOFQxcGVuS0lxenRwZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ce1defe-1ca3-4e3f-ba95-08de7b0b1f95 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 23:01:23.8690 (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: T+gayrsQIH+ZBD+ojrZh+9SUV9f3xDYMHHrS9g2q5t8DYk9T1toAiErm8oARg5mLzY6DNVZ4o8FObnUNjevRIrWRw3DiaMq4m10fmwsbF4s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB7993 On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote: > The lr_mask bitmap tracks which List Registers (LRs) are in use for > virtual interrupt injection. Previously, lr_mask always used uint64_t > (8 bytes) to support the maximum number of LRs across both GIC versions. > > However, GICv2 and GICv3 have different hardware limits: > - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) > - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) > > This patch introduces conditional compilation to optimize lr_mask size: > - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs > - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs > > With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() > cannot have a value > 15. Thus, it should not possible to hit the > BUG() in the default case. > > Signed-off-by: Ayan Kumar Halder What does this actually get you? Because it doesn't actually eliminate the BUG()s you reference. If you really want to go ahead with this patch, then make a  lr_mask_t or the right type and don't double-code everything. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 05 23:12:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 23:12:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247238.1546022 (Exim 4.92) (envelope-from ) id 1vyHrl-0002cP-5m; Thu, 05 Mar 2026 23:12:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247238.1546022; Thu, 05 Mar 2026 23:12:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyHrl-0002cI-2o; Thu, 05 Mar 2026 23:12:25 +0000 Received: by outflank-mailman (input) for mailman id 1247238; Thu, 05 Mar 2026 23:12:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyHrj-0002cC-SD for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 23:12:23 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c0e089a6-18e8-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 00:12:18 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM4PR03MB6190.namprd03.prod.outlook.com (2603:10b6:5:399::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 23:12:14 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9678.016; Thu, 5 Mar 2026 23:12:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c0e089a6-18e8-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jz8aPoOD9fw1Xwk4j0GLg8YyM2EcL/2Dz9F04eHcDA4rkT7hUz4a0FuBpt1VsqAaTDP2+UzEjBnJUTtKcS7jmDcoNw22RvpEmvxi5PNeH6XFVKFfRcsUnIkTulal0RGFCEMMvK9nfCVXyKJzZt+t4m6vpkqZAEjAVvYC8+ySDmJ6/y7t5iZ+vZa3oXbuuMj4FAQgwIW1IUNhsQTvsHfbHqXPzqUPmjt9zTZQBjHLSmO4tdC0JsyfPvuZblf0BbKEfe7PJW3UvRHrGKVq9n/Igb2RFkAzx5UOzauRlIcq9zc6T3V6AGjm1VTuRw8QBE9GVwd07iRHU2kFaJWtJVWQjw== 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=G5pjx4bf+wJbVOTCBWJI7I9V55TuDqo6aQNSqfapI5E=; b=qBluRLUiqQRskuHo4pF/ev73Na+mSNpblZcujBwOoT9IHdMI6nYnTLQ5kQj7hRWFlCEsV8Ep0JTnx8o6il6mxssR0MwM408voywOgJjprvPrbKXBb1pYuj+iaFEtSxX3q7o0k3kN+fPfL8BiQApfU9VRt/a0XUgSic1/165TOsSZtwTtfwpAk9G63Lirov/CqiVuBhNoMLE4HU9p8sVXWBPuiE/mlD1zl93Fr+RTqWSHJI5olxJUkEbtjDm7lSoblLOG3471KVlGAA5/QhXhxWgvpIhPQOQdPGSjshIa40ljCXOKN/RsEe1OKaBoC/erHyRcYGw+1N9x1DpIiW0HRw== 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=G5pjx4bf+wJbVOTCBWJI7I9V55TuDqo6aQNSqfapI5E=; b=JwQrZOT6F1CkgzrEPNIUHHs6gmqNqtiODw9e6CocLNYUK/3HF0xsKCXdZjKpxdhWLacBBDke4dwmeJFNvHeGbZin+QBUgC6Bu9Nd9WMeeAg0bqGcbw3WMTDJit7HWpiYzPVxDz/YYv8TT0CoDYQzQ4Zi+ycbjSbvyDpjTzzj0Cw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <0644e951-2200-4b24-8e01-ba178aab8136@citrix.com> Date: Thu, 5 Mar 2026 23:12:10 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Ayan Kumar Halder , xen-devel@lists.xenproject.org References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0109.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::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_|DM4PR03MB6190:EE_ X-MS-Office365-Filtering-Correlation-Id: 3953ffde-2624-4b33-8a53-08de7b0ca33c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: 51O+X3x6KjgtfDZEQ4cudvlMdazSy7BgoN6stQnI2WvtS6f0i216VN+/LMhW5UzMw8Ym6IrotQDJG7gObveFg+rCjgnr1fe6dB7u69yoSWyO2f7NV+ijLca/MVpBl4Vx/6ovRHZe5LMcbCLwWKeLixRNSJdFwqQSYF0eMnsSfFVYY5ovbgkRJ7/eNcbWe5oMjPC924ui9hunaBIeItn3eSLe8HcJj+ISA3PbVL7fPy0McrogHhjedfiRNpZoU2lRS1FMbl30wO1kfY6jY+wOfNapJ2rTozwEHHWyK2ORndyqd6J5XGH8wLbbi1ow+zUWr00yK+RwdcF+RDK0Xo/sQEHOoxxge6ZWeFlQvP+p/995fYWUbdzuStZim+D7f5sjX9ozyR2m7iaZdTC62kzsFRnX82hn1D/Rml44GnZpI1HU4UAsISNZp9Ai/HFIPnxPha8frxkmacF12p97xofLCDd6Uuosaop5VuKb3m5bkAX7qPQfkQZeSILCu+uxuzc6aoa5nsiTulzoazDmS/sJQkESSO/4hTB//0T/PBcZXZ8PrJWAbSsO2pU+XaNogaPwZEXSL+fzF7GNQjmqqN1SMQAKc48PTYPGFUerb/ecSWfCN0beEhB+APLWOQywsK0oduPqgve62xylGMs4DXXNP6pkpMUhNhfDt8Ick8bM34Gc8keazNi1PE8ZRHmhMVjgIyJCDi/AcXAcixbEacLBsiWBUzAWOnzTcbAG2N6mxqs= 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)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aVJndlRPRTJCSzlDYStWVEJ0Y1krN0hITE0rYk9Sd3NUNG5uYXFFOXpaRUlG?= =?utf-8?B?NnMxU0VGL1FKcWpuR2pDUUlVQUYwMkd5a0N3V1J5MitFTHYyQ1RlS0poTWQx?= =?utf-8?B?TjFrU1FudUxqU1YwTWxCWTlBK1prRWx0MzNIcTBoZFp3aFRqbXYwYUlXQW9l?= =?utf-8?B?SGZGUGd2ODFnVG4zTUFoZnVrRVkyZXRrZVRQL3V3QlVib2Y3M043ZHBHcjJB?= =?utf-8?B?UE9PbmE0dXBQdWhXNkU4UVNWSE5ySHN5dGtxWDVmN0w4NGxVUTFWN3NlMjR6?= =?utf-8?B?eTVtOG9RZ0VpSjJ6dXZ1aURKc0dPQ01DRkdtMS9hUVhRUzRvelJud3NRVk56?= =?utf-8?B?MndrUlNMRmM5Zisyd3p6WVhhM01wVkh5VHZrNlhUYmxzWmFpVzdRZ0FxQk1L?= =?utf-8?B?Kzg5SWIwNWMyMXVaYUY2NXJjcmtVL25VY1g4N1Z0QTNnOGhHL1E5NlduVWQ2?= =?utf-8?B?WWFJUmx4dFZjcU1XN2NjZ1ZjK3FHTkovUGxYb2NFSkplMUVZQUVZbkpPT20v?= =?utf-8?B?S2kycW9sL0FRSlRvNG1hT2x2VzdiSGx6N3lDVnhvQXR1MGR3dDhhbWFWOUdQ?= =?utf-8?B?aTdTV0FraEMrQS83cnpESnFXdkYxR1JKdVZsZHhxUEd5V0NrOWM4WTM4em8r?= =?utf-8?B?WC9MNEl2OFozVTYwdkFSRDJ4cnc5UW9yUUloaFU5MnEvVUZlWHM0NTBDd2ZH?= =?utf-8?B?UnRQc1k3ZUZHYm55aE9DTVNXbGNVdElJNW13OG9meGpURk8veERQK09ZSGF4?= =?utf-8?B?ZktJdSttR3hFcHAyZzYzYVZTSzRsZTgyY0N6WERoVnVzNHc5SWd3MWtXVHEr?= =?utf-8?B?ay9YRS9SdThJZE9nMytFTjlxOCt6K1lVQTV3L2JWY1hqSEdIcWp0MHpZVmZi?= =?utf-8?B?T3g1bUlZS0RPSHB2SnRoSllYek82UzNkWm1HeUlzZGZjT2U0NHNmdmRrZ29v?= =?utf-8?B?Q0dtcDdnOEUwOVlIb2w5Wmh0VXNpc20zOUNDQ01aTzVLMjA5RGh1NHI0L05s?= =?utf-8?B?bnZFRGd2R3ZtbVpTVXJWdTVlMWIzemVlQXJkM0xvT3R0Mldab2dyM0xPTXlX?= =?utf-8?B?M0VoMkxYanp5cGthdlU2dUJub2d4Y1NhWkRXNXVQSFJLOVNtRGhTcVVzYlJO?= =?utf-8?B?ZFdJWEMxOHNMeVJMK0JlWm9nemV6VnRjdlhnVElJUFNkaElXNEdnTHZRUzUr?= =?utf-8?B?R1RrSmVXdEtlSWFtbmhWY2FETjlSYUY3NDN2ZllhMHdZbDFPNGEwRU5QYXlC?= =?utf-8?B?aDBYSzd2NG1ObHV1ODlPc0Izd2puUDVCelJ0WmFzUm5ieVRNVzRiSm5HOXZp?= =?utf-8?B?WjJyYnRiWFB3TG5aeEFuQloySkhvNEFFVHloUlpiT2JrWlhEcFE3aXJaeEVC?= =?utf-8?B?YkdEQkpoWk84UVEzNFNiSE52UXZnTzFFOCtQOWdSN0NJeDVtWGpCZG9saEJJ?= =?utf-8?B?OGlEZUpKcUtHbjVweWRQN2dkTTFmOXQ4VmVHZnVGeDRIMjl3VFllNy90Qko0?= =?utf-8?B?UEZiZVpsTGZHYWx1c0xINGZaT0JKMnFlOUJMSjF5WGJqa3duS3N2K1liSXVF?= =?utf-8?B?b2xOb09xSS96bExWTS92ZVZLRGwwSng4T3pYSnhmbVNCcUxEM2J0aGxpYk4y?= =?utf-8?B?cmNpeWc5VmNyRDc5SHpxZ21sRnhRemZtMXAwRkVaUldzNVZLR0o1b0NyUE1u?= =?utf-8?B?eTduT0x4L3VIajRnYTc4YlVQYmJOMVYzeU9CdW1DV3RQSmlDUFhuRVdwVTds?= =?utf-8?B?QVB0U0JrRHNqbWpmRjM2VUxOYTVlbkdwNENXKzFEQjZlVkZDRmVqTnh6N3Z2?= =?utf-8?B?Z01ZSWRmcDdnU0NlR2M3TnhnVFdYR0R2SmJXam1LMzMwVjUxZVFVUDRFQzVx?= =?utf-8?B?WFRFNUtOWURVRWd4Z05FaTRVTkVuT2VtMkxtdFBma2VER3hMVGVpd3dGaURE?= =?utf-8?B?UU9ieXJwcTBhQUM2dlh1UTViMjJaanhLSWtaOXNHOE8xLzhhZW9EVUFtbWpW?= =?utf-8?B?dFNaNFg2R2N6UWNnMVdqZTErZ3E5bVkyZy9Ldng3SU5vYmxsYkJPUEtsNUYy?= =?utf-8?B?VUtOT0FTbXhld2t5OEx4ODBwM0F4ckpVWkVYdFZPdkp4UzlJL0tDT2Q2VkZV?= =?utf-8?B?SmNjTkVlUjhlY05jZjdrdkdxQ3JEWXN1TkFvQjJMaWdJMWlEOUgyT2YramJ5?= =?utf-8?B?NU5IV2x0Y2NSNnVDRzgyQUxMbDBsN0VzUU91UUVZbnJRNit0K1gvdy9PTGxa?= =?utf-8?B?eDgySXBEYlhWaTF5M1ZvUkdrRmZEdGZCTlZBUTBYUUpRNmJuS0Jmc2FRN2ZR?= =?utf-8?B?MWJLM3VLWVpkaTlCWFE3N0pUTzhhRk1raG5GM2VUejUxd0k3WWpBZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3953ffde-2624-4b33-8a53-08de7b0ca33c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 23:12:14.2316 (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: mnCejbTdqU2SsGNhfkOvgV6jqPWgFO76Lbn7dzqwdCQttWQlFUQ3sLjsq/tW7aogdq2DX/9LnRsWxpbybaLBGJ/PKRf1zYaIrnQWRUGcNBE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR03MB6190 On 05/03/2026 11:01 pm, Andrew Cooper wrote: > On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote: >> The lr_mask bitmap tracks which List Registers (LRs) are in use for >> virtual interrupt injection. Previously, lr_mask always used uint64_t >> (8 bytes) to support the maximum number of LRs across both GIC versions. >> >> However, GICv2 and GICv3 have different hardware limits: >> - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) >> - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) >> >> This patch introduces conditional compilation to optimize lr_mask size: >> - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs >> - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs >> >> With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() >> cannot have a value > 15. Thus, it should not possible to hit the >> BUG() in the default case. >> >> Signed-off-by: Ayan Kumar Halder > What does this actually get you? > > Because it doesn't actually eliminate the BUG()s you reference. > > If you really want to go ahead with this patch, then make a  lr_mask_t > or the right type and don't double-code everything. Also, this creates an Out-of-Bounds read in vgic_sync_from_lrs() amongst others. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 05 23:28:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 05 Mar 2026 23:28:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247247.1546033 (Exim 4.92) (envelope-from ) id 1vyI7f-0004Nn-Gi; Thu, 05 Mar 2026 23:28:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247247.1546033; Thu, 05 Mar 2026 23: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 ) id 1vyI7f-0004Ng-Cf; Thu, 05 Mar 2026 23:28:51 +0000 Received: by outflank-mailman (input) for mailman id 1247247; Thu, 05 Mar 2026 23:28:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyI7e-0004Na-MH for xen-devel@lists.xenproject.org; Thu, 05 Mar 2026 23:28:50 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 102f392a-18eb-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 00:28:49 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48336a6e932so54311685e9.3 for ; Thu, 05 Mar 2026 15:28:49 -0800 (PST) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485268859f1sm743165e9.2.2026.03.05.15.28.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2026 15:28:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 102f392a-18eb-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1772753328; x=1773358128; 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; bh=4vF9oHZvcy9raonXFUwX0+3Jx8cqQFifTNwFvrPALvY=; b=rnYxs1W+0C0cJAv7EsqchVOGrK2ziULp0JeZwBMXUqu67tTfSeXtwMKWOuYF12dHCy Of4T4+ESXcWR+TX1KvvsVOnbAGmKWPR95v9iRArydxUCU98ik0qVr+8/GMwjUDhD6adH qlOyQfePib5eDoHwN/lD5d8pGt/4cq5N9xck8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772753328; x=1773358128; 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; bh=4vF9oHZvcy9raonXFUwX0+3Jx8cqQFifTNwFvrPALvY=; b=fx55aDh/dueL76CzoIIp/Uhmx56qh3yc67l9AALL6xySg1V4R72F1QCgoP1G1vyx3H CTz2fw6uW87RuROcy65kk+1QMwCq4w+0KKctHL5N9uOjBehCFbzewqXWqf9H8Q3C4GH8 BjuNv15F3Q62/PuzTnbWgxo9pc0GKSwzg/YNiqI3lXDH6jVNP82BfTNmymkMu2JGwJOQ /ie6/b1xDGuaKfbx0DA/OmxEq61YOz4gq5njQ6TSPIMWfXRhMYNcuSftJlVVvJ+0XPwU HfPvJXJbXXBPQV4dqMj/TLDJSs8Cj2dk588nAUN/7Ouo84+iHRGwFjYP5ZuyNHTQWF+l pAKQ== X-Gm-Message-State: AOJu0YxEhkhdLicd8TD3+rge2vBwfmGLlDIbOkU+1sGa8ou8eRt4x48e 5rt18TjJnJhsAXQDH1lS88aU7wx0aMEakAqnjT8vr+yF7/owBtxxu5Os/fGjEImC6NV/ObKv5WD 5sNaD X-Gm-Gg: ATEYQzwGl/LO9TlhCO/lH08jV/hdP7n5VFVWXmM0yH01NTrrwm/xhr5FzsGWJ4zCgDL yEOJuZf54+SwrxD5RY7HDwcLdxAO2hERQRrGt0elrgSKyFaQrl8aLOhN99Ky9KecDHcyo2e7TvU TjZiUnL8Bxlh/fl8PIas6nJMKm9HbUxe4EMOiUIRrArCsmrHgRMjITPjGHD8ELbhhMBgYNdb9km +mTtYykFq99iVlAQMHiNR4aMXBGEkGNRbAPm7zV28kTQSOZk8blRMWZz1Vl9m2vB5Y9tggw3GcO r9F1SLcBLzlDak+eOPC0iJc9d6PYEgerFdphWgLj8OAJezgMCdpMXp4GpvceH7tSwnCElvxTma9 gmwjZkEJ7dNQuS+Vi+ZjqdbR5eKY+XcbUE4trUMYYBMK8IWVQS6MkMMuynJnBlAo6OCVcBHIIsW 38awS84V0oAjNQxkUjQYDbGNdca4WS7AyzzbWxwaYxKzmWXxNVMP+fDPu11mrHjmd7PrXjwY4= X-Received: by 2002:a05:600c:3b07:b0:483:43da:6c87 with SMTP id 5b1f17b1804b1-4852697965dmr80705e9.33.1772753328227; Thu, 05 Mar 2026 15:28:48 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Ayan Kumar Halder Subject: [PATCH] ARM/vgic: Use for_each_set_bit() in vgic_sync_from_lrs() Date: Thu, 5 Mar 2026 23:28:45 +0000 Message-Id: <20260305232845.62024-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 lr_mask doesn't have bits set beyond the hardware limit, with the upper bits remaining zero. Therefore, for_each_set_bit() is a better option. For ARM64, bloat-o-meter reports: Function old new delta vgic_sync_from_lrs 208 168 -40 but this doesn't highlight that it also removes a call to find_next_bit() from each loop iteration. No functional change. Signed-off-by: Andrew Cooper --- CC: Stefano Stabellini CC: Julien Grall CC: Volodymyr Babchuk CC: Bertrand Marquis CC: Michal Orzel CC: Jan Beulich CC: Roger Pau Monné CC: Ayan Kumar Halder RFC. This form also doesn't suffer an OoB read when lr_mask changes type. --- xen/arch/arm/gic-vgic.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c index ea48c5375a91..fae80e6cd293 100644 --- a/xen/arch/arm/gic-vgic.c +++ b/xen/arch/arm/gic-vgic.c @@ -241,9 +241,7 @@ static void gic_update_one_lr(struct vcpu *v, int i) void vgic_sync_from_lrs(struct vcpu *v) { - int i = 0; unsigned long flags; - unsigned int nr_lrs = gic_get_nr_lrs(); /* The idle domain has no LRs to be cleared. Since gic_restore_state * doesn't write any LR registers for the idle domain they could be @@ -255,11 +253,8 @@ void vgic_sync_from_lrs(struct vcpu *v) spin_lock_irqsave(&v->arch.vgic.lock, flags); - while ((i = find_next_bit((const unsigned long *) &this_cpu(lr_mask), - nr_lrs, i)) < nr_lrs ) { + for_each_set_bit ( i, this_cpu(lr_mask) ) gic_update_one_lr(v, i); - i++; - } spin_unlock_irqrestore(&v->arch.vgic.lock, flags); } base-commit: bdd49cc2f61510797a47ad81486be653633ab3ee -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 01:53:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 01:53:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247305.1546042 (Exim 4.92) (envelope-from ) id 1vyKNp-0004q6-8s; Fri, 06 Mar 2026 01:53:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247305.1546042; Fri, 06 Mar 2026 01:53:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyKNp-0004py-4K; Fri, 06 Mar 2026 01:53:41 +0000 Received: by outflank-mailman (input) for mailman id 1247305; Fri, 06 Mar 2026 01:53:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyKNo-0004ps-2n for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 01:53:40 +0000 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4a275681-18ff-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 02:53:37 +0100 (CET) Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.phl.internal (Postfix) with ESMTP id C9BDAEC053E; Thu, 5 Mar 2026 20:53:35 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Thu, 05 Mar 2026 20:53:35 -0500 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 5 Mar 2026 20:53:34 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4a275681-18ff-11f1-b164-2bf370ae4941 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=1772762015; x=1772848415; bh=6U8fQSkuzzGHsgVG0KV2VvXbd2zo1NyGpnENVNDSsbc=; b= JhtL3HQ22nMVwDNjR3CQvnkuSN1tkQ49+2VHFFjUJlsOxRtHWrBunnT5F9YaMufV D4fx5sg8eN7fzVPHW9AQwiwv1PMfwuJe47H9lZJEgxqCiCrwo27WuyIpUk/qWeDF ZumNeSeyPTxVicrnwGhWzkNQ2QkK/yNVQCJd2g6ji8WsMehrxZIiRSAu97wgn9tF MqMcP/1vd0OLJFQut0EB/9QKnaDPZgK4dWcYE1+Rq2X0DCnp35VAscyifD1mwUcg 08VHm7AxXT+7PJ8RpHHp5yDWjlGeCzeg1RZ9psI2Mv8UUZt99oG1GDWYkpE/SVts YyoVC2XpAOmWRgQIqzCUtQ== 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=fm1; t= 1772762015; x=1772848415; bh=6U8fQSkuzzGHsgVG0KV2VvXbd2zo1NyGpnE NVNDSsbc=; b=NfoWcLYKXi0VFuPamyhexjlj3Td2ngWOhPy5Y18c58OaWvRKypX kVRe9didpmFCLua3EgBBNy6WCTJzOir5d2DU5yTouCXf/t3krDdpltPLTrUFUgH4 Zo8YE44mKwz7maf30bsyk4/4pVh23hVbLgOTAas0S9c0c47VW2y4PPpJQI2FPHEK 10lEZK7CbuRC0l3201tvbvLwc8kQkjaV8Znp0+cvvGKfDeHqHfwooZhd98FijFSg aW7XlNvispkG8WCmtBr3sUQDeJoe6IRa6eKa1s/9WMn0vI8DYnUSCz+517xY34tt BJvXDAuPgR9AG1dYxmrrFZ9TVEnClX/26Hw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvieektdduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtroertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnheptdetvdfh kedutedvleffgeeutdektefhtefhfffhfeetgefhieegledvtddtkedtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepshhouhhmhigrjhihohhtihhsrghrkhgr rhdvfeesghhmrghilhdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsrghrkhgrrhhsohhumhih rghjhihothhivdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhse hsuhhsvgdrtghomhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhu thhiohhnshdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg homhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Fri, 6 Mar 2026 02:53:33 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code Message-ID: References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-3-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/16QqovfCfoBuKIR" Content-Disposition: inline In-Reply-To: <20260305191810.31033-3-soumyajyotisarkar23@gmail.com> --/16QqovfCfoBuKIR Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2026 02:53:33 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote: > Now that BGRT images are preserved during EFI boot (via > EfiACPIReclaimMemory allocation), the invalidation code in > acpi_parse_bgrt() is no longer needed. The BGRT table remains > valid throughout boot. >=20 > This removes the code that was marking BGRT invalid when the > image memory was detected as unavailable, which was causing > ACPI warnings in Linux dom0. When preserving failed for any reason, or when it was disabled (the next patch), the entry still should be invalidated. In fact, the check here for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got preserved? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --/16QqovfCfoBuKIR Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmqM50ACgkQ24/THMrX 1ywwKAf+K4Aypn1nnlz362E4k9FyryWFI1RwnfOBEbwvG47RUlxe1D+QawoMxTln ZdvCvxl6c9n5dlHNhAjauGYGvohFBadcpE1imodxulmEnj3u7GjnrgJbS9E4cYQW uOf6L7WV52/crMsfhNTfqbTRwD+zN694FvcXYWOX9599KFzJ+tmV07aIZjc5y0Ik x0Pyo9v0FZYUfxo/LMO954LhT15+N/VO6XzIkAxFcybDG98SXwnyYTetAAwqp6f5 bG0wwae24leJPy0r1jQyUSdec4tawJ4lCokfCT94Jp7mt7Lfktq3jUAq3WRkRuXk d8BpllFrZGpqUA0gisvSaeFCPtQ2iQ== =gxAI -----END PGP SIGNATURE----- --/16QqovfCfoBuKIR-- From xen-devel-bounces@lists.xenproject.org Fri Mar 06 03:29:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 03:29:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247359.1546051 (Exim 4.92) (envelope-from ) id 1vyLsQ-0007eQ-Pv; Fri, 06 Mar 2026 03:29:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247359.1546051; Fri, 06 Mar 2026 03: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 ) id 1vyLsQ-0007eJ-NL; Fri, 06 Mar 2026 03:29:22 +0000 Received: by outflank-mailman (input) for mailman id 1247359; Fri, 06 Mar 2026 03:29:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyLsP-0007eD-2m for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 03:29:21 +0000 Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [2a00:1450:4864:20::642]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a8e61b36-190c-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 04:29:19 +0100 (CET) Received: by mail-ej1-x642.google.com with SMTP id a640c23a62f3a-b935cd1c6f3so1350864066b.3 for ; Thu, 05 Mar 2026 19:29:19 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8e61b36-190c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1772767758; cv=none; d=google.com; s=arc-20240605; b=dj314FPANkDIr3AMmNX9dEGmdKHbtns2FBWiu+5U3aIZ3utiG5t/BfBQRFjisJeBk+ yVxiLJpvva0CVyyRhk/X9UVOSTMB1qTP2NddJiRrPu4RPYgEL3GDlTcBHadgseumZEGf YD9/B1Bk0UsIr2HnCcUbiV+7Kdd3R0k+RodWrEKAXHsRYasAc/pzAV5g1x6gvc5o5e5U /NfPXM+ycMNEqrJ9tJD4DcCn1XTvqniow2OnqHvcsHn8yGQPQ5yvBheZJub9lRduYm1G +nlY5vrE2KRmQ/PWJGP3k3hb5NOBt2vJRfxM7nIObrkeGYPdqDUESAN7bwh273cyo+3J N89g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=XoxbFDZsmQse7pjbVYXTdtM53ZFTNHC86YvKyQzdLDY=; fh=5FPMNlxonDnoIoIMaWMAzT+Br+bG5xkQLfcZfXfS980=; b=byc4hknhqyA7q/WNZBiICPGJTA8N6/AWfY/PAU1jgksb0y5KVuvZp/LyHBo8g+tEzb tM2xtjkFvwsoALDDOVWsQ/51lxwc8qH1C5g3HKJvDesj+Ot1wIYw7Iu37LnhDSxkewrM /BDtN92/ZR2i/kmTIBwq9PjaxOlybt3rqlsfclXFg+7Q7a2MjyWKukb4nF7JO+9yjonn ROji4OZzkTygRNo3SZ0NpClBBqJUoRPAZZuegCBX+tcGE8uNdg2IGx5vTqbj/2y22Hqn FbSYUI4sjNuJP6xSXIqKW2esf7gt8J1goPBETfjzMTZESaG3lGWBI5g/HysqZ52JOMRH WD4A==; 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=20230601; t=1772767758; x=1773372558; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XoxbFDZsmQse7pjbVYXTdtM53ZFTNHC86YvKyQzdLDY=; b=JBRbVXZIrIZB4gvESd1FL5xUggFlaRBkhzx9MmdzoJUJ9d86kv40fs6PI9ud723J38 ePu3Oj08XeRmfLp5QGQJPOvhDkpCwrVqpV5NJ5y1nauehRbK5mMLxBaD4B2ZMKD2OxDE Nv+EBri29Ik0Fr+zca7yW+/KU7uLliQ1zDxUfbFaAaLQ+TfXTsMtwukg59kUCoGj3lmD MrjDLZsyVuM9lE3Cra9gzz5MKEdAdhDNzUV9AI5Mkq+WgwEnmrxqxP9H7kNYpCgUZugQ 9VW7Y2taVqgkidzwRMQPws3zawm2Q0t8AsMULpi/W84rRwKn+JpuftVjOja9Qg0HYYDZ zopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772767758; x=1773372558; h=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; bh=XoxbFDZsmQse7pjbVYXTdtM53ZFTNHC86YvKyQzdLDY=; b=rD8/sgeDtxyrAGKmz34hd+xJyqJaCxAZueRw4ThzdPs+lzsy/derOhR//WBtgNfZ0G 1ecACbmYTeDTxgC0tjrRSPuxxYeVENCToU1c8xv2oLseFvM/N7B0N4lxRm2WAgeL6uJT Ym/8ltPCr379wgMsavUd8GZTzR9kV9H9QqkcKhp7n+4yYw8TjZx9NcIq/CDo26AcIA3N TeLM5hnCEe0MEunzNBY19z4xM/jJZrhLcY/WTz7ciYrpn8ZqlJPKLub9MQVUQy5Gy/YX LdCBims62XiDwnzKB8i9fWIhvMIdeoXPzp/MKX5bIiXxBeKd4tUq0fGo7kzlLw3z42x7 n+hw== X-Gm-Message-State: AOJu0YzaMYg0g5BRQTRCvIYKYvuZn9St7rtGHFrctICV1pTntnMYrMTW QASB3IDlZlz8S/Ul+5mBQAjhVifCd4yEbjLBFRxTlBW5OMFoZ8xnDoyWxLlyRHJ6eOurp8Ku/4b OraKw6YtI3Mkugui9/Ce1pObZbLWwp24= X-Gm-Gg: ATEYQzz6uKBFGQ0kgdICjiKpXSDytAgfHaOR5w3hcFSqZuUewUVflsakxY5xKO9tATo 27MJCk+2nA6CxZ+0jM9UvPGTDlTndwzR6HFR4oi6GX/8W+7bLzWDY9DY76AahslqCWq49ykDnn9 SF0zCZuctYcqa2hwPra2vSE1i5MAl+D+3DUy8/HWsOtWNHOjTTAO/dqkf6SIhS4aMB3ZFt4CE4i Lie8SxiHmoNzD3rDPrKkIHP7YoqAeMDzpCAkGz7sJGTQRMkvvWHpcb0VeLAsoSj7zqYGZUvE8Xz lLOzRyzLJ04GpZ2J1v6azSJFILn+VQ6bjPG+PPed1uxbfo9IdkaGgjvcRG4MBQG3+OYZcY/4TeI nUqfFfuO/ukxvjQkkzL0mruDPB1YGjrVc23AfqtnAByj5JOTO X-Received: by 2002:a17:907:9723:b0:b90:e278:a09a with SMTP id a640c23a62f3a-b942e0260a7mr28817066b.55.1772767758275; Thu, 05 Mar 2026 19:29:18 -0800 (PST) MIME-Version: 1.0 References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-3-soumyajyotisarkar23@gmail.com> In-Reply-To: From: Soumyajyotii Ssarkar Date: Fri, 6 Mar 2026 08:59:07 +0530 X-Gm-Features: AaiRm501VytSKcWIeZ-pqT47TTKnIOV6BYY3Ufp6EbWr56GD6d41Jw1euOFh5Ck Message-ID: Subject: Re: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper Content-Type: multipart/alternative; boundary="000000000000805590064c52a809" --000000000000805590064c52a809 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2026 at 7:23=E2=80=AFAM Marek Marczykowski-G=C3=B3recki < marmarek@invisiblethingslab.com> wrote: > On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote: > > Now that BGRT images are preserved during EFI boot (via > > EfiACPIReclaimMemory allocation), the invalidation code in > > acpi_parse_bgrt() is no longer needed. The BGRT table remains > > valid throughout boot. > > > > This removes the code that was marking BGRT invalid when the > > image memory was detected as unavailable, which was causing > > ACPI warnings in Linux dom0. > > When preserving failed for any reason, or when it was disabled (the next > patch), the entry still should be invalidated. In fact, the check here > for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got > preserved? > > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > I could move forward with dropping the [PATCH 2/3]. And adapt the other patches accordingly. This would serve as a safety net in case the preservation fails for any reason. Would that be a valid approach? Thank You, Soumyajyotii Ssarkar --000000000000805590064c52a809 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 6, 2026 at 7:23=E2=80=AFAM Ma= rek Marczykowski-G=C3=B3recki <marmarek@invisiblethingslab.com> wrote:
On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar w= rote:
> Now that BGRT images are preserved during EFI boot (via
> EfiACPIReclaimMemory allocation), the invalidation code in
> acpi_parse_bgrt() is no longer needed. The BGRT table remains
> valid throughout boot.
>
> This removes the code that was marking BGRT invalid when the
> image memory was detected as unavailable, which was causing
> ACPI warnings in Linux dom0.

When preserving failed for any reason, or when it was disabled (the next patch), the entry still should be invalidated. In fact, the check here
for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got
preserved?

--
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab


I c= ould move forward with dropping the [PATCH 2/3]. And adapt the other patche= s accordingly.
This would serve as a safety=C2=A0net in case the = preservation fails for any reason. Would that be a valid approach?

Thank You,
Soumyajyotii Ssarkar
--000000000000805590064c52a809-- From xen-devel-bounces@lists.xenproject.org Fri Mar 06 08:49:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 08:49:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247450.1546061 (Exim 4.92) (envelope-from ) id 1vyQsB-00038y-Ji; Fri, 06 Mar 2026 08:49:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247450.1546061; Fri, 06 Mar 2026 08:49:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyQsB-00038r-Gp; Fri, 06 Mar 2026 08:49:27 +0000 Received: by outflank-mailman (input) for mailman id 1247450; Fri, 06 Mar 2026 08:49:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyQsA-00038l-2n for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 08:49:26 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 602ce972-1939-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 09:49:24 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4837f27cf2dso83242355e9.2 for ; Fri, 06 Mar 2026 00:49:24 -0800 (PST) Received: from [10.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-4851fae0202sm128773545e9.6.2026.03.06.00.49.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Mar 2026 00:49:23 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 602ce972-1939-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772786964; x=1773391764; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=U02JrJpD6n7i++ALGsisq3tquoiP2+K1GuxNuju8wx8=; b=Lp6kWuRTU+ebKDuNqj43t6RxE3k5iqtA3M7cGMTvx/4uDauwVkq18WaRXNBiOcF+hl IROlDVaVjIYEl2anvq+hY7xYS85MZ+hbeFMyh0G1eH2qvqSBuyoZDfWZOC0KcVkNKJY/ CBdCoQ3A//8wtaAlMzuRxA34YgS3i4w8B6iAYHCT3kcuW+vKpo2MzOzaWIvyKUL4JRld 9aGFi6dLQT0wY/xibTkHePzNiiNDiPK5yIS1xAKlmuzE+Exm3CUsUOxStb+WzjYdL6Ui GeOASneuQpJ39XgmoD1BGHOiiYtSeoJh76QNnm3Jd3/2+Htutg2YayDyc4bvLzU1eECG wZyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772786964; x=1773391764; h=content-transfer-encoding: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; bh=U02JrJpD6n7i++ALGsisq3tquoiP2+K1GuxNuju8wx8=; b=pqyLght4ZWxbLwaeWLsgt2Xd0t0K503kQlnuqEPZJMud8loReSnXZiu/cFF9po68kw gx6lOvWJtwjqij7n0D6qrqhcjVj2AgQpwWmItbWZw0qHRi6OshONOhsh/k+QG/kGdwTR EOwcO8y6iIi8Sysv9I4MdAMX3s27JMwDrDYJ0ZlQ8Bw2VL47OwQeTaEibJ4uCH+iUkoU h3XxSIzN+u5HYsDtZP4+axF6CZAqQhWQBrJKE9iJBv5F5ru/9LtWv/l6rTTcYWtkmg9p KsdMwyxdf5FoGKUZYKR5VJ0fYwB7ocNSP+3FQj03wWhjURdApj23GtVCzATzrwBzGjcn ODMg== X-Forwarded-Encrypted: i=1; AJvYcCUeesnuJ8rvADh43rKPhqiDFMC7jvtuIMcG050OfDlWABehM5R0iX9/ZGIAuQyuVtoUzoqaboRa2O0=@lists.xenproject.org X-Gm-Message-State: AOJu0YyaoTMt30ZbaqCNcNQrxXtNVEf6s5Ko7IxOxmx95sOE73fzg+pX VrmhJyhM6ovhihdJ/tYi8KvZppNpT2IC35xh+rf8OG13yaqZ05Fd7PmKPa1rgY3Y3g== X-Gm-Gg: ATEYQzxsQgcJhLfYYU9WazAAPKj2tJTjS5RmCvYlYOAz3BX23z+Yewwo8Q5/XZSi9TM HnDfELWFnhVg+dhzwB8Dd6HYnhQqDriZ6c88LCZAmuL2Ntj33yAWQVJq+XlKl4X9SGHDWjPJ6gs lAikv//G76EPyYH7AaSiLNML+qJuTuwd8+/dYILjzmQtfdHnnEMcX5Bga8vADjC6dhNntvjuM/n wshGLSSpBUMqCR/xU/xk9ctY6gHa8wh3GkE8tKMHMeXDLpVb2RI9lmAhxR9p2UmIacNwr0BTJ2/ 1LQaNtm4rZgAATI3F0trgLZI/iS4uK2g39P8nhZYjIIAvfaXBag6HYfO61ZGaNEqchlXN//WA6D fUNWJKO5zLaNGc9LW50NgD6pGxVzhO/CR0xh1wz4FjxwFJtxEuA5bvJ5HKk28qyxt0YD+JCKsUB rmSJ4x7SZi+XpA6xzENtI9Du3/JyZL5LuZgnpmIBIuYQLBU8mQYU1VOvYafaid8j9lgarAeFhhS jaoH6jW3Ghlnt4= X-Received: by 2002:a05:600c:1e2a:b0:483:c771:10e with SMTP id 5b1f17b1804b1-48526957d6cmr16921425e9.20.1772786963764; Fri, 06 Mar 2026 00:49:23 -0800 (PST) Message-ID: <9e222b10-f63a-4a5a-981c-36c438e3071c@suse.com> Date: Fri, 6 Mar 2026 09:49:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Ayan Kumar Halder Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2026 20:57, Ayan Kumar Halder wrote: > --- a/xen/arch/arm/include/asm/gic.h > +++ b/xen/arch/arm/include/asm/gic.h > @@ -237,7 +237,15 @@ enum gic_version { > GIC_V3, > }; > > +/* > + * GICv3 supports up to 16 LRs (4 bits in ICH_VTR_EL2), can use uint16_t > + * GICv2 supports up to 64 LRs (6 bits in GICH_VTR), requires uint64_t > + */ > +#ifdef CONFIG_GICV3 > +DECLARE_PER_CPU(uint16_t, lr_mask); > +#else > DECLARE_PER_CPU(uint64_t, lr_mask); > +#endif But GICV2 and GICV3 can be enabled at the same time, at which point you'd still need 64 bits, I suppose. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 09:21:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 09:21:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247468.1546071 (Exim 4.92) (envelope-from ) id 1vyRNV-0007zS-Qx; Fri, 06 Mar 2026 09:21:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247468.1546071; Fri, 06 Mar 2026 09:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRNV-0007zL-ND; Fri, 06 Mar 2026 09:21:49 +0000 Received: by outflank-mailman (input) for mailman id 1247468; Fri, 06 Mar 2026 09:21:48 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRNU-0007zF-G7 for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 09:21:48 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e54e4bf1-193d-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 10:21:46 +0100 (CET) Received: from BN9PR03CA0641.namprd03.prod.outlook.com (2603:10b6:408:13b::16) by MW3PR12MB4474.namprd12.prod.outlook.com (2603:10b6:303:2e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.5; Fri, 6 Mar 2026 09:21:42 +0000 Received: from BN2PEPF0000449F.namprd02.prod.outlook.com (2603:10b6:408:13b:cafe::ad) by BN9PR03CA0641.outlook.office365.com (2603:10b6:408:13b::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.23 via Frontend Transport; Fri, 6 Mar 2026 09:21:41 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF0000449F.mail.protection.outlook.com (10.167.243.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 09:21:41 +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.17; Fri, 6 Mar 2026 03:21:40 -0600 Received: from [10.71.194.215] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 03:21:39 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e54e4bf1-193d-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wHpMflHJfgEYjP+XdcU6CaLPD3xG4Qgq7bffqEvV1AEqT/q4j3HNzkdFiM9Y8pIRrxChbkrsPCN9hntGuk7faT7pLJhf9vSlcYR/wjuRqsjj+mwsE2wihZfHTmrKFpXRsplAYfM9GrSCSVE6a5IA/kZPsFDuPyUirqml4mi3zH/umoIq3BA2UwVUSyOQCSiZNj0Zs8HaK48j4XQrfAxe+7ESAnrhkCZUBBDe2vjbFXEnsDbT0Eg+KUY+9Bio3EhHd2hxXOlun/NSXJgkJikplETMTIXFlZ1J5l+2/G0Oprg26vzrO8QquNQfg5Ch/7J8TP8pyv7sAa6KCkHDd6/bSg== 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=sFRT5nAckARuk4H+S4Yw9VmrAdvcJew+SYc7fWR7jhg=; b=vBlHjDlXw+2mpaSVtVWOZO3AND1D6C3kWbnbg6z5YQHaDsYTEzJMiipYTSyUNhJA4PrqpgCBSqJf2uDeoFuOnLnextfYY3JEDafxMRpSfLnFygXxf3ukgWDozZL0CrKXfPLxyiAjuLvseU/nYQWfcOvgcjpaJOK41xutGIYOy4DLXQ/FbrSKOrhBfTJ+z8N5sT4j8elWpxvGS0ffukCPrwWRtOCoCGFvmX9piCY6DCO/Mql53naF7pSuEQHO0J48z9UJ+MQmV6Mrc8sFjjV6Z0HpoA/BZ4ZxSU+oCh6x1FHVUtZ/CVT6/svgHS9eHOj4IkGEXZkd44m/SWl52sxUMQ== 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=sFRT5nAckARuk4H+S4Yw9VmrAdvcJew+SYc7fWR7jhg=; b=G1SADx0hf1PWuQX4ryh2I0srk87SLw0rt5pU6j6IzFdew2B+QQY11DuVtBKUOeu7eHpNXLT/HJeF6SpqIzAamI7ou/7u9mv7u+s7wvdKo3eklHwOJKIUQigWBnf574M9LmvdEEy8bl6ijjPgOV5hFWZIeRE+Dzrl7l2ily2mJkM= 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: <16fc8fd8-9256-4c95-bce7-b7e696a27601@amd.com> Date: Fri, 6 Mar 2026 10:21:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ARM/vgic: Use for_each_set_bit() in vgic_sync_from_lrs() To: Andrew Cooper , Xen-devel CC: Stefano Stabellini , Julien Grall , Volodymyr Babchuk , "Bertrand Marquis" , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Ayan Kumar Halder References: <20260305232845.62024-1-andrew.cooper3@citrix.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <20260305232845.62024-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: BN2PEPF0000449F:EE_|MW3PR12MB4474:EE_ X-MS-Office365-Filtering-Correlation-Id: be7253f7-077a-4971-75bd-08de7b61c720 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: 8txPSpvFdhEuDIgiTJq6xDQiOpaqBdy0S7TCp5Lb8Z/fEDQKMVSCDutv6u+ZsQWWX01oNYgsgAW3minjRRcgaIzCHdzZk5HbksQM3GAxxtr9nu8ZB7k27fvlGMSJ8e9cWyMnJOgxWcy/APNP127QeB4sPZcTfGN5pP/3QkLbEsvyam8AO1LxyhQqasJhIacbuLT/0l0oyY7gvpMNE/bze+6zr1ueT0iwWGojc8QTxX/XPKHhDKHPm0Pi1VDGg2SPfdGyBBpRMWEELcF+6N6P2HWSvZ6T2THbc1HUFtz4ZMPqDamGzYBk5hlk75UlV4G+QAvaT164kZaia5FaV06T3UzoXan8CDr+Gbwz2a3bdLe0AnH2HrIpq8YoTKRqQNVPIxKmiaxN5bBEqfi9f1CIHfsr/oEZK4XYH7cUPkBimJwBwadjEjAB4hcBasl+nGdnV0owiux7JkJFh1uPBXwIosVvffQTN8gJpys8U47N+DpbyUrogE6hKx7kk4hqKqvg5/zAL3pQco9fktBc++uwD2h5l7wxNpqiDxp1p5iPV7AJwHwozt1PZkXjN4sSpVqQwNa6qqIjO9AkDme4/m6mgsnzZKseRi1Io2idGMc+EDpGidSh7ppnpYuxWOZGua8JzoRlPL7gs4yzf4hGiBD4XDgxfp62BmG6jZ7rmW+60frumocYqFH540o0uSFP4q8XdXFcEfkXXOOnClCNhb9Dg52ealFuf/nDwbAJcPOwlLdIDW+oQCOjTEesi/WxB5OMtHVTOg+ElfTiIp06KriQUg== 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)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: TAJY06CRTF1zFWkjTjraiDMweFeVwcP6ddOScB/337qmEthorD3IDdUNjSj3rFaA6NxbJvlPb7dLo2cHcDJQ+A2TBsioEXWHGNm8svGyhNyHlbDpsdvc8h5ZfXk8CrybzChx3qEAaJMUj1I3NNSN+l3L+v3p5WjPEATjUiytKtQnv6CJINA1SsCKlB09dDZ7jUR9jJ4PsPoXtiX3MO2N3nmEPXKAe+sqZAxl9SZ32FIf6AftcKs+98EAPg8Y38Qi6VdGnLLyuPHj97fh+JbFGa5Ir1u4CGq/yR/zzKFUUjWIPJeLw+M/l10XSHLRKoQrk/XT+xaFMNl3WDGGf5IEIddnJh01hsu+Vty/j/ugyi9YHU4VO11b0K8LBh88bFN/DLXeEfU3++3COBoC/JspF8BI4xPQXKMX4Qcv1A+k5dQWeIEd3956lXKmuXYozQZ5 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 09:21:41.5590 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: be7253f7-077a-4971-75bd-08de7b61c720 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: BN2PEPF0000449F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR12MB4474 On 06/03/2026 00:28, Andrew Cooper wrote: > lr_mask doesn't have bits set beyond the hardware limit, with the upper bits > remaining zero. Therefore, for_each_set_bit() is a better option. > > For ARM64, bloat-o-meter reports: > > Function old new delta > vgic_sync_from_lrs 208 168 -40 > > but this doesn't highlight that it also removes a call to find_next_bit() from > each loop iteration. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Michal Orzel ~Michal From xen-devel-bounces@lists.xenproject.org Fri Mar 06 09:24:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 09:24:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247485.1546079 (Exim 4.92) (envelope-from ) id 1vyRPr-0008Ut-5a; Fri, 06 Mar 2026 09:24:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247485.1546079; Fri, 06 Mar 2026 09:24:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRPr-0008Um-2a; Fri, 06 Mar 2026 09:24:15 +0000 Received: by outflank-mailman (input) for mailman id 1247485; Fri, 06 Mar 2026 09:24:13 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRPp-0008UN-PH for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 09:24:13 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vyRPp-008BQo-17; Fri, 06 Mar 2026 09:24:13 +0000 Received: from [2a02:8012:3a1:0:f0b8:207:419e:3d8a] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vyRPp-001fEE-0R; Fri, 06 Mar 2026 09:24:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=cdn80RzxzOqsgPuCqGcvDiArU6Lg0jBJMFIuE9EfUvg=; b=nrmELLSb1WF/XtIyDxwA41SMQy r2TNJ3JtBbj1Bd6QUTH9+hihAEsTEUEFp+Wx1y076g2ledpAV4s4Vyd+atBfCQImZSdzb48XGttvh Y/WAym3kcrgfYfVSIeP4zept/JpCHPkowdmSktbQGqS939LRuoatKRBe/g+RSHLhyXYw=; Message-ID: Date: Fri, 6 Mar 2026 09:24:09 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS Content-Language: en-GB To: Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Ayan, On 05/03/2026 19:43, Ayan Kumar Halder wrote: > Set GICV3_NR_LRS as per the number of list registers in the supported > hardware. This ensures: > > 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list > registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. > This ensures that if the hardware does not support more than 4 LRs > (for example), the code accessing LR 4-15 is never reached. The > compiler can eliminate the unsupported cases as the switch case uses a > constant conditional. > > 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can > justify that the unsupported LRs (4-15) will never be reached as Xen > will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some > compiler can eliminate the code accessing LR 4-15. > In this situation, using panic() is better than accessing a list > register which is not present in the hardware > > 3. Whenever GICV3_NR_LRS is defined, the default condition and the > related BUG() cannot be reached at all. I am not sure how this is better. You will still crash Xen is 'lr' >= GICV3_NR_LRS. Can you provide some details? > > As part of functional safety effort, we are trying to enable system > integrator to configure Xen for a specific platform with a predefind > set of GICv3 list registers. So that we can minimize the chance of > runtime issues and reduce the codesize that will execute. > > Signed-off-by: Ayan Kumar Halder > Signed-off-by: Michal Orzel > --- > xen/arch/arm/Kconfig | 9 +++++++++ > xen/arch/arm/gic-v3.c | 12 ++++++++++-- > 2 files changed, 19 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index 2f2b501fda..6540013f97 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH > > endmenu > > +config GICV3_NR_LRS > + int "Number of GICv3 Link Registers supported" if EXPERT > + depends on GICV3 > + range 0 16 > + default 0 > + help > + Controls the number of Link registers to be accessed. > + Keep it set to 0 to use a value obtained from a hardware register. > + > menu "ARM errata workaround via the alternative framework" > depends on HAS_ALTERNATIVE > > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c > index bc07f97c16..fb2985fd52 100644 > --- a/xen/arch/arm/gic-v3.c > +++ b/xen/arch/arm/gic-v3.c > @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); > #define GICD (gicv3.map_dbase) > #define GICD_RDIST_BASE (this_cpu(rbase)) > #define GICD_RDIST_SGI_BASE (GICD_RDIST_BASE + SZ_64K) > +#define lrs (CONFIG_GICV3_NR_LRS ?: \ > + gicv3_info.nr_lrs) We should avoid lowercase define, in particular with generic names like 'lrs'. I think in this case, I would rather update gicv3_info.nr_lrs: gicv3_info.nr_lrs = min(gv3_info.nr_lrs, CONFIG_GICV3_NR_LRS); This would solve another problem where you don't sanity check that the system effectively support CONFIG_GICV3_NR_LRS. > @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) > static inline void gicv3_restore_lrs(const struct vcpu *v) > { > /* Fall through for all the cases */ > - switch ( gicv3_info.nr_lrs ) > + switch ( lrs ) > { > case 16: > WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); > @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const struct vcpu *v) > > static uint64_t gicv3_ich_read_lr(int lr) > { > + if ( lr >= lrs ) > + panic("Unsupported number of LRs\n"); Do we really have to panic in production build? Wouldn't it be better to return '0' and maybe use ASSERT for a crash in debug build? Same below. > + > switch ( lr ) > { > case 0: return READ_SYSREG_LR(0); > @@ -203,6 +208,9 @@ static uint64_t gicv3_ich_read_lr(int lr) > > static void gicv3_ich_write_lr(int lr, uint64_t val) > { > + if ( lr >= lrs ) > + panic("Unsupported number of LRs\n"); > + > switch ( lr ) > { > case 0: Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 06 09:26:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 09:26:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247500.1546088 (Exim 4.92) (envelope-from ) id 1vyRRs-0000cS-GY; Fri, 06 Mar 2026 09:26:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247500.1546088; Fri, 06 Mar 2026 09: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 ) id 1vyRRs-0000cL-De; Fri, 06 Mar 2026 09:26:20 +0000 Received: by outflank-mailman (input) for mailman id 1247500; Fri, 06 Mar 2026 09:26:18 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRRq-0000cE-Pk for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 09:26:18 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vyRRq-008BSr-0s; Fri, 06 Mar 2026 09:26:18 +0000 Received: from [2a02:8012:3a1:0:f0b8:207:419e:3d8a] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vyRRq-001fKK-0I; Fri, 06 Mar 2026 09:26:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=XSI1KRPvWn+IVr2eqEcVZv3jMwf0CKUKByCZYDfU0Qg=; b=XphBMuGNZk6E9Gbv0QspeobMMl EKv4qUMmlz0XTWAiemhsO2OBJmeSj6yfRKYAsKR07jiwGxB8v71DoDzuSx1cq4fqKrXk73WOyUiLt fzBbJt7A3/p1wXQBYe6N2WfEMDpFTa7og980Kv7G5RB2WT9xGIEhgD8tK7pbT54ml3m4=; Message-ID: <8eb6322f-ba2d-427b-8da7-c8df3288096d@xen.org> Date: Fri, 6 Mar 2026 09:26:16 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ARM/vgic: Use for_each_set_bit() in vgic_sync_from_lrs() Content-Language: en-GB To: Andrew Cooper , Xen-devel Cc: Stefano Stabellini , Volodymyr Babchuk , Bertrand Marquis , Michal Orzel , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Ayan Kumar Halder References: <20260305232845.62024-1-andrew.cooper3@citrix.com> From: Julien Grall In-Reply-To: <20260305232845.62024-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 05/03/2026 23:28, Andrew Cooper wrote: > lr_mask doesn't have bits set beyond the hardware limit, with the upper bits > remaining zero. Therefore, for_each_set_bit() is a better option. > > For ARM64, bloat-o-meter reports: > > Function old new delta > vgic_sync_from_lrs 208 168 -40 > > but this doesn't highlight that it also removes a call to find_next_bit() from > each loop iteration. > > No functional change. > > Signed-off-by: Andrew Cooper Acked-by: Julien Grall > --- > CC: Stefano Stabellini > CC: Julien Grall > CC: Volodymyr Babchuk > CC: Bertrand Marquis > CC: Michal Orzel > CC: Jan Beulich > CC: Roger Pau Monné > CC: Ayan Kumar Halder > > RFC. This form also doesn't suffer an OoB read when lr_mask changes type. And potentially unaligned as well. On Arm 32, this would result to a crash because for forbid unaligned access. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 06 09:52:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 09:52:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247519.1546097 (Exim 4.92) (envelope-from ) id 1vyRqU-0004rP-Ci; Fri, 06 Mar 2026 09:51:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247519.1546097; Fri, 06 Mar 2026 09:51:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRqU-0004rI-9H; Fri, 06 Mar 2026 09:51:46 +0000 Received: by outflank-mailman (input) for mailman id 1247519; Fri, 06 Mar 2026 09:51:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRqS-0004rC-NE for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 09:51:44 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 116daccf-1942-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 10:51:38 +0100 (CET) Received: from SJ0PR05CA0164.namprd05.prod.outlook.com (2603:10b6:a03:339::19) by CY5PR12MB9053.namprd12.prod.outlook.com (2603:10b6:930:37::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Fri, 6 Mar 2026 09:51:33 +0000 Received: from MWH0EPF000C6187.namprd02.prod.outlook.com (2603:10b6:a03:339:cafe::1a) by SJ0PR05CA0164.outlook.office365.com (2603:10b6:a03:339::19) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 09:51:30 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MWH0EPF000C6187.mail.protection.outlook.com (10.167.249.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 09:51:31 +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.17; Fri, 6 Mar 2026 03:51:31 -0600 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.17; Fri, 6 Mar 2026 03:51:31 -0600 Received: from [10.71.193.38] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 03:51:30 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 116daccf-1942-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bdY6W02NzBT6Ytc9SZmxr3tMC8fDCZfhekFpbTYelh5BIUoaC+UJvSX4Zztp8AaZJJWpCNUb6UIjXlZ5B6kOX3gGItItRo1dtHIbY5DQZ7fei8UMwyCgEjMpARE8+UYW7nVh6li4JThm1ux8i73Gb5OIi/NreBpOwS7oipXVTPCbK6stYeVN4JXkNFAzjFxv6gTmGyXH6+bi5Vg438j2tzvZTGwvDB+Ilh/WY0pFlxPdn7WJYZ7/KYnTsrp6PVsG6BpzeSyaTQyzZJPmSRxhj/Ie2N5702iVqPZ5LnL/e+nSDI8ozcqNmWbpUyZXVnaKfp9Ix5QiF/r8OVByYpLDGA== 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=TGZFDK9QIGeO2suqIMiWdlWd1ku7OPxRvj593QqKcbA=; b=k6wtJNyOO4V9gC5a/GWMxok4WJKxRT+i6/nIlyLWaJKPCaKIVcfr1ZC6pCjVzHmmC+ggPbMyAvp8eEXzWzLb9jngMlTX9uKx5qcHOYcQXBkzh8RaFIBvorjhKf3j1PHZYI09EdcYwadYRG2KbSYzZqxtU9B1Bv6Z7Tyt5gjmLx24ahvU4jwx54CnK8dA+jdohvz7vh40JT9dNYfDwOTAnkUEcKyzgaUBxwqJuPl6B2ROMXYo0sz8nwGMiltEIx1BUirG+BEXOwn+yIJl/N7gym0Y1U47S36J5n+JEFFA2FfMtWIR1fk80g5Z8vmdTrJm2etpO5NLRFhd55Z/L3VO7w== 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=TGZFDK9QIGeO2suqIMiWdlWd1ku7OPxRvj593QqKcbA=; b=xP2mrHBDcQF/AwqU1aYgfjhJwfu+honXdYg2F2visyeAp56coAup/wxfs5+HsmfnMvqtB1R5j2HLSsnvdKpM7AjADq5GjPp0h1pHkVODJZFdvbo8Eomj46FnYgvTigrGLezN3Up1LCwZSipGVXmHKyQ5vWNP7zR/usxvKlThdFw= 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: Date: Fri, 6 Mar 2026 09:51:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS To: Julien Grall , Ayan Kumar Halder , CC: Stefano Stabellini , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" References: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MWH0EPF000C6187:EE_|CY5PR12MB9053:EE_ X-MS-Office365-Filtering-Correlation-Id: d3e4801b-0ef3-4e58-14ec-08de7b65f240 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|30052699003|82310400026|36860700016; X-Microsoft-Antispam-Message-Info: yYnKyjQjRFIOeip+FDQOm2o6LvPgXoNk2ZBgfV7XW9RrPEU6WGOzJ64tSxK8inMOHAYZ/up0d3s6YGEf8owbiEfxoSABbQpZop9cxnWaLrHJ7X4y6eIp7xrFTAMMPfYyW0g3VX2ocwiIBW+68zf8uAXIYJGCmBxXzO4SyITM29qjLBWyNVVCjkutqmqChc4vaMT+qiSwzB8IZSZmJO4rc3TYYnfi0ic0CFm2VQSCZID/EHpHFg8PEWcQAeXotKowi//Ro0SlBqTI+7bfCbsOlOb36u3dkrB0qobICZS2pKjoIeOF8OIuxrC21xCK20OPbQpFnIJgTPqrcAvZ0XiMog/G0Av7OjSFa0r/oa5/FBZLb4RCG0PB93UXlBNS5hboOxBADLPBL0eKYuCQfa1Q97oyxzPxM7B9aYU/AhqXLikgCdQd+9haRhLjHKS9s3o7btXhMzMIZlzdLJBLtR6VAd69jG8uptU6UT6QzYTBSm8b4K11g6RgjPno8KW9TfFdxz8UQ+3wfpd56/dEtpaUWQEqJLJGzX53OGX8LVryFetngGqVcnBM0cEHXUqsjO+QywIIxY32wCsghSXhdIjlnaScyO714Laa5vogpwCpCwVoi6+sFAsBR4riuk0qtQ44igtnVELuaY+aYqBBe3O27sAa/1JCDBBmIg3ds2kr1NfZnvaRlG5nMW86FOas4WD2dLyKgMdll0o5kcd/YUyQzpdovOVcIgCK+jw4npw9f3nNOilgcY92jSZ2nNY13ZGsjYLawI0EfYK/rwK+JOGk2Q== 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)(376014)(30052699003)(82310400026)(36860700016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 3RUc/GLAZ8hKe0yYnEndv4/IOJSFNiSXTBDCxNycPuzj3VJ74pIaSS82X8Cy8Co2Sf9ltbIR+Y1bX8E6jllfVOoYZvb/2Ts4CvtEdnINN/e3FbznUtyh/WdCLjl0lc9AoQywLqK4YYFgWG7c94khK7NQ4Esc4ZxVmNYKRHUCHGW8OE3HYuWF80Anqdkeq+r4M1QQDmjoXxJRQTlRrAkKwDTNjFagZkkvJJVP2WDpmEyRiezKl4El/XVOJJFiq8QoW432D0zAsJpLLlk+1uJYgnvbPt2NHG5BeWAwArOw8Yk1aPPz7dq/lO53pebqP/BZIr5DBy8j5sjc1EREiwHIiOtgMFHmp7JHN/7zxdGRuqrJ0G8VG4SoejaSV15Ulz+CL6l72nwRWxfZm6K/HzAaW3ahrxde7wiChi5RQRNdkgwymxDLyRcFUDy1BdzxiJXq X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 09:51:31.8054 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3e4801b-0ef3-4e58-14ec-08de7b65f240 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: MWH0EPF000C6187.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB9053 On 06/03/2026 09:24, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 05/03/2026 19:43, Ayan Kumar Halder wrote: >> Set GICV3_NR_LRS as per the number of list registers in the supported >> hardware. This ensures: >> >> 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list >> registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. >> This ensures that if the hardware does not support more than 4 LRs >> (for example), the code accessing LR 4-15 is never reached. The >> compiler can eliminate the unsupported cases as the switch case uses a >> constant conditional. >> >> 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can >> justify that the unsupported LRs (4-15) will never be reached as Xen >> will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some >> compiler can eliminate the code accessing LR 4-15. >> In this situation, using panic() is better than accessing a list >> register which is not present in the hardware >> >> 3. Whenever GICV3_NR_LRS is defined, the default condition and the >> related BUG() cannot be reached at all. > > I am not sure how this is better. You will still crash Xen is 'lr' >= > GICV3_NR_LRS. Can you provide some details? > > > > As part of functional safety effort, we are trying to enable system >> integrator to configure Xen for a specific platform with a predefind >> set of GICv3 list registers. So that we can minimize the chance of >> runtime issues and reduce the codesize that will execute. >> >> Signed-off-by: Ayan Kumar Halder >> Signed-off-by: Michal Orzel >> --- >>   xen/arch/arm/Kconfig  |  9 +++++++++ >>   xen/arch/arm/gic-v3.c | 12 ++++++++++-- >>   2 files changed, 19 insertions(+), 2 deletions(-) >> >> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >> index 2f2b501fda..6540013f97 100644 >> --- a/xen/arch/arm/Kconfig >> +++ b/xen/arch/arm/Kconfig >> @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH >>     endmenu >>   +config GICV3_NR_LRS >> +    int "Number of GICv3 Link Registers supported" if EXPERT >> +    depends on GICV3 >> +    range 0 16 >> +    default 0 >> +    help >> +      Controls the number of Link registers to be accessed. >> +      Keep it set to 0 to use a value obtained from a hardware >> register. >> + >>   menu "ARM errata workaround via the alternative framework" >>       depends on HAS_ALTERNATIVE >>   diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >> index bc07f97c16..fb2985fd52 100644 >> --- a/xen/arch/arm/gic-v3.c >> +++ b/xen/arch/arm/gic-v3.c >> @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); >>   #define GICD                   (gicv3.map_dbase) >>   #define GICD_RDIST_BASE        (this_cpu(rbase)) >>   #define GICD_RDIST_SGI_BASE    (GICD_RDIST_BASE + SZ_64K) >> +#define lrs                    (CONFIG_GICV3_NR_LRS ?: \ >> +                                gicv3_info.nr_lrs) > > We should avoid lowercase define, in particular with generic names > like 'lrs'. I think in this case, I would rather update > gicv3_info.nr_lrs: > > gicv3_info.nr_lrs = min(gv3_info.nr_lrs, CONFIG_GICV3_NR_LRS); But we want to enforce the user to set CONFIG_GICV3_NR_LRS , so that we don't have to rely on gicv3_info.nr_lrs. The only reason to use gicv3_info.nr_lrs is for backward compatibility i.e. when the user forgot to set the config and as a result it used the default value as 0. We don't want to allow this for the safety use cases. > > This would solve another problem where you don't sanity check that the > system effectively support CONFIG_GICV3_NR_LRS. > >> @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) >>   static inline void gicv3_restore_lrs(const struct vcpu *v) >>   { >>       /* Fall through for all the cases */ >> -    switch ( gicv3_info.nr_lrs ) >> +    switch ( lrs ) >>       { >>       case 16: >>           WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); >> @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const struct >> vcpu *v) >>     static uint64_t gicv3_ich_read_lr(int lr) >>   { >> +    if ( lr >= lrs ) >> +        panic("Unsupported number of LRs\n"); > > Do we really have to panic in production build? Wouldn't it be better > to return '0' and maybe use ASSERT for a crash in debug build? Same > below. You are right, we may not need this. One option I am thinking is ... > >> + >>       switch ( lr ) switch ( lr & (lrs - 1) ) This ensures that we do not hit the unsupported cases. - Ayan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:00:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:00:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247534.1546106 (Exim 4.92) (envelope-from ) id 1vyRyP-0005ew-8g; Fri, 06 Mar 2026 09:59:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247534.1546106; Fri, 06 Mar 2026 09: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 ) id 1vyRyP-0005ep-5R; Fri, 06 Mar 2026 09:59:57 +0000 Received: by outflank-mailman (input) for mailman id 1247534; Fri, 06 Mar 2026 09:59:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyRyO-0005ej-IV for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 09:59:56 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 37f04371-1943-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 10:59:54 +0100 (CET) Received: from BN9PR03CA0433.namprd03.prod.outlook.com (2603:10b6:408:113::18) by MW6PR12MB7088.namprd12.prod.outlook.com (2603:10b6:303:238::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Fri, 6 Mar 2026 09:59:47 +0000 Received: from BN2PEPF0000449F.namprd02.prod.outlook.com (2603:10b6:408:113:cafe::17) by BN9PR03CA0433.outlook.office365.com (2603:10b6:408:113::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 09:59:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF0000449F.mail.protection.outlook.com (10.167.243.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 09:59:46 +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.17; Fri, 6 Mar 2026 03:59:46 -0600 Received: from [10.71.193.38] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 03:59:45 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37f04371-1943-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qFIRSb8dOb6VtGdXUpOdD7jrgdiAyBPknFGz/gpKUW7+Xg613+WPw2DdLQNdAYOidBUnkS2prE0r4tj/pDnxd5/M8dBqCY7lbnz6V41H7zmOZ6OOuAuINACrJKB+NMXA3QyAAAV5OFJELVrdx2nTVO93NYkbS6dok1SJJatnoZFv7+PZ/+O07sqiyTH8M/dycEN9yiWKH5Ri7AIPxDpSXwSP+KmLPmbAniRObK5b2ZqS10bSqr8r80M9CxLyVLDwcMmJsk4mJ6hKNOfBMSzwjjHR3/oO6Og8Taj23uO6uPBz6GPOua9T36kik2KE37Gzowwax1KHjeLDMoB3pQq2JQ== 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=YV9g7yqxFPl36v3hNmUDn+Q7GAWHyxK5zVvi2luVp54=; b=jw44Osxk92Ee1Vg7zbFpnnOkcc3+Z99TVvSPs22zjUaZ68/8cQYruN4ypL+elDiL5O+xxYDaD7poc+dQpzy7vDkmpMUZS0VcxYmaeXXgSHGqCdwOeLqsp/bp+YW7BbKBGsSXsrWoZ7y9vB9xz6vbGmv4XJK9RvQFMYkvigs6scKSHzZrk+h6wgWoYS88ctpJdXIrrpE3vwWg6gd4s5PQ4lP/RNQzfRwCP7Mo3xesaugFL8ePkYhH7ff6eXpo1xUAo2QjH2Au6+5ESimBwHxr1tYZXV4FzIGJ9bnwVSJ7wvEKOk6veXQi8NHacssCkj1vY2QtfHsRsY2Gz90En5bGSw== 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=YV9g7yqxFPl36v3hNmUDn+Q7GAWHyxK5zVvi2luVp54=; b=amF+t4T1YeiEIX2xKPkxeI77IoKsCO1BWGt6dytJRdlLudi7kaxfqGIyXop4Ga9fQmrFCXbn2SJXbU1FbObPIAb6vHsiJOJb4zp9HrJGkf9lOW3U+JYHjXLFxUYdwop7+S5mNXRHpFqdDoBmVCYcZrP4aACtbjZOy4x0aj2tBwU= 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: Date: Fri, 6 Mar 2026 09:59:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Andrew Cooper , Ayan Kumar Halder , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF0000449F:EE_|MW6PR12MB7088:EE_ X-MS-Office365-Filtering-Correlation-Id: 904d0655-39d5-4101-3659-08de7b671950 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|82310400026|376014; X-Microsoft-Antispam-Message-Info: UOZEYcZvcHZJkq1Cj+5RkdSldx9NvVcb+0f16/ZJZMpUyWNWFqyAxCjfN3iY+vOyoaiXvg7ooZ51CJrExJ03GDVSZOs3m61I1P/ArLnz9KBFlmU94i7x3190S5HD9YhZwjJJTGWdOOnLNsIY1OVJxdc+FWx78PJoJ/y4L1KB3L2bwSyuMKpqDS5UmUlwuCwT8vNDRW3IDQBK1ivI/01nkKdl8cEIpa+Xx9IhNLqufxsfZur7suarSiytzTJ1DpftpTg99muJo4m3BGf1vjeQwaBAiD9BtX76MaWLpfrdrF06oj9lRTop2Ggr+ipj31IgQ5+GXI/hu+GI6D1Jv+NFArQ5c0cVE89sx5nr48qUeqVr/B31kwR9auTsXQ0IM631mAVuUa/7CxRVlbAhnotKXmWn+c1mQ1LoVSXKRlF/Hw5q36JX9fqizTTR3RB8IJOomUcAvjdqgoxqB62IHjJWkQSWskTCjPeC9dg5yvGnH4Z9E8kOa+jX0USO+k8OW5P031lkatI6EFHPqut4KINkcm3aGyQOlLR2s+BGUCwF3zC2xbAoA5RCew0RYuchoNVIc2uzXA91yvD3iiKGiD93mRNCQDPEsUN956jINdBQyAZb6AZqqKpxBY9dwKfIicnpdG9808ZClKsFcLECAVMxSaNlkJ/ze2gXfn5PbT8ALLoAPpbwQasrfJlUg8qQjXNddJ/qEI1Zjqd8ENZdrSMbcrHw14/MUtMWJbvxl6Dj0vHhN+9bha0eGkC2eN1HAnFKeqdBVQ4fRGyVJq424MPEOw== 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)(1800799024)(82310400026)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: uh65oRktFDWH0LCBwlAYQTiWWG1VXDU3L7Ik9hxztVnrD6QLgsnvlFUH/E0eYLsJMhfedFLz5JjOazGwcEt/IbpONAt1ejhiBgrcy++k1eKC+a+duLl6LSLsIwQy5I2XWMvyazdQiBvkE5XzYk3Ei3T2QT+bhu4JwH4Du2I5Vo7Ml9NsQ2I62nwHOgeJ24C93RjthdxWh0tjxKSeeho3OD3IfnU7Z0NbUeipSlvgUGu8didc4l3ltR+Vl7Gk31lWNLyiQwdEJxIV68wTY4ADPvz170TE9mIXXgGE5TzECFphx5w53tBxY6HJ8V9TFTVWXcBevcmGCtORjY+LE4004OEtdoxn9rFZObVCA15h9qG1bYXARRC/SM9hIhs4yXFZU6R7G/fugPM6X0UwdU2MM1qT0kGd+VoMPY9Az9cerP78SoRh0KekgVvu8LbTlIlJ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 09:59:46.9301 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 904d0655-39d5-4101-3659-08de7b671950 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: BN2PEPF0000449F.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB7088 Hi Andrew, On 05/03/2026 23:01, Andrew Cooper wrote: > On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote: >> The lr_mask bitmap tracks which List Registers (LRs) are in use for >> virtual interrupt injection. Previously, lr_mask always used uint64_t >> (8 bytes) to support the maximum number of LRs across both GIC versions. >> >> However, GICv2 and GICv3 have different hardware limits: >> - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) >> - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) >> >> This patch introduces conditional compilation to optimize lr_mask size: >> - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs >> - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs >> >> With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() >> cannot have a value > 15. Thus, it should not possible to hit the >> BUG() in the default case. >> >> Signed-off-by: Ayan Kumar Halder > What does this actually get you? > > Because it doesn't actually eliminate the BUG()s you reference. As lr is obtained from lr_mask, see the snippet from gic_find_unused_lr()         for_each_set_bit ( used_lr, *lr_mask )         {             struct gic_lr lr_val;             gic_hw_ops->read_lr(used_lr, &lr_val);             if ( lr_val.virq == p->irq )                 return used_lr;         } If lr_mask is 16 bits, then used_lr should not exceed 15. That is my thinking. > > If you really want to go ahead with this patch, then make a  lr_mask_t > or the right type and don't double-code everything. Ack - Ayan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:02:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:02:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247543.1546115 (Exim 4.92) (envelope-from ) id 1vyS0v-0007D1-K7; Fri, 06 Mar 2026 10:02:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247543.1546115; Fri, 06 Mar 2026 10:02:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyS0v-0007Cu-HG; Fri, 06 Mar 2026 10:02:33 +0000 Received: by outflank-mailman (input) for mailman id 1247543; Fri, 06 Mar 2026 10:02:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyS0u-0007Co-Cg for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:02:32 +0000 Received: from CO1PR03CU002.outbound.protection.outlook.com (mail-westus2azlp170100005.outbound.protection.outlook.com [2a01:111:f403:c005::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9591fa2a-1943-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 11:02:30 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by LV9PR03MB8440.namprd03.prod.outlook.com (2603:10b6:408:377::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Fri, 6 Mar 2026 10:02:26 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9678.017; Fri, 6 Mar 2026 10:02:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9591fa2a-1943-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UHRB4tOHW8NkU8SE62QanmkqP14nmWvWPwhtYJo9PYcBWmrP/WBPen2G8OiE9NCMsadBBrMskVWsohTVjGE4eeRCSl+IJvl7Mox+76635D06frJmXILETd+VCxbG67Q5NFUT7N6R4QzBp7h7K8wkHs8QBaiAx6GoF4PN3KO8Q/Uxu5c4JCkcLTbBx/IctBXuKj1bP8h+Gay2qb8b7QEXKdRHc0Isqmie///IU6/tNHe9epuAYr8WVL0/jalkc5u/yeJ7A88QwJvcIemsuock4jv9KuI6xEW0ar1VC7AQULMIUqz9z2kg4sN9eE3eU0FY+eMSYgJSnHSA5av6t9iemA== 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=D5hzusVCfC0hMW+mRZ01vIshdf1XTGt3KIlNr3V9kfM=; b=Mpt85slZvWSkbZdrm/zE6NTLI8h06TgORQkLwSgBrXd+xQKDLet/oiL9xI08sASUzF+VAtV7sR4uLdlj2VpY7aJUL08fg4QOL7Am251nbKIWr9E1/a623r+33Za4jStaAF4bqYQWm7w5k8+u3HIJMGWVvHNxjvU6/+nFQeWQ+o5xZOmdRWFrxbSkTbJMRMb6p4mGQmhcJ546P27FPKfQTmJrGDAiA18wlP8l8t8Cj7P49zG6Xy//KVtgHPS2ty9X1KeTBcXvSNutLe6P0+6pcRD1KOe6Rs7rRZglEgjEkXBq897GrEwNhxL0Iq+VaLwxNrrYvhR7FUDfk8OoZPrfNA== 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=D5hzusVCfC0hMW+mRZ01vIshdf1XTGt3KIlNr3V9kfM=; b=T+ElyaP8PcqFI08SQIyRJwEt5nDVvJ38yDzB+SJeMKuJxnEKaVQA8kmSP1c70nGegUcSCPsUGagELJ6Z+aiuVDb+LSlkUB7M4RFCx5TaFXZcriqWqjB5ViygtsfjAwv01APnL0NSJxiYSOszNOE11pTc+xpFkWpZFGq3i6LHeSE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <03c91d39-86af-43c4-a14f-c6514b778344@citrix.com> Date: Fri, 6 Mar 2026 10:02:22 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: "Halder, Ayan Kumar" , Ayan Kumar Halder , xen-devel@lists.xenproject.org References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P123CA0075.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:138::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_|LV9PR03MB8440:EE_ X-MS-Office365-Filtering-Correlation-Id: 3c9f36b1-7463-4df6-9000-08de7b677843 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: aPXok5+vfju6rsWsidpcO989lkNYcwJ6dXSJTAY+bkTujqFj7sTrvTZyqed9sSWE78NLQJ37xoLPReD4Jptnm0NTXac5GRm5zQz9URdDf2iNXr7MsqvIF7QiS0Jw9OvkuBrvepr0nSjZhJQrm1h4JdmAFvkaZVa/EWGnr1DkZXYrK/SQbzRuLHccvZax71l0EVCiYt/jC6z954Lru4ovR9cq/ec64THCCbVI1lUEQire70/Bzajdx3cEv6/Du9VOYL19otNupBADKbw61B7XgoyaIq5qLy6o8yZE0s8C+KIEVeG3hr8K7sVz+Jc5FmsmPDg44CI+bUDuZCzKXJvMpExFFr/l5O1tOYO27hiBfwl+eda4QVLUcJdAXlOYrLW02+SSGYvi16gDIaYXEVxORQYuM/7dVpDbjEpBxtUMmk6dZu60XPYGJnovmri676o++jtk2A35vjXcbJlvpZ7DORM4HwlzYe4qiR4hCaQgCvqFexSmavLmfEyc0YmVyseEqob7DC1Vv/3RRxp48p/GErAPRGYVriBy9SbyU8Oc4grsGb0GsEFm7qaFXo6rtNVLhXFIupoKTheFBPNhIkB165nSuGe9I/7EjcZYtQHT0XL7B5QfKEZNg4SE+HISr0ZnuA8hg/5hvnev4DP1Zk8RLjseQSE5pSBiwo5IjMONd/06gUPu7JZfpdABjZKK/YsyeIIMcdO/nvCHbDhdoEWA4V8oKAt9uUAAgfaPHL95MgA= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aWlaSERWall5MCt3Qmo5WnZQTHVCeUc4Njg0MGNMenpUREJPTFpxNURFeVFr?= =?utf-8?B?WWY4V3hyN0doek4xcGxjZ2R1cG1BVGVQV2xudmp4NlBQeVpzOVpxMDg0NzM5?= =?utf-8?B?Y0QrTkQwdUVoUWVLOGJVOFNkYzFhN2ZuOWE5ZDhpai9vTnFyNlpZZTMwZGpH?= =?utf-8?B?b3lJZHNjZUNGcmg1Zit6TG94Z0hzOFMwbEQ2djZnY3FtbUJ1dzZ5aHI0NVFi?= =?utf-8?B?b3hYbWdOOGZ1UWlqTnZFQlVWSEovS3JiSTV1VkVYVUdvdGwrK2xZd0JLaXZ5?= =?utf-8?B?dHhLcm5SYlliZTNLR3pLNTg3UVRWL1Z3aE9jdmVoTWZOT0lqbkxZUm9mMUVp?= =?utf-8?B?d2Zmdm9QRVRzbFpFN1hjRk4vdngvVTRSNFJxekJVSkMzcjUyTjlGMmdKTUdm?= =?utf-8?B?Z1lWUnM3bUJlVlRFL2luVXB6ZG4zNVZ3bGE1VUgrQWtOY1Azem1XaTdENDh4?= =?utf-8?B?eXVZeUNWTytLRUp2UDVIaXpGZGtGV0RKcFZkQ0hHRWZPUk9HR3VkWFZMaWJi?= =?utf-8?B?bHlCQjU3NVZsVmFuM1RlMytMbTZ0cDNycE5ka0k2SG5Uc0NIYVNnYmVWVko1?= =?utf-8?B?Q0VUc2NiSGVxalk0MTZ1eDU1S1F0bFlNSkJ2QXM2K3M0MDJ1ckw4b0VWM2E2?= =?utf-8?B?VEZNWFFmSFNaVlJwUnJXNG9aUng3T2xqMUsvY2o1ME5hTS9zRU5sQnRNNncw?= =?utf-8?B?ZWVwaWRuUFhRUk1nZjFJWlNpanVOTmVhQUZXeFNZY3JpRnlFY0RjQkZtSUF6?= =?utf-8?B?dCtjamdhQkJXbmZmTEx0TmJnbzlRZWhZamRPcDRLSmY4Q3REMjBHZm9NQ2Ro?= =?utf-8?B?ajk3Y0kwR0F1d21HSDdsbGQ3OVZxTk9UcWlqNVAzSldYOHJiQXU4Y2UwNG8r?= =?utf-8?B?TFhodGplazVFN2hCMUxQcXRlU1pkSkRJaERPTVJpY04rOGhQTXo4TVNyS0dH?= =?utf-8?B?UzR6R3dvM0xKVGZYbzNYZktyeWlRS09TYzVjMko5dFRMczZVNXhkM0F5aXg0?= =?utf-8?B?M3hqeFgwdExtQXhZZVhSUDJ5anE4aGhXSTRucDF1UDR3N0cwNnc5UlN2dlF5?= =?utf-8?B?dUJCWnp2V0RmOGcwY1NIbTNONHliQXVsQUZiQXczYi9oVXpIR2lRczE3T1FR?= =?utf-8?B?Z3J6TTJZNGdUSmxBbklLc1hPdHVMY0xlNWs1RGFNa3JOME9ETXNsUm05RnFi?= =?utf-8?B?SFhWTFhrK3orUGQ5S0JLR3lMTnBtcEVPdFNvSnJBTUpnSHFmZDg0K1lXcm5K?= =?utf-8?B?aGVXeXZBN2Rza1FtY2xHNlFTa2FqY2MrSWdDZ3lHYkFKUmQ1a2hGZHUvSnVm?= =?utf-8?B?TFk2cFlIdXQ0UEpyejVWOUxPOGdiMVd5SnJST1l5YXllclB3dks1M2RHSHVU?= =?utf-8?B?NHJNRlUxZlBXZ29zWlplQ0ozb3F6TFpIMDRXSDBLanpaNFBoYWRzeDlVZVBE?= =?utf-8?B?RmdpMmJZUlZDVlZJL3c2R0ZuMGNVSEZQSCthRURxNkQyL0JJdDNkRi9IYURG?= =?utf-8?B?UVBnV3ArZnpjZ3hhSWNqYUMwL2tqWWRLNVNTVzJwbFVUVldxejUwUkZIUGF4?= =?utf-8?B?UjV5RmNmcGdERzNTbUNtS29tSGhFUElLZytHODAwY3J0ckhKc1hOdHNvUkN5?= =?utf-8?B?TVBBdzVrSGZrUEdRT2licTNYQ3hKaEloM2VHSzNCUnorVlI0SW9QY3NaVzZw?= =?utf-8?B?UE41WkhaelJQQkJCOUkzSnA4QUMvSjFSMjJOMEMvOFA0c0hobEtvbE53a05z?= =?utf-8?B?T0NQa2RLOU9tdWJYUzYrdjJZS0FOblp2UEJ6eTA5TXZET1R3UUZvWk1nY3g0?= =?utf-8?B?L3U1V2t5WnRUSVAxTHB4dWhFckVuME9aelBwMDR5dk5HZGhNS3VHakk2Ykc1?= =?utf-8?B?ZGVsbU82ZmRLL3pjT2pGdFVxdXVPVm0ySmtQdjFUeVhzK2xxckM5K21SZUFK?= =?utf-8?B?ODdCZHZIRHpzTm9NaTJYRUt5NStPNm5vdFpkckdkUzV2czNPbVd3amUrRUlv?= =?utf-8?B?dWlpR0VoQXNtMEFqRkRzaGFMUzFJSDFmR0RDU3A1aHZzUk9EOHEyc2l6emxC?= =?utf-8?B?TTh3bjRZS3RyWGl3dmJ1Tnc2VFNYcXdTR1dNbFBuK21Ub2lNbi9UNXpIRGFB?= =?utf-8?B?M1dkeFRHTEtnUWliYitKN0FaZFdpdXlhS25oRGtXUmVobDVPR21PY1BZeStu?= =?utf-8?B?WFErMVhQSTNQZUhnZ1RQK1lGUHNkb0pOVHgvT01rWlJLalFINWpyY3NRYlQz?= =?utf-8?B?NU1xcGFwalNjcVNObDhmWDNqSTNGS0lsNXR6TFJtTVJ0MHRJYjBtMXFaYnRB?= =?utf-8?B?U21iMVg2TmJ0YkFJY0lwQ2VIYkRrLzJLUXdFMkFHS1VCWjNrU1Mwdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c9f36b1-7463-4df6-9000-08de7b677843 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 10:02:26.3661 (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: 0HPPeqjwUpsb930aQ/lxv95JigdMnuihVkqegyRmRX7mHL89K87uXI6bSEGMc25SY2uwc70JBqrzVAmr4wh/C+bdnN4BOx3bt5VdCljlH3A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV9PR03MB8440 On 06/03/2026 9:59 am, Halder, Ayan Kumar wrote: > Hi Andrew, > > On 05/03/2026 23:01, Andrew Cooper wrote: >> On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote: >>> The lr_mask bitmap tracks which List Registers (LRs) are in use for >>> virtual interrupt injection. Previously, lr_mask always used uint64_t >>> (8 bytes) to support the maximum number of LRs across both GIC >>> versions. >>> >>> However, GICv2 and GICv3 have different hardware limits: >>> - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) >>> - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) >>> >>> This patch introduces conditional compilation to optimize lr_mask size: >>> - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs >>> - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs >>> >>> With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() >>> cannot have a value > 15. Thus, it should not possible to hit the >>> BUG() in the default case. >>> >>> Signed-off-by: Ayan Kumar Halder >> What does this actually get you? >> >> Because it doesn't actually eliminate the BUG()s you reference. > > As lr is obtained from lr_mask, see the snippet from gic_find_unused_lr() > >         for_each_set_bit ( used_lr, *lr_mask ) >         { >             struct gic_lr lr_val; > >             gic_hw_ops->read_lr(used_lr, &lr_val); >             if ( lr_val.virq == p->irq ) >                 return used_lr; >         } > > If lr_mask is 16 bits, then used_lr should not exceed 15. That is my > thinking. Sure, but what does that actually get you? It doesn't get you a compiled difference.  It can't DCE the boundary checks. So right now, it looks like it's complexity for no gain. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:09:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:09:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247553.1546124 (Exim 4.92) (envelope-from ) id 1vyS7g-0007z1-AG; Fri, 06 Mar 2026 10:09:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247553.1546124; Fri, 06 Mar 2026 10:09:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyS7g-0007yu-6X; Fri, 06 Mar 2026 10:09:32 +0000 Received: by outflank-mailman (input) for mailman id 1247553; Fri, 06 Mar 2026 10:09:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyS7e-0007yo-Q4 for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:09:30 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8f73b3a2-1944-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 11:09:28 +0100 (CET) Received: from SJ0PR03CA0150.namprd03.prod.outlook.com (2603:10b6:a03:33c::35) by MN0PR12MB5713.namprd12.prod.outlook.com (2603:10b6:208:370::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.5; Fri, 6 Mar 2026 10:09:25 +0000 Received: from SJ5PEPF000001F7.namprd05.prod.outlook.com (2603:10b6:a03:33c:cafe::37) by SJ0PR03CA0150.outlook.office365.com (2603:10b6:a03:33c::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.19 via Frontend Transport; Fri, 6 Mar 2026 10:09:24 +0000 Received: from satlexmb08.amd.com (165.204.84.17) by SJ5PEPF000001F7.mail.protection.outlook.com (10.167.242.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 10:09:24 +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.17; Fri, 6 Mar 2026 04:09:24 -0600 Received: from [10.71.193.38] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 04:09:23 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8f73b3a2-1944-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=q2ANtsmAhGm5saNCVHZhxaIZAha0vB0Iza8vb455VHPsvnQw0vupi0tJp3fkRMmiikjcIayxErN2PQTH2tG/DPik4xG9XPVJKJmZHDl42sSKA1skYdi4e2JnCKm8NWyVwHH50c+yoMcugB8kbFmPt6F1rAOdeCs6KCympEEZvXetlAbrrLzZgldQc26HKyRkCpqc0vPDgPOCvA5Tas4sq0FGPPKE7Z2EO1OvuK8v/4ZBFjAUu5dFkUr1M58EQQUOmRQ4zTVr091EVtkHKFs4yXxwCEUL74/jFoavD+muuzvNHgtkXXo41ANQGWYsHJKkrSyQDuUIGQnoHnQxcX8vnQ== 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=BTl/AVZ79RDhARblpBSb1gPaxCHhIt1OecVzUzfMbPY=; b=gBlRBtmkMnwMLMA3BcrvrlzDWZlb3ofSZtwXSCS56cjiRjrPvuhHGQJH4kujXFOcBQjwLwN826NE++oQJKCfGLyrvyJm/BRoxgv+SOwrZYUx5eXcBWLuxSHIc9CsHx/IiINp1fUDhOmz8PQpCspExlqSPTUPnTm7FiqA4cZwlCI+UNj8h0oRJaJF+9jc1+9CsmP+C7CnsMGUofJAAjMemPFvu5tDoLK875HYKJA+yf9HBJxI8A1hBW1OtrksNPWE6PSJe7Kf1BwpkWNp3/T7JmHmYmilRMCO2Xi0mDQ2Yi4uh/OdroK8ySdYVIipMDPuWxj17sZ5iVkq0r2b1Om7Lg== 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=BTl/AVZ79RDhARblpBSb1gPaxCHhIt1OecVzUzfMbPY=; b=B7wvYOki1jkH0FFBkCmK3idhygdwzME+0YEQc/P4/Wni1GSQApgXT3VbgmnKV86jYnPzPHjC4IvdQ/sH5SR4sK/W7wZ5rh5Ywm8sihBQssjkJQQLjcQAYJ6h3jGj9AoNLqTPauoFn88mYLsEOKw9kYYsPgi51/v4XLIy3qmkT/I= 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: <0f775788-2637-4cfa-8ab0-a1e60d4d470b@amd.com> Date: Fri, 6 Mar 2026 10:09:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Jan Beulich , Ayan Kumar Halder CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <9e222b10-f63a-4a5a-981c-36c438e3071c@suse.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <9e222b10-f63a-4a5a-981c-36c438e3071c@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: SJ5PEPF000001F7:EE_|MN0PR12MB5713:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f4d6043-b437-40b8-7879-08de7b6871a8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|36860700016|1800799024; X-Microsoft-Antispam-Message-Info: DS+jI1d7Ji7u6WqtxCicV/VRsvlXPBte6TlhInjE97FCFlWUzWjZXP6BGyJz/4965fMK/MwVNJjsvaifZH86Fgc1qbPGXc2Yn1gEURODOClR87MJq4L/3ki20yk/MbbqbjV02IcAoz7WZXAjHmXO+/Rs4avxTwsGICVFgV5xXblXEt76d++oouTcsVMrbWjC2qUjzw9TyW5atBcF0FKMtOBbPkvGeYrBZmHl/pSIAjYGNm2X7Pn8J2J+A1AaM0MKxK42vi/wLIlcqr3sE8FMxd0EDnswtN1W/j3H5zZHq8v/nIuDXo6hhzUV3Oj6ug02pNTIW3JxYz0Xwyk7tg8ws4r793OmEmugS9MJIfi+SKPw/D7QVqeBC6onRD28JuIK3eUhZFKzztQAgz8/wV4A2M432dSCPZ70EUZ2SQbWyJZlq2LaBvqQWRNI6psRZ56V0x2WP/FckpEPX/XgPb/N65XZEKjdeRvazU+b/u2+bYHcT1bXgAp88TJPjzqmzecH4OL75mFWVhiqlkDzUwLA5pgkBM3LHHpXYEOEoIahfKuCqVYwYbI23/P8bxSZihbF1Nj5v88UWU0yT/Wg5LV16M6sZGebZLYe8zjPjMmJ7F6b4Gvq3JA4Rmcs8oR4yzAjyGBTE8bxAQOTfInxajLTIUZ9IxD4FPZUEuE+WsZf3+QDs0tj3H9lN//TZUBBVzzLz3Na5/e7QEKmudLu78I172vA6qL4hy9jw/4LDGNiKIFka0prPORLZft245aJHPZb/56sMSEF7Xyx4OuH5UXt1A== 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: EvgVA6yRrkWj8X1mFE6dQZvWxQ+JgOTlASpKKC/TN6rrkgvYaEmKdD3zNHI+MWwZTb36NeiZZCdwhPAm8ky759BLW1WojZ9Y0RcQLYPATiFJA6b3MXIeX+klhV6Hs+Ni83gASdk2e6KU2yOurhMEl0eJ6NnZ9tacOuSddaVsIn/Cap/M81zRMEsutqHbXXoUjF/lJCOEJgHM1Q3Nj/uOHbHXSRGS7HPEG/xy1j2qeWq/DpWsCI3EkBCJt8/eqlBqZjwhF9NJa1+ieKK9eFbs1ZCdi8YDGSLnmju5+E12j6IybORLCe2J7Bnx+TH5jnrDlQ//XQJDye3cg6nAPTx8AeA1DZ24slU58BVazChtTm5xz+IGfbHkNhKHnF6b4zcBXtXzEfg9AeEy4BlWm8j+SD5jGGceymDF5LBSNqQ7OH/ME3P3D+ksOI4gbthxSGc7 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 10:09:24.5774 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f4d6043-b437-40b8-7879-08de7b6871a8 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: SJ5PEPF000001F7.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5713 Hi Jan, On 06/03/2026 08:49, Jan Beulich wrote: > On 05.03.2026 20:57, Ayan Kumar Halder wrote: >> --- a/xen/arch/arm/include/asm/gic.h >> +++ b/xen/arch/arm/include/asm/gic.h >> @@ -237,7 +237,15 @@ enum gic_version { >> GIC_V3, >> }; >> >> +/* >> + * GICv3 supports up to 16 LRs (4 bits in ICH_VTR_EL2), can use uint16_t >> + * GICv2 supports up to 64 LRs (6 bits in GICH_VTR), requires uint64_t >> + */ >> +#ifdef CONFIG_GICV3 >> +DECLARE_PER_CPU(uint16_t, lr_mask); >> +#else >> DECLARE_PER_CPU(uint64_t, lr_mask); >> +#endif > But GICV2 and GICV3 can be enabled at the same time, at which point you'd still > need 64 bits, I suppose. I see. However, a safety certified Xen which is meant to support GICv3 hardware, will only have GICv3 enabled. IOW having both GICV2 =y && GICV2 = y is out of scope for the safety use cases. - Ayan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:18:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:18:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247566.1546132 (Exim 4.92) (envelope-from ) id 1vySGO-0001JP-6v; Fri, 06 Mar 2026 10:18:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247566.1546132; Fri, 06 Mar 2026 10: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 ) id 1vySGO-0001JI-3y; Fri, 06 Mar 2026 10:18:32 +0000 Received: by outflank-mailman (input) for mailman id 1247566; Fri, 06 Mar 2026 10:18:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySGM-0001JC-Dz for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:18:30 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d13999ba-1945-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 11:18:28 +0100 (CET) Received: from BN9PR03CA0610.namprd03.prod.outlook.com (2603:10b6:408:106::15) by IA1PR12MB8312.namprd12.prod.outlook.com (2603:10b6:208:3fc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Fri, 6 Mar 2026 10:18:24 +0000 Received: from BN2PEPF000044A4.namprd02.prod.outlook.com (2603:10b6:408:106:cafe::87) by BN9PR03CA0610.outlook.office365.com (2603:10b6:408:106::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9654.23 via Frontend Transport; Fri, 6 Mar 2026 10:18:24 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BN2PEPF000044A4.mail.protection.outlook.com (10.167.243.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 10:18:24 +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.17; Fri, 6 Mar 2026 04:18:23 -0600 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.17; Fri, 6 Mar 2026 04:18:23 -0600 Received: from [10.71.193.38] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 04:18:22 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d13999ba-1945-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JsMPAvc714BoDP31KokAY6Hchxukt089s6vIp/SqO/DqMWGuVKwIiH1eQqxcUMp+I5LTQw4MTZ64LKhhIF88p4AlGdNN3mHt/UxC4FEZvcTJMWZXQT060MSFu1i030MlR9rfmUkRhig3iPoRKkEwRApmxyA/CFq+22iH4Y9hvOmcwCamqEMy4ygbhJCGQGEfNbClkIMdAe1smXpLxMC8YpuM85G4WnDuxjzpMSNp4vue4GSxmMVD2gz1irHBIwSOlN3d6C8TKoSeYqOJrhIdRzNxwkPMpIbbhzyDZCk2xARJJjcfAgMsyVajMTM9GuGrm79N0y/udnOuI17rl3qBOQ== 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=JHJpJPaHeMHdAig7u/9nZjXOciwLCEHjlAbgze5OIEU=; b=E2bmtWgfoGARZLv+97nr56GW0YPLKXWOWWErD2ewoVsyVEblMyjh5YKOu5DNsUVwM3iPVep+ESEWnPOSOIfVpL1sodZBjc70VtbMTJHzvh4GLmEorPlA2qdiWC/p9zeXB/iSyX0oieOaNMDJIf0pRQRUuLg3q4Z+HkKiVjXQ4m89rzmObEpu6LS2oawS6yDXhhG1bkNlIvBYzlwTApoexAlnrqU/Bl/fKlmAayOua/aA8QMRZZhotciE5Y5Rb1aALENMIoeAqD2OLWGiIbEitcj+PbuNTgDyp3i9kzljQI5435nSreu+6poN2xmP0VNBaUTWlhZYc3F+NA8wcC5Jcw== 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=JHJpJPaHeMHdAig7u/9nZjXOciwLCEHjlAbgze5OIEU=; b=J+PwdjOBGUE9TcMCntrvBzGUNQlucsW3rZwMgwhIuMeGjn2yiE7ttG/pfBCnojFbzi7wnTXNT6Nsn7QIrODDxCbEbnnSV+ojZOcS2J1d8uN0mSm+4DzckkgXeE/x39Ka1X3uhX7GtP75fy0HDyaTWSPq4DdCzcTlq1Mpgu4Uui0= 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: <35c87e08-9b4b-4d1b-841b-17273aca4ace@amd.com> Date: Fri, 6 Mar 2026 10:18:22 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version To: Andrew Cooper , Ayan Kumar Halder , CC: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <4d81d177-f1ce-49e6-8a40-fd16c0b4e0b9@citrix.com> <03c91d39-86af-43c4-a14f-c6514b778344@citrix.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: <03c91d39-86af-43c4-a14f-c6514b778344@citrix.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN2PEPF000044A4:EE_|IA1PR12MB8312:EE_ X-MS-Office365-Filtering-Correlation-Id: 339dfdcf-e850-4260-1065-08de7b69b339 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|36860700016|376014|30052699003; X-Microsoft-Antispam-Message-Info: DaXK4007siBxVnfx6k/XgrbTGfuN6teBRp51osLVNEdu3mCVQaj3axOUuD1qRb0D1mIs0hY/yBAyq+tfk/b1oREcD0y9qCFlsKXn+OTYKcMHxtvS2PGYCImK3de2ogOJQ1KnbRYxaKd6RGpzS/npa2YO6cT3GjveWQNojKgLNYETPxkS8LWxvcBD5idwasmRwRQsN/qHpT9obWNf0Ye4kV+AUgGuuWztqvP8LPQZFv+Ql+4bJnq72qAp2G50P32rDHTXk2pu4YRlMmXOSolj4RavYWPxZnv46m7Y5Ju3Cs9xIcTKWAQwJ6jOz8l4myShufiUsvssJ9oxUbI36wBOXaA+ZXGajzzQ+co6aBK93TWDjcTU9KNm59CAeotExWSY1WYXXgYSEyzGh4aESPx8D8hPvbrFNtq8DHITkKSyUSaeRli9SYco1TUqTyu3RvbBv/hxP4qdQkkl2PYhACSaHGomVeTJB/UeZkdWehaG+kbS9nOh9Qm8DGSJbuk39hc7e8UH1k5OZgbJKdsuGWK9rngYqt5ColdJCXsd0KdBr25BHZACb3FrSLQC3mzZ2LJdbw2zT9xudUIpI69rBaKDfbvbMTf3lt08YeROrYDmW+2QkkRxsh8Li25rnjeLXkzvVKfHhomoUjrvvtWGBTHx72vQmrrL+PyjCArlF8Uf3huYWpFNULDRKJq/TXyS69QR3SGqdb0MI5CA7BjtQVYWcLnldgpy2Xfi/1JmsMR9g/lmpL3V8beSFmDhmxLHbeBlhiAST33Gkbc8Qr1zHlVieA== 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)(376014)(30052699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: NElyCCOjy9YVKapH6Kov+1jW3eb6JrYRm74fUikaVLKFcb6P2Ji9L4YaOgV3sFh6Bv6+tRF3Gx/ARz7oKyxo7BiG0UZizmARdkMoBTws9RZ1MJ/fyN9riPGWVwSDhha8YmoU80FGHdS5UmTK5k1tGB/CejRVyB7CVlsZuh/TpvoDylhAqN7VAKBJw6s/1HQPmiYIsgtWJAVFYDBihQ4oyPEcNh8W96BeJ1rFC11h6hxx2SmDhgvMG5bRqOIG3x9eKRclT8fMpT7QK+nJyLKSkZv/OKvORD2aVi640kiwXkf/5l9EEbdEVC5jDfB8S8KfAtNgrWJLDmNklidbZ0odA5/aelWkyI79qwCRFrqRBkjZzLJxdqWL92JEWNey/+ICSq6AFaXK9aan4le7o3sovwdhcJ8uavm3RrhP0mIFzzb81mnle0fhuHF0vxkwyVz0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 10:18:24.1402 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 339dfdcf-e850-4260-1065-08de7b69b339 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: BN2PEPF000044A4.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8312 Hi Andrew, On 06/03/2026 10:02, Andrew Cooper wrote: > On 06/03/2026 9:59 am, Halder, Ayan Kumar wrote: >> Hi Andrew, >> >> On 05/03/2026 23:01, Andrew Cooper wrote: >>> On 05/03/2026 7:57 pm, Ayan Kumar Halder wrote: >>>> The lr_mask bitmap tracks which List Registers (LRs) are in use for >>>> virtual interrupt injection. Previously, lr_mask always used uint64_t >>>> (8 bytes) to support the maximum number of LRs across both GIC >>>> versions. >>>> >>>> However, GICv2 and GICv3 have different hardware limits: >>>> - GICv3: ICH_VTR_EL2[3:0] encodes LR count -> max 16 LRs (4 bits) >>>> - GICv2: GICH_VTR[5:0] encodes LR count -> max 64 LRs (6 bits) >>>> >>>> This patch introduces conditional compilation to optimize lr_mask size: >>>> - CONFIG_GICV3=y: Use uint16_t (2 bytes) - sufficient for 16 LRs >>>> - CONFIG_GICV3=n: Use uint64_t (8 bytes) - required for 64 LRs >>>> >>>> With this, parameter 'lr' in gicv3_ich_read_lr(), gicv3_ich_write_lr() >>>> cannot have a value > 15. Thus, it should not possible to hit the >>>> BUG() in the default case. >>>> >>>> Signed-off-by: Ayan Kumar Halder >>> What does this actually get you? >>> >>> Because it doesn't actually eliminate the BUG()s you reference. >> As lr is obtained from lr_mask, see the snippet from gic_find_unused_lr() >> >>         for_each_set_bit ( used_lr, *lr_mask ) >>         { >>             struct gic_lr lr_val; >> >>             gic_hw_ops->read_lr(used_lr, &lr_val); >>             if ( lr_val.virq == p->irq ) >>                 return used_lr; >>         } >> >> If lr_mask is 16 bits, then used_lr should not exceed 15. That is my >> thinking. > Sure, but what does that actually get you? Right now, it just gives me a justification why a certain code path (invoking BUG()) will never be executed. My aim here is to reduce the chances hitting this runtime BUG(). However ... > > It doesn't get you a compiled difference.  It can't DCE the boundary checks. if there can be a better approach, I am open for it. - Ayan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:32:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:32:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247583.1546143 (Exim 4.92) (envelope-from ) id 1vySTj-00042P-At; Fri, 06 Mar 2026 10:32:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247583.1546143; Fri, 06 Mar 2026 10:32:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySTj-00042I-71; Fri, 06 Mar 2026 10:32:19 +0000 Received: by outflank-mailman (input) for mailman id 1247583; Fri, 06 Mar 2026 10:32:17 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySTh-00042A-Mj for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:32:17 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vySTd-008Cpu-2G; Fri, 06 Mar 2026 10:32:13 +0000 Received: from [2a02:8012:3a1:0:f0b8:207:419e:3d8a] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vySTd-001jf1-1V; Fri, 06 Mar 2026 10:32:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=n2AQlK3H/NFh5jofcWFAoU3IfOBmTD8L1HI07DoC2Lg=; b=rgh54blBDGiLEWYwioO3k4AFbF BjNOpd2hSzOraBZHZdYU59MTgiPfX+E4Dueu5z5fcCMJMrPZf8CcBF+uXjQuzKwLmNVQO4BBfehXQ OwH+DMTj+JYyncaDUZ+O5bJbC+FDQFU03tjQazMvcmzh9/HHLaxXJzfyA+9aqSs24juI=; Message-ID: Date: Fri, 6 Mar 2026 10:32:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] arm/gic: Optimize lr_mask type based on GIC version Content-Language: en-GB To: "Halder, Ayan Kumar" , Jan Beulich , Ayan Kumar Halder Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20260305195745.2595017-1-ayan.kumar.halder@amd.com> <9e222b10-f63a-4a5a-981c-36c438e3071c@suse.com> <0f775788-2637-4cfa-8ab0-a1e60d4d470b@amd.com> From: Julien Grall In-Reply-To: <0f775788-2637-4cfa-8ab0-a1e60d4d470b@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06/03/2026 10:09, Halder, Ayan Kumar wrote: > Hi Jan, > > On 06/03/2026 08:49, Jan Beulich wrote: >> On 05.03.2026 20:57, Ayan Kumar Halder wrote: >>> --- a/xen/arch/arm/include/asm/gic.h >>> +++ b/xen/arch/arm/include/asm/gic.h >>> @@ -237,7 +237,15 @@ enum gic_version { >>>       GIC_V3, >>>   }; >>> +/* >>> + * GICv3 supports up to 16 LRs (4 bits in ICH_VTR_EL2), can use >>> uint16_t >>> + * GICv2 supports up to 64 LRs (6 bits in GICH_VTR), requires uint64_t >>> + */ >>> +#ifdef CONFIG_GICV3 >>> +DECLARE_PER_CPU(uint16_t, lr_mask); >>> +#else >>>   DECLARE_PER_CPU(uint64_t, lr_mask); >>> +#endif >> But GICV2 and GICV3 can be enabled at the same time, at which point >> you'd still >> need 64 bits, I suppose. > > I see. However, a safety certified Xen which is meant to support GICv3 > hardware, will only have GICv3 enabled. > > IOW having both GICV2 =y && GICV2 = y is out of scope for the safety use > cases. If the patch is indented to be merged in mainline Xen, then you need to support the case where both GICV2 = y && GICV3 = y. If the patch is not intended to be merged in mainline then it should have been marked as such so we can adjust our review. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:35:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:35:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247593.1546150 (Exim 4.92) (envelope-from ) id 1vySWS-0004by-NU; Fri, 06 Mar 2026 10:35:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247593.1546150; Fri, 06 Mar 2026 10:35:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySWS-0004br-Kc; Fri, 06 Mar 2026 10:35:08 +0000 Received: by outflank-mailman (input) for mailman id 1247593; Fri, 06 Mar 2026 10:35:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySWR-0004aY-38 for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:35:07 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 210814a9-1948-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 11:35:02 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BLAPR03MB5587.namprd03.prod.outlook.com (2603:10b6:208:286::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Fri, 6 Mar 2026 10:34:58 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.017; Fri, 6 Mar 2026 10:34:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 210814a9-1948-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qqp6VyCrefGK5gIKZgPwOzkRUP0zKSM6+oMlQtWtiW4sckfn5WcD5M0wpU9moYLOSMdOLyANrZcwf32FxAO0a1iFrENsZv3mPx2/s9A8tvkdx92XL5iPPoGlqVnqeespN0e6n1fqhzdFRW3072Yf6G/aK5Y4bkPMGF+aDFE37jXHB/8Ji8h9ynw6d4Bxn4tC+IGCLY32Y5ZDoleEMBj+ywf37bBTlkFEEsUxizpTmvq5c4tEbi3gguaO7Wf/n0T3CzeF64SEr3kLtqGaDkNYVNKfY/5uFCtedxUoDCoE1kWIInorEVcxBfhJdYh0ONT+AI9XT7kDrK+ualGXV2QTmg== 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=7Tci2VgEwyEMN52AZpLCVUTxgEFw2cVuPR8ixW2m7yk=; b=BmEwWNX0ypULMy1HH7O6EpKJM9AtLo4KpsEOh439hcVpHjr/U0W2Yxlb5hiT6gAZviURaT0MCy7E35/0WpflJaAVvpuKNjsTCRekVZo+Q/CrqvFlqzBeEMfd2+Eov98NUx7LsvvU4IQWr106ReffkHq31ScyKP4VrUq4/qADlJJcBPQQuGJvU7cf3HG37/40E9r4czR/iAoRH17n6u1FVHbzpOS2lu9cmY0zdnsYwip0X3R0RdF5zC8hXmc3ESW+vrgd7vublj3M/tp4B/I0WAT+ZAGZStaC2Bsqw33RqccYic7DESXceydjWLUcH6tyfYMMC6Gz1Tjdx1PZKUKg5A== 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=7Tci2VgEwyEMN52AZpLCVUTxgEFw2cVuPR8ixW2m7yk=; b=naEOYMlAuT7Hf8SYvLLnYZ3/OYO/W2wjW1+S1AHCaqgef1T78V2bNeDZ0xL0i1BNgmc+12cBawGnqXZvsR7IUJfP5RWzEPUKsfVx5ZShEObio8fgWvbynKDrFwg7ezIj5cL35yJd4mNlMUvKFnSFwgjpgNTqtnfD+55hWYKZbrg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 6 Mar 2026 11:34:55 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand Subject: Re: [PATCH v6] vPCI: re-init extended-capabilities when MMCFG availability changed Message-ID: References: <689dae19-f83d-463f-95d9-c39c15a4e45c@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <689dae19-f83d-463f-95d9-c39c15a4e45c@suse.com> X-ClientProxiedBy: MN2PR03CA0029.namprd03.prod.outlook.com (2603:10b6:208:23a::34) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BLAPR03MB5587:EE_ X-MS-Office365-Filtering-Correlation-Id: 6106dc19-98d6-4955-55c4-08de7b6c0397 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: Lin1PyZLksNR6wA6NTU0WuFy4XXA3/zpZKQF2EEv/4fd4h93GYvvEoO7BSdg6uNBQXW0rdTSFRBY1M6HplEmtDJ0errh0rPbOc9s3H9tGJFVcMz4tAMHjaa4tdUYLs5h5Rj5Tb5fSKFj/ehWQ2nctDcDl/RAMf5AtDxC25qqligR8hzfgSdDu6m4KfbixI5ykFtz/ty7IxQczcpFsZrAMFTfYWPICPJ5M6oVWjF1h+moKeHO3AfOqfySfZXO6Dmv864N4bjVwNxu6TmR7sGesJ/c/cOK3KOLKfF+kMzRI7UTved47enW3jl6QLJkqAvPfHLgx5FwUfXmlPc3pjpHVQvE3uMGM8d8EW0YHEtSlbPR9ip9p49pOad5o1/3ClHQikXHvUJWvGPP3afJyHaxEchPwNjahlqskvtIfDxT4mnXxP6Lvp6BGlnmBjXtSP9keAIFDqibprkUmXt4UcfVlkyxFVmvfPTfhdOqzhPfyvRAr6UzotkkVpQWhDHIRhhWHrnaE4omBFph/C0KppwbWG6qSUfa6EF7O7iDPkg8sx/acmQBjFGX6sB23ldGxbVsVSGn+aor9zE3O49JAC0Ln33xkGJXJ+5+8TSLBBJyzzn07a6w18ahrumoD29BYf/UNbbmzMZ9tto+BQ94XBIKc8ykQY5yWVBj1EaQl2MRmuAWCYw/62t2GUQvxrWi9rDdP5DMf9WHcErg57SadWnnVAJ2/w9N/5vNb1mkjQ+klIs= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V3MwNDFVVVFPQ1h6YXNmbnNSQTlkWU1TQ21MbnlGeFBka25zalN4SzRVY0Rz?= =?utf-8?B?TjltcGh1Kys5RnZ2ZitVNnI3anFMa3BxZ1VvQ2tCb1prNmpxTVFWb3cwa1Ri?= =?utf-8?B?UXZZL2ZaUklmQWpGWFg1c0ozWjQxa01PSGJzOVQvZEVzYjlkQXk3KzdVZU5s?= =?utf-8?B?U1JROXR3QzB2Nm1HWXVLQ2RuK254QWNpUjNjbXdCMUg0ZXNPeE1UVjN6NkF1?= =?utf-8?B?dU01NGJoTFA5aGJTcjl6WTRQd1FWSWhOL3hRTFArTnlTYmFHckNXaWduSEZN?= =?utf-8?B?UTlrZnA2YlU5dzJHUCttSzNpRGVHaExqTGI3SXdhRFJ5L2RuZG5CUU13c1pV?= =?utf-8?B?OEtmMlFMd2pCalRVRUtoY0l2dDZZK1IwcGhIcTAyZFYya2lXMi90RWwxcHd2?= =?utf-8?B?dEV3bHBtSVdYNy92Y1VZVkFVY2dMTE9lZEkyWkJyYk9xTVRsNU5lcDlIWENT?= =?utf-8?B?RGJVbW8vbXplVGpqa3dkOCtEVnlSNFFscHVtMUJXM3BrMmQ5eDFGWUVKNi83?= =?utf-8?B?a3lVdzJMQXArVmwrQzd3aHlPbEZiRzcvOWM0cW9QbHBmZVFKemlXSzIvVldZ?= =?utf-8?B?c05DMWRob1d4STBxazFqT00yeW1RTkRyL2lobk95SThDUDFxbmErVGFMTjF1?= =?utf-8?B?ODVSbExEeTdVUG4rUmpCQjdtT1c3T2FsTjIxeUdOSTNUMmpSc0dIS0xseXFE?= =?utf-8?B?NjBuaHFpWjExWlFWQWk3ajQ0QkV4MERJcjVNTTcxOTF3S2VReGxKZXhqMlpr?= =?utf-8?B?Z0pPR0hpRFVZRCtlamJGTndENHhreWY2eElxbUNrNERaMlM5TWVMdjF3YVpJ?= =?utf-8?B?Qis4TEQ4QUk0ak9IMFBVUUV2Q3NWcWdPM1dHYkRHRlNQcHpXYUozNVZvUGI3?= =?utf-8?B?SUliZ0plU1NqckliY1M2RWJPQnR3dS9mZ2E4SklIQnN3NExQN0hQWjFiUHh3?= =?utf-8?B?QUZoT1VRMXJjZGcxTFAyZzJTTjIzMG5YSHIyaGVpZHZLU3ZvdTRhRFBaR0E2?= =?utf-8?B?RGdNY05QN2dvQXB4MFBlY3RmRVIyZzEvNUhRT2ttZ3pEN2tUajFPeVVZV0NE?= =?utf-8?B?NzlKTDZNbVk3S1diV1ZPbEhUY1crSE5nL3N2SkN5WFdlOU1pd3d0T29vNmx5?= =?utf-8?B?WkYrYy9CNEVINDJadWFibHBneXA2Z0xHQXAvTHJySkJFbzdoNldPTVQ5MjRx?= =?utf-8?B?OTlKNzd4ZlN2cUZWazZLbjFGRnFyekl6ZWdFTXA4WXpDdUN2Y2RpT1VicGgx?= =?utf-8?B?aXRyNmVpb2xHUDJscDBzakNOMENuMkVXb0ZkSVhSa3RBYWVOR0JFZklheW1n?= =?utf-8?B?aDFiZGNFRGRob3RLR0hRbG1nR0RXVG85TEVWTE5UVzdjUFNZei9uL3RuMTly?= =?utf-8?B?dnErTnRWL2ZEbGg0aVZyU3dtSitxT2JUWkgzalg3RmViekx0MnpCZktzaUUy?= =?utf-8?B?cHp0SmpqSFF4L1AzRE1uT1dhc0xKSUFibWJXbGkrNGFscW50Q1E5MXAyWVFs?= =?utf-8?B?N3pXSGhzQ1grU29MRk1SdXpYNHVEbkk0TlZwTzQvUlgvOVg0eTIyKzU0c2VS?= =?utf-8?B?K1A3bEJ1WUdsaTJOYWF1eFkwbmFsMDRMTnRCZWQ2cVpFRk9Mbkk0TGJqT3ky?= =?utf-8?B?dTJaK3lOTnU3Y2k2Vlp1eFVkYjBhdlNtbTZtT1ZJYzNjNzZnTWJNcE53ZjEr?= =?utf-8?B?TTFXaGE3Yi9lWVpIQTBzT29GQmREeTR2NFgwcE5jVTZQdDgvQ2p2MDVMOEc5?= =?utf-8?B?aGU4UUlwSkljMzd2REN1Y3FJakFQUVFBbTBNdDlHU2RTdmVTZ1hRMys5em5I?= =?utf-8?B?WU5KYlFxQkw2TU9zYnZlVkxMcGVjTUdxMzZHaUtWTXU4bDhtdXRjL211ak1t?= =?utf-8?B?K0VBV1gvRlJHV3NMRis5RDFOeVJxZWJmSnZPYm5tOFZLbjNhaTNMU3FvOXJO?= =?utf-8?B?NXR6dTNRQlZCcGtmTUcra0lHR1F6OEFxV25UM0tKNEFhQzJndWlCMWRVY0Zx?= =?utf-8?B?ck5FWFJQaFVYek12UlRSNlpxenBaODNlZS91UHJPdTU0akVEcmw0SEl5TGlC?= =?utf-8?B?bEM3SVZ2aW1WL282QXF4WVdFQUNnUENzbk9IY3RONzljYmJReWRsVXp5eVR3?= =?utf-8?B?cW5VSysrKzJPemdxb2FsV2lPWHkraHZqZ21TK05ra3hWenZZalZDMzgyb3hP?= =?utf-8?B?K3hQM2p2U1ZIS2JyanJIZk1vNDAzaUM2NTQzc0ptQm5HUE5CL0NsOTJ1ZHU2?= =?utf-8?B?WUVSaWZ6ZWlJclJkVCs1NzdBL2tmL0hxTEJaRjBnQ1Nrc1Q3NmQ5MjR6SlBN?= =?utf-8?B?Z2x5Ti9XNUhpQjNBallyQzZCdUdXNlhvU012TE0vRXhtSTIxS2FKUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6106dc19-98d6-4955-55c4-08de7b6c0397 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 10:34:58.2933 (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: AQqQ2aGXdbeBBWhqNxh5oEkKZf/QVHoypM+3FzvEXIW62C82lKH4DY7teFkS1dgDxzRh0U7ZyD62PN/NQ57omQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5587 On Thu, Mar 05, 2026 at 02:56:32PM +0100, Jan Beulich wrote: > When Dom0 informs us about MMCFG usability, this may change whether > extended capabilities are available (accessible) for devices. Zap what > might be on record, and re-initialize things. > > No synchronization is added for the case where devices may already be in > use. That'll need sorting when (a) DomU support was added and (b) DomU-s > may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). > > vpci_cleanup_capabilities() also shouldn't have used > pci_find_ext_capability(), as already when the function was introduced > extended config space may not have been (properly) accessible anymore, > no matter whether it was during init. Extended capability cleanup hooks > need to cope with being called when the respective capability doesn't > exist (and hence the corresponding ->init() hook was never called). > > Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné One comment below. > --- > v6: Add comment in physdev_check_pci_extcfg(), while dropping the logging > of a(nother) message there. Drop hwdom restriction from > vpci_cleanup_capabilities(). In the re-init case don't bail early from > vpci_init_capabilities(). Simplify assertion and re-order actions in > vpci_reinit_ext_capabilities(). > v5: Don't use pci_find_ext_capability() in vpci_cleanup_capabilities(). > Add assertion in vpci_reinit_ext_capabilities(). > v4: Make sure ->cleanup() and ->init() are invoked. > v3: New. > > --- a/xen/arch/x86/physdev.c > +++ b/xen/arch/x86/physdev.c > @@ -8,6 +8,8 @@ > #include > #include > #include > +#include > + > #include > #include > #include > @@ -169,8 +171,19 @@ int cf_check physdev_check_pci_extcfg(st > > ASSERT(pdev->seg == info->segment); > if ( pdev->bus >= info->start_bus && pdev->bus <= info->end_bus ) > + { > pci_check_extcfg(pdev); > > + /* > + * The re-init failing doesn't mean the device becomes entirely non- > + * functional. In case of failure, a message was already logged. > + * Hence don't otherwise act upon failure. > + * > + * FIXME: Re-visit when DomU support is added to vPCI. > + */ > + vpci_reinit_ext_capabilities(pdev); > + } > + > return 0; > } > #endif /* COMPAT */ > --- a/xen/drivers/vpci/cap.c > +++ b/xen/drivers/vpci/cap.c > @@ -285,13 +285,16 @@ static int vpci_init_ext_capability_list > return 0; > } > > -int vpci_init_capabilities(struct pci_dev *pdev) > +int vpci_init_capabilities(struct pci_dev *pdev, bool ext_only) > { > - int rc; > + int rc, accum_rc = 0; > > - rc = vpci_init_capability_list(pdev); > - if ( rc ) > - return rc; > + if ( !ext_only ) > + { > + rc = vpci_init_capability_list(pdev); > + if ( rc ) > + return rc; > + } > > rc = vpci_init_ext_capability_list(pdev); > if ( rc ) > @@ -305,7 +308,7 @@ int vpci_init_capabilities(struct pci_de > unsigned int pos = 0; > > if ( !is_ext ) > - pos = pci_find_cap_offset(pdev->sbdf, cap); > + pos = !ext_only ? pci_find_cap_offset(pdev->sbdf, cap) : 0; > else if ( is_hardware_domain(pdev->domain) ) > pos = pci_find_ext_capability(pdev, cap); > > @@ -341,30 +344,40 @@ int vpci_init_capabilities(struct pci_de > { > printk(XENLOG_ERR "%pd %pp: hide %s cap %u fail rc=%d\n", > pdev->domain, &pdev->sbdf, type, cap, rc); > - return rc; > + > + /* Best effort for the re-init case. */ > + if ( !ext_only ) > + return rc; > + > + if ( !accum_rc ) > + accum_rc = rc; I've been wondering about this, for the hardware domain case we might as well do best effort for the init case also. The other option for the hardware domain is to allow unmediated access to the device, which is likely worse than allowing it to work in a possibly degraded mediated mode. We already special-case the hardware domain for failures of capability->cleanup(), and we should likely do the same here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 06 10:40:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 10:40:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247605.1546159 (Exim 4.92) (envelope-from ) id 1vySbI-0006En-8m; Fri, 06 Mar 2026 10:40:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247605.1546159; Fri, 06 Mar 2026 10:40:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySbI-0006Eg-6H; Fri, 06 Mar 2026 10:40:08 +0000 Received: by outflank-mailman (input) for mailman id 1247605; Fri, 06 Mar 2026 10:40:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vySbH-0006Ea-87 for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 10:40:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vySbG-008D0L-2l; Fri, 06 Mar 2026 10:40:06 +0000 Received: from [2a02:8012:3a1:0:f0b8:207:419e:3d8a] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vySbG-001kA1-1y; Fri, 06 Mar 2026 10:40:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=W0OhQJULL61N9iDqMbX1ksT7S5t5/3mGGFgX1NczVE8=; b=6j1tiyj7l7GuAUdQvYALMJrsds K+3lNYE+tEsWV6zfSGIQ8HFnyUWDq8ZHyWYQmwBYyMnL3HxjRr+ll6BKrAcLTM9ktpQ4lxDk7ZBN6 Pm31iYm9yZf95YPjZzDOQ+/F/mzICmbUFGDIIo//QuPO+8k4OizgdE56k13Gbeeh8EHE=; Message-ID: Date: Fri, 6 Mar 2026 10:40:03 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS Content-Language: en-GB To: "Halder, Ayan Kumar" , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ayan, On 06/03/2026 09:51, Halder, Ayan Kumar wrote: > > On 06/03/2026 09:24, Julien Grall wrote: >> Hi Ayan, > Hi Julien, >> >> On 05/03/2026 19:43, Ayan Kumar Halder wrote: >>> Set GICV3_NR_LRS as per the number of list registers in the supported >>> hardware. This ensures: >>> >>> 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list >>> registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. >>> This ensures that if the hardware does not support more than 4 LRs >>> (for example), the code accessing LR 4-15 is never reached. The >>> compiler can eliminate the unsupported cases as the switch case uses a >>> constant conditional. >>> >>> 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can >>> justify that the unsupported LRs (4-15) will never be reached as Xen >>> will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some >>> compiler can eliminate the code accessing LR 4-15. >>> In this situation, using panic() is better than accessing a list >>> register which is not present in the hardware >>> >>> 3. Whenever GICV3_NR_LRS is defined, the default condition and the >>> related BUG() cannot be reached at all. >> >> I am not sure how this is better. You will still crash Xen is 'lr' >= >> GICV3_NR_LRS. Can you provide some details? >> >> > > As part of functional safety effort, we are trying to enable system >>> integrator to configure Xen for a specific platform with a predefind >>> set of GICv3 list registers. So that we can minimize the chance of >>> runtime issues and reduce the codesize that will execute. >>> >>> Signed-off-by: Ayan Kumar Halder >>> Signed-off-by: Michal Orzel >>> --- >>>   xen/arch/arm/Kconfig  |  9 +++++++++ >>>   xen/arch/arm/gic-v3.c | 12 ++++++++++-- >>>   2 files changed, 19 insertions(+), 2 deletions(-) >>> >>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>> index 2f2b501fda..6540013f97 100644 >>> --- a/xen/arch/arm/Kconfig >>> +++ b/xen/arch/arm/Kconfig >>> @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH >>>     endmenu >>>   +config GICV3_NR_LRS >>> +    int "Number of GICv3 Link Registers supported" if EXPERT >>> +    depends on GICV3 >>> +    range 0 16 >>> +    default 0 >>> +    help >>> +      Controls the number of Link registers to be accessed. >>> +      Keep it set to 0 to use a value obtained from a hardware >>> register. >>> + >>>   menu "ARM errata workaround via the alternative framework" >>>       depends on HAS_ALTERNATIVE >>>   diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >>> index bc07f97c16..fb2985fd52 100644 >>> --- a/xen/arch/arm/gic-v3.c >>> +++ b/xen/arch/arm/gic-v3.c >>> @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); >>>   #define GICD                   (gicv3.map_dbase) >>>   #define GICD_RDIST_BASE        (this_cpu(rbase)) >>>   #define GICD_RDIST_SGI_BASE    (GICD_RDIST_BASE + SZ_64K) >>> +#define lrs                    (CONFIG_GICV3_NR_LRS ?: \ >>> +                                gicv3_info.nr_lrs) >> >> We should avoid lowercase define, in particular with generic names >> like 'lrs'. I think in this case, I would rather update >> gicv3_info.nr_lrs: >> >> gicv3_info.nr_lrs = min(gv3_info.nr_lrs, CONFIG_GICV3_NR_LRS); > > But we want to enforce the user to set CONFIG_GICV3_NR_LRS , so that we > don't have to rely on gicv3_info.nr_lrs. > > The only reason to use gicv3_info.nr_lrs is for backward compatibility > i.e. when the user forgot to set the config and as a result it used the > default value as 0. We don't want to allow this for the safety use cases. Xen upstream has to support various use cases. One of the use-case is Linux distributions where they want one Xen binary booting on multiple HW. So "gicv3_info.nr_lrs" will have to stay forever. Now with CONFIG_GICV3_NR_LRS in place, I am concerned that someone will try to configure the value to let say 16 but their HW support only 4. I can't find any check at boot, so any problem will still occur at runtime. > >> >> This would solve another problem where you don't sanity check that the >> system effectively support CONFIG_GICV3_NR_LRS. >> >>> @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) >>>   static inline void gicv3_restore_lrs(const struct vcpu *v) >>>   { >>>       /* Fall through for all the cases */ >>> -    switch ( gicv3_info.nr_lrs ) >>> +    switch ( lrs ) >>>       { >>>       case 16: >>>           WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); >>> @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const struct >>> vcpu *v) >>>     static uint64_t gicv3_ich_read_lr(int lr) >>>   { >>> +    if ( lr >= lrs ) >>> +        panic("Unsupported number of LRs\n"); >> >> Do we really have to panic in production build? Wouldn't it be better >> to return '0' and maybe use ASSERT for a crash in debug build? Same >> below. > You are right, we may not need this. One option I am thinking is ... >> >>> + >>>       switch ( lr ) > > switch ( lr & (lrs - 1) ) > > This ensures that we do not hit the unsupported cases. What about implementing it as RAZ-WI? This would make any issue more reliable/obvious (if you have multiple index accessing the same LR, then you could end up overwriting an existing virtual interrupt). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Mar 06 12:57:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 12:57:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247684.1546176 (Exim 4.92) (envelope-from ) id 1vyUjn-00059n-JM; Fri, 06 Mar 2026 12:57:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247684.1546176; Fri, 06 Mar 2026 12: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 ) id 1vyUjn-00059g-Gc; Fri, 06 Mar 2026 12:57:03 +0000 Received: by outflank-mailman (input) for mailman id 1247684; Fri, 06 Mar 2026 12:57:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyUjl-00059a-PA for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 12:57:01 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f6eb36c7-195b-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 13:57:00 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4806cc07ce7so105879015e9.1 for ; Fri, 06 Mar 2026 04:57:00 -0800 (PST) Received: from [10.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-485276bc6bbsm32271435e9.15.2026.03.06.04.56.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Mar 2026 04:56:59 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f6eb36c7-195b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1772801820; x=1773406620; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=6Cem6Ib2c8SgDHkY2mk+9rgqu9lS6u/qe58rl1Cpduk=; b=Ab0kMmuhluwc/TeFe1++pt1IJZZ8BDDveb+7N3Gbd2O0VCO4NAJ5e8MlqxF0cTfzZP /QjkqGp6YtCEB6lEAxKMFF3eZJRockk3DkTSRD8kD6rfV2WCBNWFf4Mmg9E9lsb1UUDR EO52m/pKmwELcK5HZRqUDNCbSKLIFqCD9KwLv8Od67vI/4bxP994K8Zz0D/FN9oNJfwh nurQ9UmAhaMIWDnAOTLYEElHmbE5tz76qWq22sD4jGXFLJQK4oCgrPB/nsumqlZMF8Cw eXbyIiNgBt1tHP63M7P6m1oNNvSQRigtSnQ3QodjNxg2oxawR++kRvde+K4BIWbLXDt1 2b9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772801820; x=1773406620; h=content-transfer-encoding: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; bh=6Cem6Ib2c8SgDHkY2mk+9rgqu9lS6u/qe58rl1Cpduk=; b=hXsFqqcMVZ2L127n5VVzVB3SUHkINzR9c9In6tI75s1lYCr5HkGkW/Qua8pP4I1wlR gOx/u+2sG2BgpaBXIoEMJPJbqT+sLwiogQ00/oZ2oRGo93SrBktE9BAqgMM8wof5zaah rUbn/afXqQu8f9F4a/lw6DxaptgdhPhCAH1F29ewuHYJRV6Yn9bNpgwCCAmERhod2UYs O8ubBLtbeMgFLx/6XxqmGQiO9+E11Bz/y2mnPjOlII/MANQfxiHW9RF7UKQawrLi7Cul 08bYKQ7m7EZwGiDmoPDgMV7bUOGmVbh7wPFmX7IRkVfKWxeMPeRB1I3lyqa2eVvsNeSa 2HJg== X-Gm-Message-State: AOJu0YxqkqVYR+yjGUuvs9nsdlpzcm7/qgybD896gbzWWDCsoeJSA9Rk lOdM0TdKpZLdaucUdZpG4cc/9bxeNzu1PTocg8qIljWenQJoeU30x5nnR5ZkSTL1DQ== X-Gm-Gg: ATEYQzygj3toMQlU9/wtcS8VvNKEbK3DNj2T/L1p4RtqPQRWrJ0f323PT1WVlQuLYYk i6UThycMpza/xK9tC7LO8dNDjOdgF+9rTPBkb1EhQdRSZrOGTs7cnMvsf0+ppOW2AbDxnJsU4oB 8qEcrzMH+lDUrLB/pH/HrCkzEQPExrYQ98nNiTF9Kh8CXlVPLjIekFti+jvDP/VuyaVrLUf0STi FNrhS90JG97SnNW5BdEwgM+bbVTa/xIrnaQe6GBHnkDnHvtu9f31Oo9JtkniYLswy4FC592MFlI vI7siv+LpKtULCghi5RqM/+FbXnkZzkGC+T7cpl0CodO+BJmTTJ3PCFbn+r5Lpz018OqQEfFcFE TGaYWWCIzjUEojoSmTXJGIQe3rpfm0ITj7uUDlFkfPAF8/06gpWv0P6+jws27fsVrMOU9CH9cUy oDrtN3a+4s65WzfNELCoO4Z/l5e8vuqFmaCGyXjHjf+1hYS+8T3zq5UlmgkeRZ+NsdiKbdUOWas fWCkIKMlQPEAko= X-Received: by 2002:a05:600c:64c7:b0:47a:935f:61a0 with SMTP id 5b1f17b1804b1-485268bd694mr33118745e9.0.1772801819606; Fri, 06 Mar 2026 04:56:59 -0800 (PST) Message-ID: Date: Fri, 6 Mar 2026 13:56:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6] vPCI: re-init extended-capabilities when MMCFG availability changed To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Stewart Hildebrand References: <689dae19-f83d-463f-95d9-c39c15a4e45c@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2026 11:34, Roger Pau Monné wrote: > On Thu, Mar 05, 2026 at 02:56:32PM +0100, Jan Beulich wrote: >> When Dom0 informs us about MMCFG usability, this may change whether >> extended capabilities are available (accessible) for devices. Zap what >> might be on record, and re-initialize things. >> >> No synchronization is added for the case where devices may already be in >> use. That'll need sorting when (a) DomU support was added and (b) DomU-s >> may run already while Dom0 / hwdom still boots (dom0less, Hyperlaunch). >> >> vpci_cleanup_capabilities() also shouldn't have used >> pci_find_ext_capability(), as already when the function was introduced >> extended config space may not have been (properly) accessible anymore, >> no matter whether it was during init. Extended capability cleanup hooks >> need to cope with being called when the respective capability doesn't >> exist (and hence the corresponding ->init() hook was never called). >> >> Fixes: 70e6dace747e ("vpci: Use cleanup to free capability resource during deassign") >> Signed-off-by: Jan Beulich > > Reviewed-by: Roger Pau Monné Thanks. >> @@ -341,30 +344,40 @@ int vpci_init_capabilities(struct pci_de >> { >> printk(XENLOG_ERR "%pd %pp: hide %s cap %u fail rc=%d\n", >> pdev->domain, &pdev->sbdf, type, cap, rc); >> - return rc; >> + >> + /* Best effort for the re-init case. */ >> + if ( !ext_only ) >> + return rc; >> + >> + if ( !accum_rc ) >> + accum_rc = rc; > > I've been wondering about this, for the hardware domain case we might > as well do best effort for the init case also. The other option for > the hardware domain is to allow unmediated access to the device, which > is likely worse than allowing it to work in a possibly degraded > mediated mode. We already special-case the hardware domain for > failures of capability->cleanup(), and we should likely do the same > here. When making the change, I was asking myself the same. I just didn't want to mix re-init with a change to how we do init. The earlier of the two if()s could be dropped in a subsequent change, or (less desirable from my pov, as then I'll need yet another iteration for this change) make that adjustment first. Jan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 13:29:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 13:29:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247723.1546194 (Exim 4.92) (envelope-from ) id 1vyVFX-00011e-5z; Fri, 06 Mar 2026 13:29:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247723.1546194; Fri, 06 Mar 2026 13:29:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFX-00011V-3M; Fri, 06 Mar 2026 13:29:51 +0000 Received: by outflank-mailman (input) for mailman id 1247723; Fri, 06 Mar 2026 13:29:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFW-00011B-6d for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 13:29:50 +0000 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [2607:f8b0:4864:20::644]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8bca8102-1960-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 14:29:48 +0100 (CET) Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-2aae146b604so69863395ad.3 for ; Fri, 06 Mar 2026 05:29:48 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae840ad92fsm34784815ad.77.2026.03.06.05.29.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 05:29:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8bca8102-1960-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772803787; x=1773408587; 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; bh=kC4SJGNXCr1rdhgZ8HB/0dsT03+rkfzmTNu95O6q6TM=; b=J6sVUthoAemQwei/GjkRWcKzmkBYijZOvCC1DOaLbubTqF/4FYd9JO0Uu+6qlbqul5 wgewO9doJbV3qYILqx3PlTgWXKJXMF5SDIf6REladQIWLpvVU2be3vU5DY6dip0RSDbu imbz0JMr+BSax5ShR8k7s4YlpxMudhJo1/e9LGQkZzFnn0BdpHpv3ZHeKpAe1bik7C3U 4DCj2G7A/1Amz4H/TX7tbt8nzD/7/qNubZMwZ+M/vd3Dwnc99k/iygS2bBfhMn3VPxXh PxYRapYPaDir08Ce+uTUgXjI2C7hwkidXCptSyL2vPGhXnvTSUdw27n2kxizK1fvRDg0 0RPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772803787; x=1773408587; 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; bh=kC4SJGNXCr1rdhgZ8HB/0dsT03+rkfzmTNu95O6q6TM=; b=NAd7/iFBuLDQj+H8aTBy10IIY9VB0Km8YolxD6CcqqZPPggDpQmf7fzL0UiWlmTDWy InVy9dCE/nCZbb0vkzdzz4n5VCPfKfAk1z8MD6B0LBT5cjeXdcVrqpwoQ2xqaG4GLkGa q4cJq+XPIdzfJPXEkspyo4K9HPPnVFIMtHo1TrLXs/g4vm6k9sWGW/CELBQjtjg4gjz4 LYWaYBHR5r5/4HvZWBklSAvvo14kdeeeoT3ikZXRb+AbR1mwIilcPqxLOFCi5yyhCLFk uQLAquXodn784ADABHp7gNDfpiLYlpi86gGIAX+m/nhDQ9GVyYqVClREzKBbJth8lhaS tXEQ== X-Gm-Message-State: AOJu0YzfZSuq1ENxOwHJwQFRgpAvwpwvlIwwGL5CJHElIi5lPtpAE2BZ s0vtNsMYYc44pl2XfqqSiq1Kgk59LMKAXsLF3ZsijjyOfdJeDw6loZ8t0FXCBtqn X-Gm-Gg: ATEYQzyGcgrJZ5ZYMsSV55OrslopxURtLiusty09ldvtxc22ZTeiQQmAj55lqziB4ZR atUq+dJ1BI5vEaW+SL9B88bcxaBREOG7ZtTx4YY5S3fN6ko3FD4jNimFF3MiVomCES0zeAN8EdO sVixpod5MHw96XSMtAYd/OrgkuzBrZECBI5aB8fxFyC/PUGbclKGGS0Wa6GgCJ3MEcVmVvf4vbc wqh+/1uuOdpNITVvyblqZVglLusRa95eGYza6sMHEDffD9bMjy/zaP8ZEbE/OmPqBkAHNcMGyOS ohs7AFeL9+7CIx7+AXgz/THARlzxFTzryBqbTMcIsBcwMqMgOhig+qnYIWsPCP+ulXyyug8g8aI l2fjKATZWckFRdNZTpWHlpNpH51cZLKJEPtHftq0vu/nw+yZu0AL9AtBLRs+LPzDG4aEDx92sVv 2iuq+zEj+aE98gFrFyJQDFmbnV0i2QKtTese/6/MFdBAj9Gosn/Q7EcFrRKJHlVX9C2rQI0jmq6 vxGZaEjN6Nfg1KIKDfAcVmtWt5LQh6isJ1x81Ltw0Hh0UsGU8hugZaWu8lcgeADIm/l0PP/Qa9W HgeZS96J X-Received: by 2002:a17:903:3808:b0:2ab:3cba:42fa with SMTP id d9443c01a7336-2ae82478619mr24900085ad.46.1772803786754; Fri, 06 Mar 2026 05:29:46 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH v2 1/3] x86/efi: Add BGRT image preservation during boot Date: Fri, 6 Mar 2026 18:59:33 +0530 Message-ID: <20260306132935.13727-2-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The ACPI BGRT (Boot Graphics Resource Table) contains a pointer to a boot logo image stored in BootServicesData memory. When Xen reclaims this memory during boot, the image is lost and the BGRT table becomes invalid, causing Linux dom0 to report ACPI checksum errors. Add preservation logic similar to ESRT table handling: - Locate BGRT table via XSDT during EFI boot services phase - Validate BMP image signature and size (max 16 MB) - Copy image to EfiACPIReclaimMemory (safe from reclamation) - Update BGRT table with new image address - Recalculate ACPI table checksum The preservation runs automatically during efi_exit_boot() before Boot Services are terminated. This ensures the image remains accessible to dom0. Open-coded ACPI parsing is used because Xen's ACPI subsystem is not available during the EFI boot phase. The RSDP is obtained from the EFI System Table, and the XSDT is walked manually to find BGRT. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/efi/efi-boot.h | 2 + xen/common/efi/boot.c | 187 ++++++++++++++++++++++++++++++++++++ 2 files changed, 189 insertions(+) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 42a2c46b5e..27792a56ff 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -910,6 +910,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, efi_relocate_esrt(SystemTable); + efi_preserve_bgrt_img(SystemTable); + efi_exit_boot(ImageHandle, SystemTable); } diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 967094994d..1e3489e902 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -7,6 +7,7 @@ #include #include #include +#include #include #include #include @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; static struct file __initdata xsm; static const CHAR16 __initconst newline[] = L"\r\n"; +static __initdata struct { + bool preserved; + uint64_t old_addr; + uint64_t new_addr; + uint32_t size; + const char *failure_reason; +} bgrt_debug_info; + static void __init PrintStr(const CHAR16 *s) { StdOut->OutputString(StdOut, (CHAR16 *)s ); @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) efi_bs->FreePool(memory_map); } +struct bmp_header { + uint16_t signature; + uint32_t file_size; + uint16_t reserved_1; + uint16_t reserved_2; + uint32_t data_offset; +} __attribute__((packed)); + +/* + * ACPI Structures - defined locally, + * since we cannot include acpi headers + * in EFI Context. + */ + +struct acpi_rsdp { + char signature[8]; + uint8_t checksum; + char oem_id[6]; + uint8_t revision; + uint32_t rsdt_physical_address; + uint32_t length; + uint64_t xsdt_physical_address; + uint8_t extended_checksum; + uint8_t reserved[3]; +} __attribute__((packed)); + +struct acpi_table_header { + char signature[4]; + uint32_t length; + uint8_t revision; + uint8_t checksum; + char oem_id[6]; + char oem_table_id[8]; + uint32_t oem_revision; + uint32_t asl_compiler_id; + uint32_t asl_compiler_revision; +} __attribute__((packed)); + +struct acpi_xsdt { + struct acpi_table_header header; + uint64_t table_offset_entry[1]; /* Variable array length */ +} __attribute__((packed)); + +struct acpi_bgrt { + struct acpi_table_header header; + uint16_t version; + uint8_t status; + uint8_t image_type; + uint64_t image_address; + uint32_t image_offset_x; + uint32_t image_offset_y; +} __attribute__((packed)); + +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE *SystemTable) +{ + EFI_GUID acpi2_guid = ACPI_20_TABLE_GUID; + struct acpi_rsdp *rsdp = NULL; + struct acpi_xsdt *xsdt; + struct acpi_bgrt *bgrt; + uint32_t entry_count, actual_size; + unsigned int i; + + for ( i = 0; i < SystemTable->NumberOfTableEntries; i++ ) + { + if ( match_guid(&acpi2_guid, &SystemTable->ConfigurationTable[i].VendorGuid) ) + { + rsdp = SystemTable->ConfigurationTable[i].VendorTable; + break; + } + } + + if ( !rsdp || !rsdp->xsdt_physical_address ) + return NULL; + + xsdt = (struct acpi_xsdt *)rsdp->xsdt_physical_address; + if ( !xsdt ) + return NULL; + + actual_size = (xsdt->header.length - sizeof(struct acpi_table_header)); + entry_count = (actual_size / sizeof(uint64_t)); + + for ( i = 0; i < entry_count; i++ ) + { + struct acpi_table_header *header = (struct acpi_table_header *)xsdt->table_offset_entry[i]; + + if ( header->signature[0] == 'B' + && header->signature[1] == 'G' + && header->signature[2] == 'R' + && header->signature[3] == 'T' ) + { + bgrt = (struct acpi_bgrt *)header; + return bgrt; + } + } + return NULL; +} + +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject if bigger */ + +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) +{ + struct acpi_bgrt *bgrt; + struct bmp_header *bmp; + void *old_image, *new_image; + uint32_t image_size; + EFI_STATUS status; + uint8_t checksum; + unsigned int i; + + bgrt_debug_info.preserved = false; + bgrt_debug_info.failure_reason = NULL; + + bgrt = find_bgrt_table(SystemTable); + if ( !bgrt ) + { + bgrt_debug_info.failure_reason = "BGRT table not found in XSDT"; + return; + } + + if ( !bgrt->image_address ) + { + bgrt_debug_info.failure_reason = "BGRT image_address is NULL"; + return; + } + + old_image = (void *)bgrt->image_address; + bmp = (struct bmp_header *)old_image; + + if ( bmp->signature != 0x4D42 ) + { + bgrt_debug_info.failure_reason = "Invalid BMP signature"; + return; + } + + image_size = bmp->file_size; + if ( !image_size || image_size > MAX_IMAGE_SIZE ) + { + bgrt_debug_info.failure_reason = "Invalid image size"; + return; + } + + status = efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &new_image); + if ( status != EFI_SUCCESS || !new_image ) + { + bgrt_debug_info.failure_reason = "Memory allocation failed"; + return; + } + + memcpy(new_image, old_image, image_size); + + bgrt->image_address = (uint64_t)new_image; + bgrt->status |= 0x01; + + bgrt->header.checksum = 0; + checksum = 0; + for ( i = 0; i < bgrt->header.length; i++ ) + checksum += ((uint8_t *)bgrt)[i]; + bgrt->header.checksum = (uint8_t)(0 - checksum); + + bgrt_debug_info.preserved = true; + bgrt_debug_info.old_addr = (uint64_t)old_image; + bgrt_debug_info.new_addr = (uint64_t)new_image; + bgrt_debug_info.size = image_size; +} + /* * Include architecture specific implementation here, which references the * static globals defined above. @@ -1794,6 +1968,19 @@ void __init efi_init_memory(void) if ( !efi_enabled(EFI_BOOT) ) return; + if ( bgrt_debug_info.preserved ) + { + printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", + bgrt_debug_info.size / 1024); + printk(XENLOG_INFO "EFI: BGRT relocated from %#" PRIx64 " to %#" PRIx64 "\n", + bgrt_debug_info.old_addr, bgrt_debug_info.new_addr); + } + else if ( bgrt_debug_info.failure_reason ) + { + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n", + bgrt_debug_info.failure_reason); + } + printk(XENLOG_DEBUG "EFI memory map:%s\n", map_bs ? " (mapping BootServices)" : ""); for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 13:29:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 13:29:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247722.1546185 (Exim 4.92) (envelope-from ) id 1vyVFU-0000oH-0j; Fri, 06 Mar 2026 13:29:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247722.1546185; Fri, 06 Mar 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 ) id 1vyVFT-0000oA-Tp; Fri, 06 Mar 2026 13:29:47 +0000 Received: by outflank-mailman (input) for mailman id 1247722; Fri, 06 Mar 2026 13:29:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFT-0000o4-2d for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 13:29:47 +0000 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [2607:f8b0:4864:20::641]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 896481cc-1960-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 14:29:44 +0100 (CET) Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-2addb31945aso66594665ad.1 for ; Fri, 06 Mar 2026 05:29:44 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae840ad92fsm34784815ad.77.2026.03.06.05.29.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 05:29:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 896481cc-1960-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772803783; x=1773408583; 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; bh=hXltUrIM8u+3vchXEmdzSSxxFAB0jLJSYsohu1ixvuk=; b=RNjtSRraoWqEQFqaG7D5BJf21dpt1o9n2fGDsf9GolO0TeClBKEPQPqHaaIupzRKig +qNgRg+JWJSK2rn+6oO/atirVuRJgzJi6PJT3peSYfcsLxWwkkGjD68vrZa0SQ8JWJ64 SLaYvCUGIZjqKTdkIBxKhmhlCoG4cxCO436J7T3I52SaboURaElTKTDKt7UtcrmXOGC3 LNRHjUzb6qI3iGHvW67pj5xBMa2RJx8oAQbCj/AAiQNkqmdi38vl50aeEtIozSC0ouUG 65K93JL+9vFOkZlY0uKhwUDCFdfZh3rvptG8xNxHYUfUhkkhf5OeMYOesvdMHrGUzAJp Tfpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772803783; x=1773408583; 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; bh=hXltUrIM8u+3vchXEmdzSSxxFAB0jLJSYsohu1ixvuk=; b=qpMAJ+Iq0cNBjlvH3VIHZaLhF2fPDczcV0DUPgGDMMgI3GFHJooQxtyC3ja/Tuzk8n vsqhUtW4fmrstdAS1tjCbNJaHlCw0m83C77Coj7WTkyE2WsQF1fpeqKpPgUBrbfACDRF tKldb3zscupxr8Gq/oRad446Q6IwX9u7QZm37jsl+O4dt5o16ObkU0r6gX7Lv/KPd8yj ynLzWj4FIOE5KCgABeu3pdgErbN2nhGk44Z2y29/yf6JBRU3OHQWTYwCCmnR2JQC1pTQ CgBLUbIEEDEwlDPHhLpa166DyYPn/EWSRLsJn6ZKr1io7mDPPfBv7I5r29W7tScp/FdP U7aw== X-Gm-Message-State: AOJu0Yw2voE6YpEGr/0Jo3mMIFmZGRwrvAYpvYL3bpKxHlR2dlC1Sdri u8Eq178ljKUe8VaKdMJxU33NIKQ3c34a2cry3QNJGq6egPslbszf0NPikoCdD2vC X-Gm-Gg: ATEYQzxYjsDDO31tqBO6nRbIbxNdm6ZI6MgztrcubkjtJXIGP8nDjhuhTbAPjtdr5Y8 hficIwJCYzPPNW8tRSAw3SVgIgDMILRpvz/DI3JqDqPNuqa/1J6IFuTReMtEeo13SgDNXlMx7aA wAh/y3PjcXog5SJLi94Y5Eiu2E0s5EO9CIOjxYWCeUfVK/i7jhIx0RKIPdLHYNky7iVw335tATT dSv93Vvg7lNUfFvN8XG0gz8Duz8N68iYcp36O9iiCspsX6hkuy3eNCcB8RDVdfzyrb3ZOEgVaYv wy9UBfs5eYKzdRB60ZTr99nWefi++06tCeqN89DqBevVNqMUe0FxUJ5i+RdZr4+RRWPAlVRaa9v MiRvC2eK3c2YkeWjKGfk08YC9BrH7AKvanwtglNjwd8+9+7DbBgqja2gL+eRiihjcCHzHjOJx9y g2z4HhK5aHxvBJkxU3r60X3vVVOVssxGXd1YZJsw+dCYnI8Xnd31KRvxO01pVfG4aChgAzmIKcq /AgmlflRXeH8eH85vo2u8zeWfHZm2IdnY6eAM+rRJLBiTdNTKaubpR5bcPcVdT7hPQMvROS8w== X-Received: by 2002:a17:903:2a8c:b0:2ae:8055:62c8 with SMTP id d9443c01a7336-2ae8243b575mr24922535ad.32.1772803782645; Fri, 06 Mar 2026 05:29:42 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH v2 0/3] Fixing ACPI BGRT (Boot Graphics Resource Table) corruption Date: Fri, 6 Mar 2026 18:59:32 +0530 Message-ID: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This series fixes ACPI BGRT (Boot Graphics Resource Table) corruption, that occured when Xen reuses the memory containing the boot logo image before dom0 is able to parse ACPI tables. The BGRT table contains a pointer to a BMP image stored in BootServicesData memory. When Xen reclaims this memory early in boot, the pointer becomes invalid, causing Linux dom0 to report: Xen: `(XEN) ACPI: BGRT: invalidating v1 image at 0x47cc2018` Linux (dom0): `ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0xF9, should be 0xB4 (20250807/utcksum-58)` This series: 1. Adds BGRT image preservation during EFI boot (similar to ESRT) 2. Clarify BGRT invalidation behavior with preservation. 3. Provides an opt-out mechanism (efi=no-bgrt) for servers The preservation is enabled by default to fix the corruption for all users, with minimal overhead (~1MB). Also, servers that don't need boot graphics can disable it using the "efi=no-bgrt" option. Changes since v1: As Marek Marczykowski-Górecki , pointed out the BGRT invalidation behaviour should still presist and server as a safety net when "efi=no-bgrt" or the preservation fails for some reason thus: Add Clarify comment for BGRT invalidation behavior with preservation. Testing: - Verified on Intel UEFI system with Fedora 43 dom0 - Before: ACPI checksum errors in dom0 - After: Clean boot, no ACPI warnings - Memory overhead: ~972 KB (preserved image size) Signed-off-by: Soumyajyotii Ssarkar Soumyajyotii Ssarkar (3): x86/efi: Add BGRT image preservation during boot x86/acpi: Clarify BGRT invalidation behavior with preservation x86/efi: Add opt-out mechanism for BGRT preservation xen/arch/x86/acpi/boot.c | 5 + xen/arch/x86/efi/efi-boot.h | 2 + xen/common/efi/boot.c | 199 ++++++++++++++++++++++++++++++++++++ 3 files changed, 206 insertions(+) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 13:29:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 13:29:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247724.1546204 (Exim 4.92) (envelope-from ) id 1vyVFb-0001Gw-CE; Fri, 06 Mar 2026 13:29:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247724.1546204; Fri, 06 Mar 2026 13:29:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFb-0001Gn-9T; Fri, 06 Mar 2026 13:29:55 +0000 Received: by outflank-mailman (input) for mailman id 1247724; Fri, 06 Mar 2026 13:29:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFa-0000o4-Fl for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 13:29:54 +0000 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [2607:f8b0:4864:20::642]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8e396bc1-1960-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 14:29:52 +0100 (CET) Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-2ae82df847bso4383165ad.2 for ; Fri, 06 Mar 2026 05:29:52 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae840ad92fsm34784815ad.77.2026.03.06.05.29.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 05:29:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8e396bc1-1960-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772803791; x=1773408591; 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; bh=vBP4BGnTbEMnu9mY2BiK5Hh8it3pJ1l1Oia2XagE9LE=; b=QR2XyAwgkl3/rmt8LGy/KhLdz9u3WhxmRe86ZwWs5fErT2e745jNDVbLAS8EK2bkWH 3lPREIf0JhuEWYQZiH72vY5+IEDkahphXczZ5hKnGpxKwL7YyyPAbRUAL4XH+/L+8p5y BY6j06/UfCERWE+Yb50Hl6PwRzbRdSOGFoCeG7ox6UqlaozHnyN1A0Mi+aEq2zM+Erg3 exqHJnoLxj1vI7HZtGy0UtDEz4sCEfKPHCNuiyFNglffJD9TZPEkBYN3v/hNozoHlDsZ Xpuac4ZHjrA7TT+PYONI4fYD7pS8tq9XFWJtapNqqZD/MLF8BYT1XmaTs+Va1NvGa2Vj 8b1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772803791; x=1773408591; 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; bh=vBP4BGnTbEMnu9mY2BiK5Hh8it3pJ1l1Oia2XagE9LE=; b=oNtMXHgrbKElQ5uJ98tvlooHGRBq8iO6hQH7oh8PYhU8tMXvpK3Xdy6Z/6r10Ma69Q qdNsjqi8ZWTBToXofuLjvYyOAbU6cBoCHV4jLYJDShccFAwVeXMw9XshtEKr94Goqp6t Pf2Uv7nAHT1bkIkGce7kw7dR/8EUt/Y79b1OJYXRwQ2iX6YrK0E1EiqI33uqtQGSVduU kOMcORwCEnL72ZssHANJYEEdhgljh5Nt7f7ekmIZ/DtDBqrXzA6yIVYrRonDEm6+oQin eOIONg1KeVMTM2FjIpP4qGVDoayo6MkHGYxfr1RNUo6asUZPHxYJiMsNSRz/OFriTGpA gHPg== X-Gm-Message-State: AOJu0Yz+ncWEq+PzMTOVAxZOS0ABFYTnC7ALeiNbZrnPEHL9cTfBfkKH u5m1XkDBmW7y+//QrEpF/9OKRCldSi+XY+jR3LVCG2QjylZ0CtLlzBhGrWagReJQ X-Gm-Gg: ATEYQzxfr/rmyqOERz/cNBOHhV7YUUR+F9KfQvbMU6x0Ihjh940Asq0P3VnWLAFLtZt J+vgHZjqQYrSQw6clo9+W98x44dO1zfIVjWEbR7ZelRRakFz3bDm7vIgX8zq0t/IxM7ouvD7Lkg 9ceLYG/sBKgBNOGFStoYahoQ0nwgtFXtH8z27SPfnbUe94LwIuqgCazPTOvwwGjR2p4L7LBIK5k 0kefAplgs4rnH8KE1951t+4ohqiGZwOdh5Af3WFxdq4YWwchg/Tv4kL0IJ6Z1mJ72mVmpRlKt99 upEA1pUS3tk3uiu/ru3cu1C4eBQioq3fsPc9kN7LUTx36r6ooMiTFLm4c/nxJ6BMeMiMn2phyUh HUk/CWWtNpyQpuTxj65ZpvfMBtycjosLA3Fk8Lk2FwfFI9sf2l2e13650lSnpgF52LVPd4v3OPq 1OtUt3I306tZZIUeDuGnO3yqovb2WjjColjHc83vJEXbE7tZBIBaHXsrFr1E759Olt/Eni/xDpR ziCLnYc5wLZuo8ibDolzRsU3De5RXryBLZGjyiMYXElHUcQHI4bCSlIBBRe6qLDtSuj/AqkLw== X-Received: by 2002:a17:903:2a84:b0:2ae:8293:7510 with SMTP id d9443c01a7336-2ae829379eamr22642085ad.54.1772803790870; Fri, 06 Mar 2026 05:29:50 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH v2 2/3] x86/acpi: Clarify BGRT invalidation behavior with preservation Date: Fri, 6 Mar 2026 18:59:34 +0530 Message-ID: <20260306132935.13727-3-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Now that BGRT images are preserved during EFI boot (via EfiACPIReclaimMemory allocation), the invalidation code in acpi_parse_bgrt() is no longer needed. However, The original invalidation code acts as a safety net for when preservation fails or is disabled via "efi=no-bgrt". Thus, Add comments to clarify this behavior for future reference. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/acpi/boot.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index 1ca2360e00..9462cc6195 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -327,6 +327,11 @@ static int __init cf_check acpi_parse_hpet(struct acpi_table_header *table) return 0; } +/* + * Invalidate BGRT if image is in conventional RAM (preservation failed). + * If preservation succeeded, image is in EfiACPIReclaimMemory, which + * won't match RAM_TYPE_CONVENTIONAL check, so table remains valid. + */ static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_header *table) { struct acpi_table_bgrt *bgrt_tbl = -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 13:29:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 13:29:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247725.1546212 (Exim 4.92) (envelope-from ) id 1vyVFf-0001YM-Mw; Fri, 06 Mar 2026 13:29:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247725.1546212; Fri, 06 Mar 2026 13:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFf-0001YC-JN; Fri, 06 Mar 2026 13:29:59 +0000 Received: by outflank-mailman (input) for mailman id 1247725; Fri, 06 Mar 2026 13:29:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVFe-00011B-1X for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 13:29:58 +0000 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [2607:f8b0:4864:20::642]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 90d16a4a-1960-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 14:29:57 +0100 (CET) Received: by mail-pl1-x642.google.com with SMTP id d9443c01a7336-2aae146b604so69864045ad.3 for ; Fri, 06 Mar 2026 05:29:57 -0800 (PST) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae840ad92fsm34784815ad.77.2026.03.06.05.29.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 05:29:54 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 90d16a4a-1960-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772803795; x=1773408595; 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; bh=WZnA155v70+QhGSyRygUUhwtWIBU38ELU4IAn875zcw=; b=k5DgFYaJ1lxlx0kjYbJwsKRNnq6XiaCWN7KXA/PjWxaDW3Fgq4oKbxU8HQwsyH+0Vz su+z+ODqMvofyM8lEYQmJDdMeN0rTz8Pir0A1BxBoFe/GulTMxESQj+PlkMRwXkyLy4P 185Wi0jWAfJbMHJWvqUfVYJWIGowHm88QcjO+wYATJnFlHbLWy00T0+T3ojske994ZDQ 6PuWXLWiGOfzMqF1uQYrKyHrD9HhnFncdaHRYEmn4Nne93lRsHOh5+rAGTSTm9998D1s PsYPX10l0V4vp53YE7NlP45aKSa9b6BWzQ9vlSCjbMIGqwTUkmXSw0gG43aKAO7r8xRh XtUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772803795; x=1773408595; 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; bh=WZnA155v70+QhGSyRygUUhwtWIBU38ELU4IAn875zcw=; b=KzHObskamz74iECKL1N5JfoSemkH4RO+r51FalH5YFmTxoQcXM+b3RTF0Z9iuGQCs7 I0bq65ngwZxgJQ7jMawvqqRUpeAwELZBL2WVAz1tGg/s2lYV3xU00wUNEesvuYUdZgjN jowo/fbA0vLgOSSf88kkYDwIoLz/AYJZQrZT1yX9bR4PUB7ihdxuqFSzln5jlMNh3r1X Oq94bwT8bO7kS3i5l1Ty1Imbc7z5IliPjh8Rqksi6ZC/QjDC22ewaq3D/+8rC84NkRHE FD6xd8D5MdIX+aL4xBGjmeVfyJxI8pNQMP19pyujQ4gf2AtZG94I6v8ircUyW3GKMnSn cIvQ== X-Gm-Message-State: AOJu0Ywtc9Oq7uk44CiwrfxujgWOzDtAQ+EVHkfc4nVA9EvbFkHPokar 4sf+4PIO8O4DoEoZrtdgscPXliSbqJ5cIHLbGgVBIXWlXy6xLrjLIfIKNwGJTxU0 X-Gm-Gg: ATEYQzy5jZdfNdzeqdewJj7QjMeJsv+uxvOqWCwe9LKQHWjOKFZjO16I36D/Z6/JkLD r1IQw5sAY/gHNX9ZmPwbzEUcTJ5cQyFuSP9ErpwZV9sKddnBKd2SQbXVnEdyop3GFa7Q/4Gh5S+ L9FV8P2CQtxW4v27TYrlraq4yujMyx5eNWSsR4rSW8qtcdktfytVQeeI2h861crExC+mWrm2TDm Q5P8RSfke2ZK+Ms27vS/X0SX2/Mwjl2P4nlc4IgJcYB4JEYnwWLJ9hGYpqUuWr5Tg6fGVNce0Jv bHRevP+uemgDXEerOlkv0ud++s17a7YnohrT+Sk9y2+HzDretOD3lPX4UqV0wQgayxy8N3IhI2h MjFYUbb0BWa6n121vt+dFG0K4Xb8RNc385viEt8E3ETNK4QicdAKFdO57a+vTZwMdAgfQztRL/O FKC83FPVgVH6s3bEDn4fdnFYZSh/hg3iXD35LDOu5RYhJ8BKVbV77SikgzFokWwlJ5r3CQwyiZz 1mjndW64E3qfMhSUPAluW06+vQC5x/UCSVKJTRzusfenhqTh5SovYG8+wH5gvtdGd209C+LWA== X-Received: by 2002:a17:902:e845:b0:2ad:c1e1:c286 with SMTP id d9443c01a7336-2ae823ac4camr23806925ad.24.1772803795206; Fri, 06 Mar 2026 05:29:55 -0800 (PST) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Jan Beulich , "Daniel P . Smith" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Andrew Cooper , Soumyajyotii Ssarkar Subject: [PATCH v2 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Date: Fri, 6 Mar 2026 18:59:35 +0530 Message-ID: <20260306132935.13727-4-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As described in the task, BGRT preservation is now enabled by default to fix ACPI corruption for desktop/workstation systems (similar to ESRT). Add an opt-out parameter 'efi=no-bgrt' to allow disabling BGRT preservation on systems where the ~1MB memory overhead is not desired. The parameter is parsed during normal Xen boot (not during EFI phase), so it only affects diagnostic logging. The opt-out flag is checked at the start of efi_preserve_bgrt_img(). Usage: Default: BGRT preserved automatically Opt-out: Add 'efi=no-bgrt' to Xen command line Signed-off-by: Soumyajyotii Ssarkar --- xen/common/efi/boot.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 1e3489e902..b735eac6b2 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -167,6 +167,7 @@ static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdErr; static UINT32 __initdata mdesc_ver; static bool __initdata map_bs; +static bool __initdata opt_bgrt_disabled = false; static struct file __initdata cfg; static struct file __initdata kernel; @@ -868,6 +869,9 @@ static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) bgrt_debug_info.preserved = false; bgrt_debug_info.failure_reason = NULL; + if ( opt_bgrt_disabled ) + return; + bgrt = find_bgrt_table(SystemTable); if ( !bgrt ) { @@ -1873,6 +1877,10 @@ static int __init cf_check parse_efi_param(const char *s) else __clear_bit(EFI_RS, &efi_flags); } + else if ( (ss - s) == 7 && !memcmp(s, "no-bgrt", 7) ) + { + opt_bgrt_disabled = true; + } else if ( (ss - s) > 5 && !memcmp(s, "attr=", 5) ) { if ( !cmdline_strcmp(s + 5, "uc") ) @@ -1968,7 +1976,11 @@ void __init efi_init_memory(void) if ( !efi_enabled(EFI_BOOT) ) return; - if ( bgrt_debug_info.preserved ) + if ( opt_bgrt_disabled ) + { + printk(XENLOG_INFO "EFI: BGRT preservation disabled\n"); + } + else if ( bgrt_debug_info.preserved ) { printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", bgrt_debug_info.size / 1024); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 13:40:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 13:40:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247764.1546222 (Exim 4.92) (envelope-from ) id 1vyVPv-00055c-LR; Fri, 06 Mar 2026 13:40:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247764.1546222; Fri, 06 Mar 2026 13:40:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVPv-00055V-ID; Fri, 06 Mar 2026 13:40:35 +0000 Received: by outflank-mailman (input) for mailman id 1247764; Fri, 06 Mar 2026 13:40:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyVPt-00055P-Kl for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 13:40:33 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0acf83d7-1962-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 14:40:31 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB5196.namprd03.prod.outlook.com (2603:10b6:5:24a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.20; Fri, 6 Mar 2026 13:40:27 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.017; Fri, 6 Mar 2026 13:40:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0acf83d7-1962-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h6J/HvQrEX545xgGVxuN2GhZnMMGrAgzho9FqJF35x/IcDrmgknNIwmY0OlJjX3U8+gifIBCwrUqau8choEyvp4n/I54Oc7nxPLz6aMUXXpvuLWBHKBVLnCH0MWYEF7iptLRP5XRl5sxt17Ms3FoNnf+iX2UIiR9LOOTdr74NOufekP9/aZvrP36eZ9lL/MoTcf06rXjh3xGfn6yD1gYp3MkJOhJf4xnL9uVUn5Nso3p0zXCjE2blbXJ1Ruum3oeSKPKkUCusb8AUIgguTgqAIGMczS5639xh+f+sseMKuI/usP81TFmW+OdqilJhA+A7wRGJETVfpgUBzKcLyJ20Q== 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=Ls2j1H9MEcE+FCeSzwwR0GbbmO14BTVpAOo+CYkzJ6U=; b=NbfAdS8m8zerWcg4gXzVQOG6K/y/S3uHf7h/o8UrP4jjT+nZ1wJQEnEoQg8FAv+JIyrfoYiNNu5olObU8QduSc9sup/S+6xatUrIwz7j/1e3lv9JLBpZX3q6UMk9sGyUb797On6kc7TR4opfXFuX2WnKXyl4JewhiY4c6XStW3fWSZfOma2nCcblMbCrY7lWPb2gkr6ON9LV+SciwzR6puL12Ub8sjPHkI6tUziiXyvpcJtgmKLsShKlD9t4yciS8JRc3cx1r7P4ltzyawLV75T6QeBhDzLmaWitxq9c6u5hfJdTsTKW81eq9asdzYz8miZTYTgRRv/w0INQlsJZew== 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=Ls2j1H9MEcE+FCeSzwwR0GbbmO14BTVpAOo+CYkzJ6U=; b=SvjjwkKBH+8fBdmgGxa6ZfgfYFFXYpP7qTJyfjXAUc7Clgq65L0raUGIPcqcqDMiZ6Vp9jEEuitZISp4lQq9uG3AW+lUb/DjImC30NCXPL2Ca/43Y0r+Ij+TS3YXQaV4syXH7m1aKLxe/qaz+gAzhDogHca/oaryB12KWXhX5go= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 6 Mar 2026 14:40:23 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper Subject: Re: [PATCH] x86/hvm: Advertise and support extended destination IDs for MSI/IO-APIC Message-ID: References: <20260209113412.2603088-1-julian.vetter@vates.tech> <993fafc6-330b-4680-8284-983efb7694f8@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <993fafc6-330b-4680-8284-983efb7694f8@vates.tech> X-ClientProxiedBy: MR1P264CA0138.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:51::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB5196:EE_ X-MS-Office365-Filtering-Correlation-Id: 7becf6c4-3fc5-41ff-48ed-08de7b85ecf4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: Z0s7KWYyk0EzOXyta/69WTm38Uew7v90CEcuzJyCqSoaqxE+kRmccmlGXPdg1DDdoE/JKlg49wWNLqhpgF+UJNC3q69nwuL17r4vK4iBR6xphT8PrFyxPK5Qvgwn4bdj7yIeQbCMu7DBEsAqi8mmN0nZPdxw44wY19Isewhz6MGWG+UHkFtQEyVpNoCZ0z6etzu8f64CpSblf+3xW8Yz3GjiphQ0q4dPki6S4Anp6Ptu5QKXfut3XZH+q5RXTtxEMAsqeC8wzU/axa5o60vX+QYZ6pOV6KxMnc+biKRR7JmFP2dOsFNquP/Ah51G8ixTnMaXQE/QRR0S4rRKVtQKTQote+LcsVhwa1GfT0trLPqb+326rJnsE1QHNV3rUm9AwrUAV/T93Plx/6HmwWNU2oI2T26zWn/066zGt6ahh5h+pSmyagJBbUi65boWU0AsYwZrOosn4eCPIT3TopN47lZ08oOAdUGRF7Q6Sx6WypYbuykVt82Jp2pb8Qq74n1HKNMNG3hkbxfTF6DwHnz9zsRUz2Egmj1lgbQjPb6M/JIloyKMYTCCBY9NPEPREeiK0QBTU6RurqWQEXITuWQKKozek4yrjwIDDbJURL8FJKvv0mM0BiaC26nPXdG0UwKKXTotlY3CdAsKcAqFexmVuoYzj/ukhfKmb4rOUsQ0A77hf8NR42ay1/EES6o9xgImyifPh5+QyKLKMRyHsuK/WRGU5rhZOqXBH8IzihyVsdA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YUNRODlMNkpTVmdOZHNjREtqbGx3eWlTaXFxWHZnU2JPZzV5UzNpeXVNUUpS?= =?utf-8?B?UlA5SVVxdittMld1akpQRWtuRmJTbm5DbmxwYU1Oa1RQbEVIcXRvaTI1dnZF?= =?utf-8?B?THh1d0hKVGxCdTVZbHZ4czdCYlZ1NVNLc3BQYlB0b0U5bFNqYTlYRUY3WG8z?= =?utf-8?B?SERtQVdRMmdRaVA1a0NMSlZpNWY0SWxYa2dnQmd0RjI3TTF5cUpXZ0EyeTlI?= =?utf-8?B?MXROSDdJaGlXbThienFGSWtkRjhjbDBqRUJBaUhjMkNnN2toMUh4bi9yWC9N?= =?utf-8?B?WWZhZ1RMSHZsUE9QRjVSZXNTOHZ5R2NPT2praWpYdmZYdkZ0bDdQdEFtVWtN?= =?utf-8?B?OGc1OE5QTTNINXJ4dmtXUis3TEkrTlEzV21jbXd3dlBvQXk4SXRjYkFCQjRo?= =?utf-8?B?YjhvYjNEMnFiWkVlYzJVb1ROeGYxeDNQYzB3K1BYVkJleXFYOFRhOEROd3Uz?= =?utf-8?B?SEdKd3MzUXNsYS9JbEdJbTNlN09GSGtNOG5RWGlRNlFsSmcyUU1kWnhyK0Mr?= =?utf-8?B?SE83cGU3ZHFwMEZ6a0J0ZkZKaVZKRktaaExlcGMxTjgvS1gvM0RMcTcwbXB3?= =?utf-8?B?NWdFcHROcHQwZ3FDQnVPQjFVTlVSd2g4WHJqSlRQMDNHRGxOcFQvL0xVZS9K?= =?utf-8?B?b2JHSW5URUZOV0QzMW5SYmYxUE9QOFdrWlR4MVRtRUdNa0NOckZoNzlyWXl4?= =?utf-8?B?MzQvZllrQjUzTEJJWEhDeUsrWWlBTngwNlF3L0EyenlIQ3h5SmtwbFNPZWhq?= =?utf-8?B?WGZ5S2VsR2o1c1JzVXhCc05CVEVzd2oyL05XWUFFRHJaSnhaR2w3SXMzNkp0?= =?utf-8?B?dkJBbVI2aUtYVkJQNzRDTHk3S2FVUGxWbTBoRGR0WmI5Y3BZdnpCRy9Wb1Ax?= =?utf-8?B?UC9NUnZtc3Z2WXplemxWazFXNHpkRDZoQU15WVN3cGU0Wk5yalpSNmlkanNt?= =?utf-8?B?UmxlTFVYb1FlODlrWEd2WnoraXM0a0V3Y3RFUTE0NE9wYzJBWlo2SnZGU2cx?= =?utf-8?B?dWJvU2pmMlVPQjJoSElwaFlHZDFmNUdVVytCSGNsQjlYS3ZrWFBQdWpqQ3Zt?= =?utf-8?B?Q3crU29BRmwzTi9tOW40Uy8vVXlia3Q5R0NMOXp3b0ljb2VsVVhZM0pHTWtC?= =?utf-8?B?bTlFWnd6YkFnVjNtWllyeXQ1TGZneW9hY1JBejZmMDhBOHRXRmVYd00rQkNv?= =?utf-8?B?aVNPUnBjZVVxb1Btbmc2SHZlaFZ3WUJ5d21FaWl4cTY5cXJpMXlGS0tIMDNk?= =?utf-8?B?QmxJVUtJWXZMOW5YM042T1k4M3RHbW9zT2YyS3VFeFZGOE9oMGRxcXdyb2g2?= =?utf-8?B?cjhBWTJNQ3V5K24yeTFSMGlveVRpazdob0JoRWRRZnhOVmcxb3BZQVZrNCtT?= =?utf-8?B?aHE5aWZCMTRuU0NmRTlFVEFobG1zTVRjemRLMnM3Ly9IWExpVXBZLzdTWEd6?= =?utf-8?B?bUZqcllqTXEvbFNsMW15UDl4dmEyNzRTd1grSkY2OVpNN2RhdnJRa1ZYVjFW?= =?utf-8?B?ekxMc0JhR1Ric3JZYWZHbEcwTzRqMGxiclVycm9PN0g3Rno5bFpVVVJHTkRE?= =?utf-8?B?dlZ4a09Eb1dVN0NMeDUvWTYyV3hIQmZDc25uV29CaitPQVhaOWdidmJGeXBy?= =?utf-8?B?VExydURWVUdteG9GNGZPTm02a1EwTVdqNzFuTnc5TWprNWdsQjVSNWE5eGEr?= =?utf-8?B?V21tWk0xd0RBNVF5WDZEVVpxaE45ek9uR21oNTVrWDY4TUkxWHhXSzEwTEJq?= =?utf-8?B?Z2tvUk9BbXFWeDZLTkYrbDJpUU1aczRvaU4rdFFQRUpDSlQ5bTllYkkvTXNH?= =?utf-8?B?N2FHbnVpZW43Q05WY0RyWSsrQm1ZellJRmtUM3FIYlZCZEJweXd2ODhsYUVp?= =?utf-8?B?OStVcVJDbzArbUF1azlDT3FkTSsyOEhNYUFSL0hVZlFwRFRtblUvcnhPOGU3?= =?utf-8?B?d0V0SVYyVXRDRElxdUJoa0x2ZVBrMEtEdTVwbjBvUnhIbUpaRUdkVTRxVzdZ?= =?utf-8?B?VFBIM1NCeUxQSnpvUnhhTDJ3ODlKdGdTV2ZLZ0VENHNvVUtWTitSVEF6dXRO?= =?utf-8?B?MFduYjR0N25ITTl4ZWRYWVArdHlqR2IzV01LMDVoN3F6cC9iMXBkaE4zRGgy?= =?utf-8?B?ZXlHanpxbjF6YXhWdUdnRVc3bW40R080S3piWlI5MXJ5LzZCbWd1SnFVN2RC?= =?utf-8?B?Z1pmVGhxeE9PempuNFlqbjRPZ2RGa2FPS0Z3cjlVc1RkcTVYaEVTR0dMQmVh?= =?utf-8?B?NzZqV3Z3b3RUa2VTN0ZHS3JJTmt1VVRoOW56VmdtdHNCRmN6YjVzSDNyUXQ2?= =?utf-8?B?TkEwbnVlT3BvdzBNSnYzZ1AzTVNheDkwSlp2SDB5d0lGakRvSlhGUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7becf6c4-3fc5-41ff-48ed-08de7b85ecf4 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 13:40:27.1235 (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: fUdS/PfFtcuIR2jwS0AB/b0I/Tvphbi/R4H9kK5b6H4TFseRkOlWgIs0Asmx7/YmRGZb8EEq8OPt2MYW3Ij8ag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5196 On Thu, Feb 19, 2026 at 12:44:47PM +0000, Julian Vetter wrote: > > > On 2/9/26 14:16, Roger Pau Monné wrote: > > On Mon, Feb 09, 2026 at 11:34:18AM +0000, Julian Vetter wrote: > >> x2APIC guests with more than 128 vCPUs have APIC IDs above 255, but MSI > >> addresses and IO-APIC RTEs only provide an 8-bit destination field. > >> Without extended destination ID support, Linux limits the maximum usable > >> APIC ID to 255, refusing to bring up vCPUs beyond that limit. So, > >> advertise XEN_HVM_CPUID_EXT_DEST_ID in the HVM hypervisor CPUID leaf, > >> signalling that guests may use MSI address bits 11:5 and IO-APIC RTE > >> bits 55:49 as additional high destination ID bits. This expands the > >> destination ID from 8 to 15 bits. > >> > >> Signed-off-by: Julian Vetter > >> --- > >> xen/arch/x86/cpuid.c | 9 +++++++++ > >> xen/arch/x86/hvm/irq.c | 11 ++++++++++- > >> xen/arch/x86/hvm/vioapic.c | 2 +- > >> xen/arch/x86/hvm/vmsi.c | 4 ++-- > >> xen/arch/x86/include/asm/hvm/hvm.h | 4 ++-- > >> xen/arch/x86/include/asm/hvm/vioapic.h | 13 +++++++++++++ > >> xen/arch/x86/include/asm/msi.h | 3 +++ > >> 7 files changed, 40 insertions(+), 6 deletions(-) > >> > >> diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c > >> index d85be20d86..fb17c71d74 100644 > >> --- a/xen/arch/x86/cpuid.c > >> +++ b/xen/arch/x86/cpuid.c > >> @@ -148,6 +148,15 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf, > >> res->a |= XEN_HVM_CPUID_DOMID_PRESENT; > >> res->c = d->domain_id; > >> > >> + /* > >> + * Advertise extended destination ID support. This allows guests to use > >> + * bits 11:5 of the MSI address and bits 55:49 of the IO-APIC RTE for > >> + * additional destination ID bits, expanding the addressable APIC ID > >> + * range from 8 to 15 bits. This is required for x2APIC guests with > >> + * APIC IDs > 255. > >> + */ > >> + res->a |= XEN_HVM_CPUID_EXT_DEST_ID; > > > > This cannot be unilaterally advertised: you need a QEMU (or in general > > any device model that manages PCI passthrough) to understand the > > extended destination mode. This requires the introduction of > > a new XEN_DOMCTL_bind_pt_irq equivalent hypercall, that can take an > > extended destination ID not limited to 256 values: > > > > struct xen_domctl_bind_pt_irq { > > [...] > > uint32_t gflags; > > #define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0x0000ff > > > > When doing PCI passthrough it's QEMU the entity that decodes the MSI > > address and data fields, and hence would need expanding (and > > negotiation with Xen) about whether the Extended ID feature can be > > advertised. > > > > It would be good to introduce a new XEN_DMOP_* set of hypercalls that > > support Extended ID to do the PCI passthrough interrupt binding. > > Thank you for your feedback. But wouldn't it be enough if QEMU extracts > the additional bits from the gflags and pass it on to XEN? Possibly, you need to use the still unused 7 bits at the top of the flags field AFAICT. > In > pt_irq_create_bind I already extract the additional bits. In QEMU the > function msi_dest_id would just need to extract the additional bits > before calling xc_domain_update_msi_irq. The gflags argument in > xc_domain_update_msi_irq is 32Bits, so there is enough room to pass the > additional bits. What do you think? It's possible. However there's still a question of how does QEMU signal Xen that it implements the extended destination logic?? QMEU and Xen are two separate components, and Xen cannot unilaterally advertise support for Extended IDs if QEMU doesn't actually implement it. You need some kind of negotiation between the device model and Xen. It would IMO be way better if we could simply avoid having to parse the MSI address and data fields in QEMU, and just forward them to Xen. Then Xen could interpret them in whatever format it wants, and there would be no negotiation needed between QEMU and Xen. XEN_DOMCTL_{un}bind_pt_irq hypercalls have no reason to be domctls, it would be much better if we introduced equivalent DM ops, as that would remove toe usage of two unstable hypercalls from QEMU and would bring us closer to QEMU not being tied to running Xen version. Hence my recommendation to take this opportinity to introduce a new pair of DM ops to replace those domctls. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 06 14:22:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 14:22:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247796.1546230 (Exim 4.92) (envelope-from ) id 1vyW3r-00028e-FE; Fri, 06 Mar 2026 14:21:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247796.1546230; Fri, 06 Mar 2026 14:21:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyW3r-00028X-Cg; Fri, 06 Mar 2026 14:21:51 +0000 Received: by outflank-mailman (input) for mailman id 1247796; Fri, 06 Mar 2026 14:21:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyW3q-00028M-ER for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 14:21:50 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9537522a-1967-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 15:20:10 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA3PR03MB8456.namprd03.prod.outlook.com (2603:10b6:208:53c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Fri, 6 Mar 2026 14:20:07 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.017; Fri, 6 Mar 2026 14:20:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9537522a-1967-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HyDyyH3UZz3LLNqtdQFrTZGfKRQSQPYdRjWToHF/2ILjBPrB4NQFkbLkuoU1UmKG7Ln4oFqDEC/ELmBXLR+n2vRsAwLhIKoSiov9U9MkzxiEfwCSUD52HmryQKCLKTKhcLuEH4xPviAS6UZltxtUWXgcotujLwmcaBofoEuSn7kV1EaeomJrnWxA/Hc8caHPvioTz8L4tf28E87gbxAVWtLVS9OrqYMOqLLBJhuFR47rgZtl2q8ApEZ08K5FfUtLuqqXbQN/maPF2xdeDHmRmQkwAqxKmJozSNmj9QjxmY/a+zI5Bvg2l1mJJ6mPFqerfCyYVkqdkYtkq0w8NFmRTQ== 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=2EU4qSkvZhAQNhEkyrOIgureEUnebpHF+nXMaNnoQdY=; b=VGKs6eNGrOu8ffdBin/J65Yms4uy6/d2P5NySTXzcUdrF0IgSTVqzlq24o/cjiX4i8A9Ho9Wdy4oECFUOAna+oJ2xRcBMk6vC7zRIz41Xu9Kd4cJweBUCeqQvg12GypIKn7AaakfsPUYkP4VW3o7aWmGXKZOQl8zc7sp/N0dwQCxolrFlqrC3qMR6nX2ihWQtQDXitRZ84bkWueidrMyvoUFH8j8hX1eegw8MOEZB9vrUBVvp/0zz8P3Usr+a3lmVNFTseUQqE7+UnlWYdIaI+tzTn50Cf2pJKyFZzUfSzSAs7HFi1WU4J+Ipeq32wX3weLvKcRNu6loaovkimczPw== 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=2EU4qSkvZhAQNhEkyrOIgureEUnebpHF+nXMaNnoQdY=; b=MJcHjJ5+Q0vXTSUPZ1sW4Sm0I8WsWZud2Btk95KDAByUIxJZNnn9r6EidjJwy8IEADNJTyLD9plKrnkAyI55viygdfhPBLTjA3TT1lAd3QZo/OESVdyzavYHP8A4BECvSAqYk8P7mKCYckKB4luW5q8uhy/Nmikc3pNHOJtj2yA= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Fri, 6 Mar 2026 15:20:03 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] core-parking: shrink and relocate core_parking_cpunum[] Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MR1P264CA0206.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:56::19) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA3PR03MB8456:EE_ X-MS-Office365-Filtering-Correlation-Id: b344f33b-43f2-47ab-7077-08de7b8b77a0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007; X-Microsoft-Antispam-Message-Info: 4yburyWBAJKpVvUzW3YByqlmoKnnWk7iUnFV6eoDajoxH9omh9x+yv4x923zNK2T4SjIBylQOt1dP4KIIp8PEvcTnoTDjK2IXQUbsy74cFRSafjWVuvtxeuleue/JXfIfP6q0lw4AxO4QF9THtrhqoW8o3tnuI/8h9vS1F7DYnMVBLOqGtX9cqYn4sImccxFYIa2Cy/eF+u7nD4Y+zznDu0ASXB9dlyHSvoBBguF7oXG1K9p7ojdIH4Vw0Eq4IytF9jXU95niBg7N42lD1B+fh3D1LXZLqIa2bmVPC5R62M0XXnqTKqgCA8FJVBJ8s40YM0HGiE+vRM5FPBQThC6+LSa5RrM+s8IO9xnmmhf6hDsvvaISGJ+dHzG7KLmBLRM7uOEiM0umrQIgEUHusEUgVAUYUyYEeltVl6mun9t3lCBZttACXdQhobR5wabbPru32H3WcDSKQjazPOKAEqPXsnUpwagjYteQcghsuorI7bgToi/vG3NcGgdircd3XVNyPDavuQxJ6/9WlQSZ498G4JMIt0Rvu7b/ZTDjnbMEOA/ZdZZisEjKs4XjVtY3ZxADGEmIRC+6kAM9QzhnTiVjSYh//M6s+6NfFKeOo1j8dQuCRsuJS7EEEF5q6xFuhwCaIQLTR/0A32lASr4SrGaeC/pCBWlVZY6asAja1tl2VNPQFuF+i9WTg2VSddgzTkWEUKc8E7C3dv/23Y/ZMU9pTq68D1kJYEAGTT3Ip7AYLY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bk9sdG01OFphZEZXSzNBdWkzY3hpVlNwKzR0dWs2cnQrUUdEc3AxMTgyWEYw?= =?utf-8?B?dmtLYXU3VlFQVklGK1lNdEU0UUx1dmkrTEMrc2sxZmd5eFBaN3lObnZMVVdp?= =?utf-8?B?bGc3NmhnQ1Z4NHFqTUt0QkxSUURDWjhpdHNhZVdRK0pQeXlEZGM4MlhqNTBX?= =?utf-8?B?Z0ZLb1dON2JBakhCTXhPdnpiYS9KMWhjQzB4Vzc1OTE2MytlZFJCRTZQRXE2?= =?utf-8?B?VEEwcjg2WXZ1aExvalRlRUU4ZXozZm9lZjdLdGhwUEg4Wi83YUdpMFdrMWJw?= =?utf-8?B?QmFKYW5sSzJtN0pDVkpKNWJGamlHZ1ZUK1J1QnZnaE1WQnRLN0lXcGlMcWFE?= =?utf-8?B?TlJlTmFqWTlsSzMrQlU4Vkl3WERSYkZkVUt1WE5KNHloNWV2YlZOQmhnYlZV?= =?utf-8?B?NHE0NWxrVEtuM0dETXdVNEE5bSttNjVZS0lEZjBQZkdhTzJZMzd0Y2FQaDVr?= =?utf-8?B?aVJlcVlvRlpkZC9DN1gxOUNXZjhPM1pxTVh4d0hoS0FJOHRCUGx4V1JiSnEx?= =?utf-8?B?enRsZDJmaUlOSTVPZFMyT09jOXlJTXU5ODYzdGo3c3BpNHBFb3FJK25oSkJX?= =?utf-8?B?VVBuMlcrZGlhZkU0dzB2d3ZsbisxWUVqYVl5aWdhaEJGclNnUENUbGRzMHln?= =?utf-8?B?VnQybjJ1bmd6cW9KSndrVmt4Q2tBLzh4LzQwNUMrVVp6Q0ZvTlhGQWh6WlF4?= =?utf-8?B?c0lybGVNK01wT21YdUg5Sm1aTmhQVWJmNjFSSGU2Nkt0MytSNjljK2k1SlR6?= =?utf-8?B?K2hwbmJDL2xJV0I5MW1jZi9HZEltMFlQYVdSdGwrYUpQcnNqaXl3bzVOMDUx?= =?utf-8?B?dHp6QzlKeHlJSmMzYTgwdGp1cU4xVklldFpnbW5hR2pJVTVtRmt1YW16dHFa?= =?utf-8?B?MEs2Nm5mckl3b0hrOCsyMmZ1VzJTd2pBemYvbXJCSVd4VWFuN0xvaStlcnZN?= =?utf-8?B?Y0lMcDcydmR3ZGdlNXFaWVNxdjA5V3k4L2xGK21Nd2dFS1ZoV3BPbHB2ZlY1?= =?utf-8?B?dUtwMVV6MUx3ZGlJem9ZRXVkZUVWbVY3Nkt4RktOR255VFFuN3BZUi93QWp0?= =?utf-8?B?ZnJUVm0vTUJUeEo4WHRIbFNyM3FKSk8xS25ORW9QcDlsRDhyY0NycWVLYlNG?= =?utf-8?B?aDA0a3E1T05PYnRjYlRkZU5ZSm5HWUVORUFMcHNBZVFuYVptZzJKSnNGbWE5?= =?utf-8?B?UWFJZ0hkV3VySDEzdjl4dTl1UnEyVzJhai9pcjJ6dkJpcSsvU3R0eTc3aG5I?= =?utf-8?B?eEYwUjlPOE1tRmJINzVoR1gxOXhEUmpqaUtESFR6VUZjakU1NWUrVVo2SXg1?= =?utf-8?B?TFNpRnAzckRtelltOFM1bHhtcGRYREhPczErQmFTa1A3Zit4OHhuQmRMaXlX?= =?utf-8?B?Uzc4WFRIR01FbzcvNU9LUmNCRWJHVnR5dFc3cHplY2xqMDFJVzZYRFlWS2lX?= =?utf-8?B?Vlc3U1pzRERXRVpwc2kwaVcyVmg5OHFVdmRKWFZDMkoyOEhGMU0rSXJYVElB?= =?utf-8?B?dGFySGVsbkhWckV3RW9Yd3l3S3hpdUNDenl5Rzk3S0NHRTFRbE5UMnc2b214?= =?utf-8?B?RHJSbkRxSkFla1NXejhSRVdUdTc2SzJrTmliUXNyaFZ6Z0NNZEM4aDFyUW1i?= =?utf-8?B?d2lLaTRDT2JQQ1B2MjNaQnhjWmM4aFg3SnB2OVZicTNsWHpMNmE4Yk5Ia0JE?= =?utf-8?B?UGJvaklGdDczZ2YydHZEZmljUTR5MmorSmRCRDBnV1NkSkdkRUpvRTN6SWVX?= =?utf-8?B?V2p2Mk9BZ0QxSEoyQjNJZk80SUVJUGxtMmYxYkFaS0cvTjdvalY1SXJqcDlp?= =?utf-8?B?WDg4ZHFNUEZ2YzhKWmFBV28zQWRDamlkd09Rem40SksvU2dPa05KV3FaUDJK?= =?utf-8?B?eGtjV3hGQ3BPck9wWVM4TURTRXUyaXIwZjNuMllqWEZNTHU2OC9FNVVOWVNV?= =?utf-8?B?WENqY0g2bzFoeGRmaDVvc2NsWlJtTUNsb21VcGlzUlZiaEtFQ3E3YVZQbm9Z?= =?utf-8?B?QnlUVk14bTFhdXNrZUU5LzVkOFZMUFdZYWFOdDJCbG9rWGNlVkNoRkh4TUhE?= =?utf-8?B?M3BlNmo3WGlsMWtaWFlGWjBRQ0tpSEhtbWt3NC9lOE5yYWxrb0drV0wyTXFu?= =?utf-8?B?YVpMQ0VXanpISnFLeGdsVmVOUFRJWFduanZzbXFEbUFEQUxXT0ZKeUs4bVFO?= =?utf-8?B?YmtnN2ZwMHNLMElWNERBcXVKQjZGSEVlbEFKNml4U2NjS2VMVUlPcHVYVEo3?= =?utf-8?B?aEF5L1EycW9sUmhOYlVDc0o0eDlTT1ZENE45R2hzQm9QZ0xjZFRGR3A1Vk1j?= =?utf-8?B?UTgyRlRPcWNlQjZVTmN0TkdnOXgzQTEvUkJvQ20xSGl6Y0tLUEJEdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: b344f33b-43f2-47ab-7077-08de7b8b77a0 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 14:20:07.6346 (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: X2K3mzJpnpCQevumkBoopuWOIHKz3pdrOEJOdeKxLFI0Usqbv0caGX1A/XYmknnkWNl5xuwzOVTpoo484oqgfQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8456 On Wed, Nov 12, 2025 at 04:38:13PM +0100, Jan Beulich wrote: > This NR_CPUS-dimensioned array is likely unused on most installations. > Therefore it is especially wasteful for it to consume more space than > really needed. Use the smallest possible type. > > Further the array having all fields set to -1 is actually useless. Nothing > relies on it, and core_parking_remove() doesn't restore the sentinel for > vacated slots. Drop the initializers, moving the array to .bss. > > Finally take the opportunity and update an adjacent variable's type, where > a fixed-width type was pretty clearly inappropriate to use. > > Signed-off-by: Jan Beulich > --- > I assume there is a reason this is acting (mostly) as a LIFO. Else a > simple cpumask_t would suffice. > > An alternative would be to use the new BRK allocator, at least for NR_CPUS > above a certain threshold. Can't we just allocate this memory using xvzalloc_array()? If we do care about it being too big certainly allocating only when needed, and based on the number of possible CPUs on the system would be much better than playing games with the array type? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247919.1546297 (Exim 4.92) (envelope-from ) id 1vyXzu-0000xD-NN; Fri, 06 Mar 2026 16:25:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247919.1546297; Fri, 06 Mar 2026 16:25:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyXzu-0000wN-JU; Fri, 06 Mar 2026 16:25:54 +0000 Received: by outflank-mailman (input) for mailman id 1247919; Fri, 06 Mar 2026 16:25:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyXzt-0000to-MV for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:25:53 +0000 Received: from na1pdmzitismtp02.tibco.com (unknown [160.101.131.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 220ad409-1979-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:25:48 +0100 (CET) Received: from localhost.localdomain (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 093EE81CB7A9; Fri, 6 Mar 2026 11:25:12 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 220ad409-1979-11f1-9ccf-f158ae23cfc8 From: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD Subject: [PATCH v3 0/1] avoid duplicate symbol errors with clang Date: Fri, 6 Mar 2026 16:25:42 +0000 Message-ID: X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous attempt with .ifndef is not necessarily always correct, and may lead to subtle bugs. The instructions executed from the emulator would always come from the first (and now only) labeled block. Although the approach worked with the existing tests, it may have broken again when more instructions are added in the future. Using -O0 achieves the same outcome as the .ifndef patch (being able to compile the tests with clang), without the drawbacks. Only added -O0 to the test runner code, which is not performance critical. This is a workaround, if a better solution is found then this can be removed. Edwin Török (1): tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 tools/tests/x86_emulator/Makefile | 5 +++++ 1 file changed, 5 insertions(+) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:26:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:26:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247918.1546291 (Exim 4.92) (envelope-from ) id 1vyXzu-0000u6-Fd; Fri, 06 Mar 2026 16:25:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247918.1546291; Fri, 06 Mar 2026 16:25:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyXzu-0000tz-D5; Fri, 06 Mar 2026 16:25:54 +0000 Received: by outflank-mailman (input) for mailman id 1247918; Fri, 06 Mar 2026 16:25:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyXzt-0000to-1k for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:25:53 +0000 Received: from na1pdmzitismtp02.tibco.com (unknown [160.101.131.9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 23815a59-1979-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:25:51 +0100 (CET) Received: from localhost.localdomain (unknown [10.113.40.46]) by na1pdmzitismtp02.tibco.com (Postfix) with ESMTPS id 7130681CBF11; Fri, 6 Mar 2026 11:25:15 -0500 (EST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 23815a59-1979-11f1-9ccf-f158ae23cfc8 From: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD Subject: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Date: Fri, 6 Mar 2026 16:25:43 +0000 Message-ID: X-Mailer: git-send-email 2.47.3 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit clang would duplicate the loop body and end up with a double definition of the symbol: ``` /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is already defined /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is already defined ``` Until a better solution is found: disable all optimizations in the test runner. Using -Os might also work, but we can't rely on the size optimization always avoiding the duplication of asm blocks. This is test code, not performance critical code, and -O0 is more future proof. Signed-off-by: Edwin Török --- Changed since v2: * use -O0 instead of .ifndef (with ifndef the 2nd iteration would use code identical to first) Changed since v1: * use .ifndef directive instead of volatile workaround --- tools/tests/x86_emulator/Makefile | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile index 5003c464f3..ba1d27177f 100644 --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -323,4 +323,9 @@ x86-emulate.o x86_emulate/%.o: HOSTCFLAGS += -D__XEN_TOOLS__ $(call cc-option-add,HOSTCFLAGS-toplevel,HOSTCC,-fno-toplevel-reorder) test_x86_emulator.o: HOSTCFLAGS += $(HOSTCFLAGS-toplevel) +# clang duplicates inline assembly when unrolling loops, +# which causes a duplicate label error. +# Until a better solution is found: disable all optimizations in the test runner. +test_x86_emulator.o: HOSTCFLAGS += -O0 + test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK)) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247972.1546315 (Exim 4.92) (envelope-from ) id 1vyY7U-000348-LJ; Fri, 06 Mar 2026 16:33:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247972.1546315; Fri, 06 Mar 2026 16:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7U-00033o-GU; Fri, 06 Mar 2026 16:33:44 +0000 Received: by outflank-mailman (input) for mailman id 1247972; Fri, 06 Mar 2026 16:33:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7T-00030j-Ew for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:43 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3c87ec6e-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:41 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-439aa2f8ebaso4138738f8f.2 for ; Fri, 06 Mar 2026 08:33:41 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:40 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3c87ec6e-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814821; x=1773419621; 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; bh=CmbbmA8PgeTF4OMY1R9mkMVOPj+EWhxjWMhkhMqQixw=; b=mt6XOoSBpqL5RjnQGdAQcigJHrRF2kgeuKl1kMY1nKq2adZ4nI4MHD8DQma9xxve3y Jrs4UVCdZfFBwi275d2Zq2CBhglHblYmDRQxSOMR/9WbkpYitLp1XPk2SVh93AO8btX3 F4uCr77wt67dhNyO5oIPdmgGELQoa5xc7fqnVX9DlwdQpzuF++55gypKVMMm5VKrG8O0 /wot/Dk6AjO8lt6Ous9KxQNuaRA53AuLxyBwsL7t+KOSSlnLgYOCCgX4nKmnnALKOroN rg3XpSi/pMmwnVdarLHhiEkxhRYj0phnqHvLd2H0G7hkjT5xTxEdXLUoWxLDLYhVailz CnNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814821; x=1773419621; 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; bh=CmbbmA8PgeTF4OMY1R9mkMVOPj+EWhxjWMhkhMqQixw=; b=qv1/AGNTx+r9gmJQYBIkb8u8FYGoC/sSeCr8JCy9zd9AYku3b3Eq1/Ke+dCyxhnU6X jKM8u6j5MqEBcAnnhV8Qki1qGpmGbd7CTBYVIeSF0mgK6RCId1OSnJx3DXSH2Ar9tr23 LN2k/J2qC0+XDglcdCB5RjWT9xjDFTxd9BWRaokeXj90YFADNi/rdPAGHl9wD+ZNyACW QRBzxjyS//L+BHD7uNaO6ezFWeIRYp/qXJZyPOgg+hOL8yukgVuCWm+5EiarlKDfJwtp e0qa416kuLq72jxk8SCsSBpaT0DOAk0EE6BDwr9bS+IGhXHeeBW+kjkeEvejp5581pcC Th8w== X-Gm-Message-State: AOJu0YzoFswGwjb+vOJXKacpXyf0kLcoVC8Gr9gJl3uIfHTCY4ijvhdr laE0N0neh8AKuLhhF2kuj1A6iyC0n01qbe2yNFMBsLRByUaM57g/Ni/OHuiglQ== X-Gm-Gg: ATEYQzxtB0P+cHXbMSF5ksOoiBkK1wU163U21kmRQw34f3MzATz34o9eAqLAqXGLDUG 7dnfoK9M7P1vjhAHbLVCG5Us5sxRKaWHwxcfY+y4nt+4sZrT+zRaSMUVUz7JgPE3u3ZwwCqAIxo 2FkmKonT2WabknwieQoexAwgGPboHlCKcfwnu+jBtG7w55aggSISV/2oDuN7ep1uHd1Iw29v8lx lr8hHA7FbNBcYeqA8HYZlZGMQjQ4Om5vlMkkAv7fNb1RFDxpZEzGmUs07KXl969vyPiMD4RW7Sh JwXW0wh9AnZqCYN8+el5uVjVGetheNBwd/fqpxAXNKpJiZRtjKfjo7ijrRBiXhVyEkQwxy/6MtY scyrWEWkqmTs//0nPuIFdbeyvfv7shbt4Pyy4zZOnoPDnytFN+CYavw5YWDt5HClWjz7aAHUmGD UI0/OaKFBCjYO9fR8pc5fUTX2orwDXkhUdUuHZwxuBLV0BHWBwoSbDmZsVODXwKLRMkgKF8AYrn 6m4 X-Received: by 2002:a05:6000:2313:b0:431:808:2d58 with SMTP id ffacd0b85a97d-439da8a147bmr5202646f8f.51.1772814820844; Fri, 06 Mar 2026 08:33:40 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot Date: Fri, 6 Mar 2026 17:33:18 +0100 Message-ID: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some hypervisor CSRs expose optional functionality and may not implement all architectural bits. Writing unsupported bits can either be ignored or raise an exception depending on the platform. Detect the set of writable bits for selected hypervisor CSRs at boot and store the resulting masks for later use. This allows safely programming these CSRs during vCPU context switching and avoids relying on hardcoded architectural assumptions. Use csr_read()&csr_write() instead of csr_swap()+all ones mask as some CSR registers have WPRI fields which should be preserved during write operation. Also, ro_one struct is introduced to cover the cases when a bit in CSR register (at the momemnt, it is only hstateen0) may be r/o-one to have hypervisor view of register seen by guest correct. Masks are calculated at the moment only for hedeleg, henvcfg, hideleg, hstateen0 registers as only them are going to be used in the follow up patch. If the Smstateen extension is not implemented, hstateen0 cannot be read because the register is considered non-existent. Instructions that attempt to access a CSR that is not implemented or not visible in the current mode are reserved and will raise an illegal-instruction exception. Signed-off-by: Oleksii Kurochko --- Changes in V7: - Use csr_read_set() in INIT_CSR_MASK() instead of csr_read()+csr_write(). - Add undef of INIT_CSR_MASK(). - Move local variable old above INIT_CSR_MASK(). - Introduce INIT_RO_ONE_MASK() to init csr_masks.ro_one.* fields. - Introduce defines for masks intead of constants. - Move old variable inside macros INIT_CSR_MASK() and INIT_RO_ONE_MASK(). --- Changes in V6: - Introduce sub-struct ro_one inside csr_masks to cover the case that hstateen0 could have read-only-one bits. - Refacotr init_csr_masks() to handle hstateen0 case when a bit is r/o-one and handle WPRI fields properly. - Update the commit message. --- Changes in V5: - Move everything related to csr_masks to domain.c and make it static. - Move declaration of old variable in init_csr_masks() inside INIT_CSR_MASK. - Use csr_swap() in INIT_CSR_MASK(). --- Changes in V4: - Move csr_masks defintion to domain.c. Make it static as at the moment it is going to be used only in domain.c. - Rename and refactor X macros inside init_csr_masks(). --- Changes in V3: - New patch. --- xen/arch/riscv/domain.c | 57 ++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/setup.h | 2 ++ xen/arch/riscv/setup.c | 2 ++ 3 files changed, 61 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index b60320b90def..32974cb48929 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -2,9 +2,66 @@ #include #include +#include #include #include +#include +#include + +struct csr_masks { + register_t hedeleg; + register_t henvcfg; + register_t hideleg; + register_t hstateen0; + + struct { + register_t hstateen0; + } ro_one; +}; + +static struct csr_masks __ro_after_init csr_masks; + +#define HEDELEG_AVAIL_MASK ULONG_MAX +#define HIDELEG_AVAIL_MASK ULONG_MAX +#define HENVCFG_AVAIL_MASK _UL(0xE0000003000000FF) +#define HSTATEEN0_AVAIL_MASK _UL(0xDE00000000000007) + +void __init init_csr_masks(void) +{ + /* + * The mask specifies the bits that may be safely modified without + * causing side effects. + * + * For example, registers such as henvcfg or hstateen0 contain WPRI + * fields that must be preserved. Any write to the full register must + * therefore retain the original values of those fields. + */ +#define INIT_CSR_MASK(csr, field, mask) do { \ + register_t old = csr_read_set(CSR_##csr, mask); \ + csr_masks.field = csr_swap(CSR_##csr, old); \ + } while (0) + +#define INIT_RO_ONE_MASK(csr, field, mask) do { \ + register_t old = csr_read_clear(CSR_HSTATEEN0, mask); \ + csr_masks.ro_one.field = csr_swap(CSR_##csr, old) & mask; \ + } while (0) + + INIT_CSR_MASK(HEDELEG, hedeleg, HEDELEG_AVAIL_MASK); + INIT_CSR_MASK(HIDELEG, hideleg, HIDELEG_AVAIL_MASK); + + INIT_CSR_MASK(HENVCFG, henvcfg, HENVCFG_AVAIL_MASK); + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + { + INIT_CSR_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); + INIT_RO_ONE_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); + } + +#undef INIT_CSR_MASK +#undef INIT_RO_ONE_MASK +} + static void continue_new_vcpu(struct vcpu *prev) { BUG_ON("unimplemented\n"); diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h index c9d69cdf5166..2215894cfbb1 100644 --- a/xen/arch/riscv/include/asm/setup.h +++ b/xen/arch/riscv/include/asm/setup.h @@ -11,6 +11,8 @@ void setup_mm(void); void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); +void init_csr_masks(void); + #endif /* ASM__RISCV__SETUP_H */ /* diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 9b4835960d20..bca6ca09eddd 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -137,6 +137,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, riscv_fill_hwcap(); + init_csr_masks(); + preinit_xen_time(); intc_preinit(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247971.1546309 (Exim 4.92) (envelope-from ) id 1vyY7U-000311-DF; Fri, 06 Mar 2026 16:33:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247971.1546309; Fri, 06 Mar 2026 16:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7U-00030u-9x; Fri, 06 Mar 2026 16:33:44 +0000 Received: by outflank-mailman (input) for mailman id 1247971; Fri, 06 Mar 2026 16:33:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7S-00030j-QG for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:42 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3bf053f2-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:41 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-439b7a87fb5so3755447f8f.3 for ; Fri, 06 Mar 2026 08:33:41 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:39 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3bf053f2-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814820; x=1773419620; 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; bh=Tk71eqXgwXytuAS2ZjjNkmU2hi0kcr9lEEqFsgwbDFA=; b=GJvR+FzGt/+QNcgJTeygcXgCgdsEIvUSWgpXlyMu5CqWy9F9SLTZtsVdjbiytt9WPV VUJ2ra4o/ViCf9ohMOAOecz5DmFT0ypx9v4KUkfft2P5XvWUixEYJA4fqgId3Exw0EmX sQbR1JjSztsJD1rxgrIDFxdskJxmuZZHbrbLKOPA8Dlz3rHt8flAFaUr2v5eTyzRaepP dosY0llyAOCx7ZEO291rsOiq7LeB6ovijlTMwU0wFDQrwe2EqS/GRk95PajncrBl6bRc /OOPvnTuZPPRspTF+VhT+axg2YXb8P0iJpebA2HgGtD/5yNe6F6rStHjmN35YCrAXHIC Cnmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814820; x=1773419620; 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; bh=Tk71eqXgwXytuAS2ZjjNkmU2hi0kcr9lEEqFsgwbDFA=; b=FUZzyfgmQ76oJSRzLRjMkrd4gEpj3G77tM2/vqyQ16XwwWcBYfeGx1FPo7H2zFc0zK AEJxt7t3aOgNqcldAdF29sTvfz32SbPoNZGfTf5XMXZytpiiZq69wfalTSelYSeNtX9f +GDVO729MehqlDPI+lKF7yHfu3foMYKveKuoBubtXmOvQvixgipo9vzW/lIhOCB3YxYb IWGkn03lKS4twIa30gJbu5yKFquFOX3kZ5RvxLmfJz7mi2Ruxg3OsSiFECIyK7rddBc6 OOzUKQTMkz4NngiR8er+wWeUyeVXg5FI3vQ2WZr9rFuR9QP9gX4XUIJ2fj6/ev2hOKXO Q91g== X-Gm-Message-State: AOJu0YymLOpW/gd5hiFTr8MLOCXtRL+A/S0wTxhqkY1YSw1w7CKlqFws Pb2G2lfN+5sGi/9VmsJWSRAoku39r7I3p+4z9gR0F80RP3MXStN1mOd+Cn+t+g== X-Gm-Gg: ATEYQzy0cy2XzN2GrVwRwP9rWKkZAIRPceI0LAJJbFpla1NFRTa3THB7OAqBS881SQh D66szOmXSkpwZiFuJpUoisc6fCsTKCHFjXCbk3VhtsQHnOJYN8duAJ5q77yAMdcO4JewB6A6x3k NFjICkQ8KEyw/A//17J5ktCtGcKgznThx8uncYvZnaH0AkfufTFTfoknG6OHJnRw3ZZLjoH4x97 OEfuMyRh7v4e0E0DnsJtULfEdYvTX/Kc1J83hqbdnvIdL7IHoLXMykFlswwXTlA0fSNvDu0jMRS Q4JftucgOZOS8JPsHuGEGQ7LJfTlpDuOTc91a6/CuEpXyzSN5C18AseiNgMqoEpke+2CXn6Pho1 bmK2JDtV2jVPomymU2dPWHO3SM3+7UJbEsn9e/r6vkekDr/Yg/NUW66BKw7A9fnPLwYTeHXr3Cc DE3JPDzSALDHT2kP6stONlIRS7Hxkj3Q1kGKJ9oh9g6crNsSG2pNDFMw0IIEqcSxFbDg== X-Received: by 2002:a05:6000:40cb:b0:439:ba75:7db0 with SMTP id ffacd0b85a97d-439da3488f6mr5176945f8f.1.1772814819810; Fri, 06 Mar 2026 08:33:39 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini , Doug Goldstein Subject: [PATCH v7 00/14] xen/riscv: introduce vtimer related things Date: Fri, 6 Mar 2026 17:33:17 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch series introduces the components necessary to implement a virtual timer (vtimer). Since the SSTC extension is not supported by Xen, an emulated (SBI-based) timer is required. To address this, a virtual timer built on Xen’s timer infrastructure is introduced, with save/restore support and SBI-based programming. To provide full guest software–based timer support, the following components are also introduced: - arch_vcpu_{create,destroy}() to initialize the virtual timer and other vCPU-related state not directly tied to timer functionality. As part of this work, struct arch_vcpu is introduced to describe the internal state of a virtual CPU, along with vcpu_csr_init() to initialize the relevant CSR state. - Support functions required by the virtual timer, including: - vcpu_kick(), and a stub implementation of smp_send_event_check_mask() (since SMP is not yet supported in Xen), which is used by vcpu_kick(). - Support for guest timer programming via interception of the SBI legacy SET_TIMER call from guest. - Implement reprogram_timer() using introduced sbi_set_timer(). - Initial lockless tracking of pending vCPU interrupts using atomic bitmaps. - Handling of hypervisor timer interrupts and dispatch into Xen’s generic timer softirq. CI tests: https://gitlab.com/xen-project/people/olkur/xen/-/pipelines/2368929819 --- Changes in v7: - Merged to upstream/staging: - xen/time: move ticks<->ns helpers to common code - Add Acked-by for Patch 2: xen/riscv: implement vcpu_csr_init(). - Address comments from ML for patch 1 and 3. - Add new patch to detect availabilty of SSTC. IMO, it is okay to have this patch separetely as at the moment it won't be an issue if Xen will use CSR_STIMECMP to setup its timer. The issue will start to occur when a guest will run. --- Changes in v6: - Address comments from ML for patch 1 and 3, and minor update of patch 2 because of introduced ro_one sub-struct in patch 1. --- Changes in v5: - Merged to upstream/staging: xen/riscv: implement arch_vcpu_{create,destroy}() xen/riscv: build setup code as .init - Rebase this patch series on top of: https://lore.kernel.org/xen-devel/5756356294dc066d835269334d0f3347fe24cec4.1771504676.git.oleksii.kurochko@gmail.com/T/#u There is no logical dependency, only the potential merge conflict question. - Address comments from ML. --- Changes in v4: - Merged to upstream/staging: xen/riscv: avoid reading hstateen0 when Smstateen is not implemented - Address other comments from ML. --- Changes in v3: - Squash patch "xen/riscv: introduce struct arch_vcpu" into other patches of the patch series. - Merged to staging: - xen/riscv: implement stub for smp_send_event_check_mask() - Address other comments from ML. --- Changes in v2: - Add consumer part of tracking of pending vCPU interrupts. - Split patch "xen/riscv: init tasklet subsystem" to two. - Patches were acked: - xen/riscv: introduce vcpu_kick() implementation - xen/riscv: implement SBI legacy SET_TIMER support for guests - All other changes are patch-specific. Please check them. --- Oleksii Kurochko (14): xen/riscv: detect and store supported hypervisor CSR bits at boot xen/riscv: implement vcpu_csr_init() xen/riscv: introduce tracking of pending vCPU interrupts, part 1 xen/riscv: introduce tracking of pending vCPU interrupts, part 2 xen/riscv: introduce basic vtimer infrastructure for guests xen/riscv: introduce vcpu_kick() implementation xen/riscv: add vtimer context switch helpers xen/riscv: implement SBI legacy SET_TIMER support for guests xen/riscv: introduce sbi_set_timer() xen/riscv: implement reprogram_timer() via SBI xen/riscv: handle hypervisor timer interrupts xen/riscv: init tasklet subsystem xen/riscv: implement sync_vcpu_execstate() xen/riscv: Disable SSTC extension and add trap-based CSR probing automation/scripts/qemu-smoke-riscv64.sh | 2 +- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/cpufeature.c | 8 + xen/arch/riscv/domain.c | 244 +++++++++++++++++++- xen/arch/riscv/entry.S | 24 ++ xen/arch/riscv/include/asm/Makefile | 1 - xen/arch/riscv/include/asm/csr.h | 32 +++ xen/arch/riscv/include/asm/current.h | 2 + xen/arch/riscv/include/asm/domain.h | 32 +++ xen/arch/riscv/include/asm/perfc_defn.h | 3 + xen/arch/riscv/include/asm/riscv_encoding.h | 2 + xen/arch/riscv/include/asm/sbi.h | 22 ++ xen/arch/riscv/include/asm/setup.h | 2 + xen/arch/riscv/include/asm/traps.h | 7 + xen/arch/riscv/include/asm/vtimer.h | 20 ++ xen/arch/riscv/riscv64/asm-offsets.c | 7 +- xen/arch/riscv/sbi.c | 40 +++- xen/arch/riscv/setup.c | 5 + xen/arch/riscv/stubs.c | 20 -- xen/arch/riscv/time.c | 43 ++++ xen/arch/riscv/traps.c | 20 ++ xen/arch/riscv/vsbi/legacy-extension.c | 6 + xen/arch/riscv/vtimer.c | 86 +++++++ 23 files changed, 603 insertions(+), 26 deletions(-) create mode 100644 xen/arch/riscv/include/asm/perfc_defn.h create mode 100644 xen/arch/riscv/include/asm/vtimer.h create mode 100644 xen/arch/riscv/vtimer.c -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247975.1546340 (Exim 4.92) (envelope-from ) id 1vyY7X-0003eV-Il; Fri, 06 Mar 2026 16:33:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247975.1546340; Fri, 06 Mar 2026 16: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 ) id 1vyY7X-0003ba-Bi; Fri, 06 Mar 2026 16:33:47 +0000 Received: by outflank-mailman (input) for mailman id 1247975; Fri, 06 Mar 2026 16:33:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7V-0003HN-WB for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:46 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3dc3ba86-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:44 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439b9b1900bso4299530f8f.1 for ; Fri, 06 Mar 2026 08:33:44 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:42 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3dc3ba86-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814823; x=1773419623; 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; bh=DcWp8tIlICTUgFr+LU+saMi86aGyTwCcvYFlYuFIRRk=; b=KRPZG7dZyCZNZGjpBS5IUC7r6ZsyRIZsyuaY7xmyq2EjeZddTAczAlZnTsrp2t2Nek nV1ttMciT5mwMEgjdTJAbOidGKv+m8JYqgkHXmN72rY/OugK0Omf7tZTwYCMey9gKaIz L9S9N4pOj4gkO6nz7C9uQgTbpLhwZmh2/Cvwh++qqrUPw3B7KqLFeoiUwW92DX4l+uRu coFUv2iLTG7JT64Z9KkDTmF4hQ8JSXErV1t6YFeaVW8PtUa5SP20KYUNZrsKFHJEn33N I31tWscGFK0mxu/Po9cBdDuSqXoqCbM4BkorOpokZbGOgdcE34BSP1DKoFOGAJkTu1Oe SxNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814823; x=1773419623; 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; bh=DcWp8tIlICTUgFr+LU+saMi86aGyTwCcvYFlYuFIRRk=; b=gVZquIZlFhsWifJfLM3eBPufX0BOT96Pj9LUuSAvJFlEHf3ziTiJj62H6ohGkdOPP1 0Jgw5ZkiiXD4p+qabVi/6dwS62GArelqRa30vhnwdytkb+3eSS3+NAHCXE5k9LAuUG37 y/khlb9pc8DW8l6ArIPdC6Kp05DrFwPG/Lq+X2Z0X2D+vrf3qJjgmIwt2sOc+fLLLDTT juoZAGPpEzWEPwr9y7O8q83ZQTbR+PTaGOUGKreW801ixdgivtGHo3qQPzu+pm2PE3Ll 3QUznJ+eyuSCDpaEWQgZyvuxrmZEksn9MJqtgLP5J5c8RqK9sA1ncXk9uaIbz6zlvbrm 0X6A== X-Gm-Message-State: AOJu0YwfJ9J0cJmVQXGRNfGbWlQtGXIiZDXMyqkSHD5n2hYxxtexDCx7 oZnLEUxRBEdeiQP/B+xFOP3HDtvH7raB0lLrGQf/IVtIt42jyHpS38JiDA5cSg== X-Gm-Gg: ATEYQzya5SeRGt0u28B7xfejCZojsYNKeCSaKz7VGi1/OL/VigQze+3qhDfpmgOH4zz LiCyxJtpO+zFqaX2uRLz7Q0STeVqw2qMa7T3Qll+8j4vee0/X01Of+zpDHeb0kjTCBLq2bB4iOZ IIpUrBctPpJvIZaUQOtenxZk6tjCk3V9W4bBqIXP91VUeXWaaD4lLqeGdOz5AHzWLc85M6KGXvj FM5WL5i1bZsUTEGGKrhCDCNkN00ITGCmXDCXlRMI1qe4cnCk5vMtrn4lJJ7IgiAanWR75b8J13v c5P0fKLh5ev7qBn4sV0Q9R/OsjoOVd64RhvWJI5ph2DDzHAJkVqMo+8S3Ifa0aHBhCosuB0c3ou /aeMtEAFf8HB4366lCkhdlu3dWzYdWB/UXsrDTl6yK/FNO9fMsnnYRm9yrsRLO8Ig17hcNEKu5t v5cs+I8rt8rYigWWWXvwYWuKO01uvbN8guhEIzXvIuY/2laSN8P8feBQrk7vc3e8ppdQ== X-Received: by 2002:a05:6000:26cc:b0:439:cb9f:d635 with SMTP id ffacd0b85a97d-439da8954e4mr4677118f8f.46.1772814823035; Fri, 06 Mar 2026 08:33:43 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 Date: Fri, 6 Mar 2026 17:33:20 +0100 Message-ID: <949104bf183688fa0416845fe7e3c19c2c5b2a2d.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Based on Linux kernel v6.16.0. Note that smp_wmb() is used instead of smp_mb__before_atomic() as what we want to guarantee that if a bit in irqs_pending_mask is obversable that the correspondent bit in irqs_pending is observable too. Add lockless tracking of pending vCPU interrupts using atomic bitops. Two bitmaps are introduced: - irqs_pending — interrupts currently pending for the vCPU - irqs_pending_mask — bits that have changed in irqs_pending The design follows a multi-producer, single-consumer model, where the consumer is the vCPU itself. Producers may set bits in irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is performed only by the consumer via xchg(). The consumer must not write to irqs_pending and must not act on bits that are not set in the mask. Otherwise, extra synchronization should be provided. On RISC-V interrupts are not injected via guest registers, so pending interrupts must be recorded in irqs_pending (using the new vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating HVIP before returning control to the guest. The consumer side is implemented in a follow-up patch. A barrier between updating irqs_pending and setting the corresponding mask bit in vcpu_set_interrupt()/vcpu_unset_interrupt() guarantees that if the consumer observes a mask bit set, the corresponding pending bit is also visible. This prevents missed interrupts during the flush. It is possible that a guest could have pending bit in the hardware register without being marked pending in irq_pending bitmap as: According to the RISC-V ISA specification: Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and interrupt-enable bits for VS-level software interrupts. VSSIP in hip is an alias (writable) of the same bit in hvip. Additionally: When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and hie.VSSIE. This means the guest may modify vsip.SSIP, which implicitly updates hip.VSSIP and the bit being written with 1 would also trigger an interrupt as according to the RISC-V spec: These conditions for an interrupt trap to occur must be evaluated in a bounded amount of time from when an interrupt becomes, or ceases to be, pending in sip, and must also be evaluated immediately following the execution of an SRET instruction or an explicit write to a CSR on which these interrupt trap conditions expressly depend (including sip, sie and sstatus). What means that IRQ_VS_SOFT must be synchronized separately, what is done in vcpu_sync_interrupts(). Note, also, that IRQ_PMU_OVF would want to be synced for the similar reason as IRQ_VS_SOFT, but isn't sync-ed now as PMU isn't supported now. For the remaining VS-level interrupt types (IRQ_VS_TIMER and IRQ_VS_EXT), the specification states they cannot be modified by the guest and are read-only because of: Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable bits for VS-level external interrupts. VSEIP is read-only in hip, and is the logical-OR of these interrupt sources: • bit VSEIP of hvip; • the bit of hgeip selected by hstatus.VGEIN; and • any other platform-specific external interrupt signal directed to VS-level. Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the logical-OR of hvip.VSTIP and any other platform-specific timer interrupt signal directed to VS-level. and When bit 10 of hideleg is zero, vsip.SEIP and vsie.SEIE are read-only zeros. Else, vsip.SEIP and vsie.SEIE are aliases of hip.VSEIP and hie.VSEIE. When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE. and also, Bits sip.SEIP and sie.SEIE are the interrupt-pending and interrupt-enable bits for supervisor-level external interrupts. If implemented, SEIP is read-only in sip, and is set and cleared by the execution environment, typically through a platform-specific interrupt controller. Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable bits for supervisor-level timer interrupts. If implemented, STIP is read-only in sip, and is set and cleared by the execution environment Thus, for these interrupt types, it is sufficient to use vcpu_set_interrupt() and vcpu_unset_interrupt(), and flush them during the call of vcpu_flush_interrupts() (which is introduced in follow up patch). vcpu_sync_interrupts(), which is called just before entering the VM, slightly bends the rule that the irqs_pending bit must be written first, followed by updating the corresponding bit in irqs_pending_mask. However, it still respects the core guarantee that the producer never clears the mask and only writes to irqs_pending if it is the one that flipped the corresponding mask bit from 0 to 1. Moreover, since the consumer won't run concurrently because vcpu_sync_interrupts() and the consumer path are going to be invoked sequentially immediately before VM entry, it is safe to slightly relax this ordering rule in vcpu_sync_interrupts(). Signed-off-by: Oleksii Kurochko --- Changes in v7: - Drop ifdef RV32 in vcpu_sync_interrupts(). It will be introduced later when it will be more clear from the context why it is needed in this function. - Rename vcpu_sync_interrups()'s argument to curr and add ASSERT(curr == current). --- Changes in v6: - Drop for the moment: /* Read current HVIP and VSIE CSRs */ v->arch.vsie = csr_read(CSR_VSIE); from vcpu_sync_interrupts() as it isn't used at the moment and will be introduced when a usage will be more clear. --- Changes in v5: - Update the commit message(). - Rename c to curr. - Update vcpu_set_interrupt() to use test_and_set_bit() for irqs_pending bitmask too. - Move #ifdef CONFIG_RISCV_32 above the comment in vcpu_sync_interrupts(). --- Changes in v4: - Update the commit message. - Update the comments in vcpu_(un)set_interrupt() and add the the comment above smp_wmb() barrier. - call vcpu_kick() only if the pending_mask bit going from 0 to 1. - Code style fixes. - Update defintion of RISCV_VCPU_NR_IRQS to cover potential RV128 case and the case if AIA isn't used. - latch current into a local variable in check_for_pcpu_work(). --- Changes in v3: - Use smp_wb() instead of smp_mb__before_atomic(). - Add explanation of the change above in the commit message. - Move vcpu_sync_interrupts() here to producers side. - Introduce check_for_pcpu_work() to be clear from where vcpu_sync_interrupts() is called. --- Changes in V2: - Move the patch before an introduction of vtimer. - Drop bitmap_zero() of irqs_pending and irqs_pending_mask bitmaps as vcpu structure starts out all zeros. - Drop const for irq argument of vcpu_{un}set_interrupt(). - Drop check "irq < IRQ_LOCAL_MAX" in vcpu_{un}set_interrupt() as it could lead to overrun of irqs_pending and irqs_pending_mask bitmaps. - Drop IRQ_LOCAL_MAX as there is no usage for it now. --- xen/arch/riscv/domain.c | 63 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 22 ++++++++++ xen/arch/riscv/traps.c | 4 ++ 3 files changed, 89 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 08b990f7b9f6..5447c17402dd 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -6,6 +6,7 @@ #include #include +#include #include #include #include @@ -168,6 +169,68 @@ void arch_vcpu_destroy(struct vcpu *v) vfree((void *)&v->arch.cpu_info[1] - STACK_SIZE); } +int vcpu_set_interrupt(struct vcpu *v, unsigned int irq) +{ + bool kick_vcpu; + + /* We only allow VS-mode software, timer, and external interrupts */ + if ( irq != IRQ_VS_SOFT && + irq != IRQ_VS_TIMER && + irq != IRQ_VS_EXT ) + return -EINVAL; + + kick_vcpu = !test_and_set_bit(irq, v->arch.irqs_pending); + + /* + * The counterpart of this barrier is the one encoded implicitly in xchg() + * which is used in consumer part (vcpu_flush_interrupts()). + */ + smp_wmb(); + + kick_vcpu |= !test_and_set_bit(irq, v->arch.irqs_pending_mask); + + if ( kick_vcpu ) + vcpu_kick(v); + + return 0; +} + +int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq) +{ + /* We only allow VS-mode software, timer, external interrupts */ + if ( irq != IRQ_VS_SOFT && + irq != IRQ_VS_TIMER && + irq != IRQ_VS_EXT ) + return -EINVAL; + + clear_bit(irq, v->arch.irqs_pending); + /* + * The counterpart of this barrier is the one encoded implicitly in xchg() + * which is used in consumer part (vcpu_flush_interrupts()). + */ + smp_wmb(); + set_bit(irq, v->arch.irqs_pending_mask); + + return 0; +} + +void vcpu_sync_interrupts(struct vcpu *curr) +{ + unsigned long hvip = csr_read(CSR_HVIP); + + ASSERT(curr == current); + + /* Sync-up HVIP.VSSIP bit changes done by Guest */ + if ( ((curr->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL)) && + !test_and_set_bit(IRQ_VS_SOFT, &curr->arch.irqs_pending_mask) ) + { + if ( hvip & BIT(IRQ_VS_SOFT, UL) ) + set_bit(IRQ_VS_SOFT, &curr->arch.irqs_pending); + else + clear_bit(IRQ_VS_SOFT, &curr->arch.irqs_pending); + } +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 17be792afe7d..1ecfe18c8519 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -54,8 +54,25 @@ struct arch_vcpu { register_t hideleg; register_t henvcfg; register_t hstateen0; + register_t hvip; register_t vsatp; + + /* + * VCPU interrupts + * + * We have a lockless approach for tracking pending VCPU interrupts + * implemented using atomic bitops. The irqs_pending bitmap represent + * pending interrupts whereas irqs_pending_mask represent bits changed + * in irqs_pending. Our approach is modeled around multiple producer + * and single consumer problem where the consumer is the VCPU itself. + * + * DECLARE_BITMAP() is needed here to support 64 vCPU local interrupts + * on RV32 host. + */ +#define RISCV_VCPU_NR_IRQS MAX(BITS_PER_LONG, 64) + DECLARE_BITMAP(irqs_pending, RISCV_VCPU_NR_IRQS); + DECLARE_BITMAP(irqs_pending_mask, RISCV_VCPU_NR_IRQS); }; struct paging_domain { @@ -94,6 +111,11 @@ static inline void update_guest_memory_policy(struct vcpu *v, static inline void arch_vcpu_block(struct vcpu *v) {} +int vcpu_set_interrupt(struct vcpu *v, unsigned int irq); +int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq); + +void vcpu_sync_interrupts(struct vcpu *curr); + #endif /* ASM__RISCV__DOMAIN_H */ /* diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 9fca941526f6..551f886e3a69 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -171,6 +171,10 @@ static void do_unexpected_trap(const struct cpu_user_regs *regs) static void check_for_pcpu_work(void) { + struct vcpu *curr = current; + + vcpu_sync_interrupts(curr); + p2m_handle_vmenter(); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247973.1546328 (Exim 4.92) (envelope-from ) id 1vyY7W-0003Rt-QB; Fri, 06 Mar 2026 16:33:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247973.1546328; Fri, 06 Mar 2026 16: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 ) id 1vyY7W-0003Rm-NR; Fri, 06 Mar 2026 16:33:46 +0000 Received: by outflank-mailman (input) for mailman id 1247973; Fri, 06 Mar 2026 16:33:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7V-0003HN-BP for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:45 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3d1f88e6-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:42 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-483703e4b08so92166675e9.1 for ; Fri, 06 Mar 2026 08:33:42 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:41 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d1f88e6-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814822; x=1773419622; 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; bh=CzQC2ov+xYcuBZPHbnymUYPvOXLbca5uUsTK8SmNRMc=; b=ZFs5by6RhXhoDd7Xfev6/OC0yC/6Q+DO+L2wRqeSNMljxn9pBcPyWZ3kaJggx/ybUN RGr99E2GvVJJr/IXIwB5SzjvZ2taWxTquPhNcDwgvQPwS7POJOnDF6eNx9PZvexeJMS/ WppRZqcSgWbY08lr5kXh9jkuDYSbnOeRQ4rs3jgUQNHS6MwSS3Ao/oGc1iRLQEEBa9ry IRuuRKXAGLEEeNNX7/XPVAn++LVI7VtaXZjjHokf2xbR/hmdNGXP/kjBepM3Ci3R5F6L lzV6vw0zmYMSriHkH6+rQBWeu4UjfjJFzioHoLktjfD9fXg0ZUVTmYSZ/YBzmHWPxSJl avAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814822; x=1773419622; 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; bh=CzQC2ov+xYcuBZPHbnymUYPvOXLbca5uUsTK8SmNRMc=; b=P/OkvASnzkwwRbh5MeMOMZH5NPCw0bE6/WURsrXPAxsyqAy45DMdgRKUJH+Y/jaDt7 Qj8+eiJPNG+yIDfTbiKo98qe67Hm7MccSiNQvNBjoAeSuzEZFHV26rFQBEF+Aucvjxhr KI7Hr7olVCgi2XGDqBGmXVtFSsA4nyDilbY5c4jaRWPba/T0uyxdHEIpkgI6SDk8YKSI sdPTPXjDbS84RZx8N4Ijj65tBuf2il8G40GSA6dtRLYKdnq7JM5Zcwx+U3IypQxAolYW 78L1pN+ooddzdjE3yIBxyQaDq3m0mBTGnjPpR0epf6eEI9UZOfW3PPC4QsN9/ORdV8Gw Hs6w== X-Gm-Message-State: AOJu0YwAh7Uht4yBL1xM2Za9xhnqOPZtg+IWN7XCUTe2vqZFAQB78p4Q IvBoteCLbkaIZFfUzruSt8yYGblSaAKPIOj2putkimAl04cewBYcKUuv3MVTTA== X-Gm-Gg: ATEYQzwFPLwX8YOfeY7onVC4mEVA5s+T1eccOTWry15snnHsDnR7hdrwM3/poLgEwbK euEq0zrSQGZ3hozr/SAWW2VoYjXu4fvLGIuCmOjRPqbshkAJ6x3lsVZgF8qnLx3DfJEO+4mHYxe VSoe8QUvb/nkJu13j+GPnPDjSOctT2hvOE0qeB9HGUu+S43AcZjpMCzSRrlSf4JbRd4rw5Ypwev bbUO87XD3tuWaNmF7D5T8ayjemDaeFalmS47Z5FLbAZuwGqorodfM2DAfX4BYLhMDY/YlkXDbJB lf4SaZpqksgFv6TGJ5klmi4TZp8s7s9Uy5xwk9WwSZeuG/EWupsTK4aoywNY8mCAKuTsLf2xt6O vG+nyv60HfmXNDOjESWJQjXEol/aekRtCtDKk4yyW9QfonAkZ0Y4r5cLguAGowr/3nJQzR4VCoO EVunaf13fhqvbAC7mc6GF7XWrrIvuMMqhs6ZIMd6yKl0BjeWKtkuk7s5JaYsop4S07UpOnyQ== X-Received: by 2002:a05:600c:154b:b0:47d:6c36:a125 with SMTP id 5b1f17b1804b1-4852675edf7mr40929495e9.17.1772814821883; Fri, 06 Mar 2026 08:33:41 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 02/14] xen/riscv: implement vcpu_csr_init() Date: Fri, 6 Mar 2026 17:33:19 +0100 Message-ID: <91724a0d6f2d2de3979a1a7d1f92da11ffd06171.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce vcpu_csr_init() to initialise hypervisor CSRs that control vCPU execution and virtualization behaviour before the vCPU is first scheduled. The function configures trap and interrupt delegation to VS-mode by setting the appropriate bits in the hedeleg and hideleg registers, initializes hstatus so that execution enters VS-mode when control is passed to the guest, and restricts guest access to hardware performance counters by initializing hcounteren, as unrestricted access would require additional handling in Xen. When the Smstateen and SSAIA extensions are available, access to AIA CSRs and IMSIC guest interrupt files is enabled by setting the corresponding bits in hstateen0, avoiding unnecessary traps into Xen (note that SVSLCT(Supervisor Virtual Select) name is used intead of CSRIND as OpenSBI uses such name and riscv_encoding.h is mostly based on it). If the Svpbmt extension is supported, the PBMTE bit is set in henvcfg to allow its use for VS-stage address translation. Guest access to the ENVCFG CSR is also enabled by setting ENVCFG bit in hstateen0, as a guest may need to control certain characteristics of the U-mode (VU-mode when V=1) execution environment. For CSRs that may contain read-only bits (e.g. hedeleg, hideleg, hstateen0), to the written value a correspondent mask is applied to avoid divergence between the software state and the actual CSR contents. As hstatus is not part of struct arch_vcpu (it already resides in struct cpu_user_regs), introduce vcpu_guest_cpu_user_regs() to provide a uniform way to access hstatus and other guest CPU user registers. This establishes a consistent and well-defined initial CSR state for vCPUs prior to their first context switch. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in V7: - Add Acked-by: Jan Beulich . --- Changes in V6: - Apply introduced in prev. patch csr_masks.ro_one.hstaten0 in vcpu_csr_init(). --- Changes in v5: - Initialize of hstateen0 with SMSTATEEN0_HSENVCFG when a variable is defined. - Use |= for a code inside if (*_ssaia) case. - Put declaration of the registers hedeleg and hideleg together in arch_vcpu structure as they are typically used together so better chances to be in the same cache line. --- Changes in v4: - Move local variable hstateen0 into narrower scope. - Code style fixes. - Move the call of vcpu_csr_init(v) after if ( is_idle_vcpu() ) check in arcg_vcpu_create(). --- Changes in v3: - Add hypervisor register used to initalize vCPU state. - Apply masks introduced before instead of csr_write()/csr_read() pattern. --- Changes in v2: - As hstatus isn't a part of arch_vcpu structure (as it is already a part of cpu_user_regs) introduce vcpu_guest_cpu_user_regs() to be able to access hstatus and other CPU user regs. - Sort hideleg bit setting by value. Drop a stray blank. - Drop | when the first initialization of hcounteren and hennvcfg happen. - Introduce HEDELEG_DEFAULT. Sort set bits by value and use BIT() macros instead of open-coding it. - Apply pattern csr_write() -> csr_read() for hedeleg and hideleg instead of direct bit setting in v->arch.h{i,e}deleg as it could be that for some reason some bits of hedeleg and hideleg are r/o. The similar patter is used for hstateen0 as some of the bits could be r/o. - Add check that SSAIA is avaialable before setting of SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT bits. - Drop local variables hstatus, hideleg and hedeleg as they aren't used anymore. --- xen/arch/riscv/domain.c | 63 +++++++++++++++++++++ xen/arch/riscv/include/asm/current.h | 2 + xen/arch/riscv/include/asm/domain.h | 6 ++ xen/arch/riscv/include/asm/riscv_encoding.h | 2 + 4 files changed, 73 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 32974cb48929..08b990f7b9f6 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -8,6 +8,7 @@ #include #include +#include struct csr_masks { register_t hedeleg; @@ -20,6 +21,21 @@ struct csr_masks { } ro_one; }; +#define HEDELEG_DEFAULT (BIT(CAUSE_MISALIGNED_FETCH, U) | \ + BIT(CAUSE_FETCH_ACCESS, U) | \ + BIT(CAUSE_ILLEGAL_INSTRUCTION, U) | \ + BIT(CAUSE_BREAKPOINT, U) | \ + BIT(CAUSE_MISALIGNED_LOAD, U) | \ + BIT(CAUSE_LOAD_ACCESS, U) | \ + BIT(CAUSE_MISALIGNED_STORE, U) | \ + BIT(CAUSE_STORE_ACCESS, U) | \ + BIT(CAUSE_USER_ECALL, U) | \ + BIT(CAUSE_FETCH_PAGE_FAULT, U) | \ + BIT(CAUSE_LOAD_PAGE_FAULT, U) | \ + BIT(CAUSE_STORE_PAGE_FAULT, U)) + +#define HIDELEG_DEFAULT (MIP_VSSIP | MIP_VSTIP | MIP_VSEIP) + static struct csr_masks __ro_after_init csr_masks; #define HEDELEG_AVAIL_MASK ULONG_MAX @@ -62,6 +78,51 @@ void __init init_csr_masks(void) #undef INIT_RO_ONE_MASK } +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; + + v->arch.hideleg = HIDELEG_DEFAULT & csr_masks.hideleg; + + /* + * VS should access only the time counter directly. + * Everything else should trap. + */ + v->arch.hcounteren = HCOUNTEREN_TM; + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_svpbmt) ) + v->arch.henvcfg = ENVCFG_PBMTE & csr_masks.henvcfg; + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + { + /* Allow guest to access CSR_SENVCFG */ + register_t hstateen0 = SMSTATEEN0_HSENVCFG; + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + /* + * If the hypervisor extension is implemented, the same three + * bits are defined also in hypervisor CSR hstateen0 but concern + * only the state potentially accessible to a virtual machine + * executing in privilege modes VS and VU: + * bit 60 CSRs siselect and sireg (really vsiselect and + * vsireg) + * bit 59 CSRs siph and sieh (RV32 only) and stopi (really + * vsiph, vsieh, and vstopi) + * bit 58 all state of IMSIC guest interrupt files, including + * CSR stopei (really vstopei) + * If one of these bits is zero in hstateen0, and the same bit is + * one in mstateen0, then an attempt to access the corresponding + * state from VS or VU-mode raises a virtual instruction exception. + */ + hstateen0 |= SMSTATEEN0_AIA | SMSTATEEN0_IMSIC | SMSTATEEN0_SVSLCT; + + v->arch.hstateen0 = (hstateen0 & csr_masks.hstateen0) | + csr_masks.ro_one.hstateen0; + } +} + static void continue_new_vcpu(struct vcpu *prev) { BUG_ON("unimplemented\n"); @@ -84,6 +145,8 @@ int arch_vcpu_create(struct vcpu *v) if ( is_idle_vcpu(v) ) return 0; + vcpu_csr_init(v); + /* * As the vtimer and interrupt controller (IC) are not yet implemented, * return an error. diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/include/asm/current.h index 58c9f1506b7c..5fbee8182caa 100644 --- a/xen/arch/riscv/include/asm/current.h +++ b/xen/arch/riscv/include/asm/current.h @@ -48,6 +48,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu); #define get_cpu_current(cpu) per_cpu(curr_vcpu, cpu) #define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; }) +#define vcpu_guest_cpu_user_regs(vcpu) \ + (&(vcpu)->arch.cpu_info->guest_cpu_user_regs) #define switch_stack_and_jump(stack, fn) do { \ asm volatile ( \ diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 5aec627a7adb..17be792afe7d 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -49,6 +49,12 @@ struct arch_vcpu { struct cpu_info *cpu_info; + register_t hcounteren; + register_t hedeleg; + register_t hideleg; + register_t henvcfg; + register_t hstateen0; + register_t vsatp; }; diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/include/asm/riscv_encoding.h index 1f7e612366f8..dd15731a86fa 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -228,6 +228,8 @@ #define ENVCFG_CBIE_INV _UL(0x3) #define ENVCFG_FIOM _UL(0x1) +#define HCOUNTEREN_TM BIT(1, U) + /* ===== User-level CSRs ===== */ /* User Trap Setup (N-extension) */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247976.1546355 (Exim 4.92) (envelope-from ) id 1vyY7Z-00048h-Ni; Fri, 06 Mar 2026 16:33:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247976.1546355; Fri, 06 Mar 2026 16:33:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7Z-00048W-IJ; Fri, 06 Mar 2026 16:33:49 +0000 Received: by outflank-mailman (input) for mailman id 1247976; Fri, 06 Mar 2026 16:33:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7X-00030j-P4 for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:47 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3f8e7791-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:47 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439b2965d4bso5226444f8f.2 for ; Fri, 06 Mar 2026 08:33:46 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:45 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f8e7791-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814826; x=1773419626; 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; bh=e8+NHmV9aIJTBlEGWlUzdypWZU3A1Zs5nOLXPSleeHM=; b=Qhw2PZU2IC64OpoScHVRrZSlZ6ttFMUGpheJjgUx/3f1BCboaFvG8E7t4isPSIWN8W 5vo/5H+trb1ekJqUP//y71RC9dWS3+2VWCUnARr74G6C2Xl2oh9cAdelZQdiBZSQvem7 EExQ28YBKMUVaMRzkA3k+6h00nbQhSv7eS259XGSZC810/k2SNk9Pj8OcQZpJ5EmWlzS LlXzO62MF+cv9MbwhM4AP1yAVLmWh64jK+LawYtKG/62EIMnegmfXhyJcjXCRnT4r5Od /CCrnFFx1llxOQPehEHVIKT+zFrqNpGZSV1Uwa55TNhx1t5mFo/pibthtkpw4wz+KmIc PJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814826; x=1773419626; 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; bh=e8+NHmV9aIJTBlEGWlUzdypWZU3A1Zs5nOLXPSleeHM=; b=ZGt+fuHFR+Rfvg8E2bLCE/2vSv0/KEATl7k8rhbYhUrgLbbgOfayk/0ueLCUM+yOGn wgEoqNlhxXeHJ/oJhDC7hGQksZBtDQYLbHqbQFrKmQRLzWmICIjApfs8jjG38tB+M5za L9KhQ7KJCRJ+pRtfpRKvrz2SK42aq6i3OiekJrxJw8vr6gXejXCaHUdk50YEQpC/fOQ0 aBONUK6Tf0ptl5WqiaCFVgp15GGSBT7IRtLrnRYxi9d5d9gF53ncQH3XKdrdPhI1GYVm DcC+iRKIN/Aa/RyonJA5Gih3XwokBAPABQq1M6d7dnyKLQhhjFI6rDG+7K9PObq5J0My 6HZw== X-Gm-Message-State: AOJu0Yx4ZPYSn0T9tFlrY9EFWxxALaEC43DHi50Byv0nGsNCUUpdMhQu DFy1cdTp8CUQC6grIdC9b5udf3JU8q0KD+jVapRyZdUtOTcFhKUM+yoeLJ/A1g== X-Gm-Gg: ATEYQzyDsgB5HzUoLiK0HocmALJqndbGrQcUrZ7+mXrDI/7ZIt5g9GZTuyPWMgNxwX4 0h/yw8IwnQTIfmZDMRW4mlIcFk2sl75picsSS8cmnkBoQbRPD8s56kaWZIICrolu8pG3Uo7Dnf4 aa0LVebd+ASaZZgikXY83bCVWI05WgjDW8uApXwa2LAfgfvtkLpTAUuoxncRhU2T60oO3x2xaFl N2IYZdmT2G4eNRrGvby1biRLIvMn33iy0ukttB8pLIrLJfkU0liPWETMcALueSJbjlGmpA8rBp0 U14fcrwXIpY8iyUnJpHi+dza7kucoTe9XxYTWG2EagDiUOu1olhDX42Ot5mPZX0BJS9m+8sVM2y vMXkb2zOJL7SSbdYRQ+uDe2i7e+krNjOBQNDwoX2iu+5xwqOkyI0pcEfAec5GPZpfAo/MU3tq1Y 8CEMX0eqV3mIp5i1Q36eNiBX4rRiT5D8o6Ba4GiD2g8tETWdsCwSMZyi7JWPoclUH0AeYjqcS2M xTW X-Received: by 2002:a05:600c:46c3:b0:480:6bef:63a0 with SMTP id 5b1f17b1804b1-48526959433mr47154465e9.21.1772814826016; Fri, 06 Mar 2026 08:33:46 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 06/14] xen/riscv: introduce vcpu_kick() implementation Date: Fri, 6 Mar 2026 17:33:23 +0100 Message-ID: <21e8e22cb62498236ebe094671d80676a46d8b76.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add a RISC-V implementation of vcpu_kick(), which unblocks the target vCPU and sends an event check IPI if the vCPU was running on another processor. This mirrors the behavior of Arm and enables proper vCPU wakeup handling on RISC-V. Remove the stub implementation from stubs.c, as it is now provided by arch/riscv/domain.c. Since vcpu_kick() calls perfc_incr(vcpu_kick), add perfcounter for vcpu_kick to handle the case when CONFIG_PERF_COUNTERS=y. Although CONFIG_PERF_COUNTERS is not enabled by default, it can be enabled, for example, by randconfig what will lead to CI build issues. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-v7: - Nothing changed. Only rebase. --- Changes in v3: - Add asm/perfc_defn.h to provide vcpu_kick perfcoounter to cover the case when CONFIG_PERF_COUNTERS=y. --- Changes in v2: - Add Acked-by: Jan Beulich . --- xen/arch/riscv/domain.c | 14 ++++++++++++++ xen/arch/riscv/include/asm/Makefile | 1 - xen/arch/riscv/include/asm/perfc_defn.h | 3 +++ xen/arch/riscv/stubs.c | 5 ----- 4 files changed, 17 insertions(+), 6 deletions(-) create mode 100644 xen/arch/riscv/include/asm/perfc_defn.h diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index b59e026a9635..c8ce1efa884d 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -1,9 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include #include +#include #include #include @@ -264,6 +266,18 @@ void vcpu_flush_interrupts(struct vcpu *curr) #endif } +void vcpu_kick(struct vcpu *v) +{ + bool running = v->is_running; + + vcpu_unblock(v); + if ( running && v != current ) + { + perfc_incr(vcpu_kick); + smp_send_event_check_mask(cpumask_of(v->processor)); + } +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/include/asm/Makefile b/xen/arch/riscv/include/asm/Makefile index 3824f31c395c..86c56251d5d7 100644 --- a/xen/arch/riscv/include/asm/Makefile +++ b/xen/arch/riscv/include/asm/Makefile @@ -7,7 +7,6 @@ generic-y += hypercall.h generic-y += iocap.h generic-y += irq-dt.h generic-y += percpu.h -generic-y += perfc_defn.h generic-y += random.h generic-y += softirq.h generic-y += vm_event.h diff --git a/xen/arch/riscv/include/asm/perfc_defn.h b/xen/arch/riscv/include/asm/perfc_defn.h new file mode 100644 index 000000000000..8a4b945df662 --- /dev/null +++ b/xen/arch/riscv/include/asm/perfc_defn.h @@ -0,0 +1,3 @@ +/* This file is intended to be included multiple times. */ + +PERFCOUNTER(vcpu_kick, "vcpu: notify other vcpu") diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index daadff0138e4..eedf8bf9350a 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -203,11 +203,6 @@ void vcpu_block_unless_event_pending(struct vcpu *v) BUG_ON("unimplemented"); } -void vcpu_kick(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - unsigned long hypercall_create_continuation(unsigned int op, const char *format, ...) { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247974.1546333 (Exim 4.92) (envelope-from ) id 1vyY7X-0003VQ-4P; Fri, 06 Mar 2026 16:33:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247974.1546333; Fri, 06 Mar 2026 16: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 ) id 1vyY7W-0003Uq-V5; Fri, 06 Mar 2026 16:33:46 +0000 Received: by outflank-mailman (input) for mailman id 1247974; Fri, 06 Mar 2026 16:33:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7V-00030j-JG for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:45 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3e69eeb1-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:45 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-439b94a19fdso5418564f8f.0 for ; Fri, 06 Mar 2026 08:33:45 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:43 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3e69eeb1-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814824; x=1773419624; 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; bh=TD32rUw8Jt+xF61vzNKRB9KoWMugslbXmkZ8IwQfvzs=; b=AcobrcEieugq1Opq15cYORGuZWYpQRlUUanh6S9bd9m7IQuTf3JBvT/A1BcS8/d0UG LsQ840KeUc8EH3HbxheP7Ranx1Z8ZBAcv3SVvkBuUOiHkhDfyEZpQ5MOOWHeUx467gfL Ssy4LnUH8FUFFTXe1kAkGF987gdkzhXSCHc9nSXIG6rdKaqgIeG89EtGa/QT0fvARKAu /mp+RLcaOZnZ32HLd5AWub44OmWQI0hh7KQk6Kxotsks8WP/hyLDNLv6PMQwwHRI3MrF 0b4+Shab+PFqd8r+weFfgxuvQD1b+HJonySHMHm+xaP34nMEvCmr42h1o9F9PNYvVZSa QN5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814824; x=1773419624; 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; bh=TD32rUw8Jt+xF61vzNKRB9KoWMugslbXmkZ8IwQfvzs=; b=t9+uvUPfJz0syFDs6yURlCt1my9su2XYm/s8lAk8bxn8aLO3FmQVZVU4pM7Jwl1qGf yUmCEbcEINQkZlNiFURGBOlOIt3i4usrq/iUw94WkBLHX62CkNkuRLwOn5renUW99/RI Sn0CPsxkMceaHUkZf3ub5Beo/Q7xbOIMD3g5lWVgMDVreC2+5hmPbMz3YWvNA0WZkbt3 mX7VvCuNUjOBqgOHNzoKtMXLvgNEC79C/YXF4rzGojDyx8TNqFKPJHT9d2viV2xjECTJ tEfo3Ov0EBbIzbi/fb8mA1T/IA0ByXatxyAxdLGWmstbkvB8oXV3m+kEQFR7gtTJWxOP EHvg== X-Gm-Message-State: AOJu0Yzametw9tZhZ0tfS3i8PJNe7ae/k4HNTueaxYidIfjr7tko0qMA 992j97dDp06QKJRdt+TOcYuMGa+AoUpa+JZaDLsMrAGLcarcuTbTKDeA6L8VDw== X-Gm-Gg: ATEYQzzC4PDOAC6sW3zUr0Q/YLY7hhMssIH4oM88K7ljfdtXUb3jk3906nrRh4auV1l RjfnM9HSkh52B5AYfCmumNbtvgoNzU1YXKOCF3NKfrIW7rLwwv2Tturv8NFdiLQgETxApk27mMb uO44lkOmk4dOXACDNMKcbDP0NKFRcF1lsUXJ5v401Z266mmWiYKQMzuclBoFX5xIm4qflrhESHz +EmJqF5+9pU1b45avDxQwtAtGfj4S+t8Xdf66jtEWaLz1j2N1d2MGhsDGcay5tdAbOAYTdkN1E9 xv7IHFt8LGCiQqYeDxUhlsaNhpqbM7Yxk4KSCWgNV23NkqJvlkkXDJDZgmLJks+GOo1p8Py/6QY Bu3YwT1bvFAz3UISJ36n5zohXh3diKGYsd8E5zaZOYhhAVh61WSTlQJsBYdH+yWfmvrVWzxSTug oVMdfwWwVsbc/GUjWa0tR7va9qow1aoztWGvX2P9amqTlj5Pa4ur+DjyItBpPNa664xw== X-Received: by 2002:a05:6000:1865:b0:439:cba2:2294 with SMTP id ffacd0b85a97d-439da88bc2dmr4437064f8f.37.1772814824070; Fri, 06 Mar 2026 08:33:44 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 04/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 2 Date: Fri, 6 Mar 2026 17:33:21 +0100 Message-ID: <9fe4e79428719cbf49442af0ab948e398861f27f.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patch is based on Linux kernel 6.16.0. Add the consumer side (vcpu_flush_interrupts()) of the lockless pending interrupt tracking introduced in part 1 (for producers). According, to the design only one consumer is possible, and it is vCPU itself. vcpu_flush_interrupts() is expected to be ran (as guests aren't ran now due to the lack of functionality) before the hypervisor returns control to the guest. Producers may set bits in irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is performed only by the consumer via xchg() (with aquire semantics). The consumer must not write to irqs_pending and must not act on bits that are not set in the mask. Otherwise, extra synchronization should be provided. The worst thing which could happen with such approach is that a new pending bit will be set to irqs_pending bitmap during update of hvip variable in vcpu_flush_interrupt() but it isn't problem as the new pending bit won't be lost and just be proceded during the next flush. As AIA specs introduced hviph register which would want to be updated when guest related AIA code vcpu_update_hvip() is introduced instead of just open-code it in vcpu_flush_interrupts(). Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v7: - Rename argument v of vcpu_flush_interrupts() to curr. - Add ASSERT(curr == current) to be sure that this functions is called only for current vCPU as the whole vcpu_flush_interrupts() implemented to work with current (at the moment, at least). - Drop vcpu_update_hvip() function and open code it in vcpu_flush_interrupt() as there is no more update of hvip unconditionally and hviph will be updated separately. (originally it was planned to update unconditionally both hvip and hviph inside vcpu_update_hvip() after if() conditions in vcpu_flush_interrupt()) --- Changes in v6: - Nothing changed. Only rebase. --- Changes in v5: - Reorder the defintions of local variables (mask, val, hvip) in vcpu_flush_interrupts(). Also, drop a blank line between them. - Move #ifdef CONFIG_RISCV_32 above the comment in vcpu_flush_interrupts() and align the comment properly. - Add Acked-by: Jan Beulich . --- Changes in v4: - Move defintion of hvip local variable to narrower space in vcpu_flush_interrupts(). - Use initializers for mask and val variables. - Use local variable c as an argument of vcpu_flush_interrupts() in check_for_pcpu_work(). --- Changes in v3: - Update the error message in case of RV32 from "hviph" to v->arch.hviph. - Make const argument of vcpu_update_hvip. - Move local variables mask and val inside if() in vcpu_flush_interrupts(). - Call vcpu_flush_interrupts() in check_pcpu_work(). - Move vcpu_update_hvip() inside if() in vcpu_flush_interrupts(). --- Changes in v2: - New patch. --- xen/arch/riscv/domain.c | 27 +++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 1 + xen/arch/riscv/traps.c | 2 ++ 3 files changed, 30 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 5447c17402dd..f3e3ad149453 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -231,6 +231,33 @@ void vcpu_sync_interrupts(struct vcpu *curr) } } +void vcpu_flush_interrupts(struct vcpu *curr) +{ + ASSERT(curr == current); + + if ( ACCESS_ONCE(curr->arch.irqs_pending_mask[0]) ) + { + unsigned long mask = xchg(&curr->arch.irqs_pending_mask[0], 0UL); + unsigned long val = ACCESS_ONCE(curr->arch.irqs_pending[0]) & mask; + register_t *hvip = &curr->arch.hvip; + + *hvip &= ~mask; + *hvip |= val; + + csr_write(CSR_HVIP, *hvip); + } + +#ifdef CONFIG_RISCV_32 + /* + * Flush AIA high interrupts. + * + * It is necessary to do only for CONFIG_RISCV_32 which isn't + * supported now. + */ +# error "Update v->arch.hviph" +#endif +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 1ecfe18c8519..59d23e4f9247 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -115,6 +115,7 @@ int vcpu_set_interrupt(struct vcpu *v, unsigned int irq); int vcpu_unset_interrupt(struct vcpu *v, unsigned int irq); void vcpu_sync_interrupts(struct vcpu *curr); +void vcpu_flush_interrupts(struct vcpu *curr); #endif /* ASM__RISCV__DOMAIN_H */ diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 551f886e3a69..244264c92a79 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -175,6 +175,8 @@ static void check_for_pcpu_work(void) vcpu_sync_interrupts(curr); + vcpu_flush_interrupts(curr); + p2m_handle_vmenter(); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247977.1546360 (Exim 4.92) (envelope-from ) id 1vyY7a-0004CT-3q; Fri, 06 Mar 2026 16:33:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247977.1546360; Fri, 06 Mar 2026 16: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 ) id 1vyY7Z-0004CF-U1; Fri, 06 Mar 2026 16:33:49 +0000 Received: by outflank-mailman (input) for mailman id 1247977; Fri, 06 Mar 2026 16:33:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7Y-0003HN-7G for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:48 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3f2fad62-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:46 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4836f363ad2so110250565e9.1 for ; Fri, 06 Mar 2026 08:33:46 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:44 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3f2fad62-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814825; x=1773419625; 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; bh=PUa+J5dx/g0jfCQXCa5GsS6lcARiceV/jkoJtxvsNwc=; b=FEJfwGK+82JNUSYtm7sbdmwEJsaLrGrJOldr4U9TjjZBc/IbW3KtDjxQdmaTA7KJU8 NzdwaWERTvYKWp8Y8eAFlTs2ZK/fSCI3mDDGkGfgMbuCNMnd4eiSWZxMP2Kb5yZmvNNV 8MPo89b5wZGYfl56oP0XFCTc3fDvgCEFtweCus5S1FQxkaYVtDQ8ZvG+/dQqeOU2ce1W 28LPfEU1bcmgANBQpcPSXdT412ZPs58huHRHSbHi4mSkdhhcx0uem20gerzf9U7JlGY8 I/7rrSbqlD755pWs+7iZHch5nGYR4xOap6tT8+JS7Us91ySAoR3a0WDe2rC2sYAR3zTG TNuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814825; x=1773419625; 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; bh=PUa+J5dx/g0jfCQXCa5GsS6lcARiceV/jkoJtxvsNwc=; b=Z6QOPQMsGUQfwTFVfotGfBbvJa/maJEl9Iy483ktG69nHXb1BcFXbmdsW9dGOSxyaV En17BBoF4U8NWOSFLo896X0AIZjNXCELcNcwJSye/Tv8ugbrT3mfQUB3T5kSbSESx2d5 p5fw68fIX2pBkc/m5qiZrJMb+bDWkDJqopIiWHHDCZldrdX05hr266dxlq/lyc1A+qXh iejuX8BWDyClHdqwidf7mnjp5zZEGJBeOK7OTYWCKzI7C335uCDn/D6QmD4RZ1PNh12r 3fe/xo7HaljEX28wHFbmEkiki/6CUhzi9dn1FGXF0394fUKSDU9t6celYuo6fK4c3Ai7 lZmA== X-Gm-Message-State: AOJu0YzZ6utrY3IClM0nINhNUwwmw4n1NDo1MkerSQpfIgn3IqAOHiMs PhpobhyEGf82VNqG+sXmtJ5S2wk4zZp2BtryX1FbXTl7QvHjQ9QyE/ckChPjAg== X-Gm-Gg: ATEYQzxJdu0QCB87WX9mhan8E5/pgCcvpwVvZ7Zvj9NOvkSWvpIfoWZMat1FjotI5iw W3ohdYfbqb6mA5wluowndGS2AcPX1Bzz527a/XiJJIyjuBqaWeA8ooDUZFAfho+Niilgki31VEw SE2euwW2WdA7WGYWm/H5Y2Z680braq47VisRrW9s/S115mskbR2RfWGMwfvS5V3tMNY1hGSWvgO nBypHyVH8SR7fJ7CRPH+4885WXviRahEjpJJKGm/Q6YPctdTjaCapKIbe9+wLkkYJqf1td1ucxh BmHnb1TaV2+ghd0rYcGHbds1JE8/IxPDbyJGI7DVP5DO1uGUUST4oIHM/6ZufsJnu8S6kymtxJY ubfvV9+lTHRHl9yOn/tc6ugeEbL537EDVmjUuawCi4OmJ4Yii9m0/JZUlwTGrrcIGJ/zRTYmPnV JsPduwWpJgnub7LH1Ks8KmnX4FYrmeakbXXY2dmicm5HsWDVJj8kRt1LR3xbAGa6k8AxruGg== X-Received: by 2002:a05:600c:198f:b0:483:6ff1:18b with SMTP id 5b1f17b1804b1-485268bd6cbmr46440355e9.0.1772814825032; Fri, 06 Mar 2026 08:33:45 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 05/14] xen/riscv: introduce basic vtimer infrastructure for guests Date: Fri, 6 Mar 2026 17:33:22 +0100 Message-ID: <1a5fcf53fa4a3e935b1814c129aa131fe1068168.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lay the groundwork for guest timer support by introducing a per-vCPU virtual timer backed by Xen’s common timer infrastructure. The virtual timer is programmed in response to the guest SBI sbi_set_timer() call and injects a virtual supervisor timer interrupt into the vCPU when it expires. While a dedicated struct vtimer is not strictly required at present, it is expected to become necessary once SSTC support is introduced. In particular, it will need to carry additional state such as whether SSTC is enabled, the next compare value (e.g. for the VSTIMECMP CSR) to be saved and restored across context switches, and time delta state (e.g. HTIMEDELTA) required for use cases such as migration. Introducing struct vtimer now avoids a later refactoring. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-v7: - Nothing changed. Only rebase. --- Changes in v5: - Drop copyright line from asm/vtimer.h. - Add Acked-by: Jan Beulich . --- Changes in v4: - Add vcpu_timer_destroy() to void arch_vcpu_destroy(). --- Changes in v3: - use one container_of() to get vcpu instead of two container_of()s. --- Changes in v2: - Drop domain_vtimer_init() as it does nothing. - Drop "struct vcpu *v;" from struct vtimer as it could be taken from arch_vcpu using container_of(). - Drop vtimer_initialized, use t->status == TIMER_STATUS_invalid instead to understand if timer was or wasn't initialized. - Drop inclusion of xen/domain.h as xen/sched.h already includes it. - s/ xen/time.h/ xen.timer.h in vtimer.c. - Drop ULL in if-conidtion in vtimer_set_timer() as with the cast it isn't necessary to have suffix ULL. - Add migrate timer to vtimer_set_timer() to be sure that vtimer will occur on pCPU it was ran, so the signalling to that vCPU will (commonly) be cheaper. - Check if the timeout has already expired and just inject the event in vtimer_vtimer_set_timer(). - Drop const for ticks argument of vtimer_set_timer(). - Merge two patches to one: - xen/riscv: introduce vtimer - xen/riscv: introduce vtimer_set_timer() and vtimer_expired() --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 10 +++- xen/arch/riscv/include/asm/domain.h | 3 ++ xen/arch/riscv/include/asm/vtimer.h | 17 +++++++ xen/arch/riscv/vtimer.c | 71 +++++++++++++++++++++++++++++ 5 files changed, 100 insertions(+), 2 deletions(-) create mode 100644 xen/arch/riscv/include/asm/vtimer.h create mode 100644 xen/arch/riscv/vtimer.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index bc47e83b26d7..ffbd7062e214 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -22,6 +22,7 @@ obj-y += traps.o obj-y += vmid.o obj-y += vm_event.o obj-y += vsbi/ +obj-y += vtimer.o $(TARGET): $(TARGET)-syms $(OBJCOPY) -O binary -S $< $@ diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index f3e3ad149453..b59e026a9635 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -10,6 +10,7 @@ #include #include #include +#include struct csr_masks { register_t hedeleg; @@ -148,11 +149,14 @@ int arch_vcpu_create(struct vcpu *v) vcpu_csr_init(v); + if ( (rc = vcpu_vtimer_init(v)) ) + goto fail; + /* - * As the vtimer and interrupt controller (IC) are not yet implemented, + * As interrupt controller (IC) is not yet implemented, * return an error. * - * TODO: Drop this once the vtimer and IC are implemented. + * TODO: Drop this once IC is implemented. */ rc = -EOPNOTSUPP; goto fail; @@ -166,6 +170,8 @@ int arch_vcpu_create(struct vcpu *v) void arch_vcpu_destroy(struct vcpu *v) { + vcpu_timer_destroy(v); + vfree((void *)&v->arch.cpu_info[1] - STACK_SIZE); } diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 59d23e4f9247..6c48bf13111d 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -8,6 +8,7 @@ #include #include +#include struct vcpu_vmid { uint64_t generation; @@ -49,6 +50,8 @@ struct arch_vcpu { struct cpu_info *cpu_info; + struct vtimer vtimer; + register_t hcounteren; register_t hedeleg; register_t hideleg; diff --git a/xen/arch/riscv/include/asm/vtimer.h b/xen/arch/riscv/include/asm/vtimer.h new file mode 100644 index 000000000000..111863610a92 --- /dev/null +++ b/xen/arch/riscv/include/asm/vtimer.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef ASM__RISCV__VTIMER_H +#define ASM__RISCV__VTIMER_H + +#include + +struct vtimer { + struct timer timer; +}; + +int vcpu_vtimer_init(struct vcpu *v); +void vcpu_timer_destroy(struct vcpu *v); + +void vtimer_set_timer(struct vtimer *t, uint64_t ticks); + +#endif /* ASM__RISCV__VTIMER_H */ diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c new file mode 100644 index 000000000000..32d142bcdfcd --- /dev/null +++ b/xen/arch/riscv/vtimer.c @@ -0,0 +1,71 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include + +#include + +static void vtimer_expired(void *data) +{ + struct vtimer *t = data; + struct vcpu *v = container_of(t, struct vcpu, arch.vtimer); + + vcpu_set_interrupt(v, IRQ_VS_TIMER); +} + +int vcpu_vtimer_init(struct vcpu *v) +{ + struct vtimer *t = &v->arch.vtimer; + + init_timer(&t->timer, vtimer_expired, t, v->processor); + + return 0; +} + +void vcpu_timer_destroy(struct vcpu *v) +{ + struct vtimer *t = &v->arch.vtimer; + + if ( t->timer.status == TIMER_STATUS_invalid ) + return; + + kill_timer(&v->arch.vtimer.timer); +} + +void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) +{ + struct vcpu *v = container_of(t, struct vcpu, arch.vtimer); + s_time_t expires = ticks_to_ns(ticks - boot_clock_cycles); + + vcpu_unset_interrupt(v, IRQ_VS_TIMER); + + /* + * According to the RISC-V sbi spec: + * If the supervisor wishes to clear the timer interrupt without + * scheduling the next timer event, it can either request a timer + * interrupt infinitely far into the future (i.e., (uint64_t)-1), + * or it can instead mask the timer interrupt by clearing sie.STIE CSR + * bit. + */ + if ( ticks == ((uint64_t)~0) ) + { + stop_timer(&t->timer); + + return; + } + + if ( expires < NOW() ) + { + /* + * Simplify the logic if the timeout has already expired and just + * inject the event. + */ + stop_timer(&t->timer); + vcpu_set_interrupt(v, IRQ_VS_TIMER); + + return; + } + + migrate_timer(&t->timer, smp_processor_id()); + set_timer(&t->timer, expires); +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247978.1546366 (Exim 4.92) (envelope-from ) id 1vyY7a-0004Ll-N6; Fri, 06 Mar 2026 16:33:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247978.1546366; Fri, 06 Mar 2026 16: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 ) id 1vyY7a-0004Jq-H5; Fri, 06 Mar 2026 16:33:50 +0000 Received: by outflank-mailman (input) for mailman id 1247978; Fri, 06 Mar 2026 16:33:49 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7Y-00030j-Vv for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:48 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 40449f26-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:48 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-480706554beso102815215e9.1 for ; Fri, 06 Mar 2026 08:33:48 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:46 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 40449f26-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814827; x=1773419627; 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; bh=wshUHaSMY4kHHsx5qEs6V10my02G5AGEo5sXu7Wg0WM=; b=mt3C7V7JKPnDGNQsg1+AoxzHJc/wwFFmfD4nJmLj/VOVxUV2p67UieTLCXfEvbBFft MNoIl5xfno7X74Bf9k5E+ICjIVn/1T5Hgntg4lT8IdlB7gt1HqW0zm5cs4OMwbiAUPpZ oOvqqTffeBeraYrqg+PKHVe/70+g3hIcPGrL26LxdH92Ucw2J9TzPJYRlaH+SftNjBOD BV+x3jpspQ9ClJslLti0l9inZLjf5fk7eaWOqAg3RQJRz3chNbIa7WcrGVDRJqW/B1Wd kknaeHoi6Fn3xTJ9M37kvOH/GWCZwqNdo5QW2USpZVSz5q6fu4hcuCXN9gUR0VGnUUtZ aipQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814827; x=1773419627; 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; bh=wshUHaSMY4kHHsx5qEs6V10my02G5AGEo5sXu7Wg0WM=; b=tAhX6FIGYWo/GG8u/R3tfrS2A6tFlyZZu/h+Q0iZ9CVO916et3wsk31EM3sDa/nC8H sEcNPEq5tnrl46p+ONTzPxxJ+dHnbCMH3kHyjhIqojWhbFZ0Wd+bdR0PqS1c8D8J4Mdi 11h83Di8dqnQjB3W6TAFK/wbBy8qwH1rp4klSA1vWlK8T/NNr9NzOVUoJHJ8qPbqMfTg zPtbaAkbIGc6cWWmkdYTKkn8Hj9umE7bVnWrbLhrKWPP5qribxE2Z6Jv1X7BIgf9JXCB V5mC0gFhP+6ri4htiBM6xciTV6xETFKR2eQTTlrtmnq12W0x9nOMfHfx5y9C1vmTsL/v d0Ow== X-Gm-Message-State: AOJu0YyGkp8+sX/B+qKp2A0Esh9s3zQgJfIj3TlSJAKM9kXLGa+9j/TW jSNo3ydku7xo5o5+Q3sW3WMwZU31CPvIHnn+BwQEiY3nbRGGok2T/viAcJprAA== X-Gm-Gg: ATEYQzwr8GQzgIIkW8qb86HKUPrnntNpOCEco5xF9Y45YHguOi8tpK8ln7yKIaLHE6h i/YJJOXZlZ1KJqN3bbu6kE1V4rPLI8tSbvFMvhU6ShZs9ikzuYFIS5sVh/XPDkyxAmOk20h/KZU fG0ImcNMx7BSLB6Ze7JE4vk6nbtyJIaeWh0CPsEXq2qb9pDsyLsvCvwdH+tqjmN23pPFfX/30aO 9nzYSgyPEJIpI6hraBZACXmFxhXYBaKK+UcUBmQabSW4oG0AcGghmb4dLS80h8UhxC3vqphruOz rLSNAR9SFIvyA+Gu6qalrVNFcPCUb11yoL7OzrANg4WfXUavl/Q6UxQ79hl+SMUWrv62c2tzdbU CD/Xsbnj+25jH1dUIJ2KEkmDSkC1sjeNjY+gzHg9J+Kef8rJ7Nw8TI3yTTvgOX5DxSGcjnkVHD5 HhXHsXCLtOrQi5bHYMgpnRu7vNKdiMM4amO44bP160l4jnB0nmX5ImYlLAa+8StCq5++aO+CrcZ Pvq X-Received: by 2002:a05:600c:620c:b0:47d:3ffa:5f03 with SMTP id 5b1f17b1804b1-4852695b633mr46566025e9.21.1772814827041; Fri, 06 Mar 2026 08:33:47 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 07/14] xen/riscv: add vtimer context switch helpers Date: Fri, 6 Mar 2026 17:33:24 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce vtimer_ctxt_switch_from() and vtimer_ctxt_switch_to() to handle virtual timer state across vCPU context switches. At present, vtimer_ctxt_switch_from() is a no-op because the RISC-V SSTC extension, which provides a virtualization-aware timer, is not yet supported. Xen therefore relies the virtual (SBI-based) timer. The virtual timer uses Xen's internal timer infrastructure and must be associated with the pCPU on which the vCPU is currently running so that timer events can be delivered efficiently. As a result, vtimer_ctxt_switch_to() migrates the timer to the target pCPU when a vCPU is scheduled in. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-v7: - Nothing changed. Only rebase. --- Changes in v3: - s/vtimer_ctx_switch_to/vtimer_ctxt_switch_to - s/vtimer_ctx_switch_from/vtimer_ctxt_switch_from - Add Acked-by: Jan Beulich . --- Changes in v2: - Align the parameters names for vtimer_ctx_switch_from() and vtimer_ctx_switch_to() in declarations to match the ones in the defintions to make Misra happy. - s/vtimer_save/vtimer_ctx_switch_from. - s/vtimer_restore/vtimer_ctx_switch_to. - Update the commit message. --- xen/arch/riscv/include/asm/vtimer.h | 3 +++ xen/arch/riscv/vtimer.c | 15 +++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/xen/arch/riscv/include/asm/vtimer.h b/xen/arch/riscv/include/asm/vtimer.h index 111863610a92..b4d48d1a1732 100644 --- a/xen/arch/riscv/include/asm/vtimer.h +++ b/xen/arch/riscv/include/asm/vtimer.h @@ -14,4 +14,7 @@ void vcpu_timer_destroy(struct vcpu *v); void vtimer_set_timer(struct vtimer *t, uint64_t ticks); +void vtimer_ctxt_switch_from(struct vcpu *p); +void vtimer_ctxt_switch_to(struct vcpu *n); + #endif /* ASM__RISCV__VTIMER_H */ diff --git a/xen/arch/riscv/vtimer.c b/xen/arch/riscv/vtimer.c index 32d142bcdfcd..afd8a53a7387 100644 --- a/xen/arch/riscv/vtimer.c +++ b/xen/arch/riscv/vtimer.c @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include @@ -69,3 +70,17 @@ void vtimer_set_timer(struct vtimer *t, const uint64_t ticks) migrate_timer(&t->timer, smp_processor_id()); set_timer(&t->timer, expires); } + +void vtimer_ctxt_switch_from(struct vcpu *p) +{ + ASSERT(!is_idle_vcpu(p)); + + /* Nothing to do at the moment as SSTC isn't supported now. */ +} + +void vtimer_ctxt_switch_to(struct vcpu *n) +{ + ASSERT(!is_idle_vcpu(n)); + + migrate_timer(&n->arch.vtimer.timer, n->processor); +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247979.1546379 (Exim 4.92) (envelope-from ) id 1vyY7c-0004kV-4h; Fri, 06 Mar 2026 16:33:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247979.1546379; Fri, 06 Mar 2026 16: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 ) id 1vyY7b-0004jR-S3; Fri, 06 Mar 2026 16:33:51 +0000 Received: by outflank-mailman (input) for mailman id 1247979; Fri, 06 Mar 2026 16:33:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7a-0003HN-Ky for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:50 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 40cb5aa9-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:49 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439b7c2788dso4198654f8f.1 for ; Fri, 06 Mar 2026 08:33:49 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:47 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 40cb5aa9-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814828; x=1773419628; 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; bh=AFH/mmXdjfsZGFnjZSa+nYBoxFRy8PjJpaEBRZ8E9iE=; b=mGyH7Ltb7HzT21mf4u7CIsGbzU3dLFfqETGZxzOcmwbN2DvFbZI7Uzt8DnkzFvRoO1 RHpCxOY3iooonWlzboWyr0uT7kj0iITxiCeS8547vuEfs6D8twvvL5+qbaWkrDKddftT 2bymNKy6xJvAl9W+mfNDeqkXQQt4A+8yCeL7jOO4IRvsR+gRw6pcoTTidtrXQZAgXlIb DALyIkqcUUAxbAO2OGDVCIILCq2CElw75kvCBKj/O9UyOIVhK5BgO5INmBec5rGExDAP LuVveeQohkjubaJeoEkPvBkhmECuBAshwcoUJdi5bKYyR4PGb3BuP53hhLmPAKsg7CNy 0YqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814828; x=1773419628; 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; bh=AFH/mmXdjfsZGFnjZSa+nYBoxFRy8PjJpaEBRZ8E9iE=; b=sDuSD2nQ7giepTdu0VEG7zNHmwUs3OUXLvSdT1zKS1sWTfF1Tu//dupja6CAu5ME5x M25koQy/3uzepG4TnJinCCz0HpddNnMpFEhjsUJPgDh1/i7HSUOsmPybYOf6QMcExVVJ bS+iKA9fNcrC0laMN5P4o4HufIJZ0/RdlnXvSTnVrHKlsak+vh0posnWOHE0nPssfhZb 4rX30UrggqQ3pxo5pVJVkhykgL4aOj0pqlkdqtZEvLWTs3WAE+KpBdyThB+ctqCMwR/+ 3ovFM63kG9+OY/nvOjUsBIKfd+UK94M23DKiqPVsIwch7L53B50cAC+jfhRQJZzZOpwt Qotg== X-Gm-Message-State: AOJu0YwY/LMAY87g8+4+Vl33Wd21d83AOZmGISBH2XRiaEpBkjgTnAiY iswxGRtvSBX+EyaT6+h+wAix3p2C/Wu2/wmFSOsP1nSePh7lX3OEe8ge428FOg== X-Gm-Gg: ATEYQzwhAeO6pTKSox6R8h4WekX8XQjzTbCNy0glT29rjqT510eInDyL00ztP0zBI5D R4BY9mL7OTXptc0gmwY7cGVQ1C7GTsVveGH8r2MUWDIHNq5NylL/xg48RHuEO2IRrSDlD+J8o0Y ebXlEv9S2b+Q3bDribKExQtGrz9AJf9AiykIwjp1GYLN9q4QZLjoP/Ggvuo8Q2rdX4nR1HmB9/Y 3au3yzwHZIqUMq4aqbxDs/s7zk6y6gtSmFcHpFZXZJYjM2cKcFzyn4tUzDaMYBjopk0r4JJfQeD evJeMZyfolOKet/znotbe2m0TjadjfxJMkYgG7U1VZkZMHILUHmAkWSNLpUQ1FGM9AFU2eQm6pq rmCJieqdy7HfSkNMY+9EQNCN2JscCZNuKLVv5WERYj7uqIzGVzGsaRX3ytjXYAQlQj+3ZGeQHDT RXzlMV9MTUezFMbZUHLLGY6009rAxtWqZW2aROWeT5exdZePY+NL1ZOz4vOEHxCJEphg+13DcW6 y+s X-Received: by 2002:a05:6000:2506:b0:439:aef4:944b with SMTP id ffacd0b85a97d-439da351a36mr4504521f8f.19.1772814828144; Fri, 06 Mar 2026 08:33:48 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 08/14] xen/riscv: implement SBI legacy SET_TIMER support for guests Date: Fri, 6 Mar 2026 17:33:25 +0100 Message-ID: <888b2d5a4a3ee9a83de4568b17253f865febaf9f.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add handling of the SBI_EXT_0_1_SET_TIMER function ID to the legacy extension ecall handler. The handler now programs the vCPU’s virtual timer via vtimer_set_timer() and returns SBI_SUCCESS. This enables guests using the legacy SBI timer interface to schedule timer events correctly. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v3-v7: - Nothing changed. Only rebase. --- Changes in v2: - Add Acked-by: Jan Beulich . --- xen/arch/riscv/vsbi/legacy-extension.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/riscv/vsbi/legacy-extension.c b/xen/arch/riscv/vsbi/legacy-extension.c index 2e8df191c295..090c23440cea 100644 --- a/xen/arch/riscv/vsbi/legacy-extension.c +++ b/xen/arch/riscv/vsbi/legacy-extension.c @@ -7,6 +7,7 @@ #include #include +#include static void vsbi_print_char(char c) { @@ -44,6 +45,11 @@ static int vsbi_legacy_ecall_handler(unsigned long eid, unsigned long fid, ret = SBI_ERR_NOT_SUPPORTED; break; + case SBI_EXT_0_1_SET_TIMER: + vtimer_set_timer(¤t->arch.vtimer, regs->a0); + regs->a0 = SBI_SUCCESS; + break; + default: /* * TODO: domain_crash() is acceptable here while things are still under -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247980.1546389 (Exim 4.92) (envelope-from ) id 1vyY7d-00055O-Er; Fri, 06 Mar 2026 16:33:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247980.1546389; Fri, 06 Mar 2026 16:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7d-000552-8E; Fri, 06 Mar 2026 16:33:53 +0000 Received: by outflank-mailman (input) for mailman id 1247980; Fri, 06 Mar 2026 16:33:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7a-00030j-Qb for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:50 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 41808ec9-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:50 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48371bb515eso139921555e9.1 for ; Fri, 06 Mar 2026 08:33:50 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:48 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 41808ec9-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814829; x=1773419629; 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; bh=J/Kmt/9cTJTTmvSy1vXRcQGyNeZ//R0WlMTYDIyos0A=; b=k5LthWAOiDzs4QDXyz8R2RdafHEnLGbO4ltENA1atSpq9PDh7R6/bSbg3sD0+V2e0b c9LcV2Iifint2NBg22744OQxjbqgSRb0UhGp9orQYFIquOtGaSVJ3hOK2gjzx4EvRYAN PCedSRQD0HdXRXeTDIdTrlxkpiHN4Rar+TXuJLZc3r3v6QViErPnluMZ7vjjgS6gnJo/ daeuim/GB2EAzTwWLwVffeAcrkw6rCrbVZFi6mg9tLXI5hV0LCGzShSkWal+KVv59hDv 43la/VlB5YjEbwSZw2lUxOYyd6W/vbfDWG9hEpCR15yP2SIYtyufH30BVFwbS4OH6Xl9 UtgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814829; x=1773419629; 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; bh=J/Kmt/9cTJTTmvSy1vXRcQGyNeZ//R0WlMTYDIyos0A=; b=iAHNLl6X5g7qKW4apoygHjzG7wc/LKKU267XHxOtRGCI2HwP63Mt6m+SwYCrfB0+cC hNLNHhp8HJwOe/b0OeAMb7CCHjUPy06ZbeePjll4fdeB8bvwFdIVUu1VNyKNTRCMXB9p NAKXImQWKFRe9jwtHz46BWkdNv+N2BjVQ63b/z8qt8xlCMXfhYrUAKhknjKZ55yIe43b 62ZVNcev/yW1NX6Bz9CLSQK/XnVowcv63xWJLT+GB45IfTO9qUzOAFbaIfkboTJBzaLd mnwbreYIFb++awRwRwuOAfMjQipmk6tAwM7fNMKYihWF7xTisW6rAtUcG/s6r9zyz1l+ cN6g== X-Gm-Message-State: AOJu0YxB0cKG/ZuSK0gOQmzncVwsb2RwWLC6yIqH2ByhKrB7eP0lPZJA uXEUqzrooyptRrTON9Yqcjae1b4V7vvCziErfLYE0hc+fHdP6wL2/eI9Czxt1Q== X-Gm-Gg: ATEYQzwMGunL2mWqR/dIyeMug4sL+jX/9iSRA+9KCXPlEg3Qbjkv4PM4tDMMQxEbJGA p9Fu/FEoDfgc/w1iFJUL0t2po+YUh+LK7nmpjKHC3Jz7bzcyFEAdr+9zwz75D+mO4SO79XYzPgA FtkOwr7aSBVfWbzF3BtP+/wnzlzbisE36kynVovdu6tqkac1P1l8QtXQvD8CuSaMEfDhJvcUUFc MYXJRTMv7RfQjjLCGHS0s5kDq621LSKedxpy7GUUJpr7YH3xBRqcJjYLnHFYrT0q3o5j23cH9y0 OZEW0mhk54uRHHkgmfGo1hQmBjVd9XniHqhQr7FxiXj5jhuhe8fYzac9NM7XiBLx1Npfq9bqTiP tY79gd06R4k2S0gOVR87RU7JrwFyOzkNLv8mg4S4txkt+njgLsdrcDN9dQTb2tv/fXkbPZB5H+R VBKyAaPTzYY5xH12+tyCtUSQlWem3KR2WWMNofw6Wh3HBJF82Honihsr6QHvMBVIMkIQ== X-Received: by 2002:a05:600c:859a:b0:477:a36f:1a57 with SMTP id 5b1f17b1804b1-485269188cfmr33076975e9.3.1772814829291; Fri, 06 Mar 2026 08:33:49 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 09/14] xen/riscv: introduce sbi_set_timer() Date: Fri, 6 Mar 2026 17:33:26 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Introduce a function pointer for sbi_set_timer(), since different OpenSBI versions may implement the TIME extension with different extension IDs and/or function IDs. If the TIME extension is not available, fall back to the legacy timer mechanism. This is useful when Xen runs as a guest under another Xen, because the TIME extension is not currently virtualised and therefore will not appear as available. Despite of the fact that sbi_set_timer_v01 is introduced and used as fall back, SBI v0.1 still isn't fully supported (with the current SBI calls usage, sbi_rfence_v01 should be introduced too), so panic() in sbi_init() isn't removed. The sbi_set_timer() pointer will be used by reprogram_timer() to program Xen’s physical timer as without SSTC extension there is no any other option except SBI call to do that as only M-timer is available for us. Use dprintk() for all the cases to print that a speicifc SBI extension is available as it isn't really necessary in case of release builds. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-v7: - Nothing changed. Only rebase. --- Changes in v5: - Add inclusion of to to deal with the compilation issue: ./arch/riscv/include/asm/sbi.h:156:30: error: expected ')' before 'sbi_set_timer' 156 | extern int (* __ro_after_init sbi_set_timer)(uint64_t stime_value); - Rephrase the first sentence of the comment above declaration of sbi_set_timer pointer to function. --- Changes in v4: - Add "stime_value is in absolute time" to the comment above declaration of sbi_set_timer() function pointer. - Add Acked-by: Jan Beulich . --- Changes in v3: - Init sbi_set_timer with sbi_set_timer_v01 as fallback value. - Sort SBI IDs in the same way as SBI EXT IDs are declared. - Add __ro_after_init for sbi_set_timer variable. - use dprintk instead of printk to print information if SBI ext is available. --- Changes in v2: - Move up defintion of SBI_EXT_TIME_SET_TIMER and use the same padding as defintions around it. - Add an extra comment about stime_value granuality above declaration of sbi_set_timer function pointer. - Refactor implemetation of sbi_set_timer_v02(). - Provide fallback for sbi_set_timer_v01(). - Update the commit message. --- xen/arch/riscv/include/asm/sbi.h | 22 ++++++++++++++++++ xen/arch/riscv/sbi.c | 40 +++++++++++++++++++++++++++++++- 2 files changed, 61 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/sbi.h b/xen/arch/riscv/include/asm/sbi.h index 79f7ff5c5501..ed7af200288f 100644 --- a/xen/arch/riscv/include/asm/sbi.h +++ b/xen/arch/riscv/include/asm/sbi.h @@ -13,6 +13,7 @@ #define ASM__RISCV__SBI_H #include +#include /* SBI-defined implementation ID */ #define SBI_XEN_IMPID 7 @@ -29,6 +30,7 @@ #define SBI_EXT_BASE 0x10 #define SBI_EXT_RFENCE 0x52464E43 +#define SBI_EXT_TIME 0x54494D45 /* SBI function IDs for BASE extension */ #define SBI_EXT_BASE_GET_SPEC_VERSION 0x0 @@ -48,6 +50,9 @@ #define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA 0x5 #define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID 0x6 +/* SBI function IDs for TIME extension */ +#define SBI_EXT_TIME_SET_TIMER 0x0 + #define SBI_SPEC_VERSION_MAJOR_MASK 0x7f000000 #define SBI_SPEC_VERSION_MINOR_MASK 0x00ffffff @@ -134,6 +139,23 @@ int sbi_remote_hfence_gvma(const cpumask_t *cpu_mask, vaddr_t start, int sbi_remote_hfence_gvma_vmid(const cpumask_t *cpu_mask, vaddr_t start, size_t size, unsigned long vmid); +/* + * Programs the clock for next event at (or after) stime_value. stime_value is + * in absolute time. This function must clear the pending timer interrupt bit + * as well. + * + * If the supervisor wishes to clear the timer interrupt without scheduling the + * next timer event, it can either request a timer interrupt infinitely far + * into the future (i.e., (uint64_t)-1), or it can instead mask the timer + * interrupt by clearing sie.STIE CSR bit. + * + * The stime_value parameter represents absolute time measured in ticks. + * + * This SBI call returns 0 upon success or an implementation specific negative + * error code. + */ +extern int (* __ro_after_init sbi_set_timer)(uint64_t stime_value); + /* * Initialize SBI library * diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c index 425dce44c679..b4a7ae6940c1 100644 --- a/xen/arch/riscv/sbi.c +++ b/xen/arch/riscv/sbi.c @@ -249,6 +249,38 @@ static int (* __ro_after_init sbi_rfence)(unsigned long fid, unsigned long arg4, unsigned long arg5); +static int cf_check sbi_set_timer_v02(uint64_t stime_value) +{ + struct sbiret ret; + + ret = sbi_ecall(SBI_EXT_TIME, SBI_EXT_TIME_SET_TIMER, stime_value, +#ifdef CONFIG_RISCV_32 + stime_value >> 32, +#else + 0, +#endif + 0, 0, 0, 0); + + return sbi_err_map_xen_errno(ret.error); +} + +static int cf_check sbi_set_timer_v01(uint64_t stime_value) +{ + struct sbiret ret; + + ret = sbi_ecall(SBI_EXT_0_1_SET_TIMER, 0, stime_value, +#ifdef CONFIG_RISCV_32 + stime_value >> 32, +#else + 0, +#endif + 0, 0, 0, 0); + + return sbi_err_map_xen_errno(ret.error); +} + +int (* __ro_after_init sbi_set_timer)(uint64_t stime_value) = sbi_set_timer_v01; + int sbi_remote_sfence_vma(const cpumask_t *cpu_mask, vaddr_t start, size_t size) { @@ -324,7 +356,13 @@ int __init sbi_init(void) if ( sbi_probe_extension(SBI_EXT_RFENCE) > 0 ) { sbi_rfence = sbi_rfence_v02; - printk("SBI v0.2 RFENCE extension detected\n"); + dprintk(XENLOG_INFO, "SBI v0.2 RFENCE extension detected\n"); + } + + if ( sbi_probe_extension(SBI_EXT_TIME) > 0 ) + { + sbi_set_timer = sbi_set_timer_v02; + dprintk(XENLOG_INFO, "SBI v0.2 TIME extension detected\n"); } } else -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247981.1546396 (Exim 4.92) (envelope-from ) id 1vyY7e-0005FX-D5; Fri, 06 Mar 2026 16:33:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247981.1546396; Fri, 06 Mar 2026 16:33:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7d-0005Cy-VY; Fri, 06 Mar 2026 16:33:53 +0000 Received: by outflank-mailman (input) for mailman id 1247981; Fri, 06 Mar 2026 16:33:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7c-00030j-5k for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:52 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 420cbc5c-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:51 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-48371119eacso112097795e9.2 for ; Fri, 06 Mar 2026 08:33:51 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:50 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 420cbc5c-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814830; x=1773419630; 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; bh=AYl+zWkW5xPd0n05ltjvtGI8d6PS/n+RbbF8iPoiaOQ=; b=mdj3j8LxlURwz5uvn8CZQ4am/ZnPlQHwmX/qxgvT0MDZfFRdOO9guZmt4qc2GfGmn3 4jjqh/8z4r5stplhNPwy5pUH0dn4LWd5Qe6Pwyjv8Im6m80wgSo85nCwVmIK7WPcRbGu IV4ILTUuDb3V/zTjKmveB0biwSD287taBdl2RAR7bhlIOfSowVsGIe5uRWNW5uOlikOI isUYGJ7Gv5zg3/njC3hmRUPcpH4wUkczQ2XC9KvP3wCyudWxOvTKVQ6mz1v2FIbkx9P0 TR7JPF1yAFAqVR9Qr+Za+M0K6lSESD9swCVv8JhtB9gAJZNjEXkKhDNlUcKX2rU5kD+A wGGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814830; x=1773419630; 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; bh=AYl+zWkW5xPd0n05ltjvtGI8d6PS/n+RbbF8iPoiaOQ=; b=TMTdarz0wV044aTaUOgYyMhXO5wYtGey+J2ck+q6g06xKfRfla9n7qRz0GXfhTEj2u jAjF90P2LWioEXNeb7FfD5O1ge9ho0qNnu8WslLwMm/jLhUfxiEV1ja5nUunE3QHr9fb N6ZIcq1qK4cKVh+1XOEfHpnVgoiVhpiFURg4dPv1qT1Df8o1Y7won2pi9JjdRxflmCJ0 4RW3UP5jnLmFx+gUK0jGb0yPcT/cBmDeXbZfw+1EDIQd7Vnlm+ngW8Ycn0ftBIwTimTg XMQ5WqBXMlMyNdTc3r6hjSbfUWVpKZluT8f2D3+18J2gJKL3M6gtNFUicpLBi+MCWBr7 jV7w== X-Gm-Message-State: AOJu0Yy0E+fXhJwH8t35w8WHJOYH9hVGjNGVpeUdQtT/8XVAG/S8nJ03 h2ZqoScUgqy/MaTuwsaUqdBxJFxpUmzT25n9CyHSENUdOy+F6xpQb7JyPfrTKw== X-Gm-Gg: ATEYQzzX3RD6CQIKcx+J9ULCEslMYgQDHYNZulAmj1Xb4PD8SpdXThTPIhn/Qv3Cter lHLoPdnRWJTZgSAKv9WB6B99RKMB6mgu5TI4XaT119AeocwJYSKVKR58lPTBYCuWm+4seCJ0rsE 177FH6Gz+G845x7OYHKZx1mUiWalY9PIc9+OVwQ3WvJzrn2lMO3LAlihyKUXiIEKPxg6YfBtnYo sfhdeOcQ1gs19CLcfmyIPt3F92H4PZgc+rpkTEti4eAo+OH3lH2uKBFZbbqhvwP/n5xb8le26LY r5BFfxG7ik8bE+wmGYggyzEAN1dWynDJ+P6HpoLNIsSjVWBEGMtQYfTNcW6DFN0OckhK0ng9v3V 0Is1gMx7SuDkoFQj333UK0MHOkfOuRe20KPxoeHhxDO5BBmzxYpFumiojEK68PcrDMOIwDdWCUP GyzDu3Aj9N4pYMJk0qoV/XfdBIJLXRl+1KeVl4Si0LdTW91VA+Q6FT8iyWjmqTfkTInA== X-Received: by 2002:a05:600c:1e2a:b0:477:b642:9dc1 with SMTP id 5b1f17b1804b1-4852695819cmr44199145e9.20.1772814830199; Fri, 06 Mar 2026 08:33:50 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 10/14] xen/riscv: implement reprogram_timer() via SBI Date: Fri, 6 Mar 2026 17:33:27 +0100 Message-ID: <89884307fb74c534c0ed07afc1443aee4cab9a7b.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Implement reprogram_timer() on RISC-V using the standard SBI timer call. The privileged architecture only defines machine-mode timer interrupts (using mtime/mtimecmp). Therefore, timer services for S/HS/VS mode must be provided by M-mode via SBI calls. SSTC (Supervisor-mode Timer Control) is optional and is not supported on the boards available to me, so the only viable approach today is to program the timer through SBI. reprogram_timer() enables/disables the supervisor timer interrupt and programs the next timer deadline using sbi_set_timer(). If the SBI call fails, the code panics, because sbi_set_timer() is expected to return either 0 or -ENOSUPP (this has been stable from early OpenSBI versions to the latest ones). The SBI spec does not define a standard negative error code for this call, and without SSTC there is no alternative method to program the timer, so the SBI timer call must be available. reprogram_timer() currently returns int for compatibility with the existing prototype. While it might be cleaner to return bool, keeping the existing signature avoids premature changes in case sbi_set_timer() ever needs to return other values (based on which we could try to avoid panic-ing) in the future. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v5 - v7: - Nothing changed. Only rebase. --- Changes in v4: - Add Acked-by: Jan Beulich . --- Changes in v3: - Correct the comments in reprogram_timer(). - Move enablement of timer interrupt after sbi_set_timer() to avoid potentially receiving a timer interrupt between these 2 operations. --- Changes in v2: - Add TODO comment above sbi_set_timer() call. - Update the commit message. --- xen/arch/riscv/stubs.c | 5 ----- xen/arch/riscv/time.c | 43 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index eedf8bf9350a..2f3a0ce76af9 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -21,11 +21,6 @@ nodemask_t __read_mostly node_online_map = { { [0] = 1UL } }; /* time.c */ -int reprogram_timer(s_time_t timeout) -{ - BUG_ON("unimplemented"); -} - void send_timer_event(struct vcpu *v) { BUG_ON("unimplemented"); diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c index 2c7af0a5d63b..7efa76fdbcb1 100644 --- a/xen/arch/riscv/time.c +++ b/xen/arch/riscv/time.c @@ -7,6 +7,9 @@ #include #include +#include +#include + unsigned long __ro_after_init cpu_khz; /* CPU clock frequency in kHz. */ uint64_t __ro_after_init boot_clock_cycles; @@ -40,6 +43,46 @@ static void __init preinit_dt_xen_time(void) cpu_khz = rate / 1000; } +int reprogram_timer(s_time_t timeout) +{ + uint64_t deadline, now; + int rc; + + if ( timeout == 0 ) + { + /* Disable timer interrupt */ + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + return 1; + } + + deadline = ns_to_ticks(timeout) + boot_clock_cycles; + now = get_cycles(); + if ( deadline <= now ) + return 0; + + /* + * TODO: When the SSTC extension is supported, it would be preferable to + * use the supervisor timer registers directly here for better + * performance, since an SBI call and mode switch would no longer + * be required. + * + * This would also reduce reliance on a specific SBI implementation. + * For example, it is not ideal to panic() if sbi_set_timer() returns + * a non-zero value. Currently it can return 0 or -ENOSUPP, and + * without SSTC we still need an implementation because only the + * M-mode timer is available, and it can only be programmed in + * M-mode. + */ + if ( (rc = sbi_set_timer(deadline)) ) + panic("%s: timer wasn't set because: %d\n", __func__, rc); + + /* Enable timer interrupt */ + csr_set(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + return 1; +} + void __init preinit_xen_time(void) { if ( acpi_disabled ) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247983.1546408 (Exim 4.92) (envelope-from ) id 1vyY7g-0005mq-H2; Fri, 06 Mar 2026 16:33:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247983.1546408; Fri, 06 Mar 2026 16:33:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7g-0005mX-Dd; Fri, 06 Mar 2026 16:33:56 +0000 Received: by outflank-mailman (input) for mailman id 1247983; Fri, 06 Mar 2026 16:33:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7d-0003HN-Uh for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:53 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42b2c3d4-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:52 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-483487335c2so79746765e9.2 for ; Fri, 06 Mar 2026 08:33:52 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:51 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42b2c3d4-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814831; x=1773419631; 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; bh=sVTsKCN0wSfASIBvtQYg3brcx2aWUdWXZHC8J7YgVpo=; b=C5WD/ptislK0gk/27Z9QRkML3FdDH9WnR76RxuARrWdW9BkVUL1W+G496AY4PHITjV rGxEUSVFNJIIMV4Jj3AeXsXyFqcD3Lln91U5glcEL6bUvp+hghhmuyJK0PaV8zBs+PMx /hDjHyTUp27QtaxmmXxqHVFGnZjQaK6VgrgPHsEJ3HJ6G9WbSYD32FNW9L4PMnXIWTRZ dLYg6gfnIoxHFKTlS9lhBU5upN3cwUUq3A6Pok/Difg7yLhpB2S5afONx1gv7IExWfP1 kyOF+b5yO893iDOSuFFZ628rd3WwfzlpWAhd3mmCAtAPeO60JJfXZZS+O4Dkny5DCqY9 jdNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814831; x=1773419631; 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; bh=sVTsKCN0wSfASIBvtQYg3brcx2aWUdWXZHC8J7YgVpo=; b=k0cC2sfWRJRZWL7XXwIdAD9S4lbUlb3aPscNrAHJGQak21YctGp2NrCteT6QbeHFMW kzriRWa0i1XTIF5IJMyN93SdboD5vCwoUillyxQt2RHYNADMerTxKPRDoMuK0BrRhhB+ Np16IRQP/KWLblHnAqQ6YfvlQ6FZBnRutDCrJcBjTovFf0Dl4CdPY8WXF70QVjUhIWDb lYURZs2RazVmxidNWTG+uwghYkcrdvsW8FaJtYY26qRvEkAtia1PPKP+zZeriBZjsl8P ZcMAr/ZjlRPC8crM/A9Kzixq/4/5WLzeqlhLbBwt0IV5dDJwiia9YJoGyBN4Va/pYtGT Q8xA== X-Gm-Message-State: AOJu0Yy+y7+rX4M9ielRib1c7QeaBJ46p9ihM6jrEZY8vptkP8Lo05ln AaNFWy9XTyFuQtl7QOd8NpIKYgK5Un4NyjOb4C0ZNIyC3wj0R2UlAyay0rVzuw== X-Gm-Gg: ATEYQzyyPYQqkglBhi6jlo/SuDolJ3v0RmAg5Z1dg+i/08HYUS4usGy0iIWKfy718WJ iNPPBl9eq5qi1xDLZiYTRNKPIMwa8F+53kG0ZSzN9t7jUiXREgdyi/nYhRK1/mjrnVxdqW7egJD TwcWJuYBZ45kNOIzNgVr6YB3rH7mENLqNC9sE3iKbaFjJ9t28IsdSyE8tQ+/Gb2tcqXzUcICQZU DUV0XBNeXCxApn/TMgQsMXO+Itg34/MvxpKHfGlycWb7kyC9beFUfruPuzgYtnh63Q4j9RtVvtQ S45ouGUZhwRMWyndUB10p527hcEMXGDF4lCVmV0fkMPii1Co4Pk1CJfmwt4YobUNdGZdsiFwiME Ti7iUMsHG5102zDseGUTkzJYlV5WTMRQih6Uml5aqsvQf8rYlAHLcX2LQB4EXMGL0Nxd1Tz47vG xvSDV9yicdsQ5j1u0CSeXDt4tW8WO1T/PAmFf0QDAqRo2Xg9snS8Gq8U3PxY+LTBPUIA== X-Received: by 2002:a05:600c:138a:b0:47e:e2eb:bc22 with SMTP id 5b1f17b1804b1-4852691c5bamr48041945e9.5.1772814831354; Fri, 06 Mar 2026 08:33:51 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 11/14] xen/riscv: handle hypervisor timer interrupts Date: Fri, 6 Mar 2026 17:33:28 +0100 Message-ID: <8a1b9279cf17fbe258af62c95377540c236b292e.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce timer_interrupt() to process IRQ_S_TIMER interrupts. The handler disables further timer interrupts by clearing SIE.STIE and raises TIMER_SOFTIRQ so the generic timer subsystem can perform its processing. Update do_trap() to dispatch IRQ_S_TIMER to this new handler. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v4-v7: - Nothing changed. Only rebase. --- Changes in v3: - add Acked-by: Jan Beulich . --- Changes in v2: - Drop cause argument of timer_interrupt() as it isn't used inside the function and anyway it is pretty clear what is the cause inside timer_interrupt(). --- xen/arch/riscv/traps.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 244264c92a79..326f2be62823 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -10,6 +10,7 @@ #include #include #include +#include #include #include @@ -180,6 +181,15 @@ static void check_for_pcpu_work(void) p2m_handle_vmenter(); } +static void timer_interrupt(void) +{ + /* Disable the timer to avoid more interrupts */ + csr_clear(CSR_SIE, BIT(IRQ_S_TIMER, UL)); + + /* Signal the generic timer code to do its work */ + raise_softirq(TIMER_SOFTIRQ); +} + void do_trap(struct cpu_user_regs *cpu_regs) { register_t pc = cpu_regs->sepc; @@ -221,6 +231,10 @@ void do_trap(struct cpu_user_regs *cpu_regs) intc_handle_external_irqs(cpu_regs); break; + case IRQ_S_TIMER: + timer_interrupt(); + break; + default: intr_handled = false; break; -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247984.1546415 (Exim 4.92) (envelope-from ) id 1vyY7h-0005qY-C6; Fri, 06 Mar 2026 16:33:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247984.1546415; Fri, 06 Mar 2026 16:33:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7g-0005pU-Tz; Fri, 06 Mar 2026 16:33:56 +0000 Received: by outflank-mailman (input) for mailman id 1247984; Fri, 06 Mar 2026 16:33:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7d-00030j-SR for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:53 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4341cdb7-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:53 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439cd6b0aedso1877979f8f.1 for ; Fri, 06 Mar 2026 08:33:53 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:52 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4341cdb7-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814832; x=1773419632; 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; bh=CHQw0iiSnYlgicKjMQWpmEGJyBczoqjDPyy2AZz+9Fw=; b=EzvjXlOBt+82hkUl0YrMvdyEsVAFxquwuHIV9uIUyb45VKS3Fg5VQvyeMLOuvbwTBy TfIrTGh0KEaTjmwi8kbQX6XoFA63NxhpX4cqrMLRMN3XtcqttyS3hNxCc5sXFJI5kiM8 2mMXAaMbOU4o4sQ71IjTqg159DSl9zRl1UCey9FwCW64JeJGPJipSPeCnC+ZSJcZ2YH2 5YcKyTtuwrbhhVwwhuW5iL95gkk1cFOcNSnrfy7/Cmvtm1jS029I8CB3+BcvkipyME7P L5Wc6BQU00uo58LLRve4n68cvDFwKYGxNPTriRjhoG0H/B8sjnhR6J8vvdmsFxteksFi UZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814832; x=1773419632; 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; bh=CHQw0iiSnYlgicKjMQWpmEGJyBczoqjDPyy2AZz+9Fw=; b=u1j9Uihsmz0p8AHQdm7qXCU+gYQu/DU7lp6TkUPKiF4mYtFVFvXsu3qGI8QBvlz/uj 2ZId7qGQSyjTSkfJEQ+RkSiPlEIkj/bSlzxBJuQYoGaPdJLoAX1fDHu5o28/o0TSECFG s79zGaUo9LPQKJ5qpKmWcnY6opiqDGZrzUus5ZiP3ZPRhXmwkuDsqntiuh1ov4qrUpJ1 6XyEJeBpzi5AQcVxkNh0Cgs0P0OoASqWKSaHI5GJ2oRyYGWmN1ywvYn0RxsINVt78oJf fqWGw2yMnqLN0nQHqTbmiaXpde4pWxUT98Mbsy5UUcvxmFzZTbg2jpmmVm6TzM7LSoBS qP4A== X-Gm-Message-State: AOJu0YytURpBvscRr4KgKDBjv5UpP18gLDpYpNeqUHTp95Ys3ClBbM5w AmpAlGTXkdUlVW7F8rylpZfa6JsZaTAazDsx/HiNbXIrrUKZbcU9WAv4bO1E6w== X-Gm-Gg: ATEYQzzDw/7qK0VVfYHQn/qwUn0Cwajn0tGtLat78vTbZdGs/yIIiZUvBYS67TKU4sS Fl46bi8plknDQPTA+841Hf0kmr7T4LYT9RC1LW2vOSJRj33Z2QD+wpiChWrUmci7nSP/Jf/O88L fmWC7fmuHI+Je4dDESVD+CanhJHz8zRutggOoC1DRNxtiFPimGeWtleIlJTFSAEUCvyh/quLzNr woOTVcn40ZAK9WlwdJvZQmMzMObwzSIYPt5VQsGhIVxAmRpeF+GWU9GO2BeoXeBcMnh09+JQodj tZHRCxM0F9lsYeXHln+N+lm8ujn0uN7+boZukI7WmLxX5k9oSc3UDRc8i5Z0EeFf002hVEZvGgc FBwkn1na9rRi//XOPBcSuaGETiuH+HAz+dIGNCIDro8rat1zbCXv+B9sKhzYljaPE0gp2qwQsws uY4arNPM8WFXx7gwBVc7L7GoyTYb5zI+Wm6IMV6f2zJbUq5eIK8BpwkBi/YGZsDqVymg== X-Received: by 2002:a05:6000:144a:b0:439:bc31:a04d with SMTP id ffacd0b85a97d-439da8941femr4925276f8f.41.1772814832338; Fri, 06 Mar 2026 08:33:52 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 12/14] xen/riscv: init tasklet subsystem Date: Fri, 6 Mar 2026 17:33:29 +0100 Message-ID: <0475cb50e04a48aedd730f2f0ab57381cc26d6ed.1772814110.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit As the tasklet subsystem is now initialized, it is necessary to implement sync_local_execstate(), since it is invoked when something calls tasklet_softirq_action(), which is registered in tasklet_subsys_init(). Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-v7: - Nothing changed. Only rebase. --- Changes in v5: - It was something wrong with prev. rebase. So fix that and move removing of sync_local_execstate() and sync_vcpu_execstate() to the next patch. --- Changes in v4: - Nothing changed. Only rebase. --- Changes in v3: - add Acked-by: Jan Beulich . --- Changes in v2: - Update the commit message. - Move implementation of sync_vcpu_execstate() to separate commit as it doesn't connect to tasklet subsystem. --- xen/arch/riscv/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index bca6ca09eddd..cae49bb29626 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -133,6 +134,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, panic("Booting using ACPI isn't supported\n"); } + tasklet_subsys_init(); + init_IRQ(); riscv_fill_hwcap(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247986.1546418 (Exim 4.92) (envelope-from ) id 1vyY7i-0005zX-1J; Fri, 06 Mar 2026 16:33:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247986.1546418; Fri, 06 Mar 2026 16:33:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7h-0005vK-Ij; Fri, 06 Mar 2026 16:33:57 +0000 Received: by outflank-mailman (input) for mailman id 1247986; Fri, 06 Mar 2026 16:33:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7e-00030j-Uc for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:54 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 43d443d0-197a-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 17:33:54 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439ce3605ecso1560842f8f.0 for ; Fri, 06 Mar 2026 08:33:54 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 43d443d0-197a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814833; x=1773419633; 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; bh=cYzV7pV3IRuCnaF6MoayYG+rthZpT+FdfN6FzWyJXSQ=; b=Mgr8bq7+BcKVYbV63vadXQqQXTgoOwBQ9IBlF0hMKa93o8qGy4qIji+jmtD/pdlFuH p2jkAGYOReA0SISIr9+1Z0ifVUGPYkRiQ41p6ixNluXCvCKOstsmtRpW8/XR+h3w1Wyh +1oJy6pX2V8mYNPgu3RTRnDmosxm7L4Lhp1SHINneYlk2k99ylwZ5UBRaXbt7PqlsxrU y75o3R9oJqQKagApicWodfk7cDaAanHQoUHbrzTCv92eleY1hJjRHiIjzFw1aTpEp7PZ mDG4izOm53IVbsdlRXVNsNH+0ea7QYSlE5x+YDjmwM7kxLUFWOw2BoNsiZXWJI6xfDNP ZYjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814833; x=1773419633; 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; bh=cYzV7pV3IRuCnaF6MoayYG+rthZpT+FdfN6FzWyJXSQ=; b=aVNUQlTM3gEckrmDFoPihEUquAU0xu8QA7hu5gg9tDRQqkc1gS3jZLJuZg/MaJSNrO rxmXrp0JGs43ZccrfdJ3fbrNlGYJr3zvN6EmxHxA6tGdfN7IUucVDIVyI/1mHIfKZMHo W9k4NUGHjfLxLv8CIkIMCo8Nap/oP3ZOnnoL2MXLNIJN17ggoa2WhUT8SAiizZyX86Wj 2EO5ts5MPggPiZ+v32B8CdC0ky91XEeCNR2Q99ZKaSjunw+AUpNE++rKoWvS77FiqcH8 NkcsxJGID9GhLqqRAdLmfBJo8fzqtb2blcRe8GPaLGYdtFbIqfV25nI6b03aFC2uUZU8 SBzg== X-Gm-Message-State: AOJu0YxItaX774536MO8Azl3Md/pkDXfr6W1elLI78KdbJXfSacFpXa/ dCG4A4R9MgSZISlVz58Hsz+pvTniIr2IbYDS5avmo7zQE4dGgxhdkqF0TZhq8w== X-Gm-Gg: ATEYQzwSTiay9VRfHdnqaipDf+bk3FvZiESIE5a3SncTn8suqTRPJ0wx3OxwxnlTxhR vtSRMN9T9LYCM9lB5HQupxpWZIDLruNf9SWyLK+U5pEwvFKsWBV7yXrNnAVWk/jK8S+XuoWS5eT pOdzEoA+Di6LGjcTgKc4kCiSiii/txnptSsK2Q65FzqKi7xakiewzqr6gROekdv2c9bZdFQQKX3 NmM9x+oeyvAkSJh5Qj+5Lvt3/cxxmW0ClVi6Hgh1QqIz5sqmnsv8JM9rntT/zB+0F5H0Zsg9Gi/ 86qkieeIfvgsQl/eY7e8rbNdg927Ym/mMsRJ2dnkJTE4DkN+OudXslkf0HBIM4v81uCftKse84T M+QtQiCLGYQrmDV00wKUrjIKEXF8oeQynunr4S6o98IlVURlLa2I83mKQex+HFSbOiDC3L0kxH1 lU2fhar8I+wjr9pHVa2ORRPFCtLiLa8tMi1PP1Z85o/StB5tF22+zVqa4aMp1kVDC7jw== X-Received: by 2002:a05:6000:1846:b0:439:b7b5:b1d1 with SMTP id ffacd0b85a97d-439da65d6e4mr4835532f8f.18.1772814833266; Fri, 06 Mar 2026 08:33:53 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v7 13/14] xen/riscv: implement sync_vcpu_execstate() Date: Fri, 6 Mar 2026 17:33:30 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The scheduler may call this function to force synchronization of given vCPU's state. RISC-V does not support lazy context switching, so nothing is done in sync_vcpu_execstate() and sync_local_execstate(). Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in v6-v7: - Nothing changed. Only rebase. --- Changes in v5: - It was something wrong with prev. rebase. Drop stubs for sync_local_execstate() and sync_vcpu_execstate() in this patch. --- Changes in v4: - Drop footer as [PATCH] sched: move vCPU exec state barriers is merged to upstream/staging. - Add Acked-by: Jan Beulich . --- Changes in v3: - Align sync_vcpu_execstate() with patch: [PATCH] sched: move vCPU exec state barriers --- Changes in v2: - New patch. --- xen/arch/riscv/domain.c | 10 ++++++++++ xen/arch/riscv/stubs.c | 10 ---------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index c8ce1efa884d..7e3070101714 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -278,6 +278,16 @@ void vcpu_kick(struct vcpu *v) } } +void sync_local_execstate(void) +{ + /* Nothing to do -- no lazy switching */ +} + +void sync_vcpu_execstate(struct vcpu *v) +{ + /* Nothing to do -- no lazy switching */ +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 2f3a0ce76af9..acbb5b9123ea 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -91,16 +91,6 @@ void continue_running(struct vcpu *same) BUG_ON("unimplemented"); } -void sync_local_execstate(void) -{ - BUG_ON("unimplemented"); -} - -void sync_vcpu_execstate(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} - void startup_cpu_idle_loop(void) { BUG_ON("unimplemented"); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:33:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:33:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1247988.1546430 (Exim 4.92) (envelope-from ) id 1vyY7j-0006Pb-Li; Fri, 06 Mar 2026 16:33:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1247988.1546430; Fri, 06 Mar 2026 16:33:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7j-0006OI-9K; Fri, 06 Mar 2026 16:33:59 +0000 Received: by outflank-mailman (input) for mailman id 1247988; Fri, 06 Mar 2026 16:33:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyY7h-0003HN-2Z for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:33:57 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 44742426-197a-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:33:55 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48371bb515eso139922685e9.1 for ; Fri, 06 Mar 2026 08:33:55 -0800 (PST) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae57c05sm4406550f8f.39.2026.03.06.08.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 08:33:53 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 44742426-197a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772814834; x=1773419634; 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; bh=qFpsHTy+iZE+ZlLI/wSoHNKAABJERus7tjJu21kZd2A=; b=c/VEaL7MKi7XawxZ031l/Wj7E2m8bIBAHYmP0SbEsYoR0Hjy9lr5nu57miDo+7uFJQ HzuZnvXQB7V7D1Ocic+fk+Ge8WGx36N8dVifHX7UAPP/xiR78fm4kEO3wkqEQbCJ2kNL CZThkYtnEtBe6ejK/uRtmKwnqZU5+OzAY+aTc0Q5x49qjbzkJzVoU1fbOSjStXrPvZ2C WAdjZjk/v17VibI6NCwzW44XABgbsi6KcY+dtyO6to3Or9Jqno47pf59t5VYybf7+K+t xnePYR/uPAASaOc5wDikjm6/3vWXNK39z8GTQJwglO2aIntilHPxP3GupSeOXOYBLb36 hBvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772814834; x=1773419634; 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; bh=qFpsHTy+iZE+ZlLI/wSoHNKAABJERus7tjJu21kZd2A=; b=Mqu5wf0zrvB15s2yUVhHetipNZvORV5BLfK8lBfqpmvLmGCfFkYKT84KzollCs0x85 Z6sxYzlqbjeTsG8zeozxSn/gGIA+hBSWwaKpdrvYsPXZAh9fT6U3iJyRHDRI0rhkzp1L bLnP78OAjUyj7kS7uLToulsRe+eZmrHyowbZpHLBbq/3Gj5iCmisTTT54gAyj9AGi3ie ql7ccA6vbuAt9beDqcnNGFcjSen40q+VjIqr3msyCldDRx5LbClZ33hmSZQs3iDPLSO6 igHWofbV8hbOuPR0KhjIh09PpIHw4x3a+70lDHoAmETuS+1HQf6YXrMN5MnXnVvXwu6/ FQlw== X-Gm-Message-State: AOJu0YwfDU9MULWb1m4yh3WaFMIZzYtsvvE3i4BplAj8up/ZxStE8ufZ kcvpFWqtC36M+qysRJDbrEP/GwjaD3a6wactLmnqyE/ZcAQ1AXhFJfPjM2Fu6w== X-Gm-Gg: ATEYQzy3Zd5EGKrv+P2dTIPSwqOiqiWjCCFYn12EilJ7Fv+HtC0r5QA4hKCn22u58Ti Ye7OtGK4bvATWPIgbL1GU0U/5ZXmqLqt3AKkJXh0YkNH8AIc278I6hsZTKL4FsZsEkOuv07ECr8 zYv6HbKj6mBTpr3a+LBUIYVXIgI0k0bES2T0mNxvxOvpuIdpHxeYHbFSUeU8IenesuLtEt5uj/V FXNdf0EmwG8GzMr4oegpW7SOxZy2AjEoItaNC5w0W9YbiiNh56Lsi+v/4GbspixqzJrfce6YaSF hceFvo854xMidHb5EO0um4z58kDEAa0bZoxPiOuLPu2tAIBfT40WknS6DNTdRBjK/pLJsdFN+mV 99yE5iaooMqju8KQY5TYMe1IQZ/f99bAn/Ng05bWSoZB6BZDtLOpMo9qUza1RwOCX+4qiEhiOOQ vk+TYwhfeWVTCxUDnenkpYDjVc659rnwXvUhT4J7jhT+a+w7kIy9divUzr1VwA+1X58g== X-Received: by 2002:a05:600c:45c6:b0:483:c35d:3662 with SMTP id 5b1f17b1804b1-48526957c37mr42964395e9.18.1772814834067; Fri, 06 Mar 2026 08:33:54 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , Jan Beulich Subject: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing Date: Fri, 6 Mar 2026 17:33:31 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Some RISC-V platforms expose the SSTC extension, but its CSRs are not properly saved and restored by Xen. Using SSTC in Xen could therefore lead to unexpected behaviour. To avoid this in QEMU, disable SSTC by passing "sstc=off". On real hardware, OpenSBI does not provide a mechanism to disable SSTC via the DTS (riscv,isa or similar property), as it does not rely on that property to determine extension availability. Instead, it directly probes the CSR_STIMECMP register. Introduce struct trap_info together with the do_expected_trap() handler to safely probe CSRs. The helper csr_read_allowed() attempts to read a CSR while catching traps, allowing Xen to detect whether the register is accessible. This mechanism is used at boot to verify SSTC support and panic if the CSR is not available. The trap handling infrastructure may also be reused for other cases where controlled trap handling is required (e.g. probing instructions such as HLV*). Also reorder header inclusion in asm-offsets.c to follow Xen coding style: should be included before headers as there is no any specific reason to remain the current order. Signed-off-by: Oleksii Kurochko --- Changes in v7: - new patch. IMO, it is okay to have this patch separetely as at the moment it won't be an issue if Xen will use CSR_STIMECMP to setup its timer. The issue will start to occur when a guest will run. --- automation/scripts/qemu-smoke-riscv64.sh | 2 +- xen/arch/riscv/cpufeature.c | 8 ++++++ xen/arch/riscv/entry.S | 24 ++++++++++++++++++ xen/arch/riscv/include/asm/csr.h | 32 ++++++++++++++++++++++++ xen/arch/riscv/include/asm/traps.h | 7 ++++++ xen/arch/riscv/riscv64/asm-offsets.c | 7 +++++- 6 files changed, 78 insertions(+), 2 deletions(-) diff --git a/automation/scripts/qemu-smoke-riscv64.sh b/automation/scripts/qemu-smoke-riscv64.sh index c0b1082a08fd..1909abb7af32 100755 --- a/automation/scripts/qemu-smoke-riscv64.sh +++ b/automation/scripts/qemu-smoke-riscv64.sh @@ -7,7 +7,7 @@ rm -f smoke.serial export TEST_CMD="qemu-system-riscv64 \ -M virt,aia=aplic-imsic \ - -cpu rv64,svpbmt=on \ + -cpu rv64,svpbmt=on,sstc=off \ -smp 1 \ -nographic \ -m 2g \ diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 03e27b037be0..987d36dc7eee 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -17,6 +17,8 @@ #include #include +#include +#include #ifdef CONFIG_ACPI # error "cpufeature.c functions should be updated to support ACPI" @@ -483,6 +485,7 @@ void __init riscv_fill_hwcap(void) unsigned int i; const size_t req_extns_amount = ARRAY_SIZE(required_extensions); bool all_extns_available = true; + struct trap_info trap; riscv_fill_hwcap_from_isa_string(); @@ -509,4 +512,9 @@ 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"); + + csr_read_allowed(CSR_STIMECMP, (unsigned long)&trap); + + if ( !trap.scause ) + panic("SSTC isn't supported\n"); } diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S index 202a35fb03a8..b434948da3a4 100644 --- a/xen/arch/riscv/entry.S +++ b/xen/arch/riscv/entry.S @@ -99,3 +99,27 @@ restore_registers: sret END(handle_trap) + + /* + * We assume that the faulting instruction is 4 bytes long and blindly + * increment SEPC by 4. + * + * This should be safe because all places that may trigger this handler + * use ".option norvc" around the instruction that could cause the trap, + * or the instruction is not available in the RVC instruction set. + * + * do_expected_trap(a3, a4): + * a3 <- pointer to struct trap_info + * a4 <- temporary register + */ +FUNC(do_expected_trap) + csrr a4, CSR_SEPC + REG_S a4, RISCV_TRAP_SEPC(a3) + csrr a4, CSR_SCAUSE + REG_S a4, RISCV_TRAP_SCAUSE(a3) + + csrr a4, CSR_SEPC + addi a4, a4, 4 + csrw CSR_SEPC, a4 + sret +END(do_expected_trap) diff --git a/xen/arch/riscv/include/asm/csr.h b/xen/arch/riscv/include/asm/csr.h index 01876f828981..b318cbdf35c3 100644 --- a/xen/arch/riscv/include/asm/csr.h +++ b/xen/arch/riscv/include/asm/csr.h @@ -9,6 +9,7 @@ #include #include #include +#include #ifndef __ASSEMBLER__ @@ -78,6 +79,37 @@ : "memory" ); \ }) +/* + * Some functions inside asm/system.h requires some of the macros above, + * so this header should be included after the macros above are introduced. + */ +#include + +#define csr_read_allowed(csr_num, trap) \ +({ \ + register unsigned long tinfo asm("a3") = (unsigned long)trap; \ + register unsigned long ttmp asm("a4"); \ + register unsigned long stvec = (unsigned long)&do_expected_trap; \ + register unsigned long ret = 0; \ + unsigned long flags; \ + ((struct trap_info *)(trap))->scause = 0; \ + local_irq_save(flags); \ + asm volatile ( \ + ".option push\n" \ + ".option norvc\n" \ + "add %[ttmp], %[tinfo], zero\n" \ + "csrrw %[stvec], " STR(CSR_STVEC) ", %[stvec]\n" \ + "csrr %[ret], %[csr]\n" \ + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ + ".option pop" \ + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ + [ttmp] "+&r" (ttmp), [ret] "=&r" (ret) \ + : [csr] "i" (csr_num) \ + : "memory" ); \ + local_irq_restore(flags); \ + ret; \ +}) + #endif /* __ASSEMBLER__ */ #endif /* ASM__RISCV__CSR_H */ diff --git a/xen/arch/riscv/include/asm/traps.h b/xen/arch/riscv/include/asm/traps.h index 21fa3c3259b3..194d9a72f3ed 100644 --- a/xen/arch/riscv/include/asm/traps.h +++ b/xen/arch/riscv/include/asm/traps.h @@ -7,10 +7,17 @@ #ifndef __ASSEMBLER__ +struct trap_info { + register_t sepc; + register_t scause; +}; + void do_trap(struct cpu_user_regs *cpu_regs); void handle_trap(void); void trap_init(void); +void do_expected_trap(void); + #endif /* __ASSEMBLER__ */ #endif /* ASM__RISCV__TRAPS_H */ diff --git a/xen/arch/riscv/riscv64/asm-offsets.c b/xen/arch/riscv/riscv64/asm-offsets.c index 472cced4f8af..b0e2a4d86bd3 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 + #include #include -#include +#include #define DEFINE(_sym, _val) \ asm volatile ( "\n.ascii\"==>#define " #_sym " %0 /* " #_val " */<==\""\ @@ -54,4 +56,7 @@ void asm_offsets(void) BLANK(); DEFINE(PCPU_INFO_SIZE, sizeof(struct pcpu_info)); BLANK(); + OFFSET(RISCV_TRAP_SEPC, struct trap_info, sepc); + OFFSET(RISCV_TRAP_SCAUSE, struct trap_info, scause); + BLANK(); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Fri Mar 06 16:46:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 16:46:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248115.1546445 (Exim 4.92) (envelope-from ) id 1vyYKC-0003qk-DW; Fri, 06 Mar 2026 16:46:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248115.1546445; Fri, 06 Mar 2026 16: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 ) id 1vyYKC-0003qd-AN; Fri, 06 Mar 2026 16:46:52 +0000 Received: by outflank-mailman (input) for mailman id 1248115; Fri, 06 Mar 2026 16:46:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyYKA-0003qX-Cq for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 16:46:50 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0eaf7dda-197c-11f1-9ccf-f158ae23cfc8; Fri, 06 Mar 2026 17:46:45 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by LV4PR03MB8235.namprd03.prod.outlook.com (2603:10b6:408:2d8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.19; Fri, 6 Mar 2026 16:46:41 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9678.017; Fri, 6 Mar 2026 16:46:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0eaf7dda-197c-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UgIedQq2bEtIBoExFb+XjPZIZQHpnkLwJymO+D1SMJjzpqOpTb6XrtDTl4TQtfbg0rJMZFadCEF7uMHvqj2khucQc5E8p9UGHaimbxk7NeASqbuqcAwlGSaMYsjqAlZgC8JWTRr1agWsXG7Flu+/t/9QVg+nN5B/anI7iA3kpWSngA9ekAbBPULbvN1s2nDCXIskCgLEzBr08cAauMjl84i9KvAKZuM22j7jT7Ag7Nk2x+o7oGFIoTzU/SG7QayuAsIFZiJlNgrrJ9JnulKTZufWAEDplBhdGOj6BGz6doRCFqGqv8ehFOsZeK010sm2Ni18FuE/aBgDgTe5j/qB8w== 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=xwr/MMETSzLgWbupWT5oQkxt+MZIlNWPAb1MSClhT14=; b=nU8VBkdhM25XRpHh+vENB/2C7oxg4akfwrhYiCVHc+0jTu/hra4gWjh4/np/P63/iPwZ0QZ4BqeAE0Tth9ifttFg8tzSI+utbaoC7/lHKygESS4tYNsR44I33wOBnmfqPDdWYI/7gOu4KhAtBiO9e8pFGxac9Uz5gKyjJ5otlhy62F2bXoe/PGGraYjaeTzvRbKxJHYiI5QS7eQKJR02qEz4JIAINSOUBpp5oCS2WONNbQnWhzR5QjQ/MBXwfBOzsFo3HlmzWVCf39F9IVRs9v9iz43LAW4sNGkN83H+P5cOCZNW9JtISI6ruCpG4MPNtzgk6l2RyqH213uuIxhTGg== 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=xwr/MMETSzLgWbupWT5oQkxt+MZIlNWPAb1MSClhT14=; b=q9TT3W3fEI5rO7ADepXMnd7ECUU0e4bBcQa0WDNeT5Qaft+lFm3FcMIQBnAydGDn9EIu2n4ngE44v17s+2or2OWe/rOTWWwnWfbzCDKuBUzxpdb7K3EJm7WK5Yy7Xn4IqT3IyPheyTOIew7iaXfFVj0y+SL//3CQjAU9Gkaskvc= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Topic: [PATCH v2 1/4] tools/tests/x86_emulator: avoid duplicate symbol error with clang Thread-Index: AQHcp9gBGAcR9pePk0GnYyu6dQzUZLWc3C6AgAATegCAAAfEgIAABTyAgAANVwCABLepgA== Date: Fri, 6 Mar 2026 16:46:40 +0000 Message-ID: <63CC9001-B239-4806-B188-7C8A6BF63DF5@citrix.com> References: <358a87d89d50475a57f2a5d6ebea01d95a1df6d7.1772189234.git.edwin.torok@citrix.com> <766824c8-2ec5-45bd-9aed-1e84ad3ff779@suse.com> <004F02CE-B8C8-40B5-8453-C754EBE92022@citrix.com> <0210cf5c-6dc3-4db5-aa2a-0e14e634b463@suse.com> In-Reply-To: <0210cf5c-6dc3-4db5-aa2a-0e14e634b463@suse.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.400.21) 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: SA3PR03MB7419:EE_|LV4PR03MB8235:EE_ x-ms-office365-filtering-correlation-id: c89b6180-dd50-48ba-aa6c-08de7b9ff113 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021; x-microsoft-antispam-message-info: AVpM49B1jD3JMgc3CSHcwySaI/BIsIiZUemO7jv3Fp46zqPLooH1lEAILu7rBYoi4OAJdJeXXm+6F5QSVBBtHPX8eNXgPJ/fuPClABDu+Y37DVYYd1viQzhsuJ08+9At9Jdon9IRE8YlU/UNTiqBfUFBLjZRJk6KUkz8EGoNMjymyShheadudAXiKaoyT3PEsNIS7ODh6+YKDo3wLmI2sGeUjQrDZubkWE+CeztllxY3O6ol0JKmWDiKO96ntMJ4B6dOnDrxDuqgzYu73Pyx7kntAVc1APNZzGtDq4fIZX4Je1fGN7xHruav8kVZFnRwPz8xU+UuU+LZYaKAw9kKjBlDvttUUG5WNB4BlY3PDC/mjLs08kzYKFHag/tUqCaUHiHCag9l+09T3fUFfJWqr1MzhujRUSMPCnGTHdT3Ht4q4DHU3ZVbr/QSaBDOwVUEeueds/f0zqdPhc9dBC6eVx6LKizPEBPB36voBjZeVE7bl5RzoenW8JSMwCp3rcfuN7eqE3q3Jc35eYvDQGQj/wTlnCqBEcT3jZQCV1K1l2xBgbjzsMMrgp5uen7CYvS+aaRp0DxpZ/9ccAGX0Ob299fU7GKhTFKoNWzE546QjnAk3jXdde49KLyiulqlIB6L6aGQ6p7fLYtv6lhe4HJvK0a3ROfwQxoLlI6t/o1JdhCEssgRMD2LgGsOK/ly+l9eCA+HdfNP3np3KUooPV0EzYRRmN4g/bkGkJil7ANYgXd0rQ37KpZ+RqU4p9BSm0EXUrNlG1JfVm76Al+0C0ssWk/WypwyVsY5Tc6U/YsHrkU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Wmo2VFo4aU1jVGFxaTVqeGVNem8wdFo4YjQ1UG5lTHcyTFM1SXF4eVNwdXhm?= =?utf-8?B?RWphRFluMmt0bm9lS3VXUXk5U1ZDVkxrcThXN2h1KzNvM0w4TjRnUTlHR3Zx?= =?utf-8?B?em9sLytJTjZycGpDcTVKNUhFMndOZXpZeG5NWkN0bmdFUmVLSnZKVWhuRGE0?= =?utf-8?B?cEFyVVdpWDdyaDRVcStLVlovaThqS29SVEVTeWRWWVJtWkxhN3RndHBkb0VI?= =?utf-8?B?ZWtJbFdPWGtPZGtyRE5BbDJKNnhZOWFvUnRRQjJkbGIvN3JtRDdBZElLMERz?= =?utf-8?B?T2VoSDkwQTJQbTAwdmFVT2tob0ZZY0RodHVTd0VsVUFFVzRaRTA5Z1pZQWhw?= =?utf-8?B?SXdJY296WktzWnc4MmtmQUZ1V0x4VVp5dU4wR2M4T2FJS3VhZUQzVW9ZRWhV?= =?utf-8?B?azZ2ZHFCZVg4Qkc3cE05eVQ5QU1Eemx3MUNKTTk1K3p2ZnU4dDQ2OWJxZDlL?= =?utf-8?B?MHZka001RklONnlJaDRid1IvVXovWlhXOUVyenI2cS9QWmNObFdMY0cyY0FW?= =?utf-8?B?alQwc3pqamp0K0VPQmJNbDJSZktsR2VuV21WS2FmcjBycC9DRVRJMG5SNmpQ?= =?utf-8?B?Y2t2UytVcG9aSnM0eWNlMDVlNFV0Y1g4b1ZJNEoxZEZ1SlduVDNIL2FmMFJW?= =?utf-8?B?QzRmWFUyMFJNSGhJNURzZDltUGZ6NFQ5TkZhWjcxMzRZWnh1Mi9qZ2ZwZXBu?= =?utf-8?B?M3crWHBiL0dLTVp2UFBBM1BSNmFpY3Byb1ZYazJENFZiVGRuSDgxeEtYZ0Zj?= =?utf-8?B?VGZzbnB5cGI2bG5FK2QwS3l4SDVkeGhicmxnRm54Y3REb3p5ZVZPc0E4end3?= =?utf-8?B?eVp2N2p6SWlwd2N1SEgzdTZJbU9OVkVYMWFTbWpLb21XMHozU3ZDSVdxZXlL?= =?utf-8?B?ZjhBRTVMVWpSMjZDNWtOU0kwY2FyalZ6OE5KSmovVWJuVXl2OEVaR3BHMDhJ?= =?utf-8?B?ZlF4VlNlS1NXaTRSb2ZidGYrQlR1enl2WElmTXdXNG00ZEhsaVdPTzBsaGZ0?= =?utf-8?B?MmgrTWdCeDBqUmhIZ094K2ZCNE5nQlMyeER2dC8xTWozQzYxbldMRGJWRmxh?= =?utf-8?B?Mldub2ltTzZKLzNKczBMbzBmV3pMT21vZHdCTkVUTjhOUXBZaW1KVVFmZkwv?= =?utf-8?B?S1BkOThvS1lNVnJaNEl1dVQrR2MxY0FOdWlBMkNNSTVSMDNGamMwY3ZPWkhB?= =?utf-8?B?TjAxejJhR2dRSTZrM3JMczIvR0dPVUZselVBb2VuZUFkUTNTTktpS2YzQTlT?= =?utf-8?B?bi9lRzExZ21hcGVVQVdyem14Y1R1alg2YWRuOXJYaWU4SVBGMUs4RThZOHcx?= =?utf-8?B?a0RjWGlsTVUvTUYyVDRiZEdNNFRvWGdyeVEyaVNhT3RwMlNYVU5wUHAwaW13?= =?utf-8?B?YTlmVEJvaE1PalkzMDJ3b05NMHUyK0RZWGhkQjhNTFkraVk3QVVsTzVrc2NE?= =?utf-8?B?ZE5iZHdlNisyeDZCZnRMNWV3TC9hWlo3azR0SWJpTTl3Z0o3c1RXNGJpaFBD?= =?utf-8?B?OFd5emdWMGMzWGpMUjlKQVMvTkxFaktDYlk5c1dOSVpLamh4MWdhQ3pFQ1dT?= =?utf-8?B?b2hCTWFWaDg3ekcra3kybzk4UEdiNk1JbnRRT1NDREJsVERJMXhnekFTSmQ5?= =?utf-8?B?Nk9jc3JlYVBYUzhDUUo0cFljd1FUWnQ2VTV6Y0hHZjFrU08zSzFvVi9MUXJj?= =?utf-8?B?bHMzNUtLZzZWcitmRE5kNUNXZlduaGx3Z3owWWVlZmVoZVhBRDMvUTVCd0Fy?= =?utf-8?B?c3NESnJNVUdWR3RSdVFSTzZjdktON3U5QVZ6TGFwZU5nVG9Rbk9uTUc4eUpk?= =?utf-8?B?R0NabWdFdlRhNUVRa2dVZ0lDbkp6Y29JTGtyeHd0alNXejdvRE1tKzRzTFVD?= =?utf-8?B?NFEzU2owRmlNeCtvcmsxTGZmb3FPNXltMDhtdXhvQlIxUXgxRzlSZzFtM3pn?= =?utf-8?B?YzlIaktYRmJlNUV3Mk45NFVUQ1RsNVQ5MnoxTFdBUU9FeTY1eUNwODJBVzU1?= =?utf-8?B?VDBoWDlWczdFclRwUDJSNnVwdnE4QitHSkltT1pFUFBHMkxPWTdxNnVkWEYv?= =?utf-8?B?aUx3ck12OXI5c2hwbWF5Zks0MEhFeExkN3o4OWFvWWVKZnNUMm9NU3E3S3FI?= =?utf-8?B?STMyQ29iV0JRRG1lWlZDdzhQeE4vRm1mdVF3OEJwRThzdlZsb0lpQlhhSmg5?= =?utf-8?B?V3BybmFZS2F3dUk3Ri9jVmMrdG1ZYjdDNG5QUTlDS3RrVVI1T1F5cnJrbnUr?= =?utf-8?B?SEl4anJDaTZWR0JzenJRYU1yV0lHQ3EvVTdQUUpWekUxRTU0bWdQdHdaNVpk?= =?utf-8?B?RFZTaW8wMzZzWUU1R0dFWGU0SFNYcUkveTFTOUxNVFBlc0hSYnFkamQ2Q0VI?= =?utf-8?Q?WA/5C44w6pxMNt9A=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c89b6180-dd50-48ba-aa6c-08de7b9ff113 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2026 16:46:40.7585 (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: AcjJVABH6L/9gy5HSGnbdOGdZxsLAQ+Ebct/RLUIrWpHFoZZcba7xNTqgjlroruIS1fei/7YPzoK08UakDItEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PR03MB8235 DQoNCj4gT24gMyBNYXIgMjAyNiwgYXQgMTY6NDMsIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwMy4wMy4yMDI2IDE2OjU1LCBFZHdpbiBUb3JvayB3cm90 ZToNCj4+PiBPbiAzIE1hciAyMDI2LCBhdCAxNTozNiwgSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1 c2UuY29tPiB3cm90ZToNCj4+PiBPbiAwMy4wMy4yMDI2IDE2OjA5LCBFZHdpbiBUb3JvayB3cm90 ZToNCj4+Pj4+IE9uIDMgTWFyIDIwMjYsIGF0IDEzOjU5LCBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+IHdyb3RlOg0KPj4+Pj4gT24gMjcuMDIuMjAyNiAxMTo1OCwgRWR3aW4gVMO2csO2 ayB3cm90ZToNCj4+Pj4+PiAtLS0gYS90b29scy90ZXN0cy94ODZfZW11bGF0b3IvdGVzdF94ODZf ZW11bGF0b3IuYw0KPj4+Pj4+ICsrKyBiL3Rvb2xzL3Rlc3RzL3g4Nl9lbXVsYXRvci90ZXN0X3g4 Nl9lbXVsYXRvci5jDQo+Pj4+Pj4gQEAgLTE4ODIsOCArMTg4MiwxMyBAQCBpbnQgbWFpbihpbnQg YXJnYywgY2hhciAqKmFyZ3YpDQo+Pj4+Pj4gI2RlZmluZSBkZWNsX2luc24od2hpY2gpIGV4dGVy biBjb25zdCB1bnNpZ25lZCBjaGFyIHdoaWNoW10sIFwNCj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgIHdoaWNoIyNfZW5kW10gYXNtICggIi5MIiAjd2hpY2ggIl9lbmQiICkNCj4+Pj4+PiAj ZGVmaW5lIHB1dF9pbnNuKHdoaWNoLCBpbnNuKSAiLnB1c2hzZWN0aW9uIC50ZXN0XG4iIFwNCj4+ Pj4+PiAtICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI3doaWNoICI6ICIgaW5zbiAiXG4i ICBcDQo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIuaWZuZGVmICIjd2hp Y2giXG4iIFwNCj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI3doaWNoICI6 IFxuIiBcDQo+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICIuZW5kaWZcbiIg XA0KPj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnNuICJcbiIgIFwNCj4+ Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi5pZm5kZWYgLkwiI3doaWNoIl9l bmRcbiIgXA0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiLkwiICN3aGljaCAi X2VuZDpcbiIgIFwNCj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIi5lbmRp ZlxuIiBcDQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICIucG9wc2VjdGlvbiIN Cj4+Pj4+IA0KPj4+Pj4gTmljZSBpZGVhLCBidXQgd2h5IG11bHRpcGxlIC5pZm5kZWYsIGFuZCB3 aHkgZW1pdHRpbmcgdGhlIGluc24gZXZlbiBpZiB0aGUNCj4+Pj4+IGxhYmVscyBhcmUgYWxyZWFk eSB0aGVyZSAoYW5kIGhlbmNlIHdvbid0IGJlIGVtaXR0ZWQgYSAybmQgdGltZSk/DQo+Pj4+IA0K Pj4+PiBJIHRoaW5rIHdlIHN0aWxsIG5lZWQgdG8gZXhlY3V0ZSB0aGUgaW5zdHJ1Y3Rpb25zLCBz byB0aGV5IGNhbiBiZSBjb21wYXJlZCBhZ2FpbnN0IHRoZSBlbXVsYXRvci4NCj4+PiANCj4+PiBP ZiBjb3Vyc2UsIGJ1dCB0aGV5IGNhbm5vdCBiZSBleGVjdXRlZCB3aXRob3V0IGhhdmluZyBhIGxh YmVsLiBXZSB1c2UgdGhlDQo+Pj4gbGFiZWwgdG8gcG9pbnQgdGhlIGVtdWxhdGVkIElQIHRoZXJl LCBhbmQgdGhlbiB3ZSB1c2UgdGhlIGVuZCBsYWJlbCB0bw0KPj4+IGNoZWNrIHRoYXQgYWZ0ZXIg ZW11bGF0aW9uIHRoZSBlbXVsYXRlZCBJUCBoYXMgYWR2YW5jZWQgYXMgZXhwZWN0ZWQuDQo+PiAN Cj4+IE9oIHRoYXQgbWVhbnMgdGhhdCB3ZSB3b27igJl0IGFjdHVhbGx5IGJlIHRlc3RpbmcgYW55 dGhpbmcgdXNlZnVsIGluIGl0ZXJhdGlvbnM+PTENCj4+ICh0aGUgdGVzdCBwYXNzZXMsIGJ1dCBp dCBydW5zIHRoZSBzYW1lIHRlc3QgYXMgaXQgZGlkIG9uIGl0ZXJhdGlvbiAwKS4NCj4gDQo+IE1h eSBJIGFzayBmb3IgYSBsaXR0bGUgbGVzcyBib2xkIHN0YXRlbWVudHM/DQoNCg0KRmFpciBlbm91 Z2gsIEkgcHJvYmFibHkgc3RpbGwgZG9u4oCZdCBmdWxseSB1bmRlcnN0YW5kIGhvdyB0aGlzIHdv cmtzLCBhbmQgSSB0ZW5kIHRvIGp1bXAgdG8gY29uY2x1c2lvbnMgdG9vIHNvb24uDQoNCj4gT2Yg Y291cnNlIHRoZSAybmQgaXRlcmF0aW9uIGlzbid0DQo+IGlkZW50aWNhbCB0byB0aGUgMXN0LiBU aGUgaW5zbiBlbmNvZGluZyBpcyB0aGUgc2FtZSwgYnV0IHRoZSBvcGVyYW5kcyAodGhlIG1hc2sN Cj4gaW4gcGFydGljdWxhciwgaS5lLiB0aGUgdmFsdWUgJWszIGhvbGRzKSBhcmVuJ3QuDQo+IA0K DQoNCklmIHdl4oCZcmUgdmVyeSBjYXJlZnVsIHdpdGggaG93IHdlIHVzZSBwdXRfaW5zbigpIHRo ZW4gaXQgbWlnaHQgd29yayAoZS5nLiB3aXRoIG1vcmUgY29tbWVudHMgYXMgeW91IHN1Z2dlc3Rl ZCkuIA0KDQpJIHRoaW5rIGl0IGNvdWxkIGdvIHdyb25nIGlmIHRoZSBjb21waWxlciB3b3VsZCBl bWl0IGEgY29uc3RhbnQgdGhhdCBpcyBkaWZmZXJlbnQgaW4gZWFjaCBsb29wIGl0ZXJhdGlvbjoN CnRoZSBlbXVsYXRvciB3b3VsZCBiZSBnaXZlbiB0aGUgc2FtZSBiaW5hcnkgc2VxdWVuY2UgdG8g ZW11bGF0ZSwgYmVjYXVzZSBpdCBhbHdheXMgcmVmZXJzIHRvIHRoZSBsYWJlbCBmcm9tIHRoZSAx c3QgaXRlcmF0aW9uDQoodGhlIG9ubHkgbGFiZWwgdGhhdCBleGlzdHMgd2l0aCBteSBwYXRjaCks IGFuZCB0aGVyZWZvcmUgdGhlIHZhbHVlIGlzIHRoZSBjb25zdGFudCBpcyB0aGUgb25lIGZyb20g dGhlIGZpcnN0IGl0ZXJhdGlvbi4NCldoZXJlYXMgdGhlIGFjdHVhbCBleGVjdXRpb24gd291bGQg dXNlIHRoZSBhY3R1YWwgdmFsdWVzIG9mIHRob3NlIGNvbnN0YW50cywgd2hpY2ggYXJlIGRpZmZl cmVudCBpbiBlYWNoIGxvb3AgaXRlcmF0aW9uLg0KVGhpcyBtYXkgcmVzdWx0IGluIGEgZGV0ZWN0 YWJsZSBjaGFuZ2UgaW4gdGhlIHJlc3VsdCBiZXR3ZWVuIHRoZSBlbXVsYXRvciBhbmQgYWN0dWFs IGV4ZWN1dGlvbnMuDQpJZiBpbnN0ZWFkIG9mIGEgY29uc3RhbnQsIGl0IGVtaXRzIGEgcmVmZXJl bmNlIHRvIGEgcmVnaXN0ZXIgdGhlbiB0aGUgcHJvYmxlbSB3b3VsZG7igJl0IGV4aXN0LCBiZWNh dXNlIHRoZSByZWdpc3RlciB3b3VsZCBjb250YWluIHRoZSBjb3JyZWN0IHZhbHVlIG9uIGVhY2gg aXRlcmF0aW9uLg0KDQpJZiB3ZeKAmXJlIGNhcmVmdWwgdG8gdXNlIHRoZSBhcHByb3ByaWF0ZSBj b25zdHJhaW50cyB0aGVuIHRoZSBwcm9ibGVtIGNhbiBiZSBhdm9pZGVkIChlLmcuIEkgYXNzdW1l IGEgcmVnaXN0ZXIgY29uc3RyYWludCBtZWFucyB0aGF0IHRoZSBjb21waWxlciBtdXN0IGFsd2F5 cyBwdXQgdGhlIHZhbHVlIGludG8gYSByZWdpc3RlciBmaXJzdCBhbmQgdXNlIHRoYXQsIGV2ZW4g d2hlbiB0aGUgdmFsdWUgd291bGQgYmUgYSBjb21waWxlLXRpbWUgY29uc3RhbnQpLiBCdXQgdGhl IG1hY3JvIGl0c2VsZiBjYW7igJl0IGNvbnRyb2wgd2hhdCBjb25zdHJhaW50cyBhcmUgdXNlZC4N Cg0KQWx0aG91Z2ggaXQgbWlnaHQgd29yaywgdGhpcyBhcHByb2FjaCBpcyBxdWl0ZSBicml0dGxl LiBGb3Igbm93IEkgc2VudCBhIFYzIHdoaWNoIHVzZXMgLU8wIGZvciB0ZXN0X3g4Nl9lbXVsYXRv ci5vLCB3aGljaCBpcyBtdWNoIHNpbXBsZXIuDQotT3Mgd291bGQgd29yayB0b28sIGlmIEkgcHV0 IGl0IGludG8gdGhlIGNvcnJlY3QgcGxhY2UgKGhhcyB0byBnbyBpbnRvIEhPU1RDRkxBR1MsIG5v dCBDRkxBR1MpLCBidXQgdGhlbiB3ZSByZWx5IG9uIHRoZSBvcHRpbWlzZXIgdG8gYWx3YXlzIGNv cnJlY3RseSBlc3RpbWF0ZSB0aGUgc2l6ZSBhbmQgYXZvaWQgZHVwbGljYXRpbmcgdGhlIGFzc2Vt Ymx5IGJsb2NrLiBTaW5jZSB0aGlzIGlzbuKAmXQgcGVyZm9ybWFuY2UgY3JpdGljYWwgSSBzdWdn ZXN0IHVzaW5nIC1PMC4NCg0KSWYgYSBiZXR0ZXIgc29sdXRpb24gaXMgZm91bmQgdGhlbiB0aGlz IGNhbiBiZSByZXZpc2l0ZWQgYWdhaW4gKGUuZy4gb25lIGJhc2VkIG9uIC5pZm5kZWYgYXMgZGlz Y3Vzc2VkIGhlcmUpDQoNCg0KQmVzdCByZWdhcmRzLA0K4oCURWR3aW4NCg0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Mar 06 17:19:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 17:19:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248131.1546453 (Exim 4.92) (envelope-from ) id 1vyYpW-0000zr-Jf; Fri, 06 Mar 2026 17:19:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248131.1546453; Fri, 06 Mar 2026 17:19:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyYpW-0000zk-Gp; Fri, 06 Mar 2026 17:19:14 +0000 Received: by outflank-mailman (input) for mailman id 1248131; Fri, 06 Mar 2026 17:19:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyYpU-0000zb-Me for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 17:19:12 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 966552e6-1980-11f1-b164-2bf370ae4941; Fri, 06 Mar 2026 18:19:10 +0100 (CET) Received: from BL1PR13CA0005.namprd13.prod.outlook.com (2603:10b6:208:256::10) by MN2PR12MB4064.namprd12.prod.outlook.com (2603:10b6:208:1d3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.6; Fri, 6 Mar 2026 17:19:04 +0000 Received: from BL6PEPF0001AB71.namprd02.prod.outlook.com (2603:10b6:208:256:cafe::5) by BL1PR13CA0005.outlook.office365.com (2603:10b6:208:256::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 17:19:03 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL6PEPF0001AB71.mail.protection.outlook.com (10.167.242.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Fri, 6 Mar 2026 17:19:03 +0000 Received: from SATLEXMB04.amd.com (10.181.40.145) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.2.2562.17; Fri, 6 Mar 2026 11:19:03 -0600 Received: from satlexmb08.amd.com (10.181.42.217) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 6 Mar 2026 11:19:03 -0600 Received: from [10.71.193.38] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Fri, 6 Mar 2026 11:19:02 -0600 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 966552e6-1980-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mbsIc6QzCoX00VPpNlTIdN8ucMguHHrM2ZWAiY2Ij14i5bhAO2DEnA26fQiV9grm8Je502ct57euS/o3/a57YXBKnvGx5zPem4C5wYLKyobIrgnf0v1HzNwEBd7aOGs/Zao0zn2bHmdpyxE2ppqRw0RQhSSxJ9AQcEr4KeNT0VQ37GtFnA2fDFo4+II81qzURNHRtiUxHYs8UgE49OacQSP+c4RmpLAn6B46lrLf7n3A/IOtNZgIdN6oPb3rb8QrqKpg/VNLr+TaF7gFQJKylNlRxQobSOrNNBpEFzsatfdMgXKOMDbGqiX30pkxUDlZgeZfmn4WLM5jKerpf7llAA== 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=9qcontLYIVWajp9z5CaJED4NI+Xo+UmR+TqAT5Xge9o=; b=SID23bpqHKxM3oS7z3f9Q5UCR73+And9TGgR0S3PMM94xpprAgBAtYKcdP6mRpTX1LwL2zODb/G7UZcD8yPYFXS9p88aoJRCyN78h6g09lKVduCOtImS6tnnjevCuiHFyvqiCLFypkCwiU4YlnxMr2hJFHFuN1sPh15GHIPkUEfvAvjJCP1crRAJobffMtUPxT3An6xOiAdHZWI42Saa6AH0UMXidctl0/iKPLGi7uXuTPxQaSGtJMhuGKjyo72L58PT5ouuqKt4mV5kLXXc2ydJrXwvd3BBgNja4+ZhsyooHrY5MybI8zE9QylcP6aXf9UynbNVKN1PPsmW2R+KmA== 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=9qcontLYIVWajp9z5CaJED4NI+Xo+UmR+TqAT5Xge9o=; b=j+/9tEA34DF49Q5ebAMudLllgxtXDvSbo3LSNzj36KQeNXwYbXBi5dWrH/wsLWqqO/5zYWCL93l3OSpb6icGP5iVhw5NphWE/D7zhaQyvr4EjrzspBa5ojjp4/qsT/WeaR1kloh2rwMHF2chEolxLiHm4vb7OJVBQMBhg7YroRs= 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: Date: Fri, 6 Mar 2026 17:19:01 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS To: Julien Grall , Ayan Kumar Halder , CC: Stefano Stabellini , Bertrand Marquis , Michal Orzel , "Volodymyr Babchuk" References: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> Content-Language: en-US From: "Halder, Ayan Kumar" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: None (SATLEXMB04.amd.com: ayankuma@amd.com does not designate permitted sender hosts) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL6PEPF0001AB71:EE_|MN2PR12MB4064:EE_ X-MS-Office365-Filtering-Correlation-Id: 99a2c7ef-e761-4f29-3e88-08de7ba4773e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|36860700016|376014|30052699003|1800799024; X-Microsoft-Antispam-Message-Info: 1K3KUQYe5JRY4lH2veudExy+Fc/tBOOsd+gCd0bRU5kiP4q3PPZfl4INhpxtVRFBzPlXvybU/KYo65yyz2k4iw1V57r6Q0rss8cykdZqh0rMsJGMrDwJmHYz7m/Sc2u2tVcFBWJIRHlRwbPooodqpIkzEY+S5f1XORaAdIt0Ob5sEtI4nxYnuadefmGkzuu1er0kYo4YyTBhpEaxsYTfiqlRMdxojVZWCSPQHD3lwF1twi4C7B78QHGPO/0Ba45sz7nRDV8opsZHvxdNamv/iH3b88Uay5PQituAkcgUTD/P2dtiqMwXidLruHQq8k57gRNGeT8G4y1ET107b6Tz/S5GujQsrqoqRSrSvpCL07DneeHNYa9FRUeJAOAqBs0E9aQ6mndu9PRnuZYFE5DYdPj2d42bersEf47LbiCQc58Ol+jMltp6bpbCDbRwqPLV0LK0kd6kgKQtwlngFbigqgID+7QBoFoSxLgjWILWbbFF+KcBCDw1KrFbXHCP+Y5bPM4qDai0GbEv0nfAdzV1TpthWOzEoPOq7B3TlcpJWu+5C5iN4NbwhW9DMHMJ4/t0ZjUSIknZsq+RT73fAQDMqo5hPHGXPvN3m2s+6ki6hY4u9KHIUgM9et7/LTgb2dWjxNguWCFJOSgTPoHz6JXyNIIkbax/13Euq5KZigWCtdn2xdSwhY+kABvJIWu+llc6Wx/xDoaI4tCQ+MKEG4pVG1atGUUHE400ikUjZYDC28zMaBrVaem7CJNC3jVwc7sMFdIfVUuXGpVckrCvnRbnmg== 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)(376014)(30052699003)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gXuL6kNjZnfVFp60Jc/154Um4PYptT6xIQkrXd54QkxP71hOSLJZuhXI6G+6oNvAWJdu5SbTVVXDMfzefr1eI8DHlt2+v7JE6hf0oCXnSi9AlHy2fc3+lzV8ROKnwXDufGPligAct5nOyykvaA4NgCL/UV/Rqnane1m3ui1tqgWfAESm/fTbBY2khYY9LMWOI307PN+KZy0ZpMSRiE+ceTKglvz6l3r6b/U5LUs1Z9rBaQ/Qo05HPP/udhbAIrQtiEHvtH3+CXxw4tgjvLZhoHrXVETmclOlkF9pywMSdSRL4H58YutRBbJZNqCnNTxcCMHVs2G7jVfvEjhOpq/VL+DoeDFZFSgi/OgD8mLgICXeKHUUauswwbEcelpfJfBQAGe8CIP0IzgefVLnUydxGfRj8pQIDP//YJSWyrIFQ+lnWptoiSu0Mmgax014CrGh X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2026 17:19:03.8166 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99a2c7ef-e761-4f29-3e88-08de7ba4773e 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: BL6PEPF0001AB71.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4064 On 06/03/2026 10:40, Julien Grall wrote: > Hi Ayan, Hi Julien, > > On 06/03/2026 09:51, Halder, Ayan Kumar wrote: >> >> On 06/03/2026 09:24, Julien Grall wrote: >>> Hi Ayan, >> Hi Julien, >>> >>> On 05/03/2026 19:43, Ayan Kumar Halder wrote: >>>> Set GICV3_NR_LRS as per the number of list registers in the supported >>>> hardware. This ensures: >>>> >>>> 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list >>>> registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. >>>> This ensures that if the hardware does not support more than 4 LRs >>>> (for example), the code accessing LR 4-15 is never reached. The >>>> compiler can eliminate the unsupported cases as the switch case uses a >>>> constant conditional. >>>> >>>> 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can >>>> justify that the unsupported LRs (4-15) will never be reached as Xen >>>> will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some >>>> compiler can eliminate the code accessing LR 4-15. >>>> In this situation, using panic() is better than accessing a list >>>> register which is not present in the hardware >>>> >>>> 3. Whenever GICV3_NR_LRS is defined, the default condition and the >>>> related BUG() cannot be reached at all. >>> >>> I am not sure how this is better. You will still crash Xen is 'lr' >>> >= GICV3_NR_LRS. Can you provide some details? >>> >>> > > As part of functional safety effort, we are trying to enable system >>>> integrator to configure Xen for a specific platform with a predefind >>>> set of GICv3 list registers. So that we can minimize the chance of >>>> runtime issues and reduce the codesize that will execute. >>>> >>>> Signed-off-by: Ayan Kumar Halder >>>> Signed-off-by: Michal Orzel >>>> --- >>>>   xen/arch/arm/Kconfig  |  9 +++++++++ >>>>   xen/arch/arm/gic-v3.c | 12 ++++++++++-- >>>>   2 files changed, 19 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>>> index 2f2b501fda..6540013f97 100644 >>>> --- a/xen/arch/arm/Kconfig >>>> +++ b/xen/arch/arm/Kconfig >>>> @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH >>>>     endmenu >>>>   +config GICV3_NR_LRS >>>> +    int "Number of GICv3 Link Registers supported" if EXPERT >>>> +    depends on GICV3 >>>> +    range 0 16 >>>> +    default 0 >>>> +    help >>>> +      Controls the number of Link registers to be accessed. >>>> +      Keep it set to 0 to use a value obtained from a hardware >>>> register. >>>> + >>>>   menu "ARM errata workaround via the alternative framework" >>>>       depends on HAS_ALTERNATIVE >>>>   diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >>>> index bc07f97c16..fb2985fd52 100644 >>>> --- a/xen/arch/arm/gic-v3.c >>>> +++ b/xen/arch/arm/gic-v3.c >>>> @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); >>>>   #define GICD                   (gicv3.map_dbase) >>>>   #define GICD_RDIST_BASE        (this_cpu(rbase)) >>>>   #define GICD_RDIST_SGI_BASE    (GICD_RDIST_BASE + SZ_64K) >>>> +#define lrs                    (CONFIG_GICV3_NR_LRS ?: \ >>>> +                                gicv3_info.nr_lrs) >>> >>> We should avoid lowercase define, in particular with generic names >>> like 'lrs'. I think in this case, I would rather update >>> gicv3_info.nr_lrs: >>> >>> gicv3_info.nr_lrs = min(gv3_info.nr_lrs, CONFIG_GICV3_NR_LRS); >> >> But we want to enforce the user to set CONFIG_GICV3_NR_LRS , so that >> we don't have to rely on gicv3_info.nr_lrs. >> > The only reason to use gicv3_info.nr_lrs is for backward compatibility >> i.e. when the user forgot to set the config and as a result it used >> the default value as 0. We don't want to allow this for the safety >> use cases. > > Xen upstream has to support various use cases. One of the use-case is > Linux distributions where they want one Xen binary booting on multiple > HW. So "gicv3_info.nr_lrs" will have to stay forever. We can default to using gicv3_info.nr_lrs if the user does not set a value in GICV3_NR_LRS. This is what I am trying to do in the patch. > > Now with CONFIG_GICV3_NR_LRS in place, I am concerned that someone > will try to configure the value to let say 16 but their HW support only 4. If the user has set it to an incorrect value, then imo Xen should trust the value that user has set. And then any malfunction caused will be the responsibility of the user. IOW, we want to put the responsibility on the user to provide the correct values. >  I can't find any check at boot, so any problem will still occur at > runtime. > >> >>> >>> This would solve another problem where you don't sanity check that >>> the system effectively support CONFIG_GICV3_NR_LRS. >>> >>>> @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) >>>>   static inline void gicv3_restore_lrs(const struct vcpu *v) >>>>   { >>>>       /* Fall through for all the cases */ >>>> -    switch ( gicv3_info.nr_lrs ) >>>> +    switch ( lrs ) >>>>       { >>>>       case 16: >>>>           WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); >>>> @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const >>>> struct vcpu *v) >>>>     static uint64_t gicv3_ich_read_lr(int lr) >>>>   { >>>> +    if ( lr >= lrs ) >>>> +        panic("Unsupported number of LRs\n"); >>> >>> Do we really have to panic in production build? Wouldn't it be >>> better to return '0' and maybe use ASSERT for a crash in debug >>> build? Same below. >> You are right, we may not need this. One option I am thinking is ... >>> >>>> + >>>>       switch ( lr ) >> >> switch ( lr & (lrs - 1) ) >> >> This ensures that we do not hit the unsupported cases. > > What about implementing it as RAZ-WI? You mean  case 4: (lr >= lrs) ? 0 : READ_SYSREG_LR(4); /* read */  case 4 : (lr >= lrs) ? :  WRITE_SYSREG_LR(val, 4); /* write */ > This would make any issue more reliable/obvious (if you have multiple > index accessing the same LR, then you could end up overwriting an > existing virtual interrupt). - Ayan From xen-devel-bounces@lists.xenproject.org Fri Mar 06 17:54:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 06 Mar 2026 17:54:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248170.1546463 (Exim 4.92) (envelope-from ) id 1vyZMz-00068q-4R; Fri, 06 Mar 2026 17:53:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248170.1546463; Fri, 06 Mar 2026 17:53:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyZMz-00068j-1F; Fri, 06 Mar 2026 17:53:49 +0000 Received: by outflank-mailman (input) for mailman id 1248170; Fri, 06 Mar 2026 17:53:47 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyZMx-00068d-Me for xen-devel@lists.xenproject.org; Fri, 06 Mar 2026 17:53:47 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.96) (envelope-from ) id 1vyZMx-008MLU-0O; Fri, 06 Mar 2026 17:53:47 +0000 Received: from [2a02:8012:3a1:0:f1c8:5b15:c616:1017] by xenbits.xenproject.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vyZMw-002MPX-2r; Fri, 06 Mar 2026 17:53:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" 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=Ua5JMEz670mMuf9tiFD5YBeLAm5xqtRDgqzeO0ZYiXo=; b=bocV2BWEVTW2bfOtWFrE4Rd9JT 6/gnoZ7d0lsJ7Jbehn5cON75VNy38U7Swz1jN80+eixgw/MQtkbJvjHvPvEdnKqjXR3jz8P4vOpBM CTPgpuf+yrlDv2abXBjrlU1u+9lpUWlnm3AnB8iL6UE1kk4z6oAffCtuZfEw69Davg4Q=; Message-ID: <343c868a-61ef-4c9d-b6ab-96c35aa66de6@xen.org> Date: Fri, 6 Mar 2026 17:53:43 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] xen: gic-v3: Introduce CONFIG_GICV3_NR_LRS Content-Language: en-GB To: "Halder, Ayan Kumar" , Ayan Kumar Halder , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk References: <20260305194358.2564387-1-ayan.kumar.halder@amd.com> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ayan, On 06/03/2026 17:19, Halder, Ayan Kumar wrote: > > On 06/03/2026 10:40, Julien Grall wrote: >> Hi Ayan, > Hi Julien, >> >> On 06/03/2026 09:51, Halder, Ayan Kumar wrote: >>> >>> On 06/03/2026 09:24, Julien Grall wrote: >>>> Hi Ayan, >>> Hi Julien, >>>> >>>> On 05/03/2026 19:43, Ayan Kumar Halder wrote: >>>>> Set GICV3_NR_LRS as per the number of list registers in the supported >>>>> hardware. This ensures: >>>>> >>>>> 1. In gicv3_save_lrs()/gicv3_restore_lrs(), use the number of list >>>>> registers from GICV3_NR_LRS (if defined) instead of gicv3_info.nr_lrs. >>>>> This ensures that if the hardware does not support more than 4 LRs >>>>> (for example), the code accessing LR 4-15 is never reached. The >>>>> compiler can eliminate the unsupported cases as the switch case uses a >>>>> constant conditional. >>>>> >>>>> 2. Similarly In gicv3_ich_read_lr()/gicv3_ich_write_lr() , we can >>>>> justify that the unsupported LRs (4-15) will never be reached as Xen >>>>> will panic if the runtime value (lr) exceeds GICV3_NR_LRS. Some >>>>> compiler can eliminate the code accessing LR 4-15. >>>>> In this situation, using panic() is better than accessing a list >>>>> register which is not present in the hardware >>>>> >>>>> 3. Whenever GICV3_NR_LRS is defined, the default condition and the >>>>> related BUG() cannot be reached at all. >>>> >>>> I am not sure how this is better. You will still crash Xen is 'lr' >>>> >= GICV3_NR_LRS. Can you provide some details? >>>> >>>> > > As part of functional safety effort, we are trying to enable system >>>>> integrator to configure Xen for a specific platform with a predefind >>>>> set of GICv3 list registers. So that we can minimize the chance of >>>>> runtime issues and reduce the codesize that will execute. >>>>> >>>>> Signed-off-by: Ayan Kumar Halder >>>>> Signed-off-by: Michal Orzel >>>>> --- >>>>>   xen/arch/arm/Kconfig  |  9 +++++++++ >>>>>   xen/arch/arm/gic-v3.c | 12 ++++++++++-- >>>>>   2 files changed, 19 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig >>>>> index 2f2b501fda..6540013f97 100644 >>>>> --- a/xen/arch/arm/Kconfig >>>>> +++ b/xen/arch/arm/Kconfig >>>>> @@ -276,6 +276,15 @@ config PCI_PASSTHROUGH >>>>>     endmenu >>>>>   +config GICV3_NR_LRS >>>>> +    int "Number of GICv3 Link Registers supported" if EXPERT >>>>> +    depends on GICV3 >>>>> +    range 0 16 >>>>> +    default 0 >>>>> +    help >>>>> +      Controls the number of Link registers to be accessed. >>>>> +      Keep it set to 0 to use a value obtained from a hardware >>>>> register. >>>>> + >>>>>   menu "ARM errata workaround via the alternative framework" >>>>>       depends on HAS_ALTERNATIVE >>>>>   diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c >>>>> index bc07f97c16..fb2985fd52 100644 >>>>> --- a/xen/arch/arm/gic-v3.c >>>>> +++ b/xen/arch/arm/gic-v3.c >>>>> @@ -51,6 +51,8 @@ static DEFINE_PER_CPU(void __iomem*, rbase); >>>>>   #define GICD                   (gicv3.map_dbase) >>>>>   #define GICD_RDIST_BASE        (this_cpu(rbase)) >>>>>   #define GICD_RDIST_SGI_BASE    (GICD_RDIST_BASE + SZ_64K) >>>>> +#define lrs                    (CONFIG_GICV3_NR_LRS ?: \ >>>>> +                                gicv3_info.nr_lrs) >>>> >>>> We should avoid lowercase define, in particular with generic names >>>> like 'lrs'. I think in this case, I would rather update >>>> gicv3_info.nr_lrs: >>>> >>>> gicv3_info.nr_lrs = min(gv3_info.nr_lrs, CONFIG_GICV3_NR_LRS); >>> >>> But we want to enforce the user to set CONFIG_GICV3_NR_LRS , so that >>> we don't have to rely on gicv3_info.nr_lrs. >>> > The only reason to use gicv3_info.nr_lrs is for backward compatibility >>> i.e. when the user forgot to set the config and as a result it used >>> the default value as 0. We don't want to allow this for the safety >>> use cases. >> >> Xen upstream has to support various use cases. One of the use-case is >> Linux distributions where they want one Xen binary booting on multiple >> HW. So "gicv3_info.nr_lrs" will have to stay forever. > We can default to using gicv3_info.nr_lrs if the user does not set a > value in GICV3_NR_LRS. This is what I am trying to do in the patch. I am still missing something. Why can't we just write GICV3_NR_LRS in gicv3_info.nr_lrs? This would simplify the code and avoid unnecessary churn. >> >> Now with CONFIG_GICV3_NR_LRS in place, I am concerned that someone >> will try to configure the value to let say 16 but their HW support >> only 4. > > If the user has set it to an incorrect value, then imo Xen should trust > the value that user has set. And then any malfunction caused will be the > responsibility of the user. > > IOW, we want to put the responsibility on the user to provide the > correct values. I think this is the same things as the device-tree. We could trust the user didn't shoot itself in the foot (e.g. asking for a feature which doesn't exist). But at least for Xen on Arm, we try to be nice and tell the user that something is wrong early. I don't see why we should diverge here. This is defense in depth which would save a crash during steady state if this was missed. I am assuming that it is better to crash while your car is parked than while you are driving ;). >>>> This would solve another problem where you don't sanity check that >>>> the system effectively support CONFIG_GICV3_NR_LRS. >>>> >>>>> @@ -121,7 +123,7 @@ static inline void gicv3_save_lrs(struct vcpu *v) >>>>>   static inline void gicv3_restore_lrs(const struct vcpu *v) >>>>>   { >>>>>       /* Fall through for all the cases */ >>>>> -    switch ( gicv3_info.nr_lrs ) >>>>> +    switch ( lrs ) >>>>>       { >>>>>       case 16: >>>>>           WRITE_SYSREG_LR(v->arch.gic.v3.lr[15], 15); >>>>> @@ -178,6 +180,9 @@ static inline void gicv3_restore_lrs(const >>>>> struct vcpu *v) >>>>>     static uint64_t gicv3_ich_read_lr(int lr) >>>>>   { >>>>> +    if ( lr >= lrs ) >>>>> +        panic("Unsupported number of LRs\n"); >>>> >>>> Do we really have to panic in production build? Wouldn't it be >>>> better to return '0' and maybe use ASSERT for a crash in debug >>>> build? Same below. >>> You are right, we may not need this. One option I am thinking is ... >>>> >>>>> + >>>>>       switch ( lr ) >>> >>> switch ( lr & (lrs - 1) ) >>> >>> This ensures that we do not hit the unsupported cases. >> >> What about implementing it as RAZ-WI? > > You mean > >  case 4: (lr >= lrs) ? 0 : READ_SYSREG_LR(4); /* read */ > >  case 4 : (lr >= lrs) ? :  WRITE_SYSREG_LR(val, 4); /* write */ I was thinking to do the check before the 'switch' as i don't think it needs to be duplicated per 'case'. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Sat Mar 07 02:55:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Mar 2026 02:55:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248393.1546484 (Exim 4.92) (envelope-from ) id 1vyhpD-0002eL-Kt; Sat, 07 Mar 2026 02:55:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248393.1546484; Sat, 07 Mar 2026 02:55:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyhpD-0002eD-Fn; Sat, 07 Mar 2026 02:55:31 +0000 Received: by outflank-mailman (input) for mailman id 1248393; Sat, 07 Mar 2026 02:55:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyhpA-0002e7-W3 for xen-devel@lists.xenproject.org; Sat, 07 Mar 2026 02:55:30 +0000 Received: from mx0b-00498f03.pphosted.com (mx0b-00498f03.pphosted.com [148.163.143.241]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1302d7e0-19d1-11f1-9ccf-f158ae23cfc8; Sat, 07 Mar 2026 03:55:19 +0100 (CET) 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 626K3NYc1670247 for ; Fri, 6 Mar 2026 18:55:17 -0800 Received: from ph0pr06cu001.outbound.protection.outlook.com (mail-westus3azon11011036.outbound.protection.outlook.com [40.107.208.36]) by m0482515.ppops.net (PPS) with ESMTPS id 4cr0xundqf-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Fri, 06 Mar 2026 18:55:17 -0800 (PST) Received: from DS7PR03CA0221.namprd03.prod.outlook.com (2603:10b6:5:3ba::16) by CO6PR16MB4258.namprd16.prod.outlook.com (2603:10b6:303:ac::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Sat, 7 Mar 2026 02:55:14 +0000 Received: from CH3PEPF00000018.namprd21.prod.outlook.com (2603:10b6:5:3ba:cafe::7c) by DS7PR03CA0221.outlook.office365.com (2603:10b6:5:3ba::16) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.19 via Frontend Transport; Sat, 7 Mar 2026 02:55:13 +0000 Received: from mx0b-00498f04.pphosted.com (148.163.138.245) by CH3PEPF00000018.mail.protection.outlook.com (10.167.244.123) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9700.0 via Frontend Transport; Sat, 7 Mar 2026 02:55: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 626MvtNs3430266 for ; Fri, 6 Mar 2026 21:55:12 -0500 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 4cqucss2r5-3 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 06 Mar 2026 21:55:12 -0500 (EST) Received: from localhost ([19.12.92.222]) by cmsmtp with ESMTPSA id yhosv7PVAV4jQyhotv3fSK; Sat, 07 Mar 2026 02:55:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1302d7e0-19d1-11f1-9ccf-f158ae23cfc8 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=gf/yYKG8HDzbk3g9D429cY3fp LWeKIBrGrZW8+ZjyEU=; b=odcXM5zFiiwACXwXH12prETVwgk6hysCC85MIGuBe 5UMdkaTZlBrO0oN8nuISaCNBXsJAXq5iscX+9XjTB06AEN4Z+y7ZXZPv0AUWAo44 xzgRO+iZrPQgLXFw9i4oxiS+ZQslJGC+JcdYJ/axdk2IGi7aLWt0j/kyzKqbWpm9 fV0bfmE8qmSE8EfNkiJs2g5ktHalC6EY1cHFRZ+LD5ZxB134Mu66BHds4Y3boh+9 28ECcKUTfL1ZyUBK3E/0MBUT1E4dM4CLZcGZ98K+DomMm/8u1LEhOOjjEzm8qC9A K//pKm+Y8cEuVC9v9WqZTUZhBvk16BZwZR35QKaQ6kgfA== ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SVAg9+k+N/e8gWrUp44ZnfhOxWdqts4jww+W5VWmiAu/4M86rvsrUQ8rK9r8notiOu31hQ/pDbUzeH72OavGkAIK+s2VhlpfRGh8pDVXxNUIFMy86z1xAxzX9ee+PACxU7NNTIXeAalJf2Vx6dPhGMRaFX46asOMZNKLGIpH96PkKx1njXOSF6UOyNGiK4U2fs2bRUxmYxBoSc6qOGlaxxQC8rbO/ZlGa+DjK4Lyx+ARnVEAPGbFsYyOeWcMBED30iuwaIq6tHH3A0ocICyKXZ6szoVhdYb0qaM7C4wepqppLGY9vQQbc5i5QBRKmUFMlSnHCuKDVW0O0kZdytQN5Q== 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=gf/yYKG8HDzbk3g9D429cY3fpLWeKIBrGrZW8+ZjyEU=; b=k3YPTOj1Olp1Pbr32Olcy1oURJaUQ7MlkxnNgbcNrObEfzjsIu2vUtDfFwTlZBZZTyAZIzUQLqj80Pr+Oy/uagrotdP4JXz8/qrdGWXN8xwIlUgWgEl3up7bqVVenFLDPjfkpR6vyOiSGYhxmoXWHJOgnQ/MKdUE4XcG4LFLsyW+wwoZ1Tz6B3HJAczOXawtiq3Kudh3wPZjb1nlXTRQmNRWjdA/Aaph+MRBsguqq2xWbUiX4N5BAxkS0eqTn785FF09mA/B0WBXw15UHgmZk1BOucOnne+glfpxb06KWhDdemsam7OrBAgH3BjEk1upB9ATkYOYf/a2BBIF6qFvWg== 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=gf/yYKG8HDzbk3g9D429cY3fpLWeKIBrGrZW8+ZjyEU=; b=M42B0z9lepaRgYsLToZUyrCSeHWPdAOf+R4FzBGRUoVly0asZxOSe0rJG/c3yNfle1kmmZmxHkZVYw6sCI3i6BtP3AHAzd4akpTEJNw++Gm7tJt5Qq3BCyCsCiyn+l5kb40worHi74dmwXEoUHLc00Vt743h/I2G+vJCsrnqUXw= 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=gf/yYKG 8HDzbk3g9D429cY3fpLWeKIBrGrZW8+ZjyEU=; b=Ob+vZZq642g95iKJklfTj4K prRtP6JWZq/3hi9VlZbUheIeTznuTZ89IZ90L40DB+M62ulMHLOSyyEQtNrE2Lrq Nk/2Q6aBREv8GMj2szUcv8mWXWvYggW+xh9Wzd/zZT+aPK6QA/1doU/2sfrGci5y FzJDfvNiv6BqTHpAwQNZ/up7q3KEOFA27XRQ3q8R/85yTnAOkKcwwwPkb9dDCkQb CqiA3+7peVDWqVxQH24v+d8cOz2pFUqTRsePAX7X2T3eFbxkihGASCUnZ5sxnbp4 u93/7gwbyoGF5BheCGsdCbaTYenx7eWiIfKumAEY57uIp0I5/lI+/KZecjnvCpw= = 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=gf/yYKG8HDzbk3g9D429cY3fpLWeKIB rGrZW8+ZjyEU=; b=lNM82muanUQSi7Y1JhaLDuZkhl5N48nnptEh0Xl0kY1WFG3 LGIfCBWQ0qvnKoygvjpJKqKGeTp6ImJ7cGjtH1Hs9Uxtd3THttnh/gFVizMI0SRQ JrdcQEdPtubrfs6ekTShWO+jRFcmr7sSCtmtdxB30BWSz/tzJgeFiRmte6AT/xnz N5qPr9GHRsg6+A19z7I8lSKv0yTBMBLBu7FtjTw322Pl/sPw2LFjbntL0f0pHga+ VIXDkHW3fjkbn0Yj3pt+NtnLxSK7EndlFdCdVli6f/guLEQKML4b8yOZ7z8To+so tbR8lBfd3Sn9LUSAU+QzKlfKbiI+JQ/fxLBfCvg== X-Mailer: SER-76bead168636dc6ed1c9e51ce4dea80dbdd4163750742b614a4d871e565792b7 X-Cloudmark-MID: yhosv7PVAV4jQyhotv3fSK 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.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: [PATCH v6] xen/domain: introduce DOMID_ANY Date: Fri, 6 Mar 2026 18:54:52 -0800 Message-ID: <20260307025451.3148078-2-dmukhin@ford.com> X-Mailer: git-send-email 2.53.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.51,FMLib:17.12.100.49 definitions=2026-03-07_01,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 malwarescore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603070025 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH3PEPF00000018:EE_|CO6PR16MB4258:EE_ Content-Type: text/plain X-MS-Office365-Filtering-Correlation-Id: 2185a8ed-e103-434a-dc15-08de7bf4f418 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|376014|1800799024|13003099007; X-Microsoft-Antispam-Message-Info: m9nQSxcU9hoNf2TUWRWsG42EQuip0cX13uJak6eFhJQkaeiO6bx+Th3ZW2BnU3hyJ1bLRNv1ls9DP1ai7vwdhtgonACRu6eBikoJpDRPAL59MYtm6/2UQzY6wZ5b44Gn5DMD/RFE4mi2SAP9Y/C2COJ1efidDMfcmI/3jJXkUYJRkYSShq6tf6n9UDFcR7juOcIBg+bQncynBaSCThtymHiyL5GtSw6ITesc+y0V+svqnfbd0QPg5mtRvlIdla5uLJ+JF1SblJwGQGbVeNq9+eXNUtT+azHnp2jTax15CqYHPtewkjG2Btc/xWyfaplBW5Zj/E070tE9vrxT1zs+YMVYNGzCB6LIke8R2EE+HrrU/EQJUYYVj3At6mrqG+iCeu1OwIKhqrYwf4ArzECdSJtZq+KZepqsJ4G1Hmo82UjCgHR8v9HKsay9w/6wQFCWdbChbA85w0cTorjWUcEbUT8uKW4AEXBKL4aOqfrJhkZ8BpUhVVRn3qupwRCRbXZPHDQ8xJWiQ8lJpglAWUtZSdySAQckbHd2HZQHtE4/KOypCYIA/Bm9mQwv9Zfo67dk/1sPOt3lgoA2vU/zVcqa58QCxPqv3l5/BsbPuCPhDUN4ZiZ597gQ69RG1S/nZdN2nMq66DKcbEarNDNATwVGwYyiLNas63yh/QjeEV8fkAWYwriITKdZrjpJDYOKejgNX2fV9V/vVhuc+2cWf4vtc9yE9NIUEmY6IsLDTBF83dYPvEKf35O0ACKjIB+bjWxon1FhtV3GqBDYiWySEbkWmQ== 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)(36860700016)(82310400026)(376014)(1800799024)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: zHoKZXZPXarKSk6Y5Iqr8aia8jWASdtzS+3Z2K9/qUuQohPt4pO5HWd8MJRN8p6O2HQw5gz9iYmCG2llxk2Iwb0Fk309zrqjsdeAXU3N5LQ1d2cjIVdLonBBDVEAf2TcRMo9ABxTgVkMVEAOGsHEfgIq2PpkSbh8o94oPCOkL6f8c/e2zyrN0AvaMhxOrABBl3y1yjQqc/g1mHqckGw9TZmiG25rlRwNAnAFQKK3CsczR+6C+ifGA741682OP5iGU84bf+aAHE7YXZP+TX1Bvl8yQama2l7DQZJzISERdCgq0I63th0C/BHY/vQqbStupVH0FbZ8kMrnM2bkjQRJm4516dy11PSwdnCYNDxzD01/nZWLtASB2QO49j9+xeaROREfgzZeBABHEeMZxrOnzvGZz0rOx+R1/J7+tE8in8Y3DorVle9xWs807BZr9x9d X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: HbqQqg8cTnHh49gnijR9Gh5n28gxpwBXbyC9aeecCEREaNfSk41G+XPjO6EUvvURm/jrQGRIkJ3gKNma3wUdBe6FL+OEa5jJkyEu5V7xGAYyolNTRISP8IzJKiQ2cEzAf2ptbTfm2nL0fBaO7kBwN+tn4nJ1fp6XbOiUG42n/DZQbcdKvtZLuUNHAiJSIHKqDzt2sJg/RaBPZpCD1C7I3DLrZSqBMsE3XFNyly0ZP97kNuQfUEPCuIyvs0JDW5D4nORUp+gBZJHnvCai7uzVfjSMzQNKTwB7LafOjJR9cvjIx8JU/qCWbVe4ui3iUCIzSyLUhAif32MINksDa5xhGgbLDWAOtFx9rupx8/twlcB1fvl3x9npKt25ppAvHHqe/la9kt5EPQhGq+MyZfcdis9RTk+V6/zJW1JGpb2gzlfgW8H1kV2URaeU9oWLNJxSqapQyajB/NW9qyvWFBDDQmEvnldDXrCVJkqE8IXpZNmj5XeAHeq3cseV/NK5JAgLLlg4Zzq7Yo/fV9Js/4b5rd46N/fqacxNyvDdvJRV7po0YOzZADE4nTecPi8hzUKVp9Aj+xNb5OKFaEDF0hQ/kty05kWbKUyBj/eIixcpvBl+kI+QN7p4j4mFdhWZQJjz X-OriginatorOrg: ford.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Mar 2026 02:55:12.9244 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2185a8ed-e103-434a-dc15-08de7bf4f418 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: CH3PEPF00000018.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR16MB4258 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA3MDAyNSBTYWx0ZWRfX3cOFhJB9wS4K s2RtWCgKjnoTeUVYyKgSi0wO/ufmSYqtnXHRxlx90g5XZTi2ApOgfrGHBTA3+g+jOe0c5nal3Mw 4Kw1BxKVVwSRGZ9czpapkeS++1edzyGbnUkoNBS8ltJeZCXFviYLXcrP2FpKVMcjKriHXOk6NOK VWXTQOr3SoRMjXKMIWYj4Jbc+8aO1jsaWS5fQ4P/1Kl/tAmDFm+QnioCGRyyiBYiSt4RaM7Wrr8 GGAT+gnnVeOqm0Jt+NsWjgVj0HdImcHbdK2t+yM4lW5ox21mX+XO2b+C1pXhijahweh0tMYxp/w 3+PPuFtRJAUpckHifvgKmuQATbIcmI9P4zXd1AE66kULVRicyJ6nHetrv8wVz/xhJ6hMDyNrVzL /RO3+v7mY0hduHbPQyM7oJYcOMmOkfDiACZGQUVd7qEfW9z/76CpGSuv1Z0aUnUfpakJnSb4lBu C9UnpQk6dqe3QB9gfUA== X-Proofpoint-ORIG-GUID: 2DXbRu_iQEBCbSm27YYvksPWBzzxElFg X-Proofpoint-GUID: 2DXbRu_iQEBCbSm27YYvksPWBzzxElFg X-Authority-Analysis: v=2.4 cv=OdWVzxTY c=1 sm=1 tr=0 ts=69ab9395 cx=c_pps a=uJxR2RjB/d5PFa0hjvWx4w==:117 a=b7IhknPlfT0FN1EembXvig==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=Yq5XynenixoA:10 a=3PXLN80vpJUA:10 a=6NUGLSImWEsA:10 a=w9pew1qAHqMA:10 a=VkNPw1HP01LnGYTKEx00:22 a=P_n1zlmtWsCQbjROFjcg:22 a=0GA0A_IKJoUHBEAzNTkD:22 a=p0WdMEafAAAA:8 a=cbNQJ9GKAAAA:8 a=Scr0WcHX4gzoYZdgL5MA:9 a=G69WFyCBNqGPyalROSdv:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-07_01,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603070025 Add a new symbol DOMID_ANY to improve the readability of the code. Update all relevant domid_alloc() call sites and harden the domid_alloc() input value check. Also, fix problem with passing invalid domain IDs in XEN_DOMCTL_createdomain: turns out libxl__domain_make() (toolstack) uses 0xffff as domain ID. Amends: 2d5065060710 ("xen/domain: unify domain ID allocation") Signed-off-by: Denis Mukhin --- Changes since v5: - fixed domain ID validity check in libxl__domain_make() - CI run: https://gitlab.com/xen-project/people/dmukhin/xen/-/pipelines/2368290952 --- tools/libs/light/libxl_create.c | 6 ++++-- tools/tests/domid/harness.h | 1 + tools/tests/domid/test-domid.c | 12 ++++++------ xen/common/device-tree/dom0less-build.c | 2 +- xen/common/domctl.c | 3 +-- xen/common/domid.c | 5 ++++- xen/include/public/xen.h | 7 +++++++ 7 files changed, 24 insertions(+), 12 deletions(-) diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c index bfc9149096a3..79af2958d170 100644 --- a/tools/libs/light/libxl_create.c +++ b/tools/libs/light/libxl_create.c @@ -666,7 +666,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, } for (;;) { - uint32_t local_domid; + uint32_t local_domid = DOMID_INVALID; bool recent; if (info->domid == RANDOM_DOMID) { @@ -681,8 +681,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, continue; local_domid = v; + } else if (libxl_domid_valid_guest(local_domid)) { + local_domid = info->domid; } else { - local_domid = info->domid; /* May not be valid */ + local_domid = DOMID_ANY; } ret = xc_domain_create(ctx->xch, &local_domid, &create); diff --git a/tools/tests/domid/harness.h b/tools/tests/domid/harness.h index 17eb22a9a854..65da0d075a2b 100644 --- a/tools/tests/domid/harness.h +++ b/tools/tests/domid/harness.h @@ -41,6 +41,7 @@ extern unsigned long find_next_zero_bit(const unsigned long *addr, #define DOMID_FIRST_RESERVED (100) #define DOMID_INVALID (101) +#define DOMID_ANY (102) #endif /* _TEST_HARNESS_ */ diff --git a/tools/tests/domid/test-domid.c b/tools/tests/domid/test-domid.c index 5915c4699a5c..71cc4e7fd86d 100644 --- a/tools/tests/domid/test-domid.c +++ b/tools/tests/domid/test-domid.c @@ -41,20 +41,20 @@ int main(int argc, char **argv) domid_free(expected); /* - * Test that that two consecutive calls of domid_alloc(DOMID_INVALID) + * Test that that two consecutive calls of domid_alloc(DOMID_ANY) * will never return the same ID. * NB: ID#0 is reserved and shall not be allocated by - * domid_alloc(DOMID_INVALID). + * domid_alloc(DOMID_ANY). */ for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 3: expected %u allocated %u\n", expected, allocated); } for ( expected = 1; expected < DOMID_FIRST_RESERVED; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == DOMID_INVALID, "TEST 4: expected %u allocated %u\n", DOMID_INVALID, allocated); } @@ -64,7 +64,7 @@ int main(int argc, char **argv) domid_free(expected); for ( expected = 1; expected < DOMID_FIRST_RESERVED / 2; expected++ ) { - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 5: expected %u allocated %u\n", expected, allocated); } @@ -72,7 +72,7 @@ int main(int argc, char **argv) /* Re-allocate last ID from [1..DOMID_FIRST_RESERVED - 1]. */ expected = DOMID_FIRST_RESERVED - 1; domid_free(DOMID_FIRST_RESERVED - 1); - allocated = domid_alloc(DOMID_INVALID); + allocated = domid_alloc(DOMID_ANY); verify(allocated == expected, "TEST 6: expected %u allocated %u\n", expected, allocated); diff --git a/xen/common/device-tree/dom0less-build.c b/xen/common/device-tree/dom0less-build.c index 840d14419da2..3c18dae5e625 100644 --- a/xen/common/device-tree/dom0less-build.c +++ b/xen/common/device-tree/dom0less-build.c @@ -852,7 +852,7 @@ void __init create_domUs(void) if ( (max_init_domid + 1) >= DOMID_FIRST_RESERVED ) panic("No more domain IDs available\n"); - domid = domid_alloc(DOMID_INVALID); + domid = domid_alloc(DOMID_ANY); if ( domid == DOMID_INVALID ) panic("Error allocating ID for domain %s\n", dt_node_name(node)); diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 93738931c575..b969f5ada6cc 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -409,8 +409,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) case XEN_DOMCTL_createdomain: { - /* NB: ID#0 is reserved, find the first suitable ID instead. */ - domid_t domid = domid_alloc(op->domain ?: DOMID_INVALID); + domid_t domid = domid_alloc(op->domain); if ( domid == DOMID_INVALID ) { diff --git a/xen/common/domid.c b/xen/common/domid.c index 2387ddb08300..b0258e477c1a 100644 --- a/xen/common/domid.c +++ b/xen/common/domid.c @@ -19,7 +19,7 @@ static DECLARE_BITMAP(domid_bitmap, DOMID_FIRST_RESERVED); * @param domid Domain ID hint: * - If an explicit domain ID is provided, verify its availability and use it * if ID is not used; - * - If DOMID_INVALID is provided, search [1..DOMID_FIRST_RESERVED-1] range, + * - If DOMID_ANY is provided, search [1..DOMID_FIRST_RESERVED-1] range, * starting from the last used ID. Implementation guarantees that two * consecutive calls will never return the same ID. ID#0 is reserved for * the first boot domain (currently, dom0) and excluded from the allocation @@ -31,6 +31,9 @@ domid_t domid_alloc(domid_t domid) { static domid_t domid_last; + if ( domid >= DOMID_FIRST_RESERVED && domid != DOMID_ANY ) + return DOMID_INVALID; + spin_lock(&domid_lock); /* Exact match. */ diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h index b12fd10e6315..f35a6f21f063 100644 --- a/xen/include/public/xen.h +++ b/xen/include/public/xen.h @@ -608,6 +608,13 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t); /* DOMID_INVALID is used to identify pages with unknown owner. */ #define DOMID_INVALID xen_mk_uint(0x7FF4) +/* + * DOMID_ANY is used to signal no specific domain ID requested. + * Handler should pick a valid ID, or handle it as a broadcast value + * depending on the context. + */ +#define DOMID_ANY xen_mk_uint(0x7FF5) + /* Idle domain. */ #define DOMID_IDLE xen_mk_uint(0x7FFF) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Sat Mar 07 10:07:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Mar 2026 10:07:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248498.1546493 (Exim 4.92) (envelope-from ) id 1vyoYa-000274-EX; Sat, 07 Mar 2026 10:06:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248498.1546493; Sat, 07 Mar 2026 10:06:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyoYa-00026w-B0; Sat, 07 Mar 2026 10:06:48 +0000 Received: by outflank-mailman (input) for mailman id 1248498; Sat, 07 Mar 2026 10:06:46 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyoYY-00026q-67 for xen-devel@lists.xenproject.org; Sat, 07 Mar 2026 10:06:46 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 57c5fc18-1a0d-11f1-9ccf-f158ae23cfc8; Sat, 07 Mar 2026 11:06:43 +0100 (CET) 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 05A9D5BD36; Sat, 7 Mar 2026 10:06:43 +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 D0DE53EA61; Sat, 7 Mar 2026 10:06:42 +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 UHFnMbL4q2niYAAAD6G6ig (envelope-from ); Sat, 07 Mar 2026 10:06:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 57c5fc18-1a0d-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772878003; 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=ktH4T/n4AWGaIdpsZn8pz8mhhflSm2yIca4kR/9/PoA=; b=rN2jx0JKkPIfpT0Rjv6hg1ZY0HATxO/l4WAz0hnUtdXWoXlRu/vH7rIFm/OMLeFw6lJrw2 zOFTuu/nyrRS5LhwViM8lRf2aiRdr0G6lsjoidGdjOrWd5rXjYEV79cDCwn6eec+wDSgXl PcPtj3uu4Wr0JjiWVbd6DeBVtr36LG4= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1772878003; 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=ktH4T/n4AWGaIdpsZn8pz8mhhflSm2yIca4kR/9/PoA=; b=rN2jx0JKkPIfpT0Rjv6hg1ZY0HATxO/l4WAz0hnUtdXWoXlRu/vH7rIFm/OMLeFw6lJrw2 zOFTuu/nyrRS5LhwViM8lRf2aiRdr0G6lsjoidGdjOrWd5rXjYEV79cDCwn6eec+wDSgXl PcPtj3uu4Wr0JjiWVbd6DeBVtr36LG4= From: Juergen Gross 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.0-rc3 Date: Sat, 7 Mar 2026 11:06:42 +0100 Message-ID: <20260307100642.2365128-1-jgross@suse.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.80 / 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.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FUZZY_RATELIMITED(0.00)[rspamd.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -2.80 X-Spam-Level: Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.0-rc3-tag xen: branch for v7.0-rc3 It contains the following changes: - a cleanup of arch/x86/kernel/head_64.S removing the pre-built page tables for Xen guests - a small comment update - another cleanup for Xen PVH guests mode - a 2-patch series fixing an issue with Xen PV-devices backed by driver domains Thanks. Juergen arch/x86/include/asm/pgtable_64.h | 2 -- arch/x86/kernel/head_64.S | 28 -------------------- arch/x86/platform/pvh/enlighten.c | 7 +---- arch/x86/xen/enlighten_pv.c | 2 +- arch/x86/xen/mmu_pv.c | 9 +++++++ drivers/net/xen-netfront.c | 34 ++++++++++++------------ drivers/pci/xen-pcifront.c | 8 +++--- drivers/scsi/xen-scsifront.c | 2 +- drivers/xen/xen-acpi-processor.c | 7 ++--- drivers/xen/xen-pciback/xenbus.c | 10 +++---- drivers/xen/xenbus/xenbus_client.c | 17 +++++++++--- drivers/xen/xenbus/xenbus_probe.c | 42 +++++++++++++++++++++++++++--- drivers/xen/xenbus/xenbus_probe_frontend.c | 2 +- include/xen/xenbus.h | 4 ++- 14 files changed, 97 insertions(+), 77 deletions(-) David Thomson (1): xen/acpi-processor: fix _CST detection using undersized evaluation buffer Hou Wenlong (2): x86/xen: Build identity mapping page tables dynamically for XENPV x86/PVH: Use boot params to pass RSDP address in start_info page Juergen Gross (2): xenbus: add xenbus_device parameter to xenbus_read_driver_state() xen/xenbus: better handle backend crash kexinsun (1): x86/xen: update outdated comment From xen-devel-bounces@lists.xenproject.org Sat Mar 07 20:01:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 07 Mar 2026 20:01:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248727.1546502 (Exim 4.92) (envelope-from ) id 1vyxpO-0002aD-Ls; Sat, 07 Mar 2026 20:00:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248727.1546502; Sat, 07 Mar 2026 20: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 ) id 1vyxpO-0002a5-H8; Sat, 07 Mar 2026 20:00:46 +0000 Received: by outflank-mailman (input) for mailman id 1248727; Sat, 07 Mar 2026 20:00:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vyxpN-0002Zz-0R for xen-devel@lists.xenproject.org; Sat, 07 Mar 2026 20:00:45 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 51e9a76d-1a60-11f1-9ccf-f158ae23cfc8; Sat, 07 Mar 2026 21:00:42 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 1D651600CB; Sat, 7 Mar 2026 20:00:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E848C19422; Sat, 7 Mar 2026 20:00:40 +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 429923808200; Sat, 7 Mar 2026 20:00:40 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 51e9a76d-1a60-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772913640; bh=3/whIQliEvBwqRoCU0LWrFeX/CEFqPM6G0VHiZFN/JM=; h=Subject:From:In-Reply-To:References:Date:To:Cc:From; b=UERpAbPFGb+G9G3LcClN/bxhKdbnqdAHFgh4gHufD7jDsEorUV8iuVdnKqPpDzEej Alw8qlC24zJ4Da75Y4bN2r005NE0jHWSu+dkGGI5NaSO8C94pxtMMBkKiusE4kyUoL MUX/ukENeSMNjp7kmVwY+hYBVn1iDx3zAjkOvttFAWJFf6qjLjwhoguG7kjPfxJ2Ku u5838wDs7XsH6+g2RJPzvAyvwChe42d4rdmDeZ5VUfQnXoBkxWoBqBGsV//4c3yDFq HARPWovwAmeR86akLIdPsuYuxjkgmcIaSqKJGPg4FzIq4h2QhF2pAa3ylHrZdpiOJL 5yt8sQzMO01vg== Subject: Re: [GIT PULL] xen: branch for v7.0-rc3 From: pr-tracker-bot@kernel.org In-Reply-To: <20260307100642.2365128-1-jgross@suse.com> References: <20260307100642.2365128-1-jgross@suse.com> X-PR-Tracked-List-Id: X-PR-Tracked-Message-Id: <20260307100642.2365128-1-jgross@suse.com> X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.0-rc3-tag X-PR-Tracked-Commit-Id: e2dcf9065536ab4a1b00828ff0d19f7d282dfecc X-PR-Merge-Tree: torvalds/linux.git X-PR-Merge-Refname: refs/heads/master X-PR-Merge-Commit-Id: 0f912c8917e810a4aa81d122a8e7d0a918505ab9 Message-Id: <177291363909.308260.5169901742133218857.pr-tracker-bot@kernel.org> Date: Sat, 07 Mar 2026 20:00:39 +0000 To: Juergen Gross Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, sstabellini@kernel.org The pull request you sent on Sat, 7 Mar 2026 11:06:42 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-7.0-rc3-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0f912c8917e810a4aa81d122a8e7d0a918505ab9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html From xen-devel-bounces@lists.xenproject.org Sun Mar 08 18:30:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 18:30:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248954.1546511 (Exim 4.92) (envelope-from ) id 1vzItL-0002o7-Ie; Sun, 08 Mar 2026 18:30:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248954.1546511; Sun, 08 Mar 2026 18:30:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzItL-0002ny-Dp; Sun, 08 Mar 2026 18:30:15 +0000 Received: by outflank-mailman (input) for mailman id 1248954; Sun, 08 Mar 2026 18:30:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzItJ-0002ns-TW for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 18:30:14 +0000 Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d5ec386c-1b1c-11f1-9ccf-f158ae23cfc8; Sun, 08 Mar 2026 19:30:10 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 31C44140019B; Sun, 8 Mar 2026 14:30:08 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sun, 08 Mar 2026 14:30:08 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 8 Mar 2026 14:30:06 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d5ec386c-1b1c-11f1-9ccf-f158ae23cfc8 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=fm1; t=1772994608; x=1773081008; bh=xdv9Dh7Jkliv5J+kXtIXlzuyxu1hU7sy77WHsvucif4=; b= UnWtiZeoD9cDAjt8LtKOXJOwW8zjr/bogpUQLNel/XlB+r6Cw2dL7uZ6zEVa07t4 OEtiGiEqO9xbD5BfoWnWZkhK4HeX+hIB6lKB7XKPpeBhTOupTK/Pkm5CNzxiBhoy vKLvgarnQThdminbLHU4M9PKfOP07pZihrckqM003pxL7rlXvkbteA3EmubPD423 RQk91KUxd9hCaOoucCKg+rLEPkj53hPei9pKs2j2N8g6OB/pxIlxaU/vW9p1mCdB 1Po3ft4HKJ97vF4ywvBwHXmkpinOFFPSSF/jTUkhPW+YMsoNTJZLGhzUzlmHQShk sJN4a1ScJkQGumtiq04E9g== 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=fm1; t= 1772994608; x=1773081008; bh=xdv9Dh7Jkliv5J+kXtIXlzuyxu1hU7sy77W Hsvucif4=; b=u+tAy0AVUmX4aNRIOP5IENeOoGZh8GG23g5QR+OjLOHMYSI3pF8 imWOpt65G6yh4Yot8V2eCtsGVwwXiiZx7aDrxX1xE6ntZxHRfz7flwPJKEQyMR6k 78ao3M8Jcp7uPyJhgl6gjxp9CR0bSdwjBMwDcZow4SuoRfTffiUwmSG0dWM5AuGM vH3YMCHDdp4u0Thg6q1jk5dG4MSRZF4Ycdx2YgOGEhBdt6qE/+R6yfdanVOJhP5c wPJ+DYZFbSyx5B/hkI2S+FlKzBjlvfkeQrUlFbx40DPGh+hQ3Zp1qv1gV1coCf22 Z6QZDiEqqwjV/e9P3EaMJK+VQ3NdG+q2uWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeehleduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhephffffffg fedvheejvddtgefhgeffgefhjeevjeekiedvfedtgeelleduueeugedunecuffhomhgrih hnpegvfhhirdhithenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtoh hmpdhnsggprhgtphhtthhopeejpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehs ohhumhihrghjhihothhishgrrhhkrghrvdefsehgmhgrihhlrdgtohhmpdhrtghpthhtoh epgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghp thhtohepshgrrhhkrghrshhouhhmhigrjhihohhtihdvfeesghhmrghilhdrtghomhdprh gtphhtthhopehjsggvuhhlihgthhesshhushgvrdgtohhmpdhrtghpthhtohepughpshhm ihhthhesrghpvghrthhushhsohhluhhtihhonhhsrdgtohhmpdhrtghpthhtoheprhhogh gvrhdrphgruhestghithhrihigrdgtohhmpdhrtghpthhtoheprghnughrvgifrdgtohho phgvrhefsegtihhtrhhigidrtghomh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 8 Mar 2026 19:30:01 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot Message-ID: References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hk58erJFVw0zWvNQ" Content-Disposition: inline In-Reply-To: <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> --hk58erJFVw0zWvNQ Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Mar 2026 19:30:01 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot On Fri, Mar 06, 2026 at 12:48:08AM +0530, Soumyajyotii Ssarkar wrote: > The ACPI BGRT (Boot Graphics Resource Table) contains a pointer to a > boot logo image stored in BootServicesData memory. When Xen reclaims > this memory during boot, the image is lost and the BGRT table becomes > invalid, causing Linux dom0 to report ACPI checksum errors. >=20 > Add preservation logic similar to ESRT table handling: > - Locate BGRT table via XSDT during EFI boot services phase > - Validate BMP image signature and size (max 16 MB) > - Copy image to EfiACPIReclaimMemory (safe from reclamation) > - Update BGRT table with new image address > - Recalculate ACPI table checksum >=20 > The preservation runs automatically during efi_exit_boot() before > Boot Services are terminated. This ensures the image remains > accessible to dom0. >=20 > Open coded ACPI parsing is used because Xen's ACPI subsystem is not > available during the EFI boot phase. The RSDP is obtained from the > EFI System Table, and the XSDT is walked manually to find BGRT. Thanks, this overall looks good, and it works :) See few remarks below. > Signed-off-by: Soumyajyotii Ssarkar > --- > xen/arch/x86/efi/efi-boot.h | 2 + > xen/common/efi/boot.c | 187 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 189 insertions(+) >=20 > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 42a2c46b5e..27792a56ff 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > @@ -910,6 +910,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, >=20 > efi_relocate_esrt(SystemTable); >=20 > + efi_preserve_bgrt_img(SystemTable); > + This covers only multiboot path, but not xen.efi. It needs adding also in efi_start(). > efi_exit_boot(ImageHandle, SystemTable); > } >=20 > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 967094994d..1e3489e902 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; > static struct file __initdata xsm; > static const CHAR16 __initconst newline[] =3D L"\r\n"; >=20 > +static __initdata struct { > + bool preserved; > + uint64_t old_addr; > + uint64_t new_addr; > + uint32_t size; > + const char *failure_reason; > +} bgrt_debug_info; > + > static void __init PrintStr(const CHAR16 *s) > { > StdOut->OutputString(StdOut, (CHAR16 *)s ); > @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TAB= LE *SystemTable) > efi_bs->FreePool(memory_map); > } >=20 > +struct bmp_header { > + uint16_t signature; > + uint32_t file_size; > + uint16_t reserved_1; > + uint16_t reserved_2; > + uint32_t data_offset; > +} __attribute__((packed)); > + > +/* > + * ACPI Structures - defined locally, > + * since we cannot include acpi headers > + * in EFI Context. > + */ > + > +struct acpi_rsdp { > + char signature[8]; > + uint8_t checksum; > + char oem_id[6]; > + uint8_t revision; > + uint32_t rsdt_physical_address; > + uint32_t length; > + uint64_t xsdt_physical_address; > + uint8_t extended_checksum; > + uint8_t reserved[3]; > +} __attribute__((packed)); > + > +struct acpi_table_header { > + char signature[4]; > + uint32_t length; > + uint8_t revision; > + uint8_t checksum; > + char oem_id[6]; > + char oem_table_id[8]; > + uint32_t oem_revision; > + uint32_t asl_compiler_id; > + uint32_t asl_compiler_revision; > +} __attribute__((packed)); > + > +struct acpi_xsdt { > + struct acpi_table_header header; > + uint64_t table_offset_entry[1]; /* Variable array length */ uint64_t table_offset_entry[]; BTW, do we have some canonical place with list of files imported (and kept in sync) with other projects? xen/include/acpi/actbl.h doesn't exactly follow Xen coding style, but it's unclear to me if it needs to stay this way. > +} __attribute__((packed)); > + > +struct acpi_bgrt { > + struct acpi_table_header header; > + uint16_t version; > + uint8_t status; > + uint8_t image_type; > + uint64_t image_address; > + uint32_t image_offset_x; > + uint32_t image_offset_y; > +} __attribute__((packed)); > + > +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE *System= Table) > +{ > + EFI_GUID acpi2_guid =3D ACPI_20_TABLE_GUID; > + struct acpi_rsdp *rsdp =3D NULL; > + struct acpi_xsdt *xsdt; > + struct acpi_bgrt *bgrt; > + uint32_t entry_count, actual_size; > + unsigned int i; > + > + for ( i =3D 0; i < SystemTable->NumberOfTableEntries; i++ ) > + { > + if ( match_guid(&acpi2_guid, &SystemTable->ConfigurationTable[i]= =2EVendorGuid) ) > + { > + rsdp =3D SystemTable->ConfigurationTable[i].VendorTable; > + break; > + } > + } > + > + if ( !rsdp || !rsdp->xsdt_physical_address ) > + return NULL; > + > + xsdt =3D (struct acpi_xsdt *)rsdp->xsdt_physical_address; > + if ( !xsdt ) > + return NULL; > + > + actual_size =3D (xsdt->header.length - sizeof(struct acpi_table_head= er)); > + entry_count =3D (actual_size / sizeof(uint64_t)); > + > + for ( i =3D 0; i < entry_count; i++ ) > + { > + struct acpi_table_header *header =3D (struct acpi_table_header *= )xsdt->table_offset_entry[i]; > + > + if ( header->signature[0] =3D=3D 'B' > + && header->signature[1] =3D=3D 'G' > + && header->signature[2] =3D=3D 'R' > + && header->signature[3] =3D=3D 'T' ) strncmp? > + { > + bgrt =3D (struct acpi_bgrt *)header; You can just return it here, avoiding the extra variable. > + return bgrt; > + } > + } > + return NULL; > +} > + > +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject if= bigger */ > + > +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) > +{ > + struct acpi_bgrt *bgrt; > + struct bmp_header *bmp; > + void *old_image, *new_image; > + uint32_t image_size; > + EFI_STATUS status; > + uint8_t checksum; > + unsigned int i; > + > + bgrt_debug_info.preserved =3D false; > + bgrt_debug_info.failure_reason =3D NULL; > + > + bgrt =3D find_bgrt_table(SystemTable); > + if ( !bgrt ) > + { > + bgrt_debug_info.failure_reason =3D "BGRT table not found in XSDT= "; > + return; > + } > + > + if ( !bgrt->image_address ) > + { > + bgrt_debug_info.failure_reason =3D "BGRT image_address is NULL"; > + return; > + } > + > + old_image =3D (void *)bgrt->image_address; > + bmp =3D (struct bmp_header *)old_image; > + > + if ( bmp->signature !=3D 0x4D42 ) > + { > + bgrt_debug_info.failure_reason =3D "Invalid BMP signature"; > + return; > + } > + > + image_size =3D bmp->file_size; > + if ( !image_size || image_size > MAX_IMAGE_SIZE ) > + { > + bgrt_debug_info.failure_reason =3D "Invalid image size"; > + return; > + } > + > + status =3D efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &n= ew_image); > + if ( status !=3D EFI_SUCCESS || !new_image ) > + { > + bgrt_debug_info.failure_reason =3D "Memory allocation failed"; > + return; > + } > + > + memcpy(new_image, old_image, image_size); > + > + bgrt->image_address =3D (uint64_t)new_image; > + bgrt->status |=3D 0x01; Why forcing the "displayed" bit here? > + bgrt->header.checksum =3D 0; > + checksum =3D 0; > + for ( i =3D 0; i < bgrt->header.length; i++ ) > + checksum +=3D ((uint8_t *)bgrt)[i]; > + bgrt->header.checksum =3D (uint8_t)(0 - checksum); > + > + bgrt_debug_info.preserved =3D true; > + bgrt_debug_info.old_addr =3D (uint64_t)old_image; > + bgrt_debug_info.new_addr =3D (uint64_t)new_image; > + bgrt_debug_info.size =3D image_size; > +} > + This is quite a bit of code, maybe move to a separate file? But I'd like to hear what others think. > /* > * Include architecture specific implementation here, which references t= he > * static globals defined above. > @@ -1794,6 +1968,19 @@ void __init efi_init_memory(void) > if ( !efi_enabled(EFI_BOOT) ) > return; >=20 > + if ( bgrt_debug_info.preserved ) > + { > + printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", > + bgrt_debug_info.size / 1024); > + printk(XENLOG_INFO "EFI: BGRT relocated from %#" PRIx64 " to %#"= PRIx64 "\n", > + bgrt_debug_info.old_addr, bgrt_debug_info.new_addr); > + } > + else if ( bgrt_debug_info.failure_reason ) > + { > + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n", > + bgrt_debug_info.failure_reason); > + } > + This is a bit unfortunate place to print this info, because it happens _after_ possibly printing the "invalidating image" message. Maybe you can wrap it in another function and call it next to the invalidating code? > printk(XENLOG_DEBUG "EFI memory map:%s\n", > map_bs ? " (mapping BootServices)" : ""); > for ( i =3D 0; i < efi_memmap_size; i +=3D efi_mdesc_size ) > -- > 2.53.0 >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --hk58erJFVw0zWvNQ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmtwCoACgkQ24/THMrX 1ywYQwgAjlzyOTusTIwqQ/+NTXJJ6T4UiAGHGlGwG3QcqnK030p1g2t/4DWNjCsF 546AtxPHLNdsV8aAW+ZXJy6ZXwET6OtOqoNUmnw3IWJt5P6Nxgy6Paib5fl2XvVw x62GlKk3gD62C/gV6zS7Op45gWda++9fLmPNcVh6bY0i3DKKdC87l+QWvDaXXawH jbhYmO2xFHQZDQwqQwf6R6fRvAFPxudae+8w7usdLLMdoLThxbzpGoWgPd52Nimo x0K4T6ba5wAnxVAidQHSVHDxDH+sy6UhvFMPk/q/VHTL1PyVCGUMLyZHADNfWq9F PDAqkl0yOp/AvIIlO8mbJKxJv8uC9Q== =oIJv -----END PGP SIGNATURE----- --hk58erJFVw0zWvNQ-- From xen-devel-bounces@lists.xenproject.org Sun Mar 08 18:30:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 18:30:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248956.1546520 (Exim 4.92) (envelope-from ) id 1vzIte-00034e-O3; Sun, 08 Mar 2026 18:30:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248956.1546520; Sun, 08 Mar 2026 18:30:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzIte-00034X-LG; Sun, 08 Mar 2026 18:30:34 +0000 Received: by outflank-mailman (input) for mailman id 1248956; Sun, 08 Mar 2026 18:30:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzItd-0002ns-DX for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 18:30:33 +0000 Received: from fhigh-a2-smtp.messagingengine.com (fhigh-a2-smtp.messagingengine.com [103.168.172.153]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e34a7839-1b1c-11f1-9ccf-f158ae23cfc8; Sun, 08 Mar 2026 19:30:31 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 04AC3140019B; Sun, 8 Mar 2026 14:30:31 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Sun, 08 Mar 2026 14:30:31 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 8 Mar 2026 14:30:29 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e34a7839-1b1c-11f1-9ccf-f158ae23cfc8 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=fm1; t=1772994631; x=1773081031; bh=Ql0SMQHbTcL8lEgyG/ZwsaaPZIthzAzl0CqRJ9zqEow=; b= Urpj1lGHG7UW+0e6EMwmjQEOLqu5uzIa1Wi6ba8qweFnjBm4tZrxHiAy9y8BJstr JVfZpMeHeJMvbO74WK4SLk3BuaEexIIEZwX+//hEMxTkaW1bV9CMnk8NrxJiJoeX /rFmFxslnbLchLJLahBmc7SwppILHzTbGxbtnk3+EmCds5Bp9wyDQsltvxRXR5fl 6il+0VPdvH2nLPlMYJkR0shn80G9KPQoHJ/3wx80TBFqwKMt3ciR7m4aDE8vAWV3 nUjRNorJWHMVCyvApn0IduF6iwHfE+IX2PJa3WUZ0BSMOkRcFZrqHxFlbRqLPGXj WAOIrCaUd+RgSMip2Ox6OA== 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=fm1; t= 1772994631; x=1773081031; bh=Ql0SMQHbTcL8lEgyG/ZwsaaPZIthzAzl0Cq RJ9zqEow=; b=rN/wb7gOwxDbpBNNImms/fEhURDtqrgNGwKbeCM5B4HLL5oJaoP A7squK8a+Zcp2QKzzzRmW6BM4qgEjIawZ0F4pUiW8zql8GKj3kLxtrQlJWYqQnZ0 DauWG4wGShofMs19gKIjJvEcUJBFuwkkV98TE5fLtyoMLkgR3cFjr7ahMNvTL95C t0tQVbZyrZHn9c3vIziDCzw77bRa6NUhsO7OUlZA9ecUNsBJ8u9ZP6W/mVZKrEPV 08H5jdTPpJUIS3XHttBLipK45eBtmEp6+VXJOtClMot62GpCUgr8d6NASd7GIlUd xhNt+n8LHvMSYCM6BaHGMM4kPmfI7JbwypA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeehleduucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepshhouhhmhigrjhihohhtihhsrghrkhgr rhdvfeesghhmrghilhdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsrghrkhgrrhhsohhumhih rghjhihothhivdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhse hsuhhsvgdrtghomhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhu thhiohhnshdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg homhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 8 Mar 2026 19:30:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code Message-ID: References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-3-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VoPcmMM3v+387hzR" Content-Disposition: inline In-Reply-To: --VoPcmMM3v+387hzR Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Mar 2026 19:30:27 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 2/3] x86/acpi: Remove BGRT invalidation code On Fri, Mar 06, 2026 at 08:59:07AM +0530, Soumyajyotii Ssarkar wrote: > On Fri, Mar 6, 2026 at 7:23=E2=80=AFAM Marek Marczykowski-G=C3=B3recki < > marmarek@invisiblethingslab.com> wrote: >=20 > > On Fri, Mar 06, 2026 at 12:48:09AM +0530, Soumyajyotii Ssarkar wrote: > > > Now that BGRT images are preserved during EFI boot (via > > > EfiACPIReclaimMemory allocation), the invalidation code in > > > acpi_parse_bgrt() is no longer needed. The BGRT table remains > > > valid throughout boot. > > > > > > This removes the code that was marking BGRT invalid when the > > > image memory was detected as unavailable, which was causing > > > ACPI warnings in Linux dom0. > > > > When preserving failed for any reason, or when it was disabled (the next > > patch), the entry still should be invalidated. In fact, the check here > > for RAM_TYPE_CONVENTIONAL may already disable invalidation when it got > > preserved? > > > > -- > > Best Regards, > > Marek Marczykowski-G=C3=B3recki > > Invisible Things Lab > > >=20 >=20 > I could move forward with dropping the [PATCH 2/3]. And adapt the other > patches accordingly. > This would serve as a safety net in case the preservation fails for any > reason. Would that be a valid approach? Yes, exactly. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --VoPcmMM3v+387hzR Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmtwEMACgkQ24/THMrX 1yy8awf/XZnVSr1EAEjYnyG1v80/QTOhm0gyM9rIXthCYq/0DaX7a6+U0RaT40Iu NT7YW406bhdVHpBj8FAr8/ZpW//e3Gm3u+GqtJOZS8tk6hfpXE8HkXpCEdNdAyYD RPfPReAnXCdYWRACAo2mgKL0E1nHe4yF5gKzN3xfsdqU0iHlqUx9TNI6jfKxthqi KAk3CHafxluqaUdEXvrve8DcznxHTvv53enh9wbuLfU6Q1yFHcy38nicyW/pRl3p n+cJvtQl2Lb8agx+lVCHZcuFjMp0IXKHKByfM3qdzaQ0ZSRz7aRIDdMIhfCQcDV7 S784pDA9ztdOZVJa4kuscK0+/q9Vog== =bYJ+ -----END PGP SIGNATURE----- --VoPcmMM3v+387hzR-- From xen-devel-bounces@lists.xenproject.org Sun Mar 08 18:34:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 18:34:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248970.1546528 (Exim 4.92) (envelope-from ) id 1vzIxm-0003oi-5i; Sun, 08 Mar 2026 18:34:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248970.1546528; Sun, 08 Mar 2026 18:34:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzIxm-0003ob-2r; Sun, 08 Mar 2026 18:34:50 +0000 Received: by outflank-mailman (input) for mailman id 1248970; Sun, 08 Mar 2026 18:34:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzIxk-0003oV-T4 for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 18:34:48 +0000 Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7b02c3aa-1b1d-11f1-9ccf-f158ae23cfc8; Sun, 08 Mar 2026 19:34:46 +0100 (CET) Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfhigh.phl.internal (Postfix) with ESMTP id 885951400127; Sun, 8 Mar 2026 14:34:45 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Sun, 08 Mar 2026 14:34:45 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 8 Mar 2026 14:34:44 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7b02c3aa-1b1d-11f1-9ccf-f158ae23cfc8 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=fm1; t=1772994885; x=1773081285; bh=moVg4hDlKB7TLH7MW3WxwibTX6FvIIhzqiS1wz5mVQE=; b= CV+PHU3Easa5TKt/O0Qm6FJIL9hwDuEnYodhZmh/q+59dzo45dvXD+oIlj9RJM5W PPze8tqmWRV5ZCBTc44jJzMpVix36PFgOh21suz5XGe5riL30uleaj6TA51CZqbx roZsh5dRfpKcJnAJus9F3mQYP3UDcmpHRdY4Fdhk9llZlvvGd4/m3/k2AZyWErny c1fTz1Dy4Xld54/b5+tBoK+T3tI8AiexpCoGXup245ZDi4sEFHo+nDKAcJdQa1FZ 7WiqKIdrB+UVdDigVo+uWZiYkYs/ukWpk0hZFTzCJ3caAxN5qKjwN2SfimE+ewGr zuCbK3OacL+nN8myt4wnxg== 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=fm1; t= 1772994885; x=1773081285; bh=moVg4hDlKB7TLH7MW3WxwibTX6FvIIhzqiS 1wz5mVQE=; b=WC8A6CIQT/R8UQyCoMBXHGy/LqoVbatnjSlH9EQ4CBHaU0Q/uaK zg5wXLMPby2C3AS5ADfZj6gdtfKDyogwzLGWfIqgM81r2YnuaLsj2hLb/bIPF7tk EKqMSzYNCjaWU6tEaEbFsgcqtcQVvWlLYxUb3KvKpYlqq2HvrlTXYDKj4MjsW8HX Ob5xSjGL8EhbdOL0wqrEjUssn+SsB4NMGzC1HtCSoYzrIOu6dmKKU1HWHdU+Zvch 76H3qbDCdMo/1FNYEWW5i2SNvmCAfaH9uRer6QQQEpfLkDE3u19ZdrQa0E6Hewp1 /os9qqvZfDkwPkSvooMrxMLZkUqwOYO+diw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeehledvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepshhouhhmhigrjhihohhtihhsrghrkhgr rhdvfeesghhmrghilhdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsrghrkhgrrhhsohhumhih rghjhihothhivdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhse hsuhhsvgdrtghomhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhu thhiohhnshdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg homhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Sun, 8 Mar 2026 19:34:42 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Message-ID: References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-4-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2nGy8xoL0y3DCac7" Content-Disposition: inline In-Reply-To: <20260305191810.31033-4-soumyajyotisarkar23@gmail.com> --2nGy8xoL0y3DCac7 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Mar 2026 19:34:42 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH 3/3] x86/efi: Add opt-out mechanism for BGRT preservation On Fri, Mar 06, 2026 at 12:48:10AM +0530, Soumyajyotii Ssarkar wrote: > As described in the task, BGRT preservation is now enabled by default to = fix ACPI corruption > for desktop/workstation systems (similar to ESRT). >=20 > Add an opt-out parameter 'efi=3Dno-bgrt' to allow disabling BGRT > preservation on systems where the ~1MB memory overhead is not > desired. >=20 > The parameter is parsed during normal Xen boot (not during EFI > phase), so it only affects diagnostic logging. The opt-out flag > is checked at the start of efi_preserve_bgrt_img(). >=20 > Usage: > Default: BGRT preserved automatically > Opt-out: Add 'efi=3Dno-bgrt' in Xen command line >=20 > Signed-off-by: Soumyajyotii Ssarkar > --- > xen/common/efi/boot.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) >=20 > diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c > index 1e3489e902..b735eac6b2 100644 > --- a/xen/common/efi/boot.c > +++ b/xen/common/efi/boot.c > @@ -167,6 +167,7 @@ static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdEr= r; >=20 > static UINT32 __initdata mdesc_ver; > static bool __initdata map_bs; > +static bool __initdata opt_bgrt_disabled =3D false; >=20 > static struct file __initdata cfg; > static struct file __initdata kernel; > @@ -868,6 +869,9 @@ static void __init efi_preserve_bgrt_img(EFI_SYSTEM_T= ABLE *SystemTable) > bgrt_debug_info.preserved =3D false; > bgrt_debug_info.failure_reason =3D NULL; >=20 > + if ( opt_bgrt_disabled ) > + return; > + > bgrt =3D find_bgrt_table(SystemTable); > if ( !bgrt ) > { > @@ -1873,6 +1877,10 @@ static int __init cf_check parse_efi_param(const c= har *s) > else > __clear_bit(EFI_RS, &efi_flags); > } > + else if ( (ss - s) =3D=3D 7 && !memcmp(s, "no-bgrt", 7) ) > + { > + opt_bgrt_disabled =3D true; > + } This is too late - standard param parsing happens after efi_exit_boot() already. See early cmdline parsing in efi_multiboot2() and also in efi_start() (but note the latter is about options to xen.efi, which isn't exactly the same as standard xen cmdline...) > else if ( (ss - s) > 5 && !memcmp(s, "attr=3D", 5) ) > { > if ( !cmdline_strcmp(s + 5, "uc") ) > @@ -1968,7 +1976,11 @@ void __init efi_init_memory(void) > if ( !efi_enabled(EFI_BOOT) ) > return; >=20 > - if ( bgrt_debug_info.preserved ) > + if ( opt_bgrt_disabled ) > + { > + printk(XENLOG_INFO "EFI: BGRT preservation disabled\n"); > + } > + else if ( bgrt_debug_info.preserved ) > { > printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", > bgrt_debug_info.size / 1024); > -- > 2.53.0 >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --2nGy8xoL0y3DCac7 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmtwUIACgkQ24/THMrX 1yynqAgAj36JkBL1ZYj9BVbQgsX9pyS5O8a828DLAzSyY8y0t5+zNPVaUcFnz8zE 6bIvbCCJeRVWyrBpEApRHIoJe6q9VL1ur5GHtMPWsSRTupBKWcdwGhZpmSmP2qYN xVSs3KuudYQiKVa66h2AGIba8QfWDPmSrYl5KeEVV6HKGeNRELGmFGz7BOxOtmVu dbG9xHD1cuX8xufzNnEEkgs7OBiA+NcyIh0mXj2zRxUwIErj32OkAq3m47W4NYgC uya9v+9lnhVaPMFEhsBd0P5NWjiutsWJLgSCj0gYHvr2AucxkfClGL9Cb4qK9ora 2sOLTGYIBW0uzjsU8jiaKha7unX/HA== =+07o -----END PGP SIGNATURE----- --2nGy8xoL0y3DCac7-- From xen-devel-bounces@lists.xenproject.org Sun Mar 08 19:34:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 19:34:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248994.1546538 (Exim 4.92) (envelope-from ) id 1vzJtJ-00039j-Cr; Sun, 08 Mar 2026 19:34:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248994.1546538; Sun, 08 Mar 2026 19:34:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtJ-00039c-AK; Sun, 08 Mar 2026 19:34:17 +0000 Received: by outflank-mailman (input) for mailman id 1248994; Sun, 08 Mar 2026 19:34:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtI-00037z-9C for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 19:34:16 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c73b53fa-1b25-11f1-b164-2bf370ae4941; Sun, 08 Mar 2026 20:34:11 +0100 (CET) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 628CPhag3683510 for ; Sun, 8 Mar 2026 19:34:09 GMT Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4crb14u517-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 08 Mar 2026 19:34:08 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-bce224720d8so6236825a12.1 for ; Sun, 08 Mar 2026 12:34:08 -0700 (PDT) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829a4676593sm7818909b3a.28.2026.03.08.12.33.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 12:34:06 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c73b53fa-1b25-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=qcppdkim1; bh=DNMdCDB4m/JS2Eqb4Zd/0G 6oEd9rQSbuN+RA5pJMqjw=; b=Iz5I4QQh+5X+EdI7ZbWYkCwMd0XsXKEgZSSk7u fZ9Y3l6+S7LKgAOi7D3AfsdoMASdDUtGTK7RZzHvs5t01JfUzEaojPuJ6bMc9ofc 2/bd2VGoUOQMpwJRFzwOorskgCxsdkMtTQplIHuOzWjx8AvvZ9lxxJMGtGLNxgSn anN7DXhtVfkGW27Ex2TmfG1rL90bMyaGXdzyW12WT3YHHeNaHtVQP07xfglcjK+U 3Hq+dgArnD8ScoB11PW9t66PZ9SMoa2utjEkZ1vtKayFBjoNbGSTSExpPj7knnQH KyxIdiH5oJAi7giVdLeW41AZ3NV+Hguvx/+DxBT7wj64Xk/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772998448; x=1773603248; darn=lists.xenproject.org; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=DNMdCDB4m/JS2Eqb4Zd/0G6oEd9rQSbuN+RA5pJMqjw=; b=YtGBGotXNbZV8VKbqs1gxm9gdjEYdtiQZMp8ieAfQwTJ1g2/iYY33u4jXe5/BvH5hO 0rTDzpp4eoPnjOKHEnttXJkr5guvDzdGEol9g2XXvp4B/eX0w3EXMDGSOsWSCAkYUVm6 akZFdpCQL3O7UezlQ5nvnCOiZIas5mIxZPVbWCR0rzyKAWQwWbN4Z3dnauVqLQwXB8dI 80Kq85uZ58BxauI6ohVmLrmnc89a/AY1FcaIeeADy+CxBukFsJkCo3kILIwNXC4dTzZn uoKMLIYbdwLQGSe6AN5L3SaxrvQnjnefmHlyGa8BJP0qrmZJmVTA9P4ZyptUn6zObdNP LNgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772998448; x=1773603248; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DNMdCDB4m/JS2Eqb4Zd/0G6oEd9rQSbuN+RA5pJMqjw=; b=nSBypgUzLHbRG7Ga7ptw6ISp970e+9l7jTgeV6v4d203QP8a6VrWJqLGFPRlUxVEKZ F74kz8fNQZnwAAyNlgS5PdMBITej5ZlVt1vPslxLyb9BQtH4bTcnatq0wF9Rogmjt0Mj 7Aau6cW8RcwCVvztjD+0ZiftZSi+n/h2YU4CmcsyGFq9HVOzBjwQ4KYw/rzh9N13lo9r hpFQmCoRwH0RDisKcrWWmfsz4V2sH1/VbqPdozzu+YiuqMkSrjQCnkQfBvTS+EXySHBw 4wE4JxF+9K30m81xGujzLOBmA2bXVC4y7Dco3s/C1M2zrXadIz83APIxmnIqYq5blbs6 BIHQ== X-Forwarded-Encrypted: i=1; AJvYcCUjrlD+B3XU1Hul0g9sopb0Ff0ZhBWcGCLqccYenmz/a3D8YV2fXyHY0K2cG32G4LuJ3Un4U46LT0A=@lists.xenproject.org X-Gm-Message-State: AOJu0YzqO5Wxdjz8tXQ7uHgkszGDXdIuUovtsZ5w3/hRxmkPjw/TDIwp ZoHOEdgdVbXMdCytypbbAEkVVvgbu+t5qbtw0zk1rIrgq507yfiKzuaiVdMZG0VfaNjTIvYGg9F Rf3tmokVMKF7xQt2e17lKN/RRp6pDb3meRhh6RtdoiYAR5IZGl/A3uPA7vOPdsoKssjpirw== X-Gm-Gg: ATEYQzwtKW+b7CzNxhG9mueberngpIiupx/uF4W1Rtrdp8frFpMtIFxv1WFKdke2C1H LTpZvmDnEg/bieBchwNLUHNqrXtVEiGsSI24SSHpE/C+eKw6Xwt7fhlf1VRCPYVi3WQc3rTjVas OmVMbaKkO755W9aZPXCewq5nM/1FObRTiITJtFz4Ux3f8OzvFOoyTY4ORrX5qNqOiX1HMnmsrpg Q7P4yes2SjlnAGSGh7eC/hTLr2L2tyRef3hsV3D/UKCrxm6tZ4ipKtFWFUcbNYLbMqvN+jGKrWF fLeyBff74XL6GbqHKlqnSp+lqdoVrjlcdrAmGsMDirS1qvjdrB9tz8VfAil8z9OI7G8Ks7N5jge oh2iJMAuYHZP9WNSxnTFFiRe71ettpE4wJo071KZKd3LfVw4dmI4QSE7B X-Received: by 2002:a05:6a00:4b53:b0:829:6f9f:ea3b with SMTP id d2e1a72fcca58-829a2e3d086mr8046006b3a.20.1772998447756; Sun, 08 Mar 2026 12:34:07 -0700 (PDT) X-Received: by 2002:a05:6a00:4b53:b0:829:6f9f:ea3b with SMTP id d2e1a72fcca58-829a2e3d086mr8045981b3a.20.1772998447234; Sun, 08 Mar 2026 12:34:07 -0700 (PDT) From: Vijayanand Jitta Subject: [PATCH v10 0/3] of: parsing of multi #{iommu,msi}-cells in maps Date: Mon, 09 Mar 2026 01:03:36 +0530 Message-Id: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIABDPrWkC/32NUQ6CMBBEr0L225KWKgpf3sMQUpZVNgGKXSEaw t2tHMCfSWYy82YFocAkUCYrBFpY2I/RGH1IADs3PkhxGwPIdJZrq42aXBCq2Q/DXCP1vSiD1p7 zi6OmcRB3U6A7v3forYq+Y3n58Nk/luKX/qMthdLq2JoGiRBPZK5eJH3OrsfYSqNAtW3bF4mVr Ue6AAAA To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Vijayanand Jitta , Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772998436; l=4795; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=PtTdudtjBZ/xPMrnHDRK1H9Z6n/XjfTDJSglqtupcDI=; b=EBb8Dk6BIlgjCH0Fqcmr+R/Zem16FjzSLlrw2KGhDvNxeYgPJwLHInLgJNWKtbmBgHLkCc5NK xDxh7Np2VUaB9ZsluGW3jBruuRfE5BZGHAei8UQe3BXzG9rX5bRMd84 X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Authority-Analysis: v=2.4 cv=IYSKmGqa c=1 sm=1 tr=0 ts=69adcf30 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=VwQbUJbxAAAA:8 a=COk6AnOGAAAA:8 a=EUspDBNiAAAA:8 a=NEAV23lmAAAA:8 a=hUMMoPFcHhpVZiwYRzIA:9 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 a=TjNXssC_j7lpFel5tvFf:22 X-Proofpoint-GUID: C3N61NEbB5_rPmOm3kCQzkC6ijS8kSQE X-Proofpoint-ORIG-GUID: C3N61NEbB5_rPmOm3kCQzkC6ijS8kSQE X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA4MDE4MSBTYWx0ZWRfX0zoZVdlAmNtm uAobE8tvezPo4o5SDvQD3bCm3FmUBZ0pnAPTypm7zD40/zclABuj1jookJAWE4doA7V3O3pXZ+W IebCIpDo6urdwHsTOoTCq/hSbeq09d2m+HJrLc7JZ65v/t4B28A9mD+skGrDjmWoKr7bGl9jJ++ kVfikDUCK1lA4c1M1BxbWe+oneqew3bxfDWWBdrt6dSsrd4nkuLmeVqSTZJ4ZdErl66dJdihlD0 VANVG5o29r6zJ+LvGx3y8IBDLSorsSvY0N13rFbZPKE/751kEQB3sMe4lk9hAgaZgas98PdB0ih x7TuHv8xZU+p4kYlYI9TFUB846hsCDHD3V4jUTripbDaWmJ3oIICtSceNI8ggYwdLc2nlTN0plD nPGhgkFto0CNvVErIy4rKsOOdABwu230EnftZNL1KngXuP6qy0+0IvBSjRlEGtTfpD6x3DGkpxG e0++g6ERVZKI93gcgIw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-08_05,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 phishscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603080181 So far our parsing of {iommu,msi}-map properites has always blindly assumed that the output specifiers will always have exactly 1 cell. This typically does happen to be the case, but is not actually enforced (and the PCI msi-map binding even explicitly states support for 0 or 1 cells) - as a result we've now ended up with dodgy DTs out in the field which depend on this behaviour to map a 1-cell specifier for a 2-cell provider, despite that being bogus per the bindings themselves. Since there is some potential use[1] in being able to map at least single input IDs to multi-cell output specifiers (and properly support 0-cell outputs as well), add support for properly parsing and using the target nodes' #cells values, albeit with the unfortunate complication of still having to work around expectations of the old behaviour too. -- Robin. Unlike single #{}-cell, it is complex to establish a linear relation between input 'id' and output specifier for multi-cell properties, thus it is always expected that len never going to be > 1. These changes have been tested on QEMU for the arm64 architecture. [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/ V10: - Move of_map_iommu_id()/of_map_msi_id() from include/linux/of.h to drivers/of/base.c as out-of-line helpers per feedback from Marc Zyngier and Rob Herring. - Add kernel-doc to document both helpers for discoverability and usage clarity. - Fix of_map_msi_id() wrapper and all its callers (cdx_msi.c, irq-gic-its-msi-parent.c, drivers/of/irq.c) to correctly use the new struct of_phandle_args-based API with proper of_node_put() handling as per feeback from Dmitry. Link to v9: https://lore.kernel.org/r/20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com V9: - Updated TO/CC list based on feedback to include all relevant maintainers. - No functional changes to the patches themselves. Link to V8: https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/ V8: - Removed mentions of of_map_args from commit message to match code. Link to V7: https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/ V7: - Removed of_map_id_args structure and replaced it with of_phandle_args as suggested by Dmitry. Link to V6: https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/ V6: - Fixed build error reported by kernel test bot. Link to V5: https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/ V5: - Fixed Build Warnings. - Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184 Link to V4: https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/ V4: - Added Reviewed-by tag. - Resolved warnings reported by kernel test bot, minor code reorganization. Link to V3: https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/ V3: - Added Reviewed-by tag. - Updated of_map_id_args struct as a wrapper to of_phandle_args and added comment description as suggested by Rob Herring. Link to V2: https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/ V2: - Incorporated the patches from Robin that does the clean implementation. - Dropped the patches the were adding multi-map support from this series as suggested. V1: https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/ RFC: https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r Signed-off-by: Vijayanand Jitta --- --- Charan Teja Kalla (1): of: factor arguments passed to of_map_id() into a struct Robin Murphy (2): of: Add convenience wrappers for of_map_id() of: Respect #{iommu,msi}-cells in maps drivers/cdx/cdx_msi.c | 6 +- drivers/iommu/of_iommu.c | 6 +- drivers/irqchip/irq-gic-its-msi-parent.c | 11 +- drivers/of/base.c | 202 ++++++++++++++++++++++++------- drivers/of/irq.c | 9 +- drivers/pci/controller/dwc/pci-imx6.c | 18 ++- drivers/pci/controller/pcie-apple.c | 6 +- drivers/xen/grant-dma-ops.c | 5 +- include/linux/of.h | 28 ++++- 9 files changed, 222 insertions(+), 69 deletions(-) --- base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31 change-id: 20260301-parse_iommu_cells-1c33768aebba Best regards, -- Vijayanand Jitta From xen-devel-bounces@lists.xenproject.org Sun Mar 08 19:34:33 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 19:34:33 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248995.1546547 (Exim 4.92) (envelope-from ) id 1vzJtP-0003NH-Jz; Sun, 08 Mar 2026 19:34:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248995.1546547; Sun, 08 Mar 2026 19: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 ) id 1vzJtP-0003NA-Ge; Sun, 08 Mar 2026 19:34:23 +0000 Received: by outflank-mailman (input) for mailman id 1248995; Sun, 08 Mar 2026 19:34:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtN-00037z-IE for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 19:34:21 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cd654c96-1b25-11f1-b164-2bf370ae4941; Sun, 08 Mar 2026 20:34:20 +0100 (CET) Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 628BDj0F2986038 for ; Sun, 8 Mar 2026 19:34:19 GMT Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4crc3vb072-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 08 Mar 2026 19:34:19 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-c73939e0314so1740626a12.1 for ; Sun, 08 Mar 2026 12:34:19 -0700 (PDT) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829a4676593sm7818909b3a.28.2026.03.08.12.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 12:34:17 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cd654c96-1b25-11f1-b164-2bf370ae4941 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= Vh58ApOUDm3FbXz3u/s00W13OYNSc/5jru8Nq3PkHFY=; b=NCiJDgtFWX7fALOI cYlP/SeFlV7hVz3MMfIeBj4CIRQ7aHOJrvUrZvIDdAmOU9/tq7yhusXbtHXNp8Hk 16EIUYQa18m/Kv//TOVmYeeua7F6BBwm/Mx9+MF0hNupRWTAaVjQb2rzBHct/TDq tVHq0PUr2BjRX6/4RgD3Cg16ebBqEHLgJJUR96n6chJZ4fRkP1cWEt/ha508VGWU HI3mRNebuPtZnigCqMTAY1JrIduqeylWEC7IR12dr9dUMRe9EVupNyiqi8xkFIyD gTLU5WKT8ALMzi/7zlFHh/r6sdP+v355QrvVbXlXe3wgVXX2jtEc8HC5nmO5nR+V Dc6ieg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772998458; x=1773603258; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=Vh58ApOUDm3FbXz3u/s00W13OYNSc/5jru8Nq3PkHFY=; b=ZyK3632CyQ0F9JyGhr6hLCeqkZG0jgMOuVLaC+AK2/cLx0ZNUY6Szu/oNmGmKcA/9z OaEu+btCRFH/UYqTnITM2iCFR7J9TWu6s0pMHRwmTN9It/t9WiwEm6cj+aGRu1GAOxYs oRNqthNpbC10QeqSMNeU1xH28YO12IU2UTwCXMuMVW7g8c3gCd8BpNerZ9cCcjnNU4o7 OVOnxRpf1+iK1uQMikKCbEWAUKYwu4TUyaubSLzyMHSc352ecXwVmJxlvnqO5BU+N7kp 2m3EcRcf6OOVJd3fjKrdem7riCfbvxEijILmr1GdYOajevS2fr6e+plh+U+ZNOHGvGr4 XZ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772998458; x=1773603258; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Vh58ApOUDm3FbXz3u/s00W13OYNSc/5jru8Nq3PkHFY=; b=gBWNkcEJ9cDGb0gZT4QpozjS0XeVFoprWC8q+4NG0vQuR0viYLDFokcxTYGITf7OlO SsVvDdxVZkYmml3f/iNqDlEOPIqw3L/a1eO75+c5/XNejB1zYEekNLcYc77pmDazSau2 P6OyCam00VvxXxl5gLLoJ/4E73UdwDiFIE7HYsPaUgEA/Jx49ZW43oXvw5I99XvdliJ7 LuQRoiKX6wRsApdsA/67o2pITP/xrFuRQlAlsayFGu5JBCqixNpAr3/r8tYTX4GED1tm Dhk3ofKd4Ypo2/kv4b2alM6puFpxLbEnNzhA/nBVNPuwZOGamskiMztzl5upijFbs1km t53g== X-Forwarded-Encrypted: i=1; AJvYcCWufJYVYj2tdQLZqv1042t6GX8X4JsRQ96MpFQArbw03BOHPLDVEeP0+PQU3cWhs1L7HPfSJi/XNMs=@lists.xenproject.org X-Gm-Message-State: AOJu0YyIhjU6GdT/1Q4J4ZAsMEMrHtNYts5AeUGCOLW10EJ3OGMN0Rbn uXw0J0+AtS08ivgT70ZthflX+n2Hl9ZPkWo0kWl26+R0Y63iAjupFTScOdJRmIewZaMyqAkj4bO FGazXk4Bhr2C0V9sPq9M1Skco2F4R4fGzvz+nGB/h0iX/ztOr1kKtO3bz2DTbCXbYmG7ARA== X-Gm-Gg: ATEYQzzxtoVNhVguDUkSjm8Mc4THtix0pm0wgHn0B57uMB8+AXg23eB6toCDag7+PKz NYeXY5sOvDSzEfHrSiAzFrtuGcBjopbXGtZw4CKRRTwimZnU9C3LCYoOxrWd66yaYCr6XPV6zHg UBurgzZjpnSTwOasqjc1FlblDR7ZOVpxvq7+t0N5WLEpwpYwNsppo1YhO1KfCDrY6KPENeMjb99 iENZ7oysS+MEUvlntxhBsRBciZecnG9yU9TZMRa3ktf0FXTLmj7L4QTzoVpITQpY9p3JoDZVZIM NkgVpoB1o69pgBXn24PDrP9GYazRMlexASZWD3yk9gbrhT7KtIKxj8tO8QAr/A+NG0icWmadSTl 6LwXg6j3HHJryFEjYOxa35S9xd9/4hpKx8ZxvDgdWMbIUhSxK70eAq63O X-Received: by 2002:a05:6a00:3d98:b0:7e8:43f5:bd4c with SMTP id d2e1a72fcca58-829a30b0da4mr5836486b3a.56.1772998458266; Sun, 08 Mar 2026 12:34:18 -0700 (PDT) X-Received: by 2002:a05:6a00:3d98:b0:7e8:43f5:bd4c with SMTP id d2e1a72fcca58-829a30b0da4mr5836476b3a.56.1772998457759; Sun, 08 Mar 2026 12:34:17 -0700 (PDT) From: Vijayanand Jitta Date: Mon, 09 Mar 2026 01:03:37 +0530 Subject: [PATCH v10 1/3] of: Add convenience wrappers for of_map_id() MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260309-parse_iommu_cells-v10-1-c62fcaa5a1d8@oss.qualcomm.com> References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> In-Reply-To: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Vijayanand Jitta X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772998436; l=8304; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=0HcqUiUmz/4eYD3bErvod4ldrniwhh4k5wTOZyawn+Q=; b=NIW6O7RTPmvFreddKnzjsXyJ5nMuEQ3h35YKP6uS4GabQ++O++b3BwYxmZvNyx/JcaKUBuwi5 TReogjCXsU8DzPxev4DnCf+9kM0nkPTOxhZZFRkatpC4OluXCiVlu9/ X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-ORIG-GUID: Qyl0HIqBBTkWmziikvn5U2EgL6zChW-b X-Proofpoint-GUID: Qyl0HIqBBTkWmziikvn5U2EgL6zChW-b X-Authority-Analysis: v=2.4 cv=OOQqHCaB c=1 sm=1 tr=0 ts=69adcf3b cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=EUspDBNiAAAA:8 a=jVkiwcMdNzIszB0OPoYA:9 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA4MDE4MSBTYWx0ZWRfX5fqtXcDwcyHS xGtJ2xZKkMB8SbpU9ZQWl5aJbmh7NySK9nN+r+HvebhAHzKchT4o95Ze1ETshal0GOuVOwa8yTP Y1W5s0a03rI6I1t1ypu6D5roeievbGSS2ZUyraN5X90y1pJ/6OGPc5lXJmYig4fok1mTKGc6OXW iNp4uHKjC6w70gnmZF/8nL3k+JwiGytpqXQgOO1QEsN4sickeej9NK2HC9srQWuOMIA6eD0Xl2a GchjN1cVnbqL8yfSKnkzNJWB/uWsezcs5SQzEPucrDsa1fLwtbS06a6e4my+dxt3LfwF0FbL5dB 8q9OI0JI3iVbCTN7+oTd5FLvI2lActgI/Xhx//tb4JLEScIi6kxwH4Wgr2Z6y2PVHQYYjLYnsvl WpmAFTs/FU6O9YCTXMftlA4xMiESMt0X5whvlYPZdhWsuCXVp4km3DhZ9tuiHYDoffGN7nIoSkQ VhtXQcg1RA4dsNsHKGg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-08_05,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603080181 From: Robin Murphy Since we now have quite a few users parsing "iommu-map" and "msi-map" properties, give them some wrappers to conveniently encapsulate the appropriate sets of property names. This will also make it easier to then change of_map_id() to correctly account for specifier cells. Reviewed-by: Rob Herring (Arm) Reviewed-by: Frank Li Signed-off-by: Robin Murphy Signed-off-by: Vijayanand Jitta --- drivers/cdx/cdx_msi.c | 3 +-- drivers/iommu/of_iommu.c | 4 +--- drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- drivers/of/base.c | 36 ++++++++++++++++++++++++++++++++ drivers/of/irq.c | 3 +-- drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- drivers/pci/controller/pcie-apple.c | 3 +-- drivers/xen/grant-dma-ops.c | 3 +-- include/linux/of.h | 18 ++++++++++++++++ 9 files changed, 62 insertions(+), 16 deletions(-) diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c index 91b95422b263..63b3544ec997 100644 --- a/drivers/cdx/cdx_msi.c +++ b/drivers/cdx/cdx_msi.c @@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, int ret; /* Retrieve device ID from requestor ID using parent device */ - ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask", - NULL, &dev_id); + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); if (ret) { dev_err(dev, "of_map_id failed for MSI: %d\n", ret); return ret; diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 6b989a62def2..a511ecf21fcd 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_map_id(master_np, *id, "iommu-map", - "iommu-map-mask", &iommu_spec.np, - iommu_spec.args); + err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); if (err) return err; diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c index d36b278ae66c..b63343a227a9 100644 --- a/drivers/irqchip/irq-gic-its-msi-parent.c +++ b/drivers/irqchip/irq-gic-its-msi-parent.c @@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u struct device_node *msi_ctrl __free(device_node) = NULL; - return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id); + return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); } static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, diff --git a/drivers/of/base.c b/drivers/of/base.c index 57420806c1a2..959305a84748 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -2201,3 +2201,39 @@ int of_map_id(const struct device_node *np, u32 id, return 0; } EXPORT_SYMBOL_GPL(of_map_id); + +/** + * of_map_iommu_id - Translate an ID using "iommu-map" bindings. + * @np: root complex device node. + * @id: device ID to map. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask". + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_iommu_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out); +} +EXPORT_SYMBOL_GPL(of_map_iommu_id); + +/** + * of_map_msi_id - Translate an ID using "msi-map" bindings. + * @np: root complex device node. + * @id: device ID to map. + * @target: optional pointer to a target device node. + * @id_out: optional pointer to receive the translated ID. + * + * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask". + * + * Return: 0 on success or a standard error code on failure. + */ +int of_map_msi_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out); +} +EXPORT_SYMBOL_GPL(of_map_msi_id); diff --git a/drivers/of/irq.c b/drivers/of/irq.c index 6367c67732d2..e37c1b3f8736 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) * "msi-map" or an "msi-parent" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { - if (!of_map_id(parent_dev->of_node, id_in, "msi-map", - "msi-map-mask", msi_np, &id_out)) + if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) break; if (!of_check_msi_parent(parent_dev->of_node, msi_np)) break; diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index a5b8d0b71677..bff8289f804a 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) u32 sid = 0; target = NULL; - err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask", - &target, &sid_i); + err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); if (target) { of_node_put(target); } else { @@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) } target = NULL; - err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask", - &target, &sid_m); + err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); /* * err_m target diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c index 2d92fc79f6dd..a0937b7b3c4d 100644 --- a/drivers/pci/controller/pcie-apple.c +++ b/drivers/pci/controller/pcie-apple.c @@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d dev_dbg(&pdev->dev, "added to bus %s, index %d\n", pci_name(pdev->bus->self), port->idx); - err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map", - "iommu-map-mask", NULL, &sid); + err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); if (err) return err; diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c index c2603e700178..1b7696b2d762 100644 --- a/drivers/xen/grant-dma-ops.c +++ b/drivers/xen/grant-dma-ops.c @@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, struct pci_dev *pdev = to_pci_dev(dev); u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); - if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np, - iommu_spec.args)) { + if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { dev_dbg(dev, "Cannot translate ID\n"); return -ESRCH; } diff --git a/include/linux/of.h b/include/linux/of.h index be6ec4916adf..fe841f3cc747 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -465,6 +465,12 @@ int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, struct device_node **target, u32 *id_out); +int of_map_iommu_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out); + +int of_map_msi_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out); + phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); struct kimage; @@ -934,6 +940,18 @@ static inline int of_map_id(const struct device_node *np, u32 id, return -EINVAL; } +static inline int of_map_iommu_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + +static inline int of_map_msi_id(const struct device_node *np, u32 id, + struct device_node **target, u32 *id_out) +{ + return -EINVAL; +} + static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np) { return PHYS_ADDR_MAX; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 08 19:34:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 19:34:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1248997.1546556 (Exim 4.92) (envelope-from ) id 1vzJtd-0003iQ-0C; Sun, 08 Mar 2026 19:34:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1248997.1546556; Sun, 08 Mar 2026 19:34:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtc-0003iH-T4; Sun, 08 Mar 2026 19:34:36 +0000 Received: by outflank-mailman (input) for mailman id 1248997; Sun, 08 Mar 2026 19:34:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtc-0003hg-Cb for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 19:34:36 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d4881ccf-1b25-11f1-9ccf-f158ae23cfc8; Sun, 08 Mar 2026 20:34:32 +0100 (CET) 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 628JXPYL2149781 for ; Sun, 8 Mar 2026 19:34:31 GMT Received: from mail-pf1-f199.google.com (mail-pf1-f199.google.com [209.85.210.199]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4crbbg330j-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 08 Mar 2026 19:34:31 +0000 (GMT) Received: by mail-pf1-f199.google.com with SMTP id d2e1a72fcca58-829b20cc6faso934466b3a.1 for ; Sun, 08 Mar 2026 12:34:31 -0700 (PDT) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829a4676593sm7818909b3a.28.2026.03.08.12.34.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 12:34:28 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4881ccf-1b25-11f1-9ccf-f158ae23cfc8 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= s0f+l0UZykxb7mxIoRRD4wGsukxC7Yg8uv8eg8ZQXhE=; b=W7t05n81CGCjJycM rB6ngvUqGgEoubTypruWnhT3yBAf+l9BKRx9nXxl8on7bN7AD7vMZvuVDbbJXBBW MI3sHnNc0AVDH4OkDMu+z6G79TVzjTt3NPX7d4pzD02oVyxbXEnoD1wYpNy5ad1O XB80ulB6gd+eCcH64Dd7KM8KMWcDfSJjAn3MxQUwF8hmevEZAVuMNFHWQs/Hb9YC B0KrhFsTTtLCkdfJ4I13Sr7hENc7pAk53RDSXgVwiB2Z+7B+KZ+7j/6brbNRuH5B G6S4wEgkOFSAXg7mxr0bDzdfl1OVaqxSKHTu21vwELL07pMtq1y07m/VLqgyZAAR nsVZXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772998470; x=1773603270; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=s0f+l0UZykxb7mxIoRRD4wGsukxC7Yg8uv8eg8ZQXhE=; b=gHp9r7gZUHoA54SyfBtdC9rXLf2TqZvLFR83ZZdmVerjPf/bRj8NfNWPAldCtNsbut iN6yP41I91s0W/zCe+M+7WDw5rVMppO7rQGjGGXcYpX0nBpLwdIstT3EwgMhFkVaItbA WW+VEU4VnvqdumS2/jHle/PMvJquVUN2R0JkWJNanJyPnxqQHU7AAxFYR6lksCq8bRT6 QKQ4PlNcMnJT1NXQqTc+7Bj60VE6x7dlBWWE0kVGsD27fG19Or8LSeTxVCZ91fAATGss NwQk1qloMUI5mggiDr4+zTRAfvS64Rx8nGU6ePJFFIL3H6Gw//QLBUOS7dMhSEgHJYEz l2Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772998470; x=1773603270; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=s0f+l0UZykxb7mxIoRRD4wGsukxC7Yg8uv8eg8ZQXhE=; b=rVcN1fBPsp3A8bliZToBC5zauQNbATzbI8vD2SOH3bddbLt5XWSJFohmvGvSWpLgaJ fZNpwR1nLUgcDvCrWV4krWUBwehrTB/vuB8wQZIHBi0ljfn3ABHLZstIR6aEZEQ9Ysof A3m6cl4//k8w4AmO0X5vhS/kA8IO5pvIQcfNB3BvDpLNAJAO4TrZozSWKX9Mm6DOSqMW aSD4T5cD60lZ2xGyrkkOTIe4JP4ClBiLiY+fZ9Df1/dU4+G+i6Z5htfDsl45cEUjx4hE xUZUY5OIAFlyDieNhQxZJpVaUgI0LLDfB8fZvTZQbFAoI23WbjBLJUrbqBvcxlsg8+ik g00Q== X-Forwarded-Encrypted: i=1; AJvYcCUO8H5T5Rq7IX4hRHznHDcIKuL9wQjZJQM10FiAMbZdCporBiul7FF4hXHVMIKgLQibKGNdWEmgjiQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyhvV/iLpnBcgpYDETZ2v2rZ95flaDAeMxtWoMBbnCAh0I0Yt7M TM0KVFizdnF/v5tgHfj27D+8NYrNP2yGBFf3EexNpmnpCcmjb+2TXMHEHAPfQoZaEFtMxgfKyCj aV1GPp0WRhcYFAun7GVhTakmpA4hMvN/e9VUzGrPijWXWwRfLX2fQ31Grsm0ciSn1h9pXNw== X-Gm-Gg: ATEYQzxMRA2o1fZmRq3g6XW6jV+IX/DnVBo/NYin5cYP0jM85bKdek1JMYQ8fvx+JYs cY05slPHmLUl8idF/2c6djDU5oUszeE/4zpiit6qh1c/cAEu7wa+xgqd5QSeuUGeordz7O3tkOG KH4gkzn9VcCVC13/UtvVdeBRpwqdaFu26DsuxqTbQdNh/0xh8IVkl/2sP//XH/bvOxf7QhUqf6c sEAesWHqzB6+ECIIO0m9dPrEYyQJm4nCpfgBtm7UR30unDC/RuMzkzPSDvKIFikIgEx0DJZ2KpU ZR547DcG8NMK7VMQVvbkf8E6mbyYTv0pitSN/rd9qm5CE6GmcMEMSpc9HTFOuTN7O1eD9GrDkKc ed8UelgGt6aHhDbCNJQPqvmNW7WXQHKMLwR2uw4GnLcLJv2Yw0e8WvoJS X-Received: by 2002:a05:6a00:124f:b0:81f:c6d1:5608 with SMTP id d2e1a72fcca58-829a29d27aemr6338695b3a.1.1772998470202; Sun, 08 Mar 2026 12:34:30 -0700 (PDT) X-Received: by 2002:a05:6a00:124f:b0:81f:c6d1:5608 with SMTP id d2e1a72fcca58-829a29d27aemr6338664b3a.1.1772998469631; Sun, 08 Mar 2026 12:34:29 -0700 (PDT) From: Vijayanand Jitta Date: Mon, 09 Mar 2026 01:03:38 +0530 Subject: [PATCH v10 2/3] of: factor arguments passed to of_map_id() into a struct MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260309-parse_iommu_cells-v10-2-c62fcaa5a1d8@oss.qualcomm.com> References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> In-Reply-To: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Vijayanand Jitta , Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772998436; l=14423; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=2xxclcz292iaXTCTUUgVe5HU3Ug92HRVDDP0RH/vc/Q=; b=5EJAcBss+t1VSBS7dm5TC4pfRYcv/8aKwEEwlHqkx/KhRZ1Bd8rbDtR/aYN2PXiCfTlToSZB0 p8l0VQz2qwiAABwp9J5JAJyalSiczsMQk0nyzXRX4xjBsUDyD02gAUJ X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-GUID: 56V1J62-m_T6q-D0Cg26jGmfM1fgbrMi X-Proofpoint-ORIG-GUID: 56V1J62-m_T6q-D0Cg26jGmfM1fgbrMi X-Authority-Analysis: v=2.4 cv=SumdKfO0 c=1 sm=1 tr=0 ts=69adcf47 cx=c_pps a=WW5sKcV1LcKqjgzy2JUPuA==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=fHHJEzlffGKYVby2EucA:9 a=QEXdDO2ut3YA:10 a=OpyuDcXvxspvyRM73sMx:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA4MDE4MSBTYWx0ZWRfX/Z3/dB57wGRU xC73AgcqlK1hyaaFW00qgwZfBUOGaQYClU/hzLRuUX6b2YGlXxFYFb2BdpiHTu9dQz4gkJlD/ft Tr5b02V8UvpIJg5hHUYfCiyNnjQJnfUIs0lbj00lS+q+6ly0m94Cy4MYZWuLi8CooKxZ4aUdvru RA6IGQSGrngZ24LzdWHIxwQJomPvFolNwlM8JKTuMLTF4GokkRqrjYZ4VdtZ2ZM/J3+J7Qb1322 QQe97Tj+eqHq3ZquQ5P50B9H4OZcqgt8jRmS6DPXMm5snKnFeiESbqZ1904Sx2h5BrzugH8J3N1 jEme79jQ9W0XA1Auu2RPHEUCRNEOO4iziwFBnABKizXRsAj7YW19/0hrDdbOsdn6bEd4WD0VjVU nJqn19fr33pZJqnvWkMr/IW4LtNElGEvyWoCdDzuSLiUkSZV9gTQxJ2cLrDoPURjt3PFVcbigR/ fmiBHdCm76LlnpVmTcA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-08_05,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 impostorscore=0 spamscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 clxscore=1015 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603080181 From: Charan Teja Kalla Change of_map_id() to take a pointer to struct of_phandle_args instead of passing target device node and translated IDs separately. Update all callers accordingly. Subsequent patch will make use of the args_count field in struct of_phandle_args. Suggested-by: Rob Herring (Arm) Signed-off-by: Charan Teja Kalla Signed-off-by: Vijayanand Jitta --- drivers/cdx/cdx_msi.c | 5 ++- drivers/iommu/of_iommu.c | 2 +- drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++-- drivers/of/base.c | 63 ++++++++++++++++---------------- drivers/of/irq.c | 8 +++- drivers/pci/controller/dwc/pci-imx6.c | 16 ++++++-- drivers/pci/controller/pcie-apple.c | 5 ++- drivers/xen/grant-dma-ops.c | 4 +- include/linux/of.h | 12 +++--- 9 files changed, 76 insertions(+), 50 deletions(-) diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c index 63b3544ec997..03232b5ffbca 100644 --- a/drivers/cdx/cdx_msi.c +++ b/drivers/cdx/cdx_msi.c @@ -121,6 +121,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, struct device *dev, int nvec, msi_alloc_info_t *info) { + struct of_phandle_args msi_spec = { .np = NULL }; struct cdx_device *cdx_dev = to_cdx_device(dev); struct device *parent = cdx_dev->cdx->dev; struct msi_domain_info *msi_info; @@ -128,11 +129,13 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, int ret; /* Retrieve device ID from requestor ID using parent device */ - ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, &msi_spec); if (ret) { dev_err(dev, "of_map_id failed for MSI: %d\n", ret); return ret; } + of_node_put(msi_spec.np); + dev_id = msi_spec.args[0]; #ifdef GENERIC_MSI_DOMAIN_OPS /* Set the device Id to be passed to the GIC-ITS */ diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index a511ecf21fcd..d255d0f58e8c 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct of_phandle_args iommu_spec = { .args_count = 1 }; int err; - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); + err = of_map_iommu_id(master_np, *id, &iommu_spec); if (err) return err; diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c index b63343a227a9..729fa2f9f758 100644 --- a/drivers/irqchip/irq-gic-its-msi-parent.c +++ b/drivers/irqchip/irq-gic-its-msi-parent.c @@ -152,6 +152,8 @@ static int its_v5_pci_msi_prepare(struct irq_domain *domain, struct device *dev, static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u32 *dev_id, phys_addr_t *pa) { + struct device_node *msi_ctrl __free(device_node) = NULL; + struct of_phandle_args msi_spec = { .np = NULL }; struct of_phandle_iterator it; int ret; @@ -178,9 +180,12 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u } } - struct device_node *msi_ctrl __free(device_node) = NULL; - - return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); + ret = of_map_msi_id(dev->of_node, dev->id, &msi_spec); + if (!ret) { + msi_ctrl = msi_spec.np; + *dev_id = msi_spec.args[0]; + } + return ret; } static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, diff --git a/drivers/of/base.c b/drivers/of/base.c index 959305a84748..b6e07c5fe715 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -2102,36 +2102,37 @@ int of_find_last_cache_level(unsigned int cpu) * @id: device ID to map. * @map_name: property name of the map to use. * @map_mask_name: optional property name of the mask to use. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. + * @arg: pointer to a &struct of_phandle_args. On input, @arg->np may be + * set to a target device node to match, or NULL to match any. On + * success, @arg->np will be set to the matched target node (with a + * reference held) and @arg->args[0] will contain the translated ID. * * Given a device ID, look up the appropriate implementation-defined * platform ID and/or the target device which receives transactions on that - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or - * @id_out may be NULL if only the other is required. If @target points to - * a non-NULL device node pointer, only entries targeting that node will be - * matched; if it points to a NULL value, it will receive the device node of - * the first matching target phandle, with a reference held. + * ID, as per the "iommu-map" and "msi-map" bindings. If @arg->np points to + * a non-NULL device node, only entries targeting that node will be matched; + * if it is NULL, it will receive the device node of the first matching + * target phandle, with a reference held. * * Return: 0 on success or a standard error code on failure. */ int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { u32 map_mask, masked_id; int map_len; const __be32 *map = NULL; - if (!np || !map_name || (!target && !id_out)) + if (!np || !map_name || !arg) return -EINVAL; map = of_get_property(np, map_name, &map_len); if (!map) { - if (target) + if (arg->np) return -ENODEV; /* Otherwise, no map implies no translation */ - *id_out = id; + arg->args[0] = id; return 0; } @@ -2173,18 +2174,15 @@ int of_map_id(const struct device_node *np, u32 id, if (!phandle_node) return -ENODEV; - if (target) { - if (*target) - of_node_put(phandle_node); - else - *target = phandle_node; + if (arg->np) + of_node_put(phandle_node); + else + arg->np = phandle_node; - if (*target != phandle_node) - continue; - } + if (arg->np != phandle_node) + continue; - if (id_out) - *id_out = masked_id - id_base + out_base; + arg->args[0] = masked_id - id_base + out_base; pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", np, map_name, map_mask, id_base, out_base, @@ -2193,11 +2191,10 @@ int of_map_id(const struct device_node *np, u32 id, } pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name, - id, target && *target ? *target : NULL); + id, arg->np); /* Bypasses translation */ - if (id_out) - *id_out = id; + arg->args[0] = id; return 0; } EXPORT_SYMBOL_GPL(of_map_id); @@ -2206,17 +2203,18 @@ EXPORT_SYMBOL_GPL(of_map_id); * of_map_iommu_id - Translate an ID using "iommu-map" bindings. * @np: root complex device node. * @id: device ID to map. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. + * @arg: pointer to a &struct of_phandle_args for the result. On success, + * @arg->np holds a reference to the target node that the caller must + * release with of_node_put(). * * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask". * * Return: 0 on success or a standard error code on failure. */ int of_map_iommu_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { - return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out); + return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); } EXPORT_SYMBOL_GPL(of_map_iommu_id); @@ -2224,16 +2222,17 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id); * of_map_msi_id - Translate an ID using "msi-map" bindings. * @np: root complex device node. * @id: device ID to map. - * @target: optional pointer to a target device node. - * @id_out: optional pointer to receive the translated ID. + * @arg: pointer to a &struct of_phandle_args for the result. On success, + * @arg->np holds a reference to the target node that the caller must + * release with of_node_put(). * * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask". * * Return: 0 on success or a standard error code on failure. */ int of_map_msi_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { - return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out); + return of_map_id(np, id, "msi-map", "msi-map-mask", arg); } EXPORT_SYMBOL_GPL(of_map_msi_id); diff --git a/drivers/of/irq.c b/drivers/of/irq.c index e37c1b3f8736..18248c3d76ae 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -817,8 +817,14 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in) * "msi-map" or an "msi-parent" property. */ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) { - if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out)) + struct of_phandle_args msi_spec = { .np = *msi_np }; + + if (!of_map_msi_id(parent_dev->of_node, id_in, &msi_spec)) { + id_out = msi_spec.args[0]; + if (!*msi_np && msi_spec.np) + *msi_np = msi_spec.np; break; + } if (!of_check_msi_parent(parent_dev->of_node, msi_np)) break; } diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index bff8289f804a..5f8a11774eb5 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -1137,6 +1137,8 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid) static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) { + struct of_phandle_args iommu_spec = { .np = NULL }; + struct of_phandle_args msi_spec = { .np = NULL }; struct device *dev = imx_pcie->pci->dev; struct device_node *target; u32 sid_i, sid_m; @@ -1144,7 +1146,12 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) u32 sid = 0; target = NULL; - err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i); + err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec); + if (!err_i) { + target = iommu_spec.np; + sid_i = iommu_spec.args[0]; + } + if (target) { of_node_put(target); } else { @@ -1156,8 +1163,11 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid) err_i = -EINVAL; } - target = NULL; - err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m); + err_m = of_map_msi_id(dev->of_node, rid, &msi_spec); + if (!err_m) { + target = msi_spec.np; + sid_m = msi_spec.args[0]; + } /* * err_m target diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c index a0937b7b3c4d..2e86f8fd300b 100644 --- a/drivers/pci/controller/pcie-apple.c +++ b/drivers/pci/controller/pcie-apple.c @@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d { u32 sid, rid = pci_dev_id(pdev); struct apple_pcie_port *port; + struct of_phandle_args iommu_spec = { .np = NULL }; int idx, err; port = apple_pcie_get_port(pdev); @@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d dev_dbg(&pdev->dev, "added to bus %s, index %d\n", pci_name(pdev->bus->self), port->idx); - err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid); + err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec); if (err) return err; + of_node_put(iommu_spec.np); + sid = iommu_spec.args[0]; mutex_lock(&port->pcie->lock); idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0); diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c index 1b7696b2d762..36547d7cf1d6 100644 --- a/drivers/xen/grant-dma-ops.c +++ b/drivers/xen/grant-dma-ops.c @@ -319,13 +319,13 @@ static int xen_dt_grant_init_backend_domid(struct device *dev, struct device_node *np, domid_t *backend_domid) { - struct of_phandle_args iommu_spec = { .args_count = 1 }; + struct of_phandle_args iommu_spec = { .np = NULL }; if (dev_is_pci(dev)) { struct pci_dev *pdev = to_pci_dev(dev); u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn); - if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) { + if (of_map_iommu_id(np, rid, &iommu_spec)) { dev_dbg(dev, "Cannot translate ID\n"); return -ESRCH; } diff --git a/include/linux/of.h b/include/linux/of.h index fe841f3cc747..f50d7a3a3b28 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -463,13 +463,13 @@ bool of_console_check(const struct device_node *dn, char *name, int index); int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out); + struct of_phandle_args *arg); int of_map_iommu_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out); + struct of_phandle_args *arg); int of_map_msi_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out); + struct of_phandle_args *arg); phys_addr_t of_dma_get_max_cpu_address(struct device_node *np); @@ -935,19 +935,19 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag static inline int of_map_id(const struct device_node *np, u32 id, const char *map_name, const char *map_mask_name, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { return -EINVAL; } static inline int of_map_iommu_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { return -EINVAL; } static inline int of_map_msi_id(const struct device_node *np, u32 id, - struct device_node **target, u32 *id_out) + struct of_phandle_args *arg) { return -EINVAL; } -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Sun Mar 08 19:34:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 08 Mar 2026 19:34:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249008.1546565 (Exim 4.92) (envelope-from ) id 1vzJtn-0004Es-7J; Sun, 08 Mar 2026 19:34:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249008.1546565; Sun, 08 Mar 2026 19:34:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtn-0004El-4M; Sun, 08 Mar 2026 19:34:47 +0000 Received: by outflank-mailman (input) for mailman id 1249008; Sun, 08 Mar 2026 19:34:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzJtl-0003hg-Gz for xen-devel@lists.xenproject.org; Sun, 08 Mar 2026 19:34:45 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dae3d967-1b25-11f1-9ccf-f158ae23cfc8; Sun, 08 Mar 2026 20:34:43 +0100 (CET) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6286exNW1519313 for ; Sun, 8 Mar 2026 19:34:42 GMT Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4crcd8axqv-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Sun, 08 Mar 2026 19:34:41 +0000 (GMT) Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-82983c9d78aso10365773b3a.2 for ; Sun, 08 Mar 2026 12:34:41 -0700 (PDT) Received: from hu-vjitta-hyd.qualcomm.com ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829a4676593sm7818909b3a.28.2026.03.08.12.34.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 12:34:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dae3d967-1b25-11f1-9ccf-f158ae23cfc8 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= pdnRU8Mu/D+Ngm/KfTZjC7mxZZbYL4Ii8ecgzHXdwuA=; b=Qn5FjJJTz3lhNSgk g+Xt+RefjAhFAGk8IMl3Nz87OMmFmqqVgGIlvCDYIYsIZ1R9wj2wP+84HY2GztvF F/FJSoE9BKC5iNrQxU2X1FnZiI9puYMJpYY2zNAl78Af4GzVoOgCfHARbzlpOL4Y tgqBoXCfvtz5rONb4E/I7j3AGf4MOeDtq/csOfsp4e3+F5hUoS5c14HkA0wJNNXK XL7vSzDw2uA2UJ6HwJDSJj9mYD3ZllkH8AmHZ7XJK5C+z9R9z7qeOSuv/QiNZisk i6ko4i8XVHP3aWdp5x21ymdYEDxk5bJUWXcNsLn/QWRrGC0NptqHrLYvkcd0LZrQ D1wT+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772998481; x=1773603281; darn=lists.xenproject.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=pdnRU8Mu/D+Ngm/KfTZjC7mxZZbYL4Ii8ecgzHXdwuA=; b=Kjgo3/TR3x11TOtVydQkDVR9BrXB5JcUr2w+HSy8uyJ+I6/sVTYEClxOeWe9evdZoH X1Rh3YDFzZGxGLATgJmS62xRsLsY/6SVhF/jFVsjS3eatH2C9R7bQ0YrFk2oiZ8/PDxr M0hznNaXw5/whVyS8oxKgDlzTxWwydBtbfBET4hSqrt7QA2c84JvzGl4hy8HwsWnSPLC XrWUiPYhjlZCSDSsSW10SM9wUviFb3So/VAnS64uq0wn+O9ysDcKR15NJkJTF0sdpiF8 dsfDp3UDDgPNH3NrEiDGndVFcGi9ozZU9PWlMqE9SnfUev0b5VvKn+/sakKU8lfNYncc UW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772998481; x=1773603281; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=pdnRU8Mu/D+Ngm/KfTZjC7mxZZbYL4Ii8ecgzHXdwuA=; b=xRoSy9F6HEIdboqdymB1c+oVxhh1v+B40T1fAbEdzi0zE7t5PVrFIvfaFsDlCMrWdd 5LrGj9QBaP2GV+bMddt8BEc46ECV+uEi7FzNwvoE+WRkQT+Ek5UliKars/W6dFzpbi4J 34TO1FD+Qf46niBbMPcUgf4Ad+kIPMopcuiVkWYFuspfKFYdIKDySdqSC35AQWJG5fbk XsAzHBk7c79GZdiilL4twimpPtN64ANc/GFhxsCe9X73YgqOw6p5WVCeo7GBAxSzwcve PAUhkDUHTcfE+EjnAujL0n7r9K7IUzNq3Jv+LBSzcQlh5Uj8d9jVIe//WhPTbQeIrOiJ SCig== X-Forwarded-Encrypted: i=1; AJvYcCXG7a6PBMNAK1MSLwzyTShkde6+SGStDZWcP6UrQc82MOAFMgy26SAYLAFqVqqsnWreqbhGTRQWSG4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzt6BPKjajRPkLZJ4Xrr3/nrFj5B8QXCuIzN9BNTUTPzIFo8cCP 8DejTGGg7Y6gGLX/kMyaJ8/NB+KbWQFgJt+9rbLY0QFPavhwGjTMAT7MfAR67kIRfk5U6FGQUcE vTCWjAwSwDCrJHj0d1eJGpNCZ9qAQgd2zl2VSDSYGWS/oDMdBPNLJyxNi7brjrkQjSJ903w== X-Gm-Gg: ATEYQzwx/pAPzk0cqsufRPcCqvCqTKiFyYlM+xPAfgIvF87h/UPD3NnHUoE1Kl0kq8Q 7+cdj4nxtb6H2YMszTweYtXbsQv4nkzSPpI8NhAWosZrdWm2P2uizfjkwa7E+kq9ATmXPdkOGIM 8Sf4B1MOFCYwAatbSe6Rbc2WMaI0T5+bNdoyOKVy4j3N7yWieBbIdKhFEWNA4Xm4oVlJTYpxL8l KkxtZ7IA/2OQsBsoB/K32n7+EcwVlt8AN1TV+pycMA2AZuKn7Vib/k7gpbTLMqqTj/lWw6z6+za 7LEm+oAHG2ko/qTndbo+dKn1gVp/dOXzw8yp5U++PHeHvV8oaHmPu2bAwmKLtfUk/AkOm2zjh/R pjiKE1nCLTczaxHZ4Kg0zLwcJkzt0WIn3VkabJZxOhL8MQgfw3OiN3KR6 X-Received: by 2002:a05:6a00:7483:b0:829:710d:a46b with SMTP id d2e1a72fcca58-829a2f7b48emr7158305b3a.41.1772998480883; Sun, 08 Mar 2026 12:34:40 -0700 (PDT) X-Received: by 2002:a05:6a00:7483:b0:829:710d:a46b with SMTP id d2e1a72fcca58-829a2f7b48emr7158286b3a.41.1772998480388; Sun, 08 Mar 2026 12:34:40 -0700 (PDT) From: Vijayanand Jitta Date: Mon, 09 Mar 2026 01:03:39 +0530 Subject: [PATCH v10 3/3] of: Respect #{iommu,msi}-cells in maps MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260309-parse_iommu_cells-v10-3-c62fcaa5a1d8@oss.qualcomm.com> References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> In-Reply-To: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> To: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Vijayanand Jitta , Charan Teja Kalla X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1772998436; l=10158; i=vijayanand.jitta@oss.qualcomm.com; s=20260301; h=from:subject:message-id; bh=Y3y9pnEGS/egnRkn7PRxW9/ZOSrIlXJJq3NDQFYUkD4=; b=JZchFxd3ySsovmwflK1CY4cBpmFZDZuap26lOuWwIhv+ZaGNWH/gkD4Mmfup1E8EbC1OrXdH4 VkkiDPdY1+8At/dTkuN9k5uBn4Rr7Byfuai9q397xPmXXKr22BEBwBT X-Developer-Key: i=vijayanand.jitta@oss.qualcomm.com; a=ed25519; pk=Lpi7Cs3wHe8KZtqvyci7FTOLzsKpEHKGCaPNZw+1zRI= X-Proofpoint-ORIG-GUID: rAqveGw91SEypSAsSTClqs5-1YdkwrYc X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA4MDE4MSBTYWx0ZWRfX4U33t7S8rava xhtu05KdxPmtfwh9t2JOMvSeEjT31Nsrv8pcnck49unloq10KcHvAtlcYuH9vQFdflV8KoFJ0+V F3iwuDZxMtJ3KU22IZGigrQ1j26XgiqkdBhT0CumV0pZB7gRFGFbCGVxUgRNxCnUPzT6aTGMB9z HEcEPdzYq2KjTjquOdiJwDl8Fm8+P+G5z+h2AVadwi+J8GzWbL5ERXNkt+a01sIdQT92x54aKBq vmhBdCY7PoV/OklhXLf1HkNB7SZp70UJ29jpyL7TgFTAF99Mzz/eXsd3qB0SBSC7w1jx3y5s1HB Bj5eyQirpCQxsfhfncvxyv8UcgXHmHCRAV1GgXq5ZKbPYPfvrgSAyszCTmdX+zhePbFJTX3Rb1T W5VZQvUN5+T3DOLlM0rRoIPTXmKAsA61oWcBjWycido+8nV3nbFmN4gdr1JlvoWDJ83gczsSa2v 5sQ1JMumDw8tFEahNHw== X-Authority-Analysis: v=2.4 cv=O/w0fR9W c=1 sm=1 tr=0 ts=69adcf51 cx=c_pps a=m5Vt/hrsBiPMCU0y4gIsQw==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=7CQSdrXTAAAA:8 a=EUspDBNiAAAA:8 a=wJGdY9mNwEi-N7fqGJcA:9 a=QEXdDO2ut3YA:10 a=IoOABgeZipijB_acs4fv:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-GUID: rAqveGw91SEypSAsSTClqs5-1YdkwrYc X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-08_05,2026-03-06_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1015 spamscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 impostorscore=0 bulkscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603080181 From: Robin Murphy So far our parsing of {iommu,msi}-map properites has always blindly assumed that the output specifiers will always have exactly 1 cell. This typically does happen to be the case, but is not actually enforced (and the PCI msi-map binding even explicitly states support for 0 or 1 cells) - as a result we've now ended up with dodgy DTs out in the field which depend on this behaviour to map a 1-cell specifier for a 2-cell provider, despite that being bogus per the bindings themselves. Since there is some potential use in being able to map at least single input IDs to multi-cell output specifiers (and properly support 0-cell outputs as well), add support for properly parsing and using the target nodes' #cells values, albeit with the unfortunate complication of still having to work around expectations of the old behaviour too. Since there are multi-cell output specifiers, the callers of of_map_id() may need to get the exact cell output value for further processing. Added support for that part --charan Signed-off-by: Robin Murphy Signed-off-by: Charan Teja Kalla Signed-off-by: Vijayanand Jitta --- drivers/iommu/of_iommu.c | 2 +- drivers/of/base.c | 129 ++++++++++++++++++++++++++++++++++++++--------- include/linux/of.h | 6 ++- 3 files changed, 109 insertions(+), 28 deletions(-) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index d255d0f58e8c..a18bb60f6f3d 100644 --- a/drivers/iommu/of_iommu.c +++ b/drivers/iommu/of_iommu.c @@ -45,7 +45,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, struct device *dev, const u32 *id) { - struct of_phandle_args iommu_spec = { .args_count = 1 }; + struct of_phandle_args iommu_spec = {}; int err; err = of_map_iommu_id(master_np, *id, &iommu_spec); diff --git a/drivers/of/base.c b/drivers/of/base.c index b6e07c5fe715..9c44eb6d445d 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -2096,16 +2096,46 @@ int of_find_last_cache_level(unsigned int cpu) return cache_level; } +/* + * Some DTs have an iommu-map targeting a 2-cell IOMMU node while + * specifying only 1 cell. Fortunately they all consist of value '1' + * as the 2nd cell entry with the same target, so check for that pattern. + * + * Example: + * IOMMU node: + * #iommu-cells = <2>; + * + * Device node: + * iommu-map = <0x0000 &smmu 0x0000 0x1>, + * <0x0100 &smmu 0x0100 0x1>; + */ +static bool of_check_bad_map(const __be32 *map, int len) +{ + __be32 phandle = map[1]; + + if (len % 4) + return false; + for (int i = 0; i < len; i += 4) { + if (map[i + 1] != phandle || map[i + 3] != cpu_to_be32(1)) + return false; + } + return true; +} + /** * of_map_id - Translate an ID through a downstream mapping. * @np: root complex device node. * @id: device ID to map. * @map_name: property name of the map to use. + * @cells_name: property name of target specifier cells. * @map_mask_name: optional property name of the mask to use. * @arg: pointer to a &struct of_phandle_args. On input, @arg->np may be * set to a target device node to match, or NULL to match any. On * success, @arg->np will be set to the matched target node (with a - * reference held) and @arg->args[0] will contain the translated ID. + * reference held), @arg->args_count will be set to the number of + * output specifier cells as defined by @cells_name in the target node, + * and @arg->args[0..args_count-1] will contain the translated output + * specifier values. * * Given a device ID, look up the appropriate implementation-defined * platform ID and/or the target device which receives transactions on that @@ -2117,17 +2147,19 @@ int of_find_last_cache_level(unsigned int cpu) * Return: 0 on success or a standard error code on failure. */ int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, + const char *map_name, const char *cells_name, + const char *map_mask_name, struct of_phandle_args *arg) { u32 map_mask, masked_id; - int map_len; + int map_bytes, map_len, offset = 0; + bool bad_map = false; const __be32 *map = NULL; if (!np || !map_name || !arg) return -EINVAL; - map = of_get_property(np, map_name, &map_len); + map = of_get_property(np, map_name, &map_bytes); if (!map) { if (arg->np) return -ENODEV; @@ -2136,11 +2168,9 @@ int of_map_id(const struct device_node *np, u32 id, return 0; } - if (!map_len || map_len % (4 * sizeof(*map))) { - pr_err("%pOF: Error: Bad %s length: %d\n", np, - map_name, map_len); - return -EINVAL; - } + if (map_bytes % sizeof(*map)) + goto err_map_len; + map_len = map_bytes / sizeof(*map); /* The default is to select all bits. */ map_mask = 0xffffffff; @@ -2153,27 +2183,69 @@ int of_map_id(const struct device_node *np, u32 id, of_property_read_u32(np, map_mask_name, &map_mask); masked_id = map_mask & id; - for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) { + + while (offset < map_len) { struct device_node *phandle_node; - u32 id_base = be32_to_cpup(map + 0); - u32 phandle = be32_to_cpup(map + 1); - u32 out_base = be32_to_cpup(map + 2); - u32 id_len = be32_to_cpup(map + 3); + u32 id_base, phandle, id_len, id_off, cells = 0; + const __be32 *out_base; + + if (map_len - offset < 2) + goto err_map_len; + + id_base = be32_to_cpup(map + offset); if (id_base & ~map_mask) { - pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n", - np, map_name, map_name, - map_mask, id_base); + pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n", + np, map_name, map_mask_name, map_mask, id_base); return -EFAULT; } - if (masked_id < id_base || masked_id >= id_base + id_len) - continue; - + phandle = be32_to_cpup(map + offset + 1); phandle_node = of_find_node_by_phandle(phandle); if (!phandle_node) return -ENODEV; + if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) { + pr_err("%pOF: missing %s property\n", phandle_node, cells_name); + of_node_put(phandle_node); + return -EINVAL; + } + + if (map_len - offset < 3 + cells) { + of_node_put(phandle_node); + goto err_map_len; + } + + if (offset == 0 && cells == 2) { + bad_map = of_check_bad_map(map, map_len); + if (bad_map) { + pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n", + np, map_name, cells_name); + cells = 1; + } + } + + out_base = map + offset + 2; + offset += 3 + cells; + + id_len = be32_to_cpup(map + offset - 1); + if (id_len > 1 && cells > 1) { + /* + * With 1 output cell we reasonably assume its value + * has a linear relationship to the input; with more, + * we'd need help from the provider to know what to do. + */ + pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n", + np, map_name, id_len, cells); + of_node_put(phandle_node); + return -EINVAL; + } + id_off = masked_id - id_base; + if (masked_id < id_base || id_off >= id_len) { + of_node_put(phandle_node); + continue; + } + if (arg->np) of_node_put(phandle_node); else @@ -2182,11 +2254,14 @@ int of_map_id(const struct device_node *np, u32 id, if (arg->np != phandle_node) continue; - arg->args[0] = masked_id - id_base + out_base; + for (int i = 0; i < cells; i++) + arg->args[i] = (id_off + be32_to_cpu(out_base[i])); + + arg->args_count = cells; pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", - np, map_name, map_mask, id_base, out_base, - id_len, id, masked_id - id_base + out_base); + np, map_name, map_mask, id_base, be32_to_cpup(out_base), + id_len, id, id_off + be32_to_cpup(out_base)); return 0; } @@ -2196,6 +2271,10 @@ int of_map_id(const struct device_node *np, u32 id, /* Bypasses translation */ arg->args[0] = id; return 0; + +err_map_len: + pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes); + return -EINVAL; } EXPORT_SYMBOL_GPL(of_map_id); @@ -2214,7 +2293,7 @@ EXPORT_SYMBOL_GPL(of_map_id); int of_map_iommu_id(const struct device_node *np, u32 id, struct of_phandle_args *arg) { - return of_map_id(np, id, "iommu-map", "iommu-map-mask", arg); + return of_map_id(np, id, "iommu-map", "#iommu-cells", "iommu-map-mask", arg); } EXPORT_SYMBOL_GPL(of_map_iommu_id); @@ -2233,6 +2312,6 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id); int of_map_msi_id(const struct device_node *np, u32 id, struct of_phandle_args *arg) { - return of_map_id(np, id, "msi-map", "msi-map-mask", arg); + return of_map_id(np, id, "msi-map", "#msi-cells", "msi-map-mask", arg); } EXPORT_SYMBOL_GPL(of_map_msi_id); diff --git a/include/linux/of.h b/include/linux/of.h index f50d7a3a3b28..953f2dbe0e86 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -462,7 +462,8 @@ const char *of_prop_next_string(const struct property *prop, const char *cur); bool of_console_check(const struct device_node *dn, char *name, int index); int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, + const char *map_name, const char *cells_name, + const char *map_mask_name, struct of_phandle_args *arg); int of_map_iommu_id(const struct device_node *np, u32 id, @@ -934,7 +935,8 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag } static inline int of_map_id(const struct device_node *np, u32 id, - const char *map_name, const char *map_mask_name, + const char *map_name, const char *cells_name, + const char *map_mask_name, struct of_phandle_args *arg) { return -EINVAL; -- 2.34.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:44:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:44:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249072.1546584 (Exim 4.92) (envelope-from ) id 1vzUMB-0005Xc-4h; Mon, 09 Mar 2026 06:44:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249072.1546584; Mon, 09 Mar 2026 06:44:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMB-0005XV-0x; Mon, 09 Mar 2026 06:44:47 +0000 Received: by outflank-mailman (input) for mailman id 1249072; Mon, 09 Mar 2026 06:44:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUM9-0005KI-60 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:45 +0000 Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [2607:f8b0:4864:20::a2e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 747b748a-1b83-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 07:44:44 +0100 (CET) Received: by mail-vk1-xa2e.google.com with SMTP id 71dfb90a1353d-56aff27dfebso2857451e0c.1 for ; Sun, 08 Mar 2026 23:44:44 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56b0f889ed2sm7456162e0c.13.2026.03.08.23.44.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 747b748a-1b83-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038683; x=1773643483; 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; bh=mAku/l+conV0dggG+e6fwfk6f4KYUT5yoO6o2dEMQkk=; b=ifaCFTUoh0bWUgGGEo59P3yNBaR0u2d9CU1x9N8zlxiBFQAyfvwmi985O6VHwJb32q 8yxh4chSBmhgGbgGwi5GnGtI8LeDHn99VVHsUX0/jmsgPXmlKTF32OnQL2xh58G0JREX xYBdp4ezxsHeipxqB8usIQMK56YtoQFqTLFufREAD7Ew3mCw3qKAzxzQtsvTyxQCNsep NcnZ+jFrE6Szq2w4y+yEF0UERAdgCSmus7F2E0j/tGSuAYhBRWJ36jdhdqG9IJq2xSSO YNsfDQMUnhNUqMga14kZ4zYL3502KdiDVsIQcK9UgsKxP5eTfMzL+LiK3TdSOWdoJfZM n5IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038683; x=1773643483; 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; bh=mAku/l+conV0dggG+e6fwfk6f4KYUT5yoO6o2dEMQkk=; b=eQqAZ+KiuTwY1uur9OqXH3uF+KBREmOTxjdgKgyxHtS6YcndQHEteFXZ8zGq+SBxRZ 0/7U9UaFYmQEyJeLziKP+ihQA03pC7fsDMJ1zjTSHujVYzacnTtL4beqmFTkBE79xniz cuYndfln8znfmGyDLLEBf2DWyAdYOtjw/4NR4E9t96hTF9D9HWtU9AiotsxSY1Qrj8I8 Yr1rVZe2sBFkjpNJ3OfME14NggB9KlG93+HaewF7J6TW+yensbWkA+t5O0e+2GhzHxx7 ebBs88vNaw5v6JruJ4y7TFEg9t68oqv4O/7GsRXzxc3WIA5yCgWfaxb3oeuCljTWGUFu jRHQ== X-Forwarded-Encrypted: i=1; AJvYcCWHggVAHUAFGnhGl7LrR2Xy0cciFFG6AQVF41frHPh1TpgwLRkhKPtNRQ9foJeQc7XWY09LmhobwBE=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywm4GAErjMy9KNsSMRtdaQeBAG+d7EXeRiwnCC3tNtE5654bDrP ra9g5qhDaoOnEs+J3aV8S97lKoJkAUE0HWRvOHRAaBkwuL1ayRl2ykI8 X-Gm-Gg: ATEYQzxBNhLBscHLsZ/G5eeWI9rUoaNVzbVQs+9ZkHOWGG0cfr841DZhZmXZqaznH0x LggYIolVBZxO/89DMZMbhmVBeNf7ovWuG4rl81clX9FOPqlOKY+tAIfTYB/WDohKC/VAXI7iqPu iDQqi9rljxPAQWo11w8ANIqjFtssunB/ihJgmLvmiOqWS0gA5WTIryNIRdceVVO//RREACye1z6 VPt/OoxHmZE0ASZhaxq+D2ziaAfrrcrZJk/5ohBEELCWEu8ll/gDQ/X6UFZ1jfP03VaJzbVsQbc pTY0AL0EdXKuPOQbznFNlzpQOIfiGw3Bv293OJqAWpVZGXoH+PokgEhdliYEfkpADxCH0dkduqr 41muaSpVb6Tro0Cmmb7VqCyIa2g1sQ1b26lZiizJPunHzFdI3OyhvIIa4ZzBF4UF6qVlle+vfgp NsFRL74B3j5sFutLXfePz8HK03SvvH27/wSzXVKg478e/bPrwvpLWmRueGAIe/6hH/t/07 X-Received: by 2002:a05:6122:e46e:b0:567:433b:e903 with SMTP id 71dfb90a1353d-56b07d79ffcmr4232283e0c.6.1773038682868; Sun, 08 Mar 2026 23:44:42 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 1/5] xen: mapcache: Assert mapcache existance Date: Mon, 9 Mar 2026 07:44:31 +0100 Message-ID: <20260309064436.51860-2-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> References: <20260309064436.51860-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Assert that the mapcache was created prior to being used. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini --- hw/xen/xen-mapcache.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index 11115f6084..517e5171b7 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -464,6 +464,8 @@ uint8_t *xen_map_cache(MemoryRegion *mr, MapCache *mc = mapcache; uint8_t *p; + assert(mapcache); + if (grant) { mc = is_write ? mapcache_grants_rw : mapcache_grants_ro; } @@ -530,6 +532,8 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr) { ram_addr_t addr; + assert(mapcache); + addr = xen_ram_addr_from_mapcache_single(mapcache, ptr); if (addr == RAM_ADDR_INVALID) { addr = xen_ram_addr_from_mapcache_single(mapcache_grants_ro, ptr); @@ -652,6 +656,8 @@ static void xen_invalidate_map_cache_entry_bh(void *opaque) void coroutine_mixed_fn xen_invalidate_map_cache_entry(uint8_t *buffer) { + assert(mapcache); + if (qemu_in_coroutine()) { XenMapCacheData data = { .co = qemu_coroutine_self(), @@ -709,6 +715,8 @@ static void xen_invalidate_map_cache_single(MapCache *mc) void xen_invalidate_map_cache(void) { + assert(mapcache); + /* Flush pending AIO before destroying the mapcache */ bdrv_drain_all(); @@ -776,6 +784,8 @@ uint8_t *xen_replace_cache_entry(hwaddr old_phys_addr, { uint8_t *p; + assert(mapcache); + mapcache_lock(mapcache); p = xen_replace_cache_entry_unlocked(mapcache, old_phys_addr, new_phys_addr, size); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249077.1546619 (Exim 4.92) (envelope-from ) id 1vzUMM-0006XK-85; Mon, 09 Mar 2026 06:44:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249077.1546619; Mon, 09 Mar 2026 06:44:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMM-0006X6-39; Mon, 09 Mar 2026 06:44:58 +0000 Received: by outflank-mailman (input) for mailman id 1249077; Mon, 09 Mar 2026 06:44:56 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMK-0005KI-Ot for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:56 +0000 Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [2607:f8b0:4864:20::a2a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7bbb3518-1b83-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 07:44:56 +0100 (CET) Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-56b17c0223bso628832e0c.1 for ; Sun, 08 Mar 2026 23:44:56 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56b0f889ed2sm7456276e0c.13.2026.03.08.23.44.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7bbb3518-1b83-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038695; x=1773643495; 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; bh=OcNC0yip2XrDmFo80yDxRtX2oleYkrUeo7InlE7zv9I=; b=LOU2YxLCDKLnQ2zAkCvHD/pWl1L/yiN5wh/KZrOhuosRRV6Dlk06GcFyFuKxi9uY4G BtEd4+CCF/iCRgqR6//5255EdBWolK3+U+JefJ2xd+z1u5qAlt7kBE4BLTxzNWaXf1UR +aCVzd7YKJTb4dxSG0ELron77q58brXjkThM1/c6z1p7zKvlIGbjI1LP/cF8IwuZ8u1Y VNiFzwuYLY/MBLMjDi3SKMBoqMj17EsTVr2grb/v02t0yHOItL1NmHwHgu9tzngk/mOj ZaQ1mcxFxJ64rNRRPteW6vNs9igfsagsYHr6hXYhb+TEc8l6wggexPJwLzGDz04UhXAm LhHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038695; x=1773643495; 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; bh=OcNC0yip2XrDmFo80yDxRtX2oleYkrUeo7InlE7zv9I=; b=lFycrzStSpHtu6QESel7ijcs69+6UobIFBI9FRRMrGDKIkO/2tafy/e/QqPmd4yOEA 2KAV8okzNuZkz01SnYIdEe2xOENADMcy2EBaSIc12WSsbz5NR8HzS1Y2mrDCGnjoeNht 0FAw3RSVenQd3gGj+HveYxM9shNDZ974bJn5W4So+aqYQ1ctntFVYG0bZEHeckhbA8aM TkybhhOUOn2EaHTMvt9w1kh78RVh1BRTx0PrS+OLgqhFvnNEnOmjvVUBSxOUi65FkAZD dddyvjNt9NOGt63Xa2PHjJxmDyQUHfbLIBmZyWpytnPJdij4E+PpHxMkedMD1eAWBGuF AHhA== X-Forwarded-Encrypted: i=1; AJvYcCV5tqO9ECmP7BG5DFNlRKMP7Ewg9W9nz9kQflEVfNom8DvqjPFtDjW7sb8NkYg7ng6y7saOzbamtX0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz+GwncYEgp9VPlIxwkm10wTTP8Nz0Zn9RVaUF0sBDGje4lzcsi ZHt37xGSjicPiff7AjrrmKD8qJcDMyVwjNPWSxe+UOzbAQCk9cGiQtnhv63/akyJ X-Gm-Gg: ATEYQzxZmSMI3j8BrIi3r6zbT77SuvXDGuF+teBXjYj8Pf/33t9gBQqkiiPUQ5jOuei omrGDh/EaLxLc3WkKYI0m8gJhyRi3MSWUIRPyjKuX4uur4zOSObeJbo+fPyGWUSRY72p4pAW9mV SX2jKsY/5TSU2br6d+MhjB++IIaWwYwsOlSHaXzfRl3pFzcTE2a2fbXDH+orbZ0PSAzhYCQ+KC5 BpnYttgCBP2+3B7mk/JpMkzVcLhZzw/eGeBkV01bjLH2wmv4f/r7LwrUzl0JTRbcD4DwmCqMd0b ADMg4Z+o03hsUdrs1gWdma/GvWrPrhds0w7UdyAIxalExCKoWPY0R8Akft+Xz8chbIPHmHHsH6M rBFyqgnUHQ7Vj7CmZmQiEPnJbqsyOD8F3V8QDhApkhlVpbHL0LF2VTyHb5DJey3G96NVynVNbHO 5BZnecX9UnvG9afU3pmIv+gq5/0iXxt/s4ixOemZVa2yyz6FUHyxPcdQrLTw== X-Received: by 2002:a05:6122:1c0a:b0:567:4722:66a3 with SMTP id 71dfb90a1353d-56b07da5535mr3763057e0c.8.1773038695019; Sun, 08 Mar 2026 23:44:55 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 5/5] hw/xen: xenpvh: Add prop to enable/disable the mapcache Date: Mon, 9 Mar 2026 07:44:35 +0100 Message-ID: <20260309064436.51860-6-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> References: <20260309064436.51860-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add a machine property to enable/disable the mapcache. Default it to enabled for backwards compatibility. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini --- hw/xen/xen-pvh-common.c | 133 +++++++++++++++++++++++++++++--- include/hw/xen/xen-pvh-common.h | 2 + 2 files changed, 124 insertions(+), 11 deletions(-) diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index 4fade017bb..cca37202ff 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -29,6 +29,69 @@ static const MemoryListener xen_memory_listener = { .priority = MEMORY_LISTENER_PRIORITY_ACCEL, }; +/* + * Map foreign RAM in bounded chunks so we don't build a PFN array for the + * entire guest size (which can be huge for large guests). We reserve a VA + * range once and then MAP_FIXED each chunk into place. + */ +#define XEN_PVH_MAP_CHUNK_PAGES 65535 + +static void *xen_map_guest_ram(XenPVHMachineState *s, + uint64_t addr, uint64_t size) +{ + size_t total_pages = size >> XC_PAGE_SHIFT; + size_t chunk_pages = MIN(XEN_PVH_MAP_CHUNK_PAGES, total_pages); + g_autofree xen_pfn_t *pfns = NULL; + void *base = NULL; + size_t offset; + + if (!total_pages) { + goto done; + } + + base = mmap(NULL, size, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (base == MAP_FAILED) { + base = NULL; + goto done; + } + + pfns = g_new0(xen_pfn_t, chunk_pages); + if (!pfns) { + munmap(base, size); + base = NULL; + goto done; + } + + for (offset = 0; offset < total_pages; offset += chunk_pages) { + size_t num_pages = MIN(chunk_pages, total_pages - offset); + void *mapped; + size_t i; + + for (i = 0; i < num_pages; i++) { + pfns[i] = (addr >> XC_PAGE_SHIFT) + offset + i; + } + + mapped = xenforeignmemory_map2( + xen_fmem, xen_domid, + (uint8_t *)base + (offset << XC_PAGE_SHIFT), + PROT_READ | PROT_WRITE, MAP_FIXED, + num_pages, pfns, NULL); + if (!mapped) { + munmap(base, size); + base = NULL; + goto done; + } + } +done: + if (!base) { + /* We can't recover from this. */ + error_report("FATAL: Failed to foreign-map %" PRIx64 " - %" PRIx64, + addr, addr + size); + exit(EXIT_FAILURE); + } + return base; +} + static void xen_pvh_init_ram(XenPVHMachineState *s, MemoryRegion *sysmem) { @@ -45,22 +108,42 @@ static void xen_pvh_init_ram(XenPVHMachineState *s, block_len = s->cfg.ram_high.base + ram_size[1]; } - memory_region_init_ram(&xen_memory, NULL, "xen.ram", block_len, - &error_fatal); + if (s->cfg.mapcache) { + memory_region_init_ram(&xen_memory, NULL, "xen.ram", + block_len, &error_fatal); + memory_region_init_alias(&s->ram.low, NULL, "xen.ram.lo", &xen_memory, + s->cfg.ram_low.base, ram_size[0]); + if (ram_size[1] > 0) { + memory_region_init_alias(&s->ram.high, NULL, "xen.ram.hi", + &xen_memory, + s->cfg.ram_high.base, ram_size[1]); + } + } else { + void *p; + + p = xen_map_guest_ram(s, s->cfg.ram_low.base, ram_size[0]); + memory_region_init_ram_ptr(&s->ram.low, NULL, "xen.ram.lo", + ram_size[0], p); + if (ram_size[1] > 0) { + p = xen_map_guest_ram(s, s->cfg.ram_high.base, ram_size[1]); + memory_region_init_ram_ptr(&s->ram.high, NULL, "xen.ram.hi", + ram_size[1], p); + } + } - memory_region_init_alias(&s->ram.low, NULL, "xen.ram.lo", &xen_memory, - s->cfg.ram_low.base, ram_size[0]); + /* Map them onto QEMU's address-space. */ memory_region_add_subregion(sysmem, s->cfg.ram_low.base, &s->ram.low); if (ram_size[1] > 0) { - memory_region_init_alias(&s->ram.high, NULL, "xen.ram.hi", &xen_memory, - s->cfg.ram_high.base, ram_size[1]); memory_region_add_subregion(sysmem, s->cfg.ram_high.base, &s->ram.high); } - /* Setup support for grants. */ - memory_region_init_ram(&xen_grants, NULL, "xen.grants", block_len, - &error_fatal); - memory_region_add_subregion(sysmem, XEN_GRANT_ADDR_OFF, &xen_grants); + /* Grants are only supported when the mapcache is on. */ + if (s->cfg.mapcache) { + /* Setup support for grants. */ + memory_region_init_ram(&xen_grants, NULL, "xen.grants", block_len, + &error_fatal); + memory_region_add_subregion(sysmem, XEN_GRANT_ADDR_OFF, &xen_grants); + } } static void xen_set_irq(void *opaque, int irq, int level) @@ -203,7 +286,7 @@ static void xen_pvh_init(MachineState *ms) xen_register_ioreq(&s->ioreq, ms->smp.max_cpus, xpc->handle_bufioreq, &xen_memory_listener, - true); + s->cfg.mapcache); if (s->cfg.virtio_mmio_num) { xen_create_virtio_mmio_devices(s); @@ -285,6 +368,20 @@ XEN_PVH_PROP_MEMMAP(pci_ecam) XEN_PVH_PROP_MEMMAP(pci_mmio) XEN_PVH_PROP_MEMMAP(pci_mmio_high) +static void xen_pvh_set_mapcache(Object *obj, bool value, Error **errp) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + xp->cfg.mapcache = value; +} + +static bool xen_pvh_get_mapcache(Object *obj, Error **errp) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + return xp->cfg.mapcache; +} + static void xen_pvh_set_pci_intx_irq_base(Object *obj, Visitor *v, const char *name, void *opaque, Error **errp) @@ -338,6 +435,12 @@ do { \ OC_MEMMAP_PROP_SIZE(c, prop_name, name); \ } while (0) + object_class_property_add_bool(oc, "mapcache", xen_pvh_get_mapcache, + xen_pvh_set_mapcache); + object_class_property_set_description(oc, "mapcache", + "Set on/off to enable/disable the " + "mapcache"); + /* * We provide memmap properties to allow Xen to move things to other * addresses for example when users need to accomodate the memory-map @@ -377,6 +480,13 @@ do { \ #endif } +static void xen_pvh_instance_init(Object *obj) +{ + XenPVHMachineState *xp = XEN_PVH_MACHINE(obj); + + xp->cfg.mapcache = true; +} + static void xen_pvh_class_init(ObjectClass *oc, const void *data) { MachineClass *mc = MACHINE_CLASS(oc); @@ -395,6 +505,7 @@ static const TypeInfo xen_pvh_info = { .parent = TYPE_MACHINE, .abstract = true, .instance_size = sizeof(XenPVHMachineState), + .instance_init = xen_pvh_instance_init, .class_size = sizeof(XenPVHMachineClass), .class_init = xen_pvh_class_init, }; diff --git a/include/hw/xen/xen-pvh-common.h b/include/hw/xen/xen-pvh-common.h index 0ed07c5694..0209b798f3 100644 --- a/include/hw/xen/xen-pvh-common.h +++ b/include/hw/xen/xen-pvh-common.h @@ -84,6 +84,8 @@ struct XenPVHMachineState { /* PCI */ MemMapEntry pci_ecam, pci_mmio, pci_mmio_high; uint32_t pci_intx_irq_base; + + bool mapcache; } cfg; }; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249074.1546601 (Exim 4.92) (envelope-from ) id 1vzUMF-0005z4-He; Mon, 09 Mar 2026 06:44:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249074.1546601; Mon, 09 Mar 2026 06: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 ) id 1vzUMF-0005yt-EL; Mon, 09 Mar 2026 06:44:51 +0000 Received: by outflank-mailman (input) for mailman id 1249074; Mon, 09 Mar 2026 06:44:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUME-0005KI-QK for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:50 +0000 Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [2607:f8b0:4864:20::a36]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7811c53a-1b83-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 07:44:50 +0100 (CET) Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-56affe9f4c4so1330781e0c.2 for ; Sun, 08 Mar 2026 23:44:50 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56b09a2614fsm9529782e0c.7.2026.03.08.23.44.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:47 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7811c53a-1b83-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038689; x=1773643489; 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; bh=a2tMEsPmEaiHyXknwk29SjcZVAaayzKi1p57s2lEHB0=; b=mW5Pe+2jWCfCSoNVatxLSZaJ4edjNDz9JE8VMdeodAgPrMiiGgrpOGwnVkBHtJfhGn salNlGFW3yF8gOnoJG03fXmP/n16y63jTxl5qPeQLYqoVRFlM3TblWZvCCB+owUz563E atgBH9HmnhY9WYHvSIwOYQlPSsXCxv1EkOIj/z14laDo2Eh7vtjXECO3hQPe0zgchsK0 JSyxjMCEU0KPn+dDMhjvqYuywFElO68PmLnkBW6OM073Ab41mwAC+Dq6TTZtKZ5bNbrE xuG6vM+rFn3kbnZdxiyofHN80aQPFhTGD7qwjgMCH56CvJJ0p8Adm5tHnizITFmuIA77 s0uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038689; x=1773643489; 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; bh=a2tMEsPmEaiHyXknwk29SjcZVAaayzKi1p57s2lEHB0=; b=D0pWStxgUu9g+wry4OsbfrP8BCaHNt+oTKB7phyWzKVeMOis0FRCgC/5H1VRiw+mjd ZiWlNtleV7xqXINxn3DTf+cjVbDJvVok8IROvG+gH00vRRa0HqX0Fh5hv8H8iX4yY6Rc KdRCUG5i2x0UJnlcdRtQnHtztSJjC41F/2EvcsHfAcHFM8wmmTHUk9sUDEL/+672ayNb mnJ54OdQKLk5IHr/berroeJDsq9l0pUGJtmJM1Ae/KL7R8wWs3RrIPPgNaHWk8bSIJwd rG7MrjTLIMFBbh8pIRTFMHQTxBT3elWQwrYgQCcK9ftL6xrv4Kho8diUEbQ4IvG0eVtr +syw== X-Forwarded-Encrypted: i=1; AJvYcCXq/OYY8LNVgV8zHWXZvU01H0A0b4LvG6Tb56MDHL8bdlGQgpJI6zhjfriO6DRX96RIan3xTXzmcyk=@lists.xenproject.org X-Gm-Message-State: AOJu0YzN8uKH6bQhTNnC1L2+ht0JXPZSm9Kq64WBemGznABQfmVUWgPz KgvV5a3DsuVsb7pRamhjNyFIV/XDt7smT/e8hYwRv13eG7pAD7o/Wssd X-Gm-Gg: ATEYQzzi66KKtoVwWhmVLr9c4hDa7Bw2YM9ccz3VWtKLBcXGgnbHZDCaeBu+2Xr6nhn Pw/AD9WK+MFUq+arl2sfPIio3MwYECt8D+zsWNbCM8EvrIMOdmVw4og8YzYGZFGyLAyLaM+0Xp4 ZUPOFuK8xfQKUjEPj7SWsKGxupqjjoqr+HEYXugYA1pNXdZsY9yfYJFZ+tkVEMO78BmTE+QSyGV 5Ah638bOSOZh2X0qK07auFzXa4ekw7+NE/77s6MMbWuaf3etwTPlHbtJcBz2e6q0aiNIDUFJqAD 7d9cF4pzGnDRrTLEDXfowfuWDFGCdDU9wk0Dm5EfaNx1/1ch7CME+kdDwiSYUVPM9IDeCwdkqoV GVLXQINlRsJ+d2lxSqBEGb3qXhm088WYRi8mTchBsVRstdM5K4VaH30bYG6tKwYG7GZEaiWE/3y AqcZpPRvgvlAiyTmTbPyP3fbU22nfpNnJoFz7ZYeX6Oqt44+uDgjbt1OXISg== X-Received: by 2002:a05:6122:1350:b0:566:36e7:8934 with SMTP id 71dfb90a1353d-56b07e8b7dcmr3378593e0c.16.1773038688827; Sun, 08 Mar 2026 23:44:48 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Paolo Bonzini , Peter Xu , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Cc: sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 3/5] physmem: xen: Conditionalize use of the mapcache Date: Mon, 9 Mar 2026 07:44:33 +0100 Message-ID: <20260309064436.51860-4-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> References: <20260309064436.51860-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Conditionalize use of the mapcache. This is in preparation to optionally disable the mapcache at runtime. Signed-off-by: Edgar E. Iglesias Acked-by: Peter Xu Reviewed-by: Stefano Stabellini --- system/physmem.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/system/physmem.c b/system/physmem.c index e5ff26acec..7eecd81877 100644 --- a/system/physmem.c +++ b/system/physmem.c @@ -578,7 +578,9 @@ MemoryRegion *flatview_translate(FlatView *fv, hwaddr addr, hwaddr *xlat, is_write, true, &as, attrs); mr = section.mr; - if (xen_enabled() && memory_access_is_direct(mr, is_write, attrs)) { + if (xen_map_cache_enabled() && + memory_access_is_direct(mr, is_write, attrs)) { + /* mapcache: Next page may be unmapped or in a different bucket/VA. */ hwaddr page = ((addr & TARGET_PAGE_MASK) + TARGET_PAGE_SIZE) - addr; *plen = MIN(page, *plen); } @@ -2577,7 +2579,7 @@ static void reclaim_ramblock(RAMBlock *block) { if (block->flags & RAM_PREALLOC) { ; - } else if (xen_enabled()) { + } else if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(block->host); #if !defined(_WIN32) && !defined(EMSCRIPTEN) } else if (block->fd >= 0) { @@ -2736,7 +2738,7 @@ static void *qemu_ram_ptr_length(RAMBlock *block, ram_addr_t addr, len = *size; } - if (xen_enabled() && block->host == NULL) { + if (xen_map_cache_enabled() && block->host == NULL) { /* We need to check if the requested address is in the RAM * because we don't want to map the entire memory in QEMU. * In that case just map the requested area. @@ -2785,7 +2787,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, RAMBlock *block; uint8_t *host = ptr; - if (xen_enabled()) { + if (xen_map_cache_enabled()) { ram_addr_t ram_addr; RCU_READ_LOCK_GUARD(); ram_addr = xen_ram_addr_from_mapcache(ptr); @@ -3787,7 +3789,7 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, if (is_write) { invalidate_and_set_dirty(mr, addr1, access_len); } - if (xen_enabled()) { + if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(buffer); } memory_region_unref(mr); @@ -3898,7 +3900,7 @@ void address_space_cache_destroy(MemoryRegionCache *cache) return; } - if (xen_enabled()) { + if (xen_map_cache_enabled()) { xen_invalidate_map_cache_entry(cache->ptr); } memory_region_unref(cache->mrs.mr); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249073.1546592 (Exim 4.92) (envelope-from ) id 1vzUMD-0005kp-A0; Mon, 09 Mar 2026 06:44:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249073.1546592; Mon, 09 Mar 2026 06:44:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMD-0005ki-7K; Mon, 09 Mar 2026 06:44:49 +0000 Received: by outflank-mailman (input) for mailman id 1249073; Mon, 09 Mar 2026 06:44:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMB-0005KI-SB for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:47 +0000 Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [2607:f8b0:4864:20::a2a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 764f911f-1b83-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 07:44:47 +0100 (CET) Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-56afafef7aeso3209087e0c.3 for ; Sun, 08 Mar 2026 23:44:47 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5ffe8922cdfsm8333849137.5.2026.03.08.23.44.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:44 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 764f911f-1b83-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038686; x=1773643486; 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; bh=xgO9zG7fMna9CoPh8ghnxcTLAQlMFEOZkqL0utLfYyE=; b=ENpG5V5usi1dQDsSbkonf3DtNFki4VYUf8duZcAKBOGI1W+/hpmf8RIdgKSlgUOc+I KHt+8MSMlTqcyJZ203F3eUaJvoJKmilORXBcZC9qHyH7ExDhM0/7k4X/TQextuc52yic 3geaiCqD6Qh6sObjfdJ7yc4l+Cm2dzcqOJ+BEO2Na9IE5+kuZdAnkH9lXYIgp/j06u9Q r+IKlIpOgp1NUGjbuBuyEc9GLUn/TuOSNBpLyGpmsVC1UUWxTal2TbFz8gmvBB6uedY1 cRPqPrWcSxrjKLSeJESxJuGJIn94BcVY5+tHhOvXjFahBX8oKrUe1Er9KE3RlPicubpb Bm5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038686; x=1773643486; 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; bh=xgO9zG7fMna9CoPh8ghnxcTLAQlMFEOZkqL0utLfYyE=; b=jPQKXiqiIjLK6re0Ji0NSMQ2Ev9yuIJPs8K8pV16r+HoMitIOCP5lgGNYOQo1L5yvh LwK46gtkBwvQi8siScsng/4/II167B7GbQck22bZ59gYEsGN7ZN45KlYQagiT161hxi7 jKkZkBBRj9r85f+fXZI1UjclMiyH4vJc0YEd5tvCZpJGle5Vu2kae5wxwkG8cYePhjsd r296/z5rPpBUSbiX197iPLnTCrolnl6vKc+AG8KDCUx2m1+Gpglsx4PSwznDrGqLMOh7 6gA9uV4PWaLbMNYp9EeNkpnZGHKgmfPcXjrg86fRjivIvvAzISeiK9kmuBFwlow9nL88 WMbQ== X-Forwarded-Encrypted: i=1; AJvYcCXiok5T6AQCmyMKO1x+yRDeh6IkAK8tgoZx47+Qxg+hTYeMB4J3Gzvsr05IgAg/hzlrObxIStsS8JI=@lists.xenproject.org X-Gm-Message-State: AOJu0YyUeG6ezip/TSSlmgFThW1cNYouyAX5uvExPOJYHU27jrjnZ6C9 Oo/aplumbPVL/RnMnxjHjuHDD8ZVPJ8ZO1BxrfU+CMjyytb7JUnWmkyU X-Gm-Gg: ATEYQzzZLQ6kIZsrTf+KlsMgHNzNd/z8mm7INEwOxv832s4dGQZqxlFj/PEQgsbbd+P 4fXLi3mmqyvXa68OicLK+kalCHmMkArVHjbJNeMM9K+1HuMgdmF4MJMhs4SdN2Of5ekT+VDLryS SsHMMhps77A95JilTM0MEgeo96sXWpAJAWAdUEVFDyFkpIa5B29jv0C5ccH8FBYv5b8buWlgX2w tikdx8ZpNG2ledDYgSXOfjHePgV1TQgYENnh6r/gaN3JvNw835aU++v6lSEF7N2SjhkNe+d2gxF 029wjg6TiAGzxZ4jB4Pt+2KEBkyyH0fqys55sfg7OwmVk/wviHxlzO/SnJW/5ZE4gtYCnvYjw1u KSJUu2ZV7Rq/V7xCD4xjb+RWw7flY8RyKRJ7KyKlmPO/A6mMsjTsdWPw6Zc322xVFjZh/YYeiB1 kWjQsfRVGl6LHqJApOdKurt5oYuQHvJYcJjQsNkFSF/hNHZy/iC3QaS2x5qcmWmfLFqqOR X-Received: by 2002:a05:6102:c86:b0:5ff:a606:3cfc with SMTP id ada2fe7eead31-5ffe61248dfmr4759508137.21.1773038685979; Sun, 08 Mar 2026 23:44:45 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 2/5] xen: mapcache: Add function to check if the mapcache is enabled Date: Mon, 9 Mar 2026 07:44:32 +0100 Message-ID: <20260309064436.51860-3-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> References: <20260309064436.51860-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add function to check if the mapcache is enabled. No functional change. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini --- hw/xen/xen-mapcache.c | 6 ++++++ hw/xen/xen_stubs.c | 5 +++++ include/system/xen-mapcache.h | 1 + 3 files changed, 12 insertions(+) diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index 517e5171b7..a3c162cd4c 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -80,6 +80,12 @@ static MapCache *mapcache_grants_ro; static MapCache *mapcache_grants_rw; static xengnttab_handle *xen_region_gnttabdev; +bool xen_map_cache_enabled(void) +{ + /* Map cache enabled implies xen_enabled(). */ + return xen_enabled() && mapcache; +} + static inline void mapcache_lock(MapCache *mc) { qemu_mutex_lock(&mc->lock); diff --git a/hw/xen/xen_stubs.c b/hw/xen/xen_stubs.c index 5e565df392..a39efb5062 100644 --- a/hw/xen/xen_stubs.c +++ b/hw/xen/xen_stubs.c @@ -29,6 +29,11 @@ bool xen_mr_is_memory(MemoryRegion *mr) g_assert_not_reached(); } +bool xen_map_cache_enabled(void) +{ + return false; +} + void xen_invalidate_map_cache_entry(uint8_t *buffer) { g_assert_not_reached(); diff --git a/include/system/xen-mapcache.h b/include/system/xen-mapcache.h index fa2cff38d1..c46190dd0c 100644 --- a/include/system/xen-mapcache.h +++ b/include/system/xen-mapcache.h @@ -13,6 +13,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr phys_offset, ram_addr_t size); +bool xen_map_cache_enabled(void); void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); uint8_t *xen_map_cache(MemoryRegion *mr, hwaddr phys_addr, hwaddr size, -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249071.1546574 (Exim 4.92) (envelope-from ) id 1vzUM9-0005KX-0M; Mon, 09 Mar 2026 06:44:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249071.1546574; Mon, 09 Mar 2026 06:44:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUM8-0005KO-R3; Mon, 09 Mar 2026 06:44:44 +0000 Received: by outflank-mailman (input) for mailman id 1249071; Mon, 09 Mar 2026 06:44:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUM7-0005KI-BW for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:43 +0000 Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [2607:f8b0:4864:20::a2c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 72e510e2-1b83-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 07:44:41 +0100 (CET) Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-56adf76631cso2441445e0c.1 for ; Sun, 08 Mar 2026 23:44:41 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-56b09a0881asm9247726e0c.4.2026.03.08.23.44.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:38 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 72e510e2-1b83-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038680; x=1773643480; 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; bh=JhBJGCljjR2vWP5NBGBE3Ox/OrYcaC529yay0waARyQ=; b=Le8xFLVt2Ri2TNA3hEy5MQ2U1fZQXAVSgT5Pyu3AcKlHNoBCyyabt2tKpxBzQhIQic PpemP7vAxVaKhGaFbQA3SM46TdDoUyRu34CY7niP9Y1XNB+4pDjPxJpJYxgtaBo1WTiq 1nsGMsZpj7SJtrfGRcpy/NkE9uRvIRvuAwhDKpbFugj5tuMJhpsMBagcHA3hpv2h8u8d nkh89lWqcW1wL8C+oPFnsVmEOLMIFpWqtRqkMcdgIUad3rGnMRqlHPEMD7rqySuOU3VY VvOzaucbpAE3mrHJlS8FybLRI5I3/NVBtJYq8LHtGIXlIgMI4vfl9uPvbkUa6gGG5C2C 1F7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038680; x=1773643480; 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; bh=JhBJGCljjR2vWP5NBGBE3Ox/OrYcaC529yay0waARyQ=; b=a+hh7HJ5kKwK0AEcxmZL81XnSMNbgaSJo1FdWDFpNADsqS2CDZokLW8GqcTv6AZXmY fuBze8g4svNEioL06Rwi1m9lE0c5dP6ZDKn0Y++GPZ5+QhXCiPJp0KRdz5JXFR+341Fh o2VAmJqfDllXa65Q+pfAJkKOw8aBa2yw/U1EFfLzjHakhxil9HZpI6P/1wEJ19kRp6A6 lKLpIYfXbgdaZiCLn+ngowMlq4DC7485v3GxYc/DXNv8OfnmSGiSJ/8zBeTIjnAsBXEL Qh/z+hIxD128dB6pKiQ3sWC+T+KyGFtCDYtZCe5BW9c5OBpVyBc55UlDPzU4ynPEboxH R8VA== X-Forwarded-Encrypted: i=1; AJvYcCWYn5CdKftwzOmomhOfw1xqpCBFmAXOcXfRE5axVYl4XFqpybTZ/u2vNN021wZw925U7YrwXiLvgYk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy6TWXLVNpMwNfr6ZY8jH/O+L/Hi2RGASVD5OiLapNWMolcIweU CHe61UHNt4EERi/T7y+cvLTNy5oSdkz+YR9QX02150yB3cLB0hhPtkUX X-Gm-Gg: ATEYQzxLAun6jkAG52GYAdfcCdBD9+H5MhNH7wuJ/X5weWW6aDGddQ04CCqmmWl9zrj yDf4p8/zNEHXSMZkKl/VcbWl78tJYdgBYQZZrD3PAEZsWQ1SCQOHp6s6cZPaXpUIV6duMGZya06 /KIrhE9asHy0cRqDKwHLV89seBU0GNJjmSIMmUJHCLDLzOhDHPIPby8Il61MglL92r/zK8qAfEB BNVajJ3czWxjKE3WylW+QCUoxqgJbLA4DO4lYwoNzDtNWrjrBKDwqU9ItQDgNYFf40OIZruQ+ml +F84/+2CknEpECL7qXZ3VAX1Sx3ilZn/QBRUIvbF1zrDVEi1ce3Y847hNd8YZZ1GXkxCzKDqjTS 9Z/ncF6Xt7h61V+vQFXxcnPRjhjj1ngYUPsAC0JkDosXQQjAzV14CQFOcu5mvgnolSHUYkKHdoj 5z4D3MsA7As8YkMoDIOdkaL7lAXPLgHHtGTQgig7/uzhX4XMRzPT+F02ptRw== X-Received: by 2002:a05:6123:4b:b0:55b:16ba:2854 with SMTP id 71dfb90a1353d-56b07d15b1dmr3664236e0c.5.1773038680128; Sun, 08 Mar 2026 23:44:40 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org Cc: sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 0/5] xen: pvh: Add machine option to disable the mapcache Date: Mon, 9 Mar 2026 07:44:30 +0100 Message-ID: <20260309064436.51860-1-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Merge tag 'pull-11.0-virtio-gpu-updates-060326-1' of https://gitlab.com/stsquad/qemu into staging (2026-03-07 11:22:16 +0000) are available in the Git repository at: https://gitlab.com/edgar.iglesias/qemu.git tags/edgar/edgars-xen-queue-2026-02-09 for you to fetch changes up to 83d1d9a49e8eb970f87508ae4ce0f222084df365: hw/xen: xenpvh: Add prop to enable/disable the mapcache (2026-03-09 03:24:02 +0100) ---------------------------------------------------------------- Edgars Xen queue ---------------------------------------------------------------- Edgar E. Iglesias (5): xen: mapcache: Assert mapcache existance xen: mapcache: Add function to check if the mapcache is enabled physmem: xen: Conditionalize use of the mapcache hw/xen-hvm: Add a mapcache arg to xen_register_ioreq() hw/xen: xenpvh: Add prop to enable/disable the mapcache hw/i386/xen/xen-hvm.c | 2 +- hw/xen/xen-hvm-common.c | 18 +++-- hw/xen/xen-mapcache.c | 16 ++++ hw/xen/xen-pvh-common.c | 134 +++++++++++++++++++++++++++++--- hw/xen/xen_stubs.c | 5 ++ include/hw/xen/xen-hvm-common.h | 3 +- include/hw/xen/xen-pvh-common.h | 2 + include/system/xen-mapcache.h | 1 + system/physmem.c | 14 ++-- 9 files changed, 170 insertions(+), 25 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 06:45:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 06:45:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249075.1546610 (Exim 4.92) (envelope-from ) id 1vzUMK-0006I3-OZ; Mon, 09 Mar 2026 06:44:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249075.1546610; Mon, 09 Mar 2026 06:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMK-0006Ho-Lb; Mon, 09 Mar 2026 06:44:56 +0000 Received: by outflank-mailman (input) for mailman id 1249075; Mon, 09 Mar 2026 06:44:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzUMK-0006FY-60 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 06:44:56 +0000 Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [2607:f8b0:4864:20::a2b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79d54920-1b83-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 07:44:53 +0100 (CET) Received: by mail-vk1-xa2b.google.com with SMTP id 71dfb90a1353d-56a9076813bso4437617e0c.3 for ; Sun, 08 Mar 2026 23:44:53 -0700 (PDT) Received: from gmail.com (ip190-5-140-138.intercom.com.sv. [190.5.140.138]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-94ea681505csm1360097241.4.2026.03.08.23.44.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 23:44:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79d54920-1b83-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773038692; x=1773643492; 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; bh=WJrq6QMWPG9vMn/f3A1Ji6UEIjqvYTStXL9SXKLYoe4=; b=DMapLI2G3W9Xev1kUbEqF0oz8j/q+p9Tyhdi80uZy1cjI1I9NrzPtDu4jICJB5/kAZ qSGUn63UYBWM4PuIXzjwA0IlU5iI/3jwV1pHZssWripLyWJOAkB3bVH4YlP5TE55PEqU q+8EhpJKPGrx2sSyovdhMJFjapo/dOsqWQhBDksZJkc01Kd2ywd5uAvnTcrSp7GX94Y9 0n5ngYOGcdsF07R+NvrvnHqAFDUfMT8SNkCpi+IKhlPxAOjMc6mHerpfXZcZqtUOd0Z+ pvBQQlV5YhvzRpVPt2W/PfzFupOOHOLAYLqJ6ZILHp5wuVpn912FnoXWF6WHShpOKv3X kSUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773038692; x=1773643492; 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; bh=WJrq6QMWPG9vMn/f3A1Ji6UEIjqvYTStXL9SXKLYoe4=; b=r9KZut7wqK80hgQ7BchUwbqYh853RHGyjO3nnB1tEz5ccscmYHx7DXECzIgS1RoJX3 pLDkPvP2+hV8N4kMNi2yiqZB8LetUHGcb22dXFTs7GEVx2xGwALhtgBIfj5fEWNfo3PX T6Lp2UQ5IKg8LM+cA5gLvdgGbycwqk//lrInwwYpHPuRsoAZYeidZB0t1aIrUDTC7kRH 2RFsSHfBnqO+ELgpGsqAnb6KuiNFwUuXWMirchMXlAtyR7vHfMRY5Gd4rf33rRAk3zmH JcfbRHkIgN+zCyrAsO2hJyF1G47D63sgqx3Y6mbAQGcXi1oImApHdRdEXoMyUougdyqe faKQ== X-Forwarded-Encrypted: i=1; AJvYcCXOw8cqfqAf9G9mf+a3zuF/523x3+eRMoVxpKDBOmiEMWqHzu/VqWhMo9i0SFJpCb7PnDBF9R6pheM=@lists.xenproject.org X-Gm-Message-State: AOJu0YwYeFKGcJJRkW0GTTLEcfSbqRhIUSsBbINE5pF1k+BssTTGkutp DXX/cOYzOg182VHXn8/8dC1PGTg4k/I5LiuI+d6qtnO+rHTPjYuCX0Z+ X-Gm-Gg: ATEYQzxitIfrxITDaVxrpOIihnmfZe/V27UdGwGsa6Im8OL1scMRT3XskGYCrLhecYh YG3p37dlUXwYS7hwLm619f1Z5B7/XWD9n6DO/pCJo6d94Vf0kAk84Hpnx3GH6KzoI4IC4Le7jfY 6vl905a3DGF31JQGT6zf0pw67s7pF+e689kTsgoaeTabSMdFqTCYjkACzpjgavh7zIvDgWueDOS EJkKXCCD6NfpJXD5h124Ps1YG7x3zOO5mYUsGcVcTs1xbJ43rliHZWAWnALCBN7QvXuJEtm7fgS KwWkp5XM9T0wrUxVEtiWLtyPiMM/94yowEynECfR1d8Kjq4wdML5xC6dtuYbmZ9CWjmtXo7Kwh1 6az+TCJknng/Ptcz19MSB3y32MUfspnjbluWL0GIRaJkKGdhKcaKFTyvKn5VqMp873gmw9byPvb D/HiaPXycZalT/NfWzqkzExs5NtwU7V5GRCXIH8X9OO0HxaSd5BbSPaclzcQ== X-Received: by 2002:a05:6122:1d4e:b0:559:58a5:f6cc with SMTP id 71dfb90a1353d-56b07d19f27mr3622628e0c.4.1773038691781; Sun, 08 Mar 2026 23:44:51 -0700 (PDT) From: "Edgar E. Iglesias" To: qemu-devel@nongnu.org, Stefano Stabellini , Anthony PERARD , "Edgar E. Iglesias" , Paolo Bonzini , Richard Henderson , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum Cc: edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Subject: [PULL v1 4/5] hw/xen-hvm: Add a mapcache arg to xen_register_ioreq() Date: Mon, 9 Mar 2026 07:44:34 +0100 Message-ID: <20260309064436.51860-5-edgar.iglesias@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> References: <20260309064436.51860-1-edgar.iglesias@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Edgar E. Iglesias" Add a mapcache argument to xen_register_ioreq() allowing the caller to optionally disable the mapcache. All callers still call it with mapcache = true so there's no functional change yet. Signed-off-by: Edgar E. Iglesias Reviewed-by: Stefano Stabellini --- hw/i386/xen/xen-hvm.c | 2 +- hw/xen/xen-hvm-common.c | 18 ++++++++++++------ hw/xen/xen-pvh-common.c | 3 ++- include/hw/xen/xen-hvm-common.h | 3 ++- 4 files changed, 17 insertions(+), 9 deletions(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index a6e1683885..c7bfcaae8e 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -622,7 +622,7 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory) xen_register_ioreq(state, max_cpus, HVM_IOREQSRV_BUFIOREQ_ATOMIC, - &xen_memory_listener); + &xen_memory_listener, true); xen_is_stubdomain = xen_check_stubdomain(state->xenstore); diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index 59c73dfaeb..8c825588ae 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -473,7 +473,9 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req) case IOREQ_TYPE_TIMEOFFSET: break; case IOREQ_TYPE_INVALIDATE: - xen_invalidate_map_cache(); + if (xen_map_cache_enabled()) { + xen_invalidate_map_cache(); + } break; case IOREQ_TYPE_PCI_CONFIG: cpu_ioreq_config(state, req); @@ -823,7 +825,8 @@ void xen_shutdown_fatal_error(const char *fmt, ...) static void xen_do_ioreq_register(XenIOState *state, unsigned int max_cpus, - const MemoryListener *xen_memory_listener) + const MemoryListener *xen_memory_listener, + bool mapcache) { int i, rc; @@ -874,11 +877,13 @@ static void xen_do_ioreq_register(XenIOState *state, state->bufioreq_local_port = rc; } /* Init RAM management */ + if (mapcache) { #ifdef XEN_COMPAT_PHYSMAP - xen_map_cache_init(xen_phys_offset_to_gaddr, state); + xen_map_cache_init(xen_phys_offset_to_gaddr, state); #else - xen_map_cache_init(NULL, state); + xen_map_cache_init(NULL, state); #endif + } qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state); @@ -901,7 +906,8 @@ err: void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, uint8_t handle_bufioreq, - const MemoryListener *xen_memory_listener) + const MemoryListener *xen_memory_listener, + bool mapcache) { int rc; @@ -922,7 +928,7 @@ void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, state->has_bufioreq = handle_bufioreq != HVM_IOREQSRV_BUFIOREQ_OFF; rc = xen_create_ioreq_server(xen_domid, handle_bufioreq, &state->ioservid); if (!rc) { - xen_do_ioreq_register(state, max_cpus, xen_memory_listener); + xen_do_ioreq_register(state, max_cpus, xen_memory_listener, mapcache); } else { warn_report("xen: failed to create ioreq server"); } diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c index 1381310fc7..4fade017bb 100644 --- a/hw/xen/xen-pvh-common.c +++ b/hw/xen/xen-pvh-common.c @@ -202,7 +202,8 @@ static void xen_pvh_init(MachineState *ms) xen_pvh_init_ram(s, sysmem); xen_register_ioreq(&s->ioreq, ms->smp.max_cpus, xpc->handle_bufioreq, - &xen_memory_listener); + &xen_memory_listener, + true); if (s->cfg.virtio_mmio_num) { xen_create_virtio_mmio_devices(s); diff --git a/include/hw/xen/xen-hvm-common.h b/include/hw/xen/xen-hvm-common.h index e1beca062f..d177ff14ea 100644 --- a/include/hw/xen/xen-hvm-common.h +++ b/include/hw/xen/xen-hvm-common.h @@ -91,7 +91,8 @@ void xen_device_unrealize(DeviceListener *listener, DeviceState *dev); void xen_hvm_change_state_handler(void *opaque, bool running, RunState rstate); void xen_register_ioreq(XenIOState *state, unsigned int max_cpus, uint8_t handle_bufioreq, - const MemoryListener *xen_memory_listener); + const MemoryListener *xen_memory_listener, + bool mapcache); void cpu_ioreq_pio(ioreq_t *req); #endif /* HW_XEN_HVM_COMMON_H */ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 07:31:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 07:31:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249127.1546627 (Exim 4.92) (envelope-from ) id 1vzV50-0006Hn-C5; Mon, 09 Mar 2026 07:31:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249127.1546627; Mon, 09 Mar 2026 07:31:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzV50-0006Hg-9V; Mon, 09 Mar 2026 07:31:06 +0000 Received: by outflank-mailman (input) for mailman id 1249127; Mon, 09 Mar 2026 07:31:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzV4y-0006Ha-Mu for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 07:31:04 +0000 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [2a00:1450:4864:20::431]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ebf63124-1b89-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 08:31:01 +0100 (CET) Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439c9bdc1eeso1839841f8f.3 for ; Mon, 09 Mar 2026 00: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-439dadb85b8sm24006574f8f.17.2026.03.09.00.30.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 00:30:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ebf63124-1b89-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773041460; x=1773646260; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=JY1YIqMpS+svr4GEl0wS4/8/T5I/0QlYvZB1MYhrF4c=; b=OOMbvUgWYhafmSagm+014NoWQJQyOjP6HVgwbBLwha5fFzSwTQENkRbFEc/39Uwma6 PtsEqr+gnAJcNjwmsrJVz6x/F4SUXj2+YTebz1E/eSbp0MqkhcSTGzqWHrilHNorSYVf /c9HiFfmvcpBYQUgh7nCCftuedisnpS0UnVIZXOh5lRvZ7izR6pXqKfYRWvwCum96fi3 Wp7dTBp8PDqXQgEjAmtW45vH7qO6ZSAKLPuQn/cHy4fzGy9vcRcfXFkHesQ6w7FYgurF VyLL4bDqH9JXcqfhlksyWJxU3at1HF0jnvKjKZdShRTkkS1iDR7nqfnUAHv4cSx5YXeH P+CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773041460; x=1773646260; h=content-transfer-encoding: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; bh=JY1YIqMpS+svr4GEl0wS4/8/T5I/0QlYvZB1MYhrF4c=; b=okSp3juH7hrGKSuNM1fpkLVPN+0o1CzPihJCdK9n53lREp5Ry+5FNNyaXxIFmPwUQS rSQKYkgSrBjpcRDU+XR41BX1rwUFefRjT34mzYGxcIwUgAC27s9mxWfASEErchErDJRR qvoAY60Fs/yCX1e5viEs2sJhdUxFwWTD5+CEzmY/kj8smq6e2Ld6hir2hYXQLcH5z/U3 7WXW/f3mswMO7tPt0n1qJAK1CupTpvroYq7ibkkd0bO2zytvRrda/FPNoFhhHNkO/Z6W eUH6C3s77gcQyhfuNSPP0oGMjLiVVDmkyGjPgX9mvlIHoTUCwU8Jgbg0M0hF5leFKeaH 7Zzw== X-Gm-Message-State: AOJu0YxOCn3B48HARuFpUGQ0GOyOOsk8cwfrOIlWBC/Oj5dZaD8UFsUT RZeTlZfvhOZkztVp+PCUADyFUE/pb94O7mtuSfw+iikUMCl3cqHP/Sy2jLz4U0oM2Q== X-Gm-Gg: ATEYQzy5+2uVg0Ubq14Y/KiVFlxeJw3hTf7ZRSeC7SxUtuKb3V7fYkY+6IValLGhpLC TFjJ4n+eO8HBllCsn1GClB/+vg6pS+m9B/i6BDOj3goDi4Oi7BH1o3ND3IhUqKoLYEfO5EvMhDy nkD9GXiO0SzJkJGxwaiuWT1ZoJW9B7bsXKTrXO19PHasKCfaFyKRZ9v0CBQkJ7ZkmY3CVKgs/yE sISOng7jm95h7VLyIPzCSQ+Tjcx9ppt2sEF0u9NJHA63GamryHRDNRXkM2utwQTWC6GQZFzkWVU 7ViLsAZR+gLcj5yPlbHEnFOCeZQvibjHSNzj1oKxO4O1jFpgNU70Q/bOb9BtLWJfmoabbulOibG MLxB7xsX6HLaiOn/ebuU90cXU3risEF+ZfC7b/f7vbDZabZ5ToCCsNA2fHN34qSuHDa3BxtNljs fMApryQ4GMS5j0vCtkvUUabOCsjfpAhDk6dlaDJylg3NEPXSQ1cm4Tu8HKe3AVL4cpSRXiHZU3I f2kab2KbI722Sc= X-Received: by 2002:a05:6000:2dca:b0:439:b046:2044 with SMTP id ffacd0b85a97d-439da354a8emr19153955f8f.12.1773041460065; Mon, 09 Mar 2026 00:31:00 -0700 (PDT) Message-ID: <609060f4-d94b-4b65-a10b-5126f10307db@suse.com> Date: Mon, 9 Mar 2026 08:31:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper , Soumyajyotii Ssarkar References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08.03.2026 19:30, Marek Marczykowski-Górecki wrote: > On Fri, Mar 06, 2026 at 12:48:08AM +0530, Soumyajyotii Ssarkar wrote: >> --- a/xen/common/efi/boot.c >> +++ b/xen/common/efi/boot.c >> @@ -7,6 +7,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; >> static struct file __initdata xsm; >> static const CHAR16 __initconst newline[] = L"\r\n"; >> >> +static __initdata struct { >> + bool preserved; >> + uint64_t old_addr; >> + uint64_t new_addr; >> + uint32_t size; >> + const char *failure_reason; >> +} bgrt_debug_info; >> + >> static void __init PrintStr(const CHAR16 *s) >> { >> StdOut->OutputString(StdOut, (CHAR16 *)s ); >> @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) >> efi_bs->FreePool(memory_map); >> } >> >> +struct bmp_header { >> + uint16_t signature; >> + uint32_t file_size; >> + uint16_t reserved_1; >> + uint16_t reserved_2; >> + uint32_t data_offset; >> +} __attribute__((packed)); >> + >> +/* >> + * ACPI Structures - defined locally, >> + * since we cannot include acpi headers >> + * in EFI Context. >> + */ >> + >> +struct acpi_rsdp { >> + char signature[8]; >> + uint8_t checksum; >> + char oem_id[6]; >> + uint8_t revision; >> + uint32_t rsdt_physical_address; >> + uint32_t length; >> + uint64_t xsdt_physical_address; >> + uint8_t extended_checksum; >> + uint8_t reserved[3]; >> +} __attribute__((packed)); >> + >> +struct acpi_table_header { >> + char signature[4]; >> + uint32_t length; >> + uint8_t revision; >> + uint8_t checksum; >> + char oem_id[6]; >> + char oem_table_id[8]; >> + uint32_t oem_revision; >> + uint32_t asl_compiler_id; >> + uint32_t asl_compiler_revision; >> +} __attribute__((packed)); >> + >> +struct acpi_xsdt { >> + struct acpi_table_header header; >> + uint64_t table_offset_entry[1]; /* Variable array length */ > > uint64_t table_offset_entry[]; > > BTW, do we have some canonical place with list of files imported (and > kept in sync) with other projects? xen/include/acpi/actbl.h doesn't > exactly follow Xen coding style, but it's unclear to me if it needs to > stay this way. I don't really understand why the headers we've got can't be used. Even some of the library-like code under xen/acpi/ may be usable here. While we don't exactly keep xen/include/acpi/ in sync with Linux, when things are added we preferably add them in the way Linux has them. >> +} __attribute__((packed)); >> + >> +struct acpi_bgrt { >> + struct acpi_table_header header; >> + uint16_t version; >> + uint8_t status; >> + uint8_t image_type; >> + uint64_t image_address; >> + uint32_t image_offset_x; >> + uint32_t image_offset_y; >> +} __attribute__((packed)); >> + >> +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE *SystemTable) Nit (style): The first * is misplaced. >> +{ >> + EFI_GUID acpi2_guid = ACPI_20_TABLE_GUID; >> + struct acpi_rsdp *rsdp = NULL; >> + struct acpi_xsdt *xsdt; >> + struct acpi_bgrt *bgrt; Here and ... >> + uint32_t entry_count, actual_size; >> + unsigned int i; >> + >> + for ( i = 0; i < SystemTable->NumberOfTableEntries; i++ ) >> + { >> + if ( match_guid(&acpi2_guid, &SystemTable->ConfigurationTable[i].VendorGuid) ) >> + { >> + rsdp = SystemTable->ConfigurationTable[i].VendorTable; >> + break; >> + } >> + } >> + >> + if ( !rsdp || !rsdp->xsdt_physical_address ) >> + return NULL; >> + >> + xsdt = (struct acpi_xsdt *)rsdp->xsdt_physical_address; >> + if ( !xsdt ) >> + return NULL; >> + >> + actual_size = (xsdt->header.length - sizeof(struct acpi_table_header)); >> + entry_count = (actual_size / sizeof(uint64_t)); >> + >> + for ( i = 0; i < entry_count; i++ ) >> + { >> + struct acpi_table_header *header = (struct acpi_table_header *)xsdt->table_offset_entry[i]; ... here and elsewhere - please use pointer-to-const wherever possible. >> + if ( header->signature[0] == 'B' >> + && header->signature[1] == 'G' >> + && header->signature[2] == 'R' >> + && header->signature[3] == 'T' ) > > strncmp? Or even memcmp() in this case. Plus there is ACPI_SIG_BGRT. >> + { >> + bgrt = (struct acpi_bgrt *)header; > > You can just return it here, avoiding the extra variable. > >> + return bgrt; >> + } >> + } >> + return NULL; >> +} >> + >> +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject if bigger */ >> + >> +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) >> +{ >> + struct acpi_bgrt *bgrt; >> + struct bmp_header *bmp; >> + void *old_image, *new_image; >> + uint32_t image_size; >> + EFI_STATUS status; >> + uint8_t checksum; >> + unsigned int i; >> + >> + bgrt_debug_info.preserved = false; >> + bgrt_debug_info.failure_reason = NULL; >> + >> + bgrt = find_bgrt_table(SystemTable); >> + if ( !bgrt ) >> + { >> + bgrt_debug_info.failure_reason = "BGRT table not found in XSDT"; >> + return; >> + } >> + >> + if ( !bgrt->image_address ) >> + { >> + bgrt_debug_info.failure_reason = "BGRT image_address is NULL"; >> + return; >> + } >> + >> + old_image = (void *)bgrt->image_address; >> + bmp = (struct bmp_header *)old_image; >> + >> + if ( bmp->signature != 0x4D42 ) >> + { >> + bgrt_debug_info.failure_reason = "Invalid BMP signature"; >> + return; >> + } >> + >> + image_size = bmp->file_size; >> + if ( !image_size || image_size > MAX_IMAGE_SIZE ) >> + { >> + bgrt_debug_info.failure_reason = "Invalid image size"; >> + return; >> + } >> + >> + status = efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &new_image); >> + if ( status != EFI_SUCCESS || !new_image ) >> + { >> + bgrt_debug_info.failure_reason = "Memory allocation failed"; >> + return; >> + } >> + >> + memcpy(new_image, old_image, image_size); >> + >> + bgrt->image_address = (uint64_t)new_image; >> + bgrt->status |= 0x01; > > Why forcing the "displayed" bit here? And if this is needed, why by way of a literal number rather than a suitable #define? >> + bgrt->header.checksum = 0; >> + checksum = 0; >> + for ( i = 0; i < bgrt->header.length; i++ ) >> + checksum += ((uint8_t *)bgrt)[i]; >> + bgrt->header.checksum = (uint8_t)(0 - checksum); >> + >> + bgrt_debug_info.preserved = true; >> + bgrt_debug_info.old_addr = (uint64_t)old_image; >> + bgrt_debug_info.new_addr = (uint64_t)new_image; >> + bgrt_debug_info.size = image_size; >> +} >> + > > This is quite a bit of code, maybe move to a separate file? But I'd like > to hear what others think. Whether to put in a separate file is only the 2nd question imo. The first is whether this much code is needed in the first place. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 09 07:47:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 07:47:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249136.1546637 (Exim 4.92) (envelope-from ) id 1vzVKh-00086s-MR; Mon, 09 Mar 2026 07:47:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249136.1546637; Mon, 09 Mar 2026 07:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzVKh-00086l-Jc; Mon, 09 Mar 2026 07:47:19 +0000 Received: by outflank-mailman (input) for mailman id 1249136; Mon, 09 Mar 2026 07:47:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzVKg-00086D-4q for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 07:47:18 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3085d8e2-1b8c-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 08:47:15 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-483487335c2so93925775e9.2 for ; Mon, 09 Mar 2026 00:47: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-4851fae00absm319480845e9.4.2026.03.09.00.47.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 00:47:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3085d8e2-1b8c-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773042434; x=1773647234; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=qsabEXkhux99yzwsSjH5RxSJbqhPM5KtfGWU+0nIdFw=; b=V8R0Gc+fRw/R2eny8xsDRWTjHyX4T1/3+zjeeFbjPPO37kixGgOAD+69YlLoqJlnzZ Bxjqupd89cIlkpw+ekTL8cDZx62Ifv03sknR1kvCJlPDRbUZc97ccYlt/40MmwUem/Qk NkWPBIgOx1k+SAkTtmZ/frBxcI5ww89anf72VjEt35r3HseKBVd5FCAjwl5faFVn0occ n8R1rYDcAqfd8DJ6LW5iH5J/Ye/NhD0Ef0tjKO3HwLA6c8b4W8a8rAP1WEsJz7mCNigO I0zFwc1QkcpYKW6B778ok8hnGawaqklGsvhSvOcBgjOxbQpHVGAW5ddVmqxRiHZcGVRo JPpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773042434; x=1773647234; h=content-transfer-encoding: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; bh=qsabEXkhux99yzwsSjH5RxSJbqhPM5KtfGWU+0nIdFw=; b=ef3kCtLcxnNsQwSiU6+UxQ2JTKBxL3jQyGCQCHD3b2ZUwfc2Imcd7iYV58HSfAinIm +KdrASbc3IP+7oYtVoVEPwiXJ54RPwJC7mbIrBBzo1xs9WehOwKZaWL0rjbv84NVBMyQ VpHHlk87JWmnhexc3wiiRL8uZYy65NaFwGAoOHIg/L+HDUvYLb2/2pRhqgRy47L63W4n BLtD5lyJJ1WnY4/x/YkZEfEVN6uRmX2BT76jCP9xORdAAIU/iPTQlQg29lngHhj4S24L vIjZF5z2PIKhEenbJdX4/Lijo8Zo5D3iC+3Y2KwnQS92MqibU220DvuAdK+/KjsyCJ6N 4Lbg== X-Forwarded-Encrypted: i=1; AJvYcCXV9Kk7K4HEaMY7udSOwAXJisql9T3Uu4sqRLDNqylhsSjAXFoTyxGUSMXYcf1DDEO8KNIGVvOCNuI=@lists.xenproject.org X-Gm-Message-State: AOJu0YzMGEgXRt106PFGYg1OrGV4KZBcKN3xgSdQXXNjk7CJcKz2JuKw SnGQaVy8YzI+golTM2JEfPyDuYNzbaZxWPFyIbLfZvo2CPRrEdNrpo9j15yyZ7CjAA== X-Gm-Gg: ATEYQzwLs/70U1xN9dIB8QT/k1uTfILE3nbMepGhxI7SmGk5eu8anqQU6g4W8NUoXDn WT555RAO4K6N812I6oZuLZnIqUKZpacobtAsje6NR5fJc+DMNXyQw7BBaFgAShZO8oiLX+uOaPM OITZsK8wr7HFavHNgoLHXA8bLx7o1ztKhmKV/tA6yXN4iple4VO1vYMLEpo3gRadC4rAXFBM4BR 7FPhDK0y2yx17J9Tr4RhVzkIhhItj6105Fq7boX8C4ohsMkj2xWq5AC4CkrdObaXCZNYdRuYeX9 0yuN4A1tK73gzhWCypimkEtFYXvkcn3PKW3uSasEddzV/H7GF2A2mi5DHNnFdW4e2vbo/Lh8a/o LYVAIalXHP154Tl43KcGoOX4DdqdQYcvdB18tvZuvjlRMxJk++1SehqBExaJzZH4qD4m4ajQUxm xmH8icKvAwGag/vuLhijwW67Jdp8G5QTSqmPK8r6vf5rYtQ67OJLuSKvr9Tr69S/bnYXgAtXDH/ Z4ttu0QY9y/xao= X-Received: by 2002:a05:600c:8209:b0:485:3a93:3aa3 with SMTP id 5b1f17b1804b1-4853a933e17mr42287645e9.12.1773042434345; Mon, 09 Mar 2026 00:47:14 -0700 (PDT) Message-ID: <49d22b35-f5d8-4992-a32a-bb3f7c3e5ad2@suse.com> Date: Mon, 9 Mar 2026 08:47:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2026 17:25, Edwin Török wrote: > clang would duplicate the loop body and end up with a double definition > of the symbol: > ``` > /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is already defined > /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is already defined > ``` > > Until a better solution is found: disable all optimizations in the test runner. > > Using -Os might also work, but we can't rely on the size optimization > always avoiding the duplication of asm blocks. > This is test code, not performance critical code, and -O0 is more future > proof. Hmm, yes, the good thing is that this then doesn't even conflict with my https://lists.xen.org/archives/html/xen-devel/2023-04/msg00283.html. > --- a/tools/tests/x86_emulator/Makefile > +++ b/tools/tests/x86_emulator/Makefile > @@ -323,4 +323,9 @@ x86-emulate.o x86_emulate/%.o: HOSTCFLAGS += -D__XEN_TOOLS__ > $(call cc-option-add,HOSTCFLAGS-toplevel,HOSTCC,-fno-toplevel-reorder) > test_x86_emulator.o: HOSTCFLAGS += $(HOSTCFLAGS-toplevel) > > +# clang duplicates inline assembly when unrolling loops, > +# which causes a duplicate label error. > +# Until a better solution is found: disable all optimizations in the test runner. > +test_x86_emulator.o: HOSTCFLAGS += -O0 I think the first sentence may want wording a little differently, and I further think it absolutely needs to mention put_insn(). Maybe: "When unrolling loops, compilers may duplicate inline assembly. put_insn() emits labels, which may not be emitted multiple times." Happy to adjust while committing if you're okay with me doing so. There's one other question though: Isn't -O0 the default? Where would any other optimization setting come from in HOSTCFLAGS? Ah, I see ./Config.mk does this, for an unclear to me reason. Perhaps that would want mentioning here then as well. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 09 08:01:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 08:01:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249156.1546657 (Exim 4.92) (envelope-from ) id 1vzVYY-0003Or-BJ; Mon, 09 Mar 2026 08:01:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249156.1546657; Mon, 09 Mar 2026 08:01:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzVYY-0003Ok-8L; Mon, 09 Mar 2026 08:01:38 +0000 Received: by outflank-mailman (input) for mailman id 1249156; Mon, 09 Mar 2026 08:01:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzVYW-0003Oc-Vy for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 08:01:36 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 30e47894-1b8e-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 09:01:34 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-483487335c2so94070185e9.2 for ; Mon, 09 Mar 2026 01:01: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-4853a310b8fsm86052215e9.11.2026.03.09.01.01.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 01:01:33 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 30e47894-1b8e-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773043294; x=1773648094; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=BZTM1bGALy2lCngF9Ee8Ep5UL3DY9PWcQzrczS1SlxE=; b=W/MyENh1TJVN9CjnXw9LXI8ec935qBVNix04SHyT/LjGJBJThsqP3Y4GPVVCsA/VhL Zj2M1Z6sTz+QYIs4KIZVc/Ff68/rJg7X3TBBfu4AGqHpaMF6+RjvClmuCll4uHrftHXe 02SckAEla6VbQBnra+pS+Bdgoz6TmAfViM/y/L5TgOvMlCUCgSj1afMzjA9SQ5IzPpCS sGQXSg3241RBmsXKjogX1AK6qz3+r+6285RLzyPscWFs/az2ulvDNZA3R5fkWkJDCNZi ezqqTMH4w7cR8Tne9KC2MWTQR4NmAp0rU8x1hC8l58EU4uUgRlb85Ffq4DCK76QEXmQ+ 1bYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773043294; x=1773648094; h=content-transfer-encoding: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; bh=BZTM1bGALy2lCngF9Ee8Ep5UL3DY9PWcQzrczS1SlxE=; b=FH8VCdrxrNwNuNOZ5BmYnz4MxtoaZkE8Uy60kYV/ftij5y9VjMA0EOjbFxwFOAV66E 0pNDJRu3UoagR663S1HQL2m7fBwgjzWwnXdX46yvEQmGMzKpkew2arbTr+E/PorYBtM8 MxgnIPP70V0zc+5PdONdyLw5PSAEfnD7fwU2N2yrAOP0tWjcGxU8SxUMO5+7TRiyXfv6 4hA43bvIvdY0YkRltaE80ihk+gmrvXZ9HYkwsOeWsslHRQhFNO6lqiFGKwuNJy4b6587 aZHsO1o24cTW6V9nigEVFs2PHU00mf86vYjpPTyP441gsy6zoWiFIB9RqelwQrZ+mhsC ELhw== X-Gm-Message-State: AOJu0YzKNtx/uCIGlAqm9ONVef35Cjx5fZpqORVBV9iou5fjoBICmCaX sW+huxNvgEGc3dXj4OZAEPJCyliD725UTJA0LCnz5piYxKyXuqsLG3mxjTAUhGAUhw== X-Gm-Gg: ATEYQzwmGMw7kjZJ7Y4f/PCVvLMd91cp/H79HSSKiuqODYL8WbMSz7w4fS3/kHHY34/ 5jBZpqEoQwJq+Wu3Kg9COJfEfXHiOhWZl8kDJGIRUcMYuuWss5u80XB50dBPH2Cm6uBCLkMjwgd /oBW1wEhDVd5mnAhya61UuemlfqTSRZaRdrJNfJTAEYdhSNbmM0nQqgnrkIogZb74DsFpcAlbTD iuO2kWZCPSbLSvLag8y0zMo2iuqSMAHAHQfXLkG/M8XJH6aXcsj4HOgtiLclZQylx7X+rEqZ5FI RjombZtdpWqsL+eNgWSu7XFRHZGYRuD/0cxAygDTsaVCY8mABBYuhWkHlPEHrd/JG9BKtYP6lid CkGenjfysAEus9L7IaVE5iUbK3eTODSgHQP14IdQiZwJLtVEpEGbsGo+ikyX4rK8R97vv/vpwO1 k+Vs03JkpU5ffHZj8ef3ESYzx4vAf8yMnszEYVeMhYFEPIy/RCBMNSeCO9N7QRlleRIB2I+1v/u BnhYqwy/B6gWOC2UXvoa1EVYg== X-Received: by 2002:a05:600c:81c8:b0:485:3812:36f6 with SMTP id 5b1f17b1804b1-48538123973mr63720905e9.21.1773043293760; Mon, 09 Mar 2026 01:01:33 -0700 (PDT) Message-ID: <8b7e5cf6-e259-46a1-9af9-8b75242d9c7c@suse.com> Date: Mon, 9 Mar 2026 09:01:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] core-parking: shrink and relocate core_parking_cpunum[] To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2026 15:20, Roger Pau Monné wrote: > On Wed, Nov 12, 2025 at 04:38:13PM +0100, Jan Beulich wrote: >> This NR_CPUS-dimensioned array is likely unused on most installations. >> Therefore it is especially wasteful for it to consume more space than >> really needed. Use the smallest possible type. >> >> Further the array having all fields set to -1 is actually useless. Nothing >> relies on it, and core_parking_remove() doesn't restore the sentinel for >> vacated slots. Drop the initializers, moving the array to .bss. >> >> Finally take the opportunity and update an adjacent variable's type, where >> a fixed-width type was pretty clearly inappropriate to use. >> >> Signed-off-by: Jan Beulich >> --- >> I assume there is a reason this is acting (mostly) as a LIFO. Else a >> simple cpumask_t would suffice. >> >> An alternative would be to use the new BRK allocator, at least for NR_CPUS >> above a certain threshold. > > Can't we just allocate this memory using xvzalloc_array()? If we do > care about it being too big certainly allocating only when needed, and > based on the number of possible CPUs on the system would be much > better than playing games with the array type? Hmm, yes, how did it not occur to me to dynamically allocate the array? It can't be used ahead of core_parking_init(). (Not shrinking the array element type will still be a little wasteful, but perhaps that's acceptable to keep the code simple.) Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 09 08:46:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 08:46:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249170.1546671 (Exim 4.92) (envelope-from ) id 1vzWGC-0000FC-Oc; Mon, 09 Mar 2026 08:46:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249170.1546671; Mon, 09 Mar 2026 08:46:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzWGC-0000F4-LH; Mon, 09 Mar 2026 08:46:44 +0000 Received: by outflank-mailman (input) for mailman id 1249170; Mon, 09 Mar 2026 08:46:43 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzWGB-0000Ey-1o for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 08:46:43 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7d70ac1d-1b94-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 09:46:40 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-6615c766e60so5888409a12.3 for ; Mon, 09 Mar 2026 01:46: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 a640c23a62f3a-b942efb273csm332695366b.29.2026.03.09.01.46.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 01:46:38 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7d70ac1d-1b94-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773045999; x=1773650799; darn=lists.xenproject.org; h=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; bh=mzARPScbwnE1dvt8UvB7LVvBx6Pl5gHYQG6LHeQwFv4=; b=aALRuEnk/3JpFGE5VHvjmSpns/b77vXdfLhHlEm89BYsVoEZc+bOlJ+ZGFxrueZySk fU1xZbwE+aqrgJdLp/+2zEQFJiFwKiE0bEzM7QfSsmOL7Q0IBbY5Ox29O3opn9qL1VlK pSx8OQ5mQK8rlCV/LNq7bMuNwxoqJTKl5260O11SfdpNtaVrkbOiwCu/YS1djxp1vIRW u98x5GKo5FlSy7fvCAhRzq6oZpJE0H6UI0FxVM9FepANIj1+C9s0JEX+dqO17H4zOz5N S8Cmk75c5yEd37FmO2CL6UfvE8dYxFpUbHnexzccNCBFak0/kn5QOVWHPQ5wA/t0pBRP FtTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773045999; x=1773650799; h=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; bh=mzARPScbwnE1dvt8UvB7LVvBx6Pl5gHYQG6LHeQwFv4=; b=jNP9Uqo44hzlByRiT9XXceM62gt6Q+KV2jn9kgn5XlXR/oIDhgl6F+7zpCgJ1IXLvi xtxKsGbsLDSoYf6kM3QWvkqRj8chg4CCQvlm6m3F6aNrrxCIPnFyFzlNwwaFfYhi0S2E fGS2I9IYKvozBRDRZilUFnjrjqeeVs5F14rJSMpXoIt5F1svv8Oo/9z1HAzIKl5+J+LL 0VUT/M8cV/kor+YDh01xd9LFJqLMb5BZbmYuw5nBlwXAzzgYhsDEAHrWvbCqZS+il7rw SQV0V6HCpkDFR1BEMXIu6hi5NGNUTsZGhvSKf/Az1qfLXjkW7nzNAST4kmM88tnpmPNe 0Y5w== X-Gm-Message-State: AOJu0YwAtlWRm+7Ad+P5hWU6dRjBFZsPqBPlXW8W0dPmqWUyTTdgKdGc Ot/RJVIk3c0t3TtiMwG7HR2P56aNz9gy8oQCItqvt/gZHhxG5E8tcoxIJcXLjLEN9GI= X-Gm-Gg: ATEYQzwENIaXwxHmPTeHGrs62tzPP8w6VNZhBqvvqSaNRZHnW+KXipOhwHfgF4WGUwy 2FxhcqNy2TQxbAUOYQ1fFwSAbUsl90bc5bnkwtdfPmDVgqaINEc3UYJKA3jbQcg6BZNtsFAnyPW BV2DIU4w3uN0VG2JGMwmw9lhEsRJfrJszGdzpOpdFY5ubkfHVxGYOjvIgoYrjfZwD+QirMLG+do /KKW5cZ2FOb+TxrF8WzlKL6X+Llba+VMgYcOwEwMskP/vWUrQr9nh913/cpWzy0wgXl/9BSakh6 N85Ku7A1dgJMg7/9hFQKJm8+aIUqFFZGq9W6Kl6wO/yML6V9I3MBuiq0g03/qXaTlmKW/Em6fDL OSdN6iPc+E+EHr23d5oq0c3gu4OSBQrXmaEW2uJo6oYDWiFngZzXtfcuXV5iCh7s2/2SL985qG8 XOhm+bl10Duty+Lf7KCG9uvPB/tbBTnQnHzkU6FyzPEujaNoWCwWDjiA/1oD4Sbd2jG4Q2rT30N s7+Tk01sZl38X4y991KF+iwHBcIvgowYbk+0i87+6ciEL8VRAW43A== X-Received: by 2002:a17:906:f5a5:b0:b90:35c8:d01b with SMTP id a640c23a62f3a-b942df74781mr562384166b.36.1773045999253; Mon, 09 Mar 2026 01:46:39 -0700 (PDT) Message-ID: Date: Mon, 9 Mar 2026 09:46:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/grant-table: scope gnttab suspend and resume helpers to hibernate callbacks To: Pengpeng Hou , sstabellini@kernel.org, oleksandr_tyshchenko@epam.com Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, 18291782795@163.com References: <20260309083622.717803-1-pengpeng.hou@isrc.iscas.ac.cn> Content-Language: en-US From: Juergen Gross 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: <20260309083622.717803-1-pengpeng.hou@isrc.iscas.ac.cn> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4HXLkhp0pooATIYDhpvMKsoZ" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4HXLkhp0pooATIYDhpvMKsoZ Content-Type: multipart/mixed; boundary="------------hs29NsfQFLuM860P8kEdl2C0"; protected-headers="v1" From: Juergen Gross To: Pengpeng Hou , sstabellini@kernel.org, oleksandr_tyshchenko@epam.com Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, 18291782795@163.com Message-ID: Subject: Re: [PATCH] xen/grant-table: scope gnttab suspend and resume helpers to hibernate callbacks References: <20260309083622.717803-1-pengpeng.hou@isrc.iscas.ac.cn> In-Reply-To: <20260309083622.717803-1-pengpeng.hou@isrc.iscas.ac.cn> --------------hs29NsfQFLuM860P8kEdl2C0 Content-Type: multipart/mixed; boundary="------------y9t3zWFL0v0uuF0Tre27fsJl" --------------y9t3zWFL0v0uuF0Tre27fsJl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDkuMDMuMjYgMDk6MzYsIFBlbmdwZW5nIEhvdSB3cm90ZToNCj4gRnJvbTogcGVuZ3Bl bmcuaG91QGlzcmMuaXNjYXMuYWMuY24NCj4gDQo+IEluIGN1cnJlbnQgbGludXguZ2l0ICgx OTU0YzRmMDEyMjApLCBnbnR0YWJfc3VzcGVuZCgpIGFuZA0KPiBnbnR0YWJfcmVzdW1lKCkg YXJlIGRlZmluZWQgYW5kIGRlY2xhcmVkIHVuY29uZGl0aW9uYWxseS4gSG93ZXZlciwNCj4g dGhlaXIgb25seSBpbi10cmVlIGNhbGxlcnMgcmVzaWRlIGluIGRyaXZlcnMveGVuL21hbmFn ZS5jLCB3aGljaCBhcmUNCj4gZ3VhcmRlZCBieSAjaWZkZWYgQ09ORklHX0hJQkVSTkFURV9D QUxMQkFDS1MuDQo+IA0KPiBNYXRjaCB0aGUgaGVscGVyIHNjb3BlIHRvIHRoZWlyIGNhbGxl cnMgYnkgd3JhcHBpbmcgdGhlIGRlZmluaXRpb25zIGluDQo+IENPTkZJR19ISUJFUk5BVEVf Q0FMTEJBQ0tTIGFuZCBwcm92aWRpbmcgbm8tb3Agc3R1YnMgaW4gdGhlIGhlYWRlci4gVGhp cw0KPiBmaXhlcyB0aGUgY29uZmlnLXNjb3BlIG1pc21hdGNoIGFuZCByZWR1Y2VzIHRoZSBj b2RlIGZvb3RwcmludCB3aGVuDQo+IGhpYmVybmF0aW9uIGNhbGxiYWNrcyBhcmUgZGlzYWJs ZWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBwZW5ncGVuZy5ob3VAaXNyYy5pc2Nhcy5hYy5j bg0KPiAtLS0NCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMveGVuL2dyYW50LXRhYmxlLmMgYi9k cml2ZXJzL3hlbi9ncmFudC10YWJsZS5jDQo+IC0tLSBhL2RyaXZlcnMveGVuL2dyYW50LXRh YmxlLmMNCj4gKysrIGIvZHJpdmVycy94ZW4vZ3JhbnQtdGFibGUuYw0KPiBAQA0KPiAtaW50 IGdudHRhYl9yZXN1bWUodm9pZCkNCj4gKyNpZmRlZiBDT05GSUdfSElCRVJOQVRFX0NBTExC QUNLUw0KPiAraW50IGdudHRhYl9yZXN1bWUodm9pZCkNCj4gICB7DQo+ICAgCWdudHRhYl9y ZXF1ZXN0X3ZlcnNpb24oKTsNCj4gICAJcmV0dXJuIGdudHRhYl9zZXR1cCgpOw0KPiBAQA0K PiAgIAlpZiAoeGVuX3B2X2RvbWFpbigpKQ0KPiAgIAkJZ250dGFiX2ludGVyZmFjZS0+dW5t YXBfZnJhbWVzKCk7DQo+ICAgCXJldHVybiAwOw0KPiAgIH0NCj4gKyNlbmRpZg0KPiAgIA0K PiAgIHN0YXRpYyBpbnQgZ250dGFiX2V4cGFuZCh1bnNpZ25lZCBpbnQgcmVxX2VudHJpZXMp DQo+ICAgew0KPiBkaWZmIC0tZ2l0IGEvaW5jbHVkZS94ZW4vZ3JhbnRfdGFibGUuaCBiL2lu Y2x1ZGUveGVuL2dyYW50X3RhYmxlLmgNCj4gLS0tIGEvaW5jbHVkZS94ZW4vZ3JhbnRfdGFi bGUuaA0KPiArKysgYi9pbmNsdWRlL3hlbi9ncmFudF90YWJsZS5oDQo+IEBADQo+ICAgDQo+ ICAgaW50IGdudHRhYl9pbml0KHZvaWQpOw0KPiArI2lmZGVmIENPTkZJR19ISUJFUk5BVEVf Q0FMTEJBQ0tTDQo+ICAgaW50IGdudHRhYl9zdXNwZW5kKHZvaWQpOw0KPiAgIGludCBnbnR0 YWJfcmVzdW1lKHZvaWQpOw0KPiArI2Vsc2UNCj4gK3N0YXRpYyBpbmxpbmUgaW50IGdudHRh Yl9zdXNwZW5kKHZvaWQpDQo+ICt7DQo+ICsJcmV0dXJuIDA7DQo+ICt9DQo+ICsNCj4gK3N0 YXRpYyBpbmxpbmUgaW50IGdudHRhYl9yZXN1bWUodm9pZCkNCj4gK3sNCj4gKwlyZXR1cm4g MDsNCj4gK30NCj4gKyNlbmRpZg0KPiAgIA0KPiAgIGludCBnbnR0YWJfZ3JhbnRfZm9yZWln bl9hY2Nlc3MoZG9taWRfdCBkb21pZCwgdW5zaWduZWQgbG9uZyBmcmFtZSwNCj4gICAJCQkJ aW50IHJlYWRvbmx5KTsNCj4gDQo+IA0KDQpJIGRvIGFncmVlIG9uIHRoZSBwdXJwb3NlIG9m IHRoZSBwYXRjaCwgYnV0IHRoZSBwYXRjaCBpdHNlbGYgaXMgYSBsaXR0bGUNCmJpdCBzdHJh bmdlLiBUaGUgaHVua3MgbGFjayBhbnkgaW5mb3JtYXRpb24gYWJvdXQgbGluZSBudW1iZXJz IGFuZCBodW5rDQpzaXplLCBhbmQgdGhlIGNvbnRleHQgaXMgbm90IGNvbnNpc3RlbnQgKDAg LSA0IGxpbmVzIG9mIHVubW9kaWZpZWQgY29kZQ0KYXJvdW5kIHRoZSBtb2RpZmllZCBwYXJ0 cykuDQoNClBsZWFzZSBwcm9kdWNlIHRoZSBwYXRjaCB3aXRoIGEgcHJvcGVyIHRvb2wsIGxp a2UgImdpdCBmb3JtYXQtcGF0Y2giLg0KDQoNCkp1ZXJnZW4NCg== --------------y9t3zWFL0v0uuF0Tre27fsJl 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----- --------------y9t3zWFL0v0uuF0Tre27fsJl-- --------------hs29NsfQFLuM860P8kEdl2C0-- --------------4HXLkhp0pooATIYDhpvMKsoZ 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/Ey8FAmmuiO4FAwAAAAAACgkQsN6d1ii/Ey/z Wgf/QYyREP0AsSMRRar57XwrUdlkHBBy2KQ1h82B4amy0RmHL7CQ4fiW5Gvca/4eMjjE4bK3IRn9 o6nrVU/imftyXnTEV0MFh0yocZQDknDa2C8dcYMGaMFu08+gO+CXNWNnWKTPKPCdJEiJbVY4Llj8 bAcQnYsGEXqd0LkRhXTEcJnxK2gNDQDk7F/UJxrDuXS2M2VPF8hpK/TpLI2kmmyNlLqmZt+uBRQf OS9PM4Zcs2/niwLkNdZ4WMWliVZZtYuyiLNYpc7NIgk7ogayHVuY31NctQ3+9UvPnelHoxuB2FOg 38Pj4/wDd2wh49rPZVNrerc+a9ejlX1nNSPTyyvogg== =wdKK -----END PGP SIGNATURE----- --------------4HXLkhp0pooATIYDhpvMKsoZ-- From xen-devel-bounces@lists.xenproject.org Mon Mar 09 08:47:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 08:47:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249168.1546681 (Exim 4.92) (envelope-from ) id 1vzWGS-0000W6-WE; Mon, 09 Mar 2026 08:47:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249168.1546681; Mon, 09 Mar 2026 08:47:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzWGS-0000Vz-SC; Mon, 09 Mar 2026 08:47:00 +0000 Received: by outflank-mailman (input) for mailman id 1249168; Mon, 09 Mar 2026 08:37:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzW78-0007Y7-EB for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 08:37:22 +0000 Received: from cstnet.cn (smtp25.cstnet.cn [159.226.251.25]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2bf5d2b0-1b93-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 09:37:17 +0100 (CET) Received: from localhost.localdomain (unknown [210.73.43.101]) by APP-05 (Coremail) with SMTP id zQCowABX7A+yhq5pUEjxCQ--.52456S2; Mon, 09 Mar 2026 16:37:06 +0800 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2bf5d2b0-1b93-11f1-b164-2bf370ae4941 From: Pengpeng Hou To: jgross@suse.com, sstabellini@kernel.org, oleksandr_tyshchenko@epam.com Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, 18291782795@163.com, pengpeng.hou@isrc.iscas.ac.cn Subject: [PATCH] xen/grant-table: scope gnttab suspend and resume helpers to hibernate callbacks Date: Mon, 9 Mar 2026 08:36:22 +0000 Message-Id: <20260309083622.717803-1-pengpeng.hou@isrc.iscas.ac.cn> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowABX7A+yhq5pUEjxCQ--.52456S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AFyfCFW7Wr4UCw1UKF1xKrg_yoW8Xw1fpF WDJrWjyrZ8Ga4SvFWSya4FyFy5Ca9xJayxJrs8urZxZa1xGF1xArWSqFy0vrn7GrW8JF4v yFsFg343Cr4UZFUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvv14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r 4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCY1x0262kKe7AKxVWU AVWUtwCY02Avz4vE14v_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr 1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE 14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7 IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E 87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73Uj IFyTuYvjfU8wIDDUUUU X-Originating-IP: [210.73.43.101] X-CM-SenderInfo: pshqw1hhqjhx1rx6x21ufox2xfdvhtffof0/ From: pengpeng.hou@isrc.iscas.ac.cn In current linux.git (1954c4f01220), gnttab_suspend() and gnttab_resume() are defined and declared unconditionally. However, their only in-tree callers reside in drivers/xen/manage.c, which are guarded by #ifdef CONFIG_HIBERNATE_CALLBACKS. Match the helper scope to their callers by wrapping the definitions in CONFIG_HIBERNATE_CALLBACKS and providing no-op stubs in the header. This fixes the config-scope mismatch and reduces the code footprint when hibernation callbacks are disabled. Signed-off-by: pengpeng.hou@isrc.iscas.ac.cn --- diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -int gnttab_resume(void) +#ifdef CONFIG_HIBERNATE_CALLBACKS +int gnttab_resume(void) { gnttab_request_version(); return gnttab_setup(); @@ if (xen_pv_domain()) gnttab_interface->unmap_frames(); return 0; } +#endif static int gnttab_expand(unsigned int req_entries) { diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ int gnttab_init(void); +#ifdef CONFIG_HIBERNATE_CALLBACKS int gnttab_suspend(void); int gnttab_resume(void); +#else +static inline int gnttab_suspend(void) +{ + return 0; +} + +static inline int gnttab_resume(void) +{ + return 0; +} +#endif int gnttab_grant_foreign_access(domid_t domid, unsigned long frame, int readonly); From xen-devel-bounces@lists.xenproject.org Mon Mar 09 09:23:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 09:23:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249189.1546689 (Exim 4.92) (envelope-from ) id 1vzWp5-0005fl-Fv; Mon, 09 Mar 2026 09:22:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249189.1546689; Mon, 09 Mar 2026 09:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzWp5-0005fe-Cf; Mon, 09 Mar 2026 09:22:47 +0000 Received: by outflank-mailman (input) for mailman id 1249189; Mon, 09 Mar 2026 09:22:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzWp3-0005fX-A0 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 09:22:45 +0000 Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c000::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 86307fa3-1b99-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 10:22:43 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by LV4PR03MB8284.namprd03.prod.outlook.com (2603:10b6:408:2e0::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 09:22:39 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c%4]) with mapi id 15.20.9678.024; Mon, 9 Mar 2026 09:22:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 86307fa3-1b99-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=giDUUfhdXUGAJg5eIfqbMDYy2HuO4dejAhx6ILZONa8uTpGYvpk4DSuW5eQRnoscqqOjiL1tj1vOMJKBenwrRyJtnfb7sYRLqh+JJ/Al8MtdTCePDHo4Lv439nnclqNHNwo88iah9EubcVFTLf9j/v2d6qGjOOgHqL0tMgCeFs0+RWENvTagJrmY8zS+HuqyvMqf8p6L95mhKf1+tXPxCOVkpaJm3xmhVcg31yuhBXI0iVA0YhU5+cQ6MPDEFsZ5WqkjfpMdl8QcYFQpBIHX4XADAiMydzP39GI+noegW5ztjlwYyNTnMHbvsv6dwZlatU/eDLG8cfFKrhtmfO4q9w== 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=DCyJRSxi8Ee2tAMTwB+64n2mYRJXbAoslZsTiGaa2TE=; b=JnZASNDYUeSxEiXdV+JGITpkCd3zxbualZcHhswxXaJGCN0f9tZ0c9OnIFhf3q4Up7Foutu6NbFlBPmsHqkNqio+t3JuAOViDsjexZwfk+POAfBvoxkkep7JuY3vYcoFP6CWDJVJOHsNU1rkgWL0kSFCggyb35NQhQdvmHSqLHsJYv24d771DLbXxnXaMgTmah7CTCDpATpN3XAs/Z0zNTgv1z+4YTYdmIe5jQ0vTLT3DICrV8RTeYmmM3VGAWeUEfjVaC82Cb6GFDQa1SVK5ITKUbACj+VeoglPssKPY4CUavFcjRJUKA7lOmCak9Wgi+nQ4My+XmUkwZJHr0WcQQ== 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=DCyJRSxi8Ee2tAMTwB+64n2mYRJXbAoslZsTiGaa2TE=; b=cPObCUnpxXDtkL78tJVsMXQW2MWx6+ypgPuqQOMDseEftr1N3LT+HnM0oJ+lBFH//uS0oxpR6/Wo79UWgpHXVKQbucYvRgyFbT57NXEnopvbSOJBL+uOD+FoszKu5G5vg0GfJB+TeGX7BZKEcOhJ1muOtSXzoBHYRSwyChKBC1Y= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Mon, 9 Mar 2026 10:21:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] core-parking: shrink and relocate core_parking_cpunum[] Message-ID: References: <8b7e5cf6-e259-46a1-9af9-8b75242d9c7c@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8b7e5cf6-e259-46a1-9af9-8b75242d9c7c@suse.com> X-ClientProxiedBy: MA3P292CA0014.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|LV4PR03MB8284:EE_ X-MS-Office365-Filtering-Correlation-Id: 634c1685-9318-4a57-349a-08de7dbd5b89 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007; X-Microsoft-Antispam-Message-Info: GPvctX4W1IzA1IgI6d8WPBsFWge7BAuPMNupBRHrROQuNR5nl3Fueta28pLkzqIIRBjq80TDsbf5wxJb2W4PpUOpRDhcFXuxNWfdYtpaqR4D3PidHNk4yE14tVoVirZVRaeASz1n32MLrMpq/2MeDdlilrWZJRRqhO5dnkzM2RDG2DveFihEiGUkUjJcxLaAM/aXxNXSSiiWa0e6szGLjt6UysF6ZOdHwucxTx48j/GEVEe7qMCMOPsak9wqRJQFDL6jpxVawm64TGfKpnaHNu37pGwSQQaX7DB+aCqsGwQ2mTPBaLG+iQc/syHiR+tYYqU8IfzwAji4ocFl0VCYkW/SA1HVU4ay6fL95qWpkoM/olGE4dsmiKW/9Xn8YX7WrsE1B+9Wp3jMjQsRC3EmMiLwi3L+Z7vihqNsDQWb336c+RbzFxoCysypQwIWOAEdyzpp7xJ3sp3n/MiqyJEROeWtMf7eoLMgzeLIDBLfH/qREifOffmUnW9Uoy7BA4Wo86roZc5ANxhHmMM3yq+x9390NAI/jccBC5uVYgBFCnAJ/EJLvp6ju0h+vvEF0X+TnbqJVamNEfdC93Rvd4eD5Ke+Myy+7lTG+tJ5KY9iXkaDZvSouHgM9qKL/1O7Oe/aIyaay5bxoCPfXXavBAumf2KUY+H6LrlFlK8Tq9uLAT2UzkaIj/ehgiMAjDYwS85ASpQkGg9+IZb+Ik2SVXYZYU96V/bSor6QfgSuBJCuxtw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ODZVWGZYeElCbWN1dEhmdFFjcUwxdTlXQXJQeE5xUnlkV1Yxc0toY1c3WnpJ?= =?utf-8?B?WkFQVEttSTBOeGxtSXpoSUJlVnV3NXhaTmdBbnI4bXYvcGtFSWRXSkJFOS96?= =?utf-8?B?UFBBUEE2MTdtMlhmdnZGMHJNbmhRckJiSldEZlhhRUpMQVpqM29heFlOeWRq?= =?utf-8?B?bmpJV2tSOXF4ZjhuNnhoVVkwUTBxbS9CUkNEKzBvd01zVUF0TlBGbWZQMjRy?= =?utf-8?B?UjRJMGxVR1FQb3c0bUNBYzJ2MGJIY1AyMGU4R3NsaXpmOEswSWY0bDZxc2tE?= =?utf-8?B?VnRLNm9BVXlURzBiVXNVYjYxdW03a25SbWxmTjZ5VkRDN3NFZzRMVkd4QkFw?= =?utf-8?B?TEZEWkRhY0M3NVdWRnFScWtUVmlCb0gremR3Q1RuRENBdFc2blcrRVBuM1Bu?= =?utf-8?B?cms0N3hjS2NYR1RDRUh4RThWcTZHOXpqUWVaU01sZG04YU8xWnlHd3BpdjFm?= =?utf-8?B?L3lRUkpaczBJRjBtMmJxdTVjcjdRU1lHc0liVmtEbUJVNVIrekJLT3plU2xQ?= =?utf-8?B?ZlJHekMxUjh4bWRqVUJJem1PTmR2d1lHb2pDdHVPS3pHa2djTlJKRjBvSU5s?= =?utf-8?B?UEl6Wi8vTnZKMkFKWUttZGliQWgvZzdFNnVWQytMYWpFK3FDL3BRNUs5WENB?= =?utf-8?B?L3FVMTRla1Q4UlVZSm5DUGNmUjZEdDR4SXNtUkF3dDR1Qjdxa05qQjBZYXJR?= =?utf-8?B?WGQ1K2xhaUk4ZGhIWnR0eFhXeWV6dWg2VVg4T1FqY0hqeitEdHpUUkp1bHNx?= =?utf-8?B?TGM1ZEJBTXVRaVNBQk1CNTA5RVc5UDduSlkrZllLS0ZvR0Z2TURSN2QyNGJE?= =?utf-8?B?OGhDTjlJOW1OY1oyZndVSXZ4ZmJlV0kxVHQybWN0YXB4Vmt1S2J6b2RUSDVF?= =?utf-8?B?M0lLaGw5SmRtN2lBdHlBOUxlMkkxYjkxaFdRTHJScTQxd3hhS2QxeDQ2Tlda?= =?utf-8?B?Qi94VStTTVJrd1pKWDJscGZncVhSaGdDR3BPZ04yd293bUN5cVRVZjYzRStM?= =?utf-8?B?QzYvSzNKblNhZTRQVzYybXNOV203dnNadzR4OWZPTGhpYkRFUmhVc1BJRXdB?= =?utf-8?B?d2ZmYjZOS3lEd0ZnS1p4TUZmd2d2ZkcrUGluWThJTEF6bnNsaWVsZ0FhSzRR?= =?utf-8?B?cjJsNnVkczJpVW14R2NPYXYwdHJ5OVIrMnZ1T01wTmpCa0luWFExTGwwT0xK?= =?utf-8?B?N0lzeG5yOFJQUGh3a2ZTbnlkanBlSmY0MnVTcTltWnRYMW1VdW5nNCs4Qml2?= =?utf-8?B?Ujd6bzFjOU4waDk5cVRzSktaWGZKVmI1S2VreUE1REdBYW1lVWM0OVpkb3h1?= =?utf-8?B?YjE3aGEvcFo0NmJkVXlUUnkwYWlYb2xCYThJV0pCU09ySnowQVI4ZDU0VCtB?= =?utf-8?B?TnYxcHlaR1hISDRDTkNTaTMwUVAzUnJNZGZ5aStNanFyNUo3NERYc2N5ZzBY?= =?utf-8?B?ejBUSmx1Yzd3ZVVaT1kzOGpmRlNrQ2ZVazhpU21RSUp0MHg4QU9GTUxUL2E2?= =?utf-8?B?QmlVdFU4ejRZMUx6bEJRM01YVVRDUmRzWnczVFdhaHR2cmE3YXBTZmQ2YVdP?= =?utf-8?B?eUpKWDM2STdTNkFZTWhGVzRnK0ZHMmZOVTl4c2h4NjhOdlE1QnRXT0lRbm9h?= =?utf-8?B?NUNhU0d0OEhxRjRBaGVCWmpTWURSZGhrSWNYbVcwU2pZOUZUMDNQY0E5UDI4?= =?utf-8?B?c1F2dVZLV3ZuYzJLSUM0K1NqQUgwNHl2enp0cHRTVWloVWdqdWY0dDlKazBM?= =?utf-8?B?L0xGUHFEckl6RFZJS2RYbWRjL2NmYjRnQ1pZQ3dRU3doNUt0QWtlNlRtWlpY?= =?utf-8?B?ajM5c2RWM3Uzd2dTR2N6UU1mOElwam9DMHFVUVUyUjBCeVhtV3Q5SGR2R1Zn?= =?utf-8?B?TmxISm5DN1lzS1R3NGQ2M0gwWFRTcXRxWFhzVHliTE5mbENiOGJQYU9HeXZQ?= =?utf-8?B?VE55RjVpNC9nRmRicnNtaVg0eGJCd0lyU3VFTkdkQUZ3L3NsUElUd2dCSDdT?= =?utf-8?B?Z2t6cTdqaThQSEQ1WlE3d0NIdGJxRjUrdXdNSnMyQ1VWWWtyQitTQ0l5VVRR?= =?utf-8?B?Y3pTREo2UlZIMkhiNU5lRXJleDhUMXhnZjVIT0RmWnV2MHJSRCtRZHJYNUh1?= =?utf-8?B?dHZqZXZMVkJWRUdjQXFIM25IOU1YQ2tldkRlUVlycUhyWHoybXRJRXkyVFkv?= =?utf-8?B?dXZqdWo2SGVTbDRVQjVZVVl2UVhNcVZoUjA5UDJLbDlFbjhOTnRaQlNDaU9L?= =?utf-8?B?T0UyTTJ4MUljNXpFeE5vVFl5K3ZGdEZKMkowZXRsc1o2VGxPTzdMT1V2eWYv?= =?utf-8?B?b2FNYlpCSHpmR25IOEI0UVI5U2tsM24zdy9HVG1rSG5OUzlHd1BTUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 634c1685-9318-4a57-349a-08de7dbd5b89 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 09:22:38.8217 (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: vWHn68zK64jqkkAknehiL4AY3OgqEBXQGh+RZsUxAEzRVxdcOxKFtoampW+78PFH3z9odbSerBgU4Xd41NyMpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV4PR03MB8284 On Mon, Mar 09, 2026 at 09:01:35AM +0100, Jan Beulich wrote: > On 06.03.2026 15:20, Roger Pau Monné wrote: > > On Wed, Nov 12, 2025 at 04:38:13PM +0100, Jan Beulich wrote: > >> This NR_CPUS-dimensioned array is likely unused on most installations. > >> Therefore it is especially wasteful for it to consume more space than > >> really needed. Use the smallest possible type. > >> > >> Further the array having all fields set to -1 is actually useless. Nothing > >> relies on it, and core_parking_remove() doesn't restore the sentinel for > >> vacated slots. Drop the initializers, moving the array to .bss. > >> > >> Finally take the opportunity and update an adjacent variable's type, where > >> a fixed-width type was pretty clearly inappropriate to use. > >> > >> Signed-off-by: Jan Beulich > >> --- > >> I assume there is a reason this is acting (mostly) as a LIFO. Else a > >> simple cpumask_t would suffice. > >> > >> An alternative would be to use the new BRK allocator, at least for NR_CPUS > >> above a certain threshold. > > > > Can't we just allocate this memory using xvzalloc_array()? If we do > > care about it being too big certainly allocating only when needed, and > > based on the number of possible CPUs on the system would be much > > better than playing games with the array type? > > Hmm, yes, how did it not occur to me to dynamically allocate the array? > It can't be used ahead of core_parking_init(). (Not shrinking the array > element type will still be a little wasteful, but perhaps that's > acceptable to keep the code simple.) We don't shrink other similar element types based on the supported CPU count. Iff we ever wanted to do this (which I'm not sure) we should introduce a new typedef that generalizes the optimization rather than open coding it (ie: cpu_id_t or similar?) Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 09 09:49:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 09:49:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249200.1546697 (Exim 4.92) (envelope-from ) id 1vzXF5-0000Cy-H0; Mon, 09 Mar 2026 09:49:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249200.1546697; Mon, 09 Mar 2026 09:49:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzXF5-0000Cr-E0; Mon, 09 Mar 2026 09:49:39 +0000 Received: by outflank-mailman (input) for mailman id 1249200; Mon, 09 Mar 2026 09:49:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzXF4-0000Cl-PU for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 09:49:38 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 484bca3d-1b9d-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 10:49:37 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by IA3PR03MB8454.namprd03.prod.outlook.com (2603:10b6:208:53c::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18; Mon, 9 Mar 2026 09:49:33 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9678.024; Mon, 9 Mar 2026 09:49:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 484bca3d-1b9d-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AhKYOtCVY8fo+83hBBKnvCE1AhZml82iSrrLTtv0AZHyLkHBWtRjwhiIlFbJkLLGux53MpePhy7AnEs51D9Hdr+JRXXK6z3YdIFnvQhFNDi1AM+VM8gWJwRwiOsIm+HLfOFLhmFmv+bfuHM8M8lH8hiQxCvdQdxuNHhcHp0JTinHTv/b6ptn7mpwipdi8LrLKBVgRX9jcmS1EFD+2PNA/r+RiVtNL7+8kvotgjdlmAqEtcUVWFhR5RABvyM9DMciRloromj9j8vZ8jQzMjfCcCbYCdWLRhdexT4EKvdV/Z+X7nf6lhzwudDC0e/yVj8TDktSMekAH+i6dzgpzKnNBA== 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=NYJxUgiPO3of0y9hfACZwYYPr9iPHgeW7LPoEkymUb4=; b=njuy9FN5npYlGSzIKieOmvk2B0FJEBaYetq4bHyQAIHeL9Ye+NgB1ECZH3U/ntD6O6E87DM66iC+qLuDkFqZcPFThNZmfMYZFesa9jOT6tThWFuf+WW+YHR8Cr5WyET0Ovlz54Jc6iW+fmCqM/QZv25FkKEmZgtuvOY+MrFftHSjrOJsLcfE4Su2lvPEMwUUZpoYJTpTk/+PWV/OedpKiS0stYlRKBzCZYKYkoTt38miA8/jviqyCuag+6kErqj4fOy2GJc5ssX8ey7zoC60l191iQ0bNi+pmQszf6vg/gcZNJ//aVVI5LPcyNY8v6XZ3JaMWfgaxso8tq0rw9JQ1Q== 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=NYJxUgiPO3of0y9hfACZwYYPr9iPHgeW7LPoEkymUb4=; b=n384mOnbU1hFJA0GPZ6K9v68VUttNafVRH7g9xS2Z/qJTN1xHDdDaA/G4DVUImwAzicwz/JWgm3PhOp5SlXKXTYSOwH11UGStOEZGC0iZBh1+UH5IDEY4P7GVvcYnNsm7Yuvuf2FvTYP+SE3j6bdznK6rAODv0usgTD7bbWmY7A= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Topic: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Index: AQHcrYXnXQSbfSYkDE2XRiS+3V/VSLWl1toAgAAhtYA= Date: Mon, 9 Mar 2026 09:49:33 +0000 Message-ID: <5B5A0A1C-B7EA-47F2-8CF9-3000CF4414F1@citrix.com> References: <49d22b35-f5d8-4992-a32a-bb3f7c3e5ad2@suse.com> In-Reply-To: <49d22b35-f5d8-4992-a32a-bb3f7c3e5ad2@suse.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.400.21) 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: SA3PR03MB7419:EE_|IA3PR03MB8454:EE_ x-ms-office365-filtering-correlation-id: fee31f6c-a740-4b55-59cc-08de7dc12abc x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700021; x-microsoft-antispam-message-info: tZDg1XrttwgL1N99RUTF4OITvRmArSa8fx/WdaAOTPMkhmiROY8NZbtTbqmSDD+7jN+6tpucJHRyXUjkyfu6p5+02m2zO/0Jr0VujPeXEW6PvMZe/Aj95wNtmIWBUPMw9Zhoz34v6au1auoU9KCHXnSv/iQ7qZtdJrDKwSkS0ylJQQphb3FaL8c8AgAywn2e/Xx2AqRhuid85NPbc+qVuHZ/2Xpgudy+fnPOxPGFb2OR6sjs2rT3I3faltgHQhfl/T8LWF95ujPkwGTFqDEn0LojFal1mjsPlJQFF/6nGlZf/OG194JnuO21iP6pzkwsU5G/35uZKuM9CL9dLxkmnygNaZ5dejXSZzKDPG+Q5br01b0bnqMF7uF7sGk/bpmn+16hb94GZTX54dmh5KSu0h1/1MrG/mgBZYzu3VSnd3Z4vZFueb/9IqmVjlATJOV8wdT1c41TKfET1eIAYA+6bwwb27zUP7cdI/+hYqYPLr7RIT/ceDYQkThfY8qFCRw5Z4BEeSJUBDLWWeSnG49nIFeE8Z7UUbAysurvLvJItEEGlCJUamP0pfahp4don8J5C39sQPmJ/ugs2fkpdXaDEU/NHuGhqFaChqdcnt7/eZvBnbR021AxzQ5f3PMINOdKe7WlqTs79w8LyPNU1wCiaqdmT5VmxnZVXIt0G5EQNe3agglCL41cgbAWwmkYcsoxpNOwzXeTlGp1uMK7kmYdApzSXH796R1LG0+reA+s4t/f+bYqz9oGL4Ifh3r58hPni0QwecN3Hu9XS7Nq2D1fJSFLg3P4fuT/FRdRp8djji4= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VVdnWFFxUTE4K0pOT2dhaUNOR2RzNXZ2YTZXMjAvZ0hsTXNRWHdmRXUxNk84?= =?utf-8?B?bjRWdnhtd3FHb1gxS2V1RnBaQXhCeWtYMnlPRFg0VVpUVDRjZmFycThCTUs2?= =?utf-8?B?UlltZ09YWU1FK09IU3lpMENqUlNSYkdSdUVKV2M1a2UxR21XeE9kZnZkNXNR?= =?utf-8?B?cGVWRXlxaG9LcjRVbS9VRS9qRWN0bytOdmk3M1VSZGRsT3FiVDkzdUFzSC9i?= =?utf-8?B?RzdWaFd3ODhJQUJtWTRqazlLaEFUWVdxbnRWbnp0cU42R3hNaWM0SHUxands?= =?utf-8?B?b0VUZ202a0JnMk1uc1I4SzdoazIwTU15V25IblFiT0kwQ0FZL1lOZUlXWE5T?= =?utf-8?B?K1ZmUmx3bzdZQVUxWWNIeXAybGRHdENYVWJYbjFsRHNheEhnVjIzOHE0b0hV?= =?utf-8?B?QjlRdzBDSmlrTXY4UDkzc2JRMWJ2NWQ4bmQzZmJHbEdaQ28wU0I5Rnk5Z1FT?= =?utf-8?B?RlRpenFRTkI4S3JabWVmQnhET3pMYTk0dnBRc1gxOG9iY0g4M0FaYU1VcXZ4?= =?utf-8?B?ak9hZ1BlNnJmVGlpK3ZFMFRIUDRwbFZTRHNiVGpja2dQN1h4MjlHM2wxYktz?= =?utf-8?B?SDJVdXZQaEhhNS9pdjdNM3gxeUY0QmNyV3FDa1RKZzI0T2FhTHV4M3VWb3g1?= =?utf-8?B?NkJ3SnRiNWhnTVc4OGlMN3hZcmE1cFUyWUJJVDZCbkpjSTQwYkw2NXhoS1Vm?= =?utf-8?B?NUdwWHg2NG5jWWFRUGkweHBVU0huVHMzamtiLzJFMUlHL01Rczh6dXdXaGlT?= =?utf-8?B?Wmk4ZHZxRWdwWmh1WHZZRnZkVDk3SEhUSHBDTDZNNm1aS3VEcUwvWmVHT3N0?= =?utf-8?B?RmplNGxSUHRRWlBpdXNmN3pIbFliYjU3SmMyb0NBbmFsaXdndm5MeUgxSkVD?= =?utf-8?B?cW5NK1VMYW0xU081OXQvZDYxekRDVktzMUZFYWhLMm1jZFNsb25CdlVUMms2?= =?utf-8?B?K05Jd0pXY3doc25mMm4xTXFZVHBrbkplTi91MzA0Y1lyTmM4L3ZFbkdxZmNB?= =?utf-8?B?VmNxUzBxZFNUY3JaT0ozTVdHa1YrSUEydWZWL2MwOUhKYXJaNjFheG9VZm1z?= =?utf-8?B?N1JlZThSVm54YUhXK1k5Z05Edk91TGQwWTlLRmdrQWtlUkJzWFJJUk9CZFJL?= =?utf-8?B?ano1cWMyWkZReGQ5V3d4Rlk1UnRLV2JMNHRIbDc5aUQzOW1DUXNYNUxpOXFx?= =?utf-8?B?aWtGR3A4SGxRZlVjeTVPWGNzbWFTOXpFbk1zQXBLTWFLWDl2REx5MmNYU2xL?= =?utf-8?B?bUMzbGNmeVZOMThUTGFlUTZKSjVBK0hLb0YwMHlaSlMxMjFLYkRsZW9LeXA2?= =?utf-8?B?MjA3RjNzc28rNyt6d3pER1JVZVZyWXYvSi9BTk01L0YxbVN5NWp4RDNsd1NE?= =?utf-8?B?QnVLcGs3VkRmczVJUTEzRlZlL0FFWmw0TkEyMmxYcGg3ajlVbWhxYm5qNTNr?= =?utf-8?B?R3FxbitzMW14Z29SWUpQanpUK0w2aVZhbnlnUVZuTmZOL1FXbmJvQnptMVJj?= =?utf-8?B?L1lkaUtCcWZyTEN0MG1nTXB0NGN1TGRybjFmbzYxTnlRMGVXZmwwSTJqNHFN?= =?utf-8?B?ZFNXcVVnSWNjam5YTlVUbzFWN0NMenNuN1pvS3JKN3YyTUlJdFZYd1Y1QVh6?= =?utf-8?B?REIrbDhOZGhoMlJ5SmRyQ3pGVUdHTTM2UDJMTXhodTBoZ1BSU0o5c0V0RUhH?= =?utf-8?B?Z09YOTRPSm1pcThGQ0RUZytLWGE2KzNLSmlidGZWMEdkcThBTlU1TnY5V3BZ?= =?utf-8?B?MFUzNVpuZ3Q3ckVkZ3NxRWFwcUh5dXUxb1RFWW42bmN0V3l5REdNR1g0SzQx?= =?utf-8?B?QlExeXFPNG1jYU5nKzN0THlCRjQ3QjBnYnZsMmpYTERJZi82eE0rbFBGR1dm?= =?utf-8?B?a01KVzFIci9kUGxSa25GeG9kNjh0cXBoRGdGKzBTUWxQRUJNdlFaNzVjZ2xS?= =?utf-8?B?VklqYzRNLzVqZ25STi9xUVdPZENtcWlUdVBqYk8rTVllUVhqY3I4a0pqSlVp?= =?utf-8?B?QWVwNi90UzhLSHFYNmUyYTFjUU94Ly9oRnZMK3ZFQ3VRd1ZoMVNHSkJSSkZG?= =?utf-8?B?c1h5bVZLeE9sbVY3NHdiYXFJL1FodllDNkRsMFZuMlgzd0pTYjk4bHY1YU9N?= =?utf-8?B?ZmdNVDFCUGRabTZITEtYSWpyano2amZkd21tTHlIby80Z0RHOTV3TUJaM0k1?= =?utf-8?B?S3JtTFl6RGFLM1FPRU9WQWx4VGkxb0swd0V2TU5mS29QSXk3L3o0V0VPbDJp?= =?utf-8?B?NWdLdGUvM2RqNFRZQmZ6aUg0R3lzNTVrSmtjd25HUG9FODMyR0xHY0FjWTIy?= =?utf-8?B?ZExlM2U1ZWtpYzRMMGgzZW5OVXNqYmJvZk85T0R2RGtiTG1oeFdHeEJJeGdr?= =?utf-8?Q?NFJrgaLlpS58J7YU=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <1326BF537297954E827C06FAD71B89A8@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fee31f6c-a740-4b55-59cc-08de7dc12abc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 09:49:33.1413 (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: MLiyHth4BibpM03gPcEr0JnRZwqsDFX4vYz3aG+0FmgYMteEXr4OlhWwR1SwodAHsr2hFLj+78oeTTNJ9i7s8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA3PR03MB8454 DQoNCj4gT24gOSBNYXIgMjAyNiwgYXQgMDc6NDcsIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwNi4wMy4yMDI2IDE3OjI1LCBFZHdpbiBUw7Zyw7ZrIHdy b3RlOg0KPj4gY2xhbmcgd291bGQgZHVwbGljYXRlIHRoZSBsb29wIGJvZHkgYW5kIGVuZCB1cCB3 aXRoIGEgZG91YmxlIGRlZmluaXRpb24NCj4+IG9mIHRoZSBzeW1ib2w6DQo+PiBgYGANCj4+IC90 bXAvdGVzdF94ODZfZW11bGF0b3ItMGYzNTc2LnM6Mjc4MjM6IEVycm9yOiBzeW1ib2wgYHZtb3Zz aF90b19tZW0nIGlzIGFscmVhZHkgZGVmaW5lZA0KPj4gL3RtcC90ZXN0X3g4Nl9lbXVsYXRvci0w ZjM1NzYuczoyNzgyNTogRXJyb3I6IHN5bWJvbCBgLkx2bW92c2hfdG9fbWVtX2VuZCcgaXMgYWxy ZWFkeSBkZWZpbmVkDQo+PiBgYGANCj4+IA0KPj4gVW50aWwgYSBiZXR0ZXIgc29sdXRpb24gaXMg Zm91bmQ6IGRpc2FibGUgYWxsIG9wdGltaXphdGlvbnMgaW4gdGhlIHRlc3QgcnVubmVyLg0KPj4g DQo+PiBVc2luZyAtT3MgbWlnaHQgYWxzbyB3b3JrLCBidXQgd2UgY2FuJ3QgcmVseSBvbiB0aGUg c2l6ZSBvcHRpbWl6YXRpb24NCj4+IGFsd2F5cyBhdm9pZGluZyB0aGUgZHVwbGljYXRpb24gb2Yg YXNtIGJsb2Nrcy4NCj4+IFRoaXMgaXMgdGVzdCBjb2RlLCBub3QgcGVyZm9ybWFuY2UgY3JpdGlj YWwgY29kZSwgYW5kIC1PMCBpcyBtb3JlIGZ1dHVyZQ0KPj4gcHJvb2YuDQo+IA0KPiBIbW0sIHll cywgdGhlIGdvb2QgdGhpbmcgaXMgdGhhdCB0aGlzIHRoZW4gZG9lc24ndCBldmVuIGNvbmZsaWN0 IHdpdGggbXkNCj4gaHR0cHM6Ly9saXN0cy54ZW4ub3JnL2FyY2hpdmVzL2h0bWwveGVuLWRldmVs LzIwMjMtMDQvbXNnMDAyODMuaHRtbC4NCj4gDQo+PiAtLS0gYS90b29scy90ZXN0cy94ODZfZW11 bGF0b3IvTWFrZWZpbGUNCj4+ICsrKyBiL3Rvb2xzL3Rlc3RzL3g4Nl9lbXVsYXRvci9NYWtlZmls ZQ0KPj4gQEAgLTMyMyw0ICszMjMsOSBAQCB4ODYtZW11bGF0ZS5vIHg4Nl9lbXVsYXRlLyUubzog SE9TVENGTEFHUyArPSAtRF9fWEVOX1RPT0xTX18NCj4+ICQoY2FsbCBjYy1vcHRpb24tYWRkLEhP U1RDRkxBR1MtdG9wbGV2ZWwsSE9TVENDLC1mbm8tdG9wbGV2ZWwtcmVvcmRlcikNCj4+IHRlc3Rf eDg2X2VtdWxhdG9yLm86IEhPU1RDRkxBR1MgKz0gJChIT1NUQ0ZMQUdTLXRvcGxldmVsKQ0KPj4g DQo+PiArIyBjbGFuZyBkdXBsaWNhdGVzIGlubGluZSBhc3NlbWJseSB3aGVuIHVucm9sbGluZyBs b29wcywNCj4+ICsjIHdoaWNoIGNhdXNlcyBhIGR1cGxpY2F0ZSBsYWJlbCBlcnJvci4NCj4+ICsj IFVudGlsIGEgYmV0dGVyIHNvbHV0aW9uIGlzIGZvdW5kOiBkaXNhYmxlIGFsbCBvcHRpbWl6YXRp b25zIGluIHRoZSB0ZXN0IHJ1bm5lci4NCj4+ICt0ZXN0X3g4Nl9lbXVsYXRvci5vOiBIT1NUQ0ZM QUdTICs9IC1PMA0KPiANCj4gSSB0aGluayB0aGUgZmlyc3Qgc2VudGVuY2UgbWF5IHdhbnQgd29y ZGluZyBhIGxpdHRsZSBkaWZmZXJlbnRseSwgYW5kIEkNCj4gZnVydGhlciB0aGluayBpdCBhYnNv bHV0ZWx5IG5lZWRzIHRvIG1lbnRpb24gcHV0X2luc24oKS4gTWF5YmU6DQo+IA0KPiAiV2hlbiB1 bnJvbGxpbmcgbG9vcHMsIGNvbXBpbGVycyBtYXkgZHVwbGljYXRlIGlubGluZSBhc3NlbWJseS4g cHV0X2luc24oKQ0KPiBlbWl0cyBsYWJlbHMsIHdoaWNoIG1heSBub3QgYmUgZW1pdHRlZCBtdWx0 aXBsZSB0aW1lcy4iDQo+IA0KPiBIYXBweSB0byBhZGp1c3Qgd2hpbGUgY29tbWl0dGluZyBpZiB5 b3UncmUgb2theSB3aXRoIG1lIGRvaW5nIHNvLg0KDQoNClN1cmUsIGdvIGFoZWFkLg0KDQoNCj4g VGhlcmUncw0KPiBvbmUgb3RoZXIgcXVlc3Rpb24gdGhvdWdoOiBJc24ndCAtTzAgdGhlIGRlZmF1 bHQ/IFdoZXJlIHdvdWxkIGFueSBvdGhlcg0KPiBvcHRpbWl6YXRpb24gc2V0dGluZyBjb21lIGZy b20gaW4gSE9TVENGTEFHUz8gQWgsIEkgc2VlIC4vQ29uZmlnLm1rIGRvZXMNCj4gdGhpcywgZm9y IGFuIHVuY2xlYXIgdG8gbWUgcmVhc29uLg0KDQpPbmUgcG9zc2libGUgcmVhc29uIEnigJlkIGVu YWJsZSBvcHRpbWlzYXRpb25zIChldmVuIGZvciBub24tcGVyZm9ybWFuY2UgY3JpdGljYWwgY29k ZSkgaXMgdG8gZ2V0IGJldHRlciB3YXJuaW5ncy4NCkkgbG9va2VkIHRoaXMgdXAsIGFuZCBJIHNl ZSBpdCBpcyBhY3R1YWxseSBkb2N1bWVudGVkIGluIHRoZSBHQ0MgbWFudWFsOg0KIlRoZSBlZmZl Y3RpdmVuZXNzIG9mIHNvbWUgd2FybmluZ3MgZGVwZW5kcyBvbiBvcHRpbWl6YXRpb25zIGFsc28g YmVpbmcgZW5hYmxlZC4NCkZvciBleGFtcGxlLCAtV3N1Z2dlc3QtZmluYWwtdHlwZXMgaXMgbW9y ZSBlZmZlY3RpdmUgd2l0aCBsaW5rLXRpbWUgb3B0aW1pemF0aW9uLiANClNvbWUgb3RoZXIgd2Fy bmluZ3MgbWF5IG5vdCBiZSBpc3N1ZWQgYXQgYWxsIHVubGVzcyBvcHRpbWl6YXRpb24gaXMgZW5h YmxlZC4NCldoaWxlIG9wdGltaXphdGlvbiBpbiBnZW5lcmFsIGltcHJvdmVzIHRoZSBlZmZpY2Fj eSBvZiB3YXJuaW5ncyBhYm91dCBjb250cm9sIGFuZCBkYXRhLWZsb3cgcHJvYmxlbXMsDQppbiBz b21lIGNhc2VzIGl0IG1heSBhbHNvIGNhdXNlIGZhbHNlIHBvc2l0aXZlcy7igJ0NCg0KSW4gZmFj dCB3YXJuaW5ncyByZWx5IG9uIG9wdGltaXNhdGlvbnMgZXZlbiBtb3JlIHRoYW4gSSB0aG91Z2h0 LCBkaWRu4oCZdCBrbm93IGFib3V0IGxpbmsgdGltZSBvcHRpbWlzYXRpb25zIGhhdmluZyBhbiBl ZmZlY3QNCihmcm9tIHRoZSBleGFtcGxlIHRoYXQgd2FybmluZyBpcyBvbmx5IHJlbGV2YW50IGZv ciBDKysgZm9yIG5vdykNCg0KSSBjYW4gc2VlIHdoeSBpbiBnZW5lcmFsIGEgY29tcGlsZXIgd291 bGQgZGVjaWRlIHRvIGltcGxlbWVudCBpdCB0aGF0IHdheSAoaWYgeW91IHJ1biBhbiBhbmFseXNp cyB0byBnZXQgbW9yZSBhY2N1cmF0ZQ0KaW5mb3JtYXRpb24gZm9yIHNob3dpbmcgd2FybmluZ3Mg dGhlbiB5b3UgbWlnaHQgYXMgd2VsbCB1c2UgaXQgdG8gZW1pdCBiZXR0ZXIgY29kZSksIGJ1dCBJ IHdpc2ggdGhhdCB3YXNu4oCZdCB0aGUgY2FzZS4gDQpFLmcuIHlvdSBtYXkgd2FudCB0byB1c2Ug YSBsb3cgb3B0aW1pc2F0aW9uIGxldmVsIHRvIGdldCBiZXR0ZXIgZGVidWdnaW5nLCB3aXRob3V0 IGdpdmluZyB1cCBvbiB0aGUgYmV0dGVyIHdhcm5pbmdzLg0KVGhlIG9ubHkgd2F5IHRvIGRvIHRo YXQgY3VycmVudGx5IGlzIHRvIGJ1aWxkIGl0IHR3aWNlIChvciByZWx5IG9uIGEgQ0kgdGhhdCBi dWlsZHMgd2l0aCBkaWZmZXJlbnQgZmxhZ3MpLg0KDQpJZiB5b3Ugd2FudCB0byBjaGFuZ2UgaXQg SeKAmWQgc3VnZ2VzdCBzZXR0aW5nIGl0IGF0IGxlYXN0IHRvIC1PZywgd2hpY2ggaXMgcmVjb21t ZW5kZWQgb3ZlciBPMDoNCiJJbiBjb250cmFzdCB0byAtTzAsIHRoaXMgZW5hYmxlcyAtZnZhci10 cmFja2luZy1hc3NpZ25tZW50cyBhbmQgLWZ2YXItdHJhY2tpbmcgd2hpY2ggaGFuZGxlIGRlYnVn IGluZm9ybWF0aW9uIGluIHRoZSBwcm9sb2d1ZSBhbmQgZXBpbG9ndWUgb2YgZnVuY3Rpb25zIGJl dHRlciB0aGFuIC1PMC4iDQpCdXQgSSBkb27igJl0IGtub3cgaG93IHRoaXMgYWZmZWN0cyB0aGUg ZWZmZWN0aXZlbmVzcyBvZiB3YXJuaW5ncy4NCg0KPiBQZXJoYXBzIHRoYXQgd291bGQgd2FudCBt ZW50aW9uaW5nDQo+IGhlcmUgdGhlbiBhcyB3ZWxsLg0KDQpIb3cgYWJvdXQ6DQoNCiMgVGhlIGRl ZmF1bHQgSE9TVENGTEFHUyBmcm9tICQoWEVOX1JPT1QpL0NvbmZpZy5tayB3b3VsZCBzZXQNCiMg YSBub24temVybyBvcHRpbWlzYXRpb24gbGV2ZWwNCg0KSeKAmWQgYXZvaWQgbWVudGlvbmluZyAt TzIsIGluIGNhc2UgdGhhdCBjaGFuZ2VzLg0KDQoNCkJlc3QgcmVnYXJkcywNCuKAlEVkd2luDQo= From xen-devel-bounces@lists.xenproject.org Mon Mar 09 10:20:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 10:20:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249211.1546707 (Exim 4.92) (envelope-from ) id 1vzXid-0005Em-Np; Mon, 09 Mar 2026 10:20:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249211.1546707; Mon, 09 Mar 2026 10:20:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzXid-0005Ef-KE; Mon, 09 Mar 2026 10:20:11 +0000 Received: by outflank-mailman (input) for mailman id 1249211; Mon, 09 Mar 2026 10:20:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzXic-0005EZ-Jc for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 10:20:10 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 8b56890d-1ba1-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 11:20:06 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-439b78b638eso8627926f8f.2 for ; Mon, 09 Mar 2026 03:20: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-4852ad0ce60sm391471295e9.12.2026.03.09.03.20.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 03:20:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8b56890d-1ba1-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773051606; x=1773656406; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=F2pCmSLQMzsaxAIlAFDiSmlwjrvfzsVeQwbG2dyIc88=; b=G2QtNvD/vAJkWvbDFpaOG1kQHEuoi+bzUH+NIiOwEcggn6CVazkycaznD4HWxlMM9V RUvV2BsSbkPmbtoz+fGZA5cMuTI3MGX0bY4NCrDk0JQx6+Xz1x4S65E/z4WaEK2v9SlD /jVka2fUPOHHRm8wilZR/vfhiEBf5/hsh3bNpCQBEs0Bfp3L+PyKxBG9L0TovZ90Nhi/ R4TM6zaxfqC5TIcZLycYfG+N4kIewsYb1o5GFIEkL4COQrWHYbL9+EvyblyHeaFRSW4+ ZXy9ErUPn9s2iSVkyFWlekFK+dAPCzhri6Kx/g46rPiNfq1HUG8vyVVUMd9Kng/TD+lf DwDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773051606; x=1773656406; h=content-transfer-encoding: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; bh=F2pCmSLQMzsaxAIlAFDiSmlwjrvfzsVeQwbG2dyIc88=; b=kA5nMvz+vs6AVFnVt16xSYvJ0t4nlWZXKsa04TG5w1/ivoELwF+WrOUz/8X1c54zGa x5TRiTEQrYGaXfg8D6225k6Yn37lchJ2mRA3FVP8wMY4wqK4pNJm7JXidkJ4CkpcfSHG /tz/4/+9KncPchdxlIrHFQzv5LDO6zH2lJ86dmo8BxaS5lYJGn1YwTXkf7CRkfMZWsYv RZCCSnwweX02u3NlG50FFPIvf0ADPUdGq1wjXGRmmp2aRBLJZ3RxBZcA9NWgnBxcMHlz ycGBiQSvJp9mLy9sHix3me3rIJK+/ZGdnJw8qGl4sU8bs+E4tvD3sESrYOz6HJzDqkro iNig== X-Forwarded-Encrypted: i=1; AJvYcCXUH3UMnNIFc2uUGyjbA0xeDg/3u/Rz+TTRzEmiZRGhjkeSk4oBJgCUiINDxwhnamRDvHa0kj5306E=@lists.xenproject.org X-Gm-Message-State: AOJu0YyWdQPG7nzgtGnAQvpPZOVXRB496Yw8tU0Tfdybsc9haBxrVmXt g8NlQd+Ws1ZPPVPCDIy8sNZEG5pY65l7f6b1TTBDz9etmm0rqS0ZXUGaLiri+/BnCA== X-Gm-Gg: ATEYQzz3FPhhsffSt0MVTj6dcR3wKC0Wx3a3ySdDqKNqjCDhYS0tBH0fmR8IiciNb8Q tAIusMvfn3Yf9+BTYnbIrkQHCqvjgRlwFLhQWBFhiQ/GUPejeh2RPmASbf2NE85svkbtEcC+ncL ZPNrlbyBQ7yd/D4J23ewQeoAVBejhckrp1jCCoa2RJOrTAoHLuOaU6qNektAJ9ZwRSHPRgbjJdc HWl+JYQVnnbd+/pMXJDbHCSchaCPENyeF7NVSnRsuhd2SKbSO2EcRXsBVg+jfm7+fShD63lZOih xCw8T8cw493j5mX3SlZurq2Ee5EiQmnq9FNETtos41WXmjdCQtJZfuyCSYPSjUYdopy5DAO6ESP A5bZn+OPdevvGJr3H1iueNm/y5WEzmiikesTihX13k/NBVLANJSJbDGrmAJRpaTkpwKMNc49QaU 0bJEGo8Z/DwZP7UQtBVWL4cbdiPLxQK9v5i6NAGQcTgTtjSJN9E6r8jdG3f1ANhsGr0P7ivhn4+ mU0mugWYhmQPI4= X-Received: by 2002:a05:600c:1e86:b0:483:5310:dc67 with SMTP id 5b1f17b1804b1-4852695b81cmr181327035e9.20.1773051606075; Mon, 09 Mar 2026 03:20:06 -0700 (PDT) Message-ID: <39057e2b-5d1e-41ff-b5d3-0e5aa4745d15@suse.com> Date: Mon, 9 Mar 2026 11:20:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 To: Edwin Torok Cc: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" References: <49d22b35-f5d8-4992-a32a-bb3f7c3e5ad2@suse.com> <5B5A0A1C-B7EA-47F2-8CF9-3000CF4414F1@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <5B5A0A1C-B7EA-47F2-8CF9-3000CF4414F1@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.03.2026 10:49, Edwin Torok wrote: >> On 9 Mar 2026, at 07:47, Jan Beulich wrote: >> There's >> one other question though: Isn't -O0 the default? Where would any other >> optimization setting come from in HOSTCFLAGS? Ah, I see ./Config.mk does >> this, for an unclear to me reason. > > One possible reason I’d enable optimisations (even for non-performance critical code) is to get better warnings. > I looked this up, and I see it is actually documented in the GCC manual: > "The effectiveness of some warnings depends on optimizations also being enabled. > For example, -Wsuggest-final-types is more effective with link-time optimization. > Some other warnings may not be issued at all unless optimization is enabled. > While optimization in general improves the efficacy of warnings about control and data-flow problems, > in some cases it may also cause false positives.” > > In fact warnings rely on optimisations even more than I thought, didn’t know about link time optimisations having an effect > (from the example that warning is only relevant for C++ for now) > > I can see why in general a compiler would decide to implement it that way (if you run an analysis to get more accurate > information for showing warnings then you might as well use it to emit better code), but I wish that wasn’t the case. > E.g. you may want to use a low optimisation level to get better debugging, without giving up on the better warnings. > The only way to do that currently is to build it twice (or rely on a CI that builds with different flags). > > If you want to change it I’d suggest setting it at least to -Og, which is recommended over O0: > "In contrast to -O0, this enables -fvar-tracking-assignments and -fvar-tracking which handle debug information in the prologue and epilogue of functions better than -O0." And did you check that -Og works for the purposes here? I'd indeed prefer to use that, if we can. >> Perhaps that would want mentioning >> here then as well. > > How about: > > # The default HOSTCFLAGS from $(XEN_ROOT)/Config.mk would set > # a non-zero optimisation level > > I’d avoid mentioning -O2, in case that changes. Of course. Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 09 10:41:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 10:41:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249224.1546716 (Exim 4.92) (envelope-from ) id 1vzY3S-00084l-BD; Mon, 09 Mar 2026 10:41:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249224.1546716; Mon, 09 Mar 2026 10:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzY3S-00084e-8U; Mon, 09 Mar 2026 10:41:42 +0000 Received: by outflank-mailman (input) for mailman id 1249224; Mon, 09 Mar 2026 10:41:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzY3Q-00084Y-Im for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 10:41:40 +0000 Received: from na1pdmzitismtp01.tibco.com (na1pdmzitismtp01.tibco.com [160.101.131.8]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8d6bf574-1ba4-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 11:41:39 +0100 (CET) Received: from localhost.localdomain (unknown [10.113.40.46]) by na1pdmzitismtp01.tibco.com (Postfix) with ESMTPS id 229C84153174; Mon, 9 Mar 2026 06:41:13 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8d6bf574-1ba4-11f1-b164-2bf370ae4941 From: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= To: xen-devel@lists.xenproject.org Cc: =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD Subject: [PATCH v4] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Date: Mon, 9 Mar 2026 10:41:35 +0000 Message-ID: X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit clang would duplicate the loop body and end up with a double definition of the symbol: ``` /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is already defined /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is already defined ``` Until a better solution is found: reduce optimizations in the test runner. Using -Os might also work, but we can't rely on the size optimization always avoiding the duplication of asm blocks. This is test code, not performance critical code, and -O0 is more future proof. However for debugging -Og is recommended over -O0, and this still avoids the duplicate label problem. Signed-off-by: Edwin Török --- Changed since v3: * use -Og instead of -O0, adjust comment Changed since v2: * use -O0 instead of .ifndef (with ifndef the 2nd iteration would use code identical to first) Changed since v1: * use .ifndef directive instead of volatile workaround --- tools/tests/x86_emulator/Makefile | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/tests/x86_emulator/Makefile b/tools/tests/x86_emulator/Makefile index 5003c464f3..8210e83345 100644 --- a/tools/tests/x86_emulator/Makefile +++ b/tools/tests/x86_emulator/Makefile @@ -323,4 +323,11 @@ x86-emulate.o x86_emulate/%.o: HOSTCFLAGS += -D__XEN_TOOLS__ $(call cc-option-add,HOSTCFLAGS-toplevel,HOSTCC,-fno-toplevel-reorder) test_x86_emulator.o: HOSTCFLAGS += $(HOSTCFLAGS-toplevel) +# When unrolling loops, compilers may duplicate inline assembly. put_insn() +# emits labels, which may not be emitted multiple times. +# The default HOSTCFLAGS from $(XEN_ROOT)/Config.mk would set a non-zero +# optimisation level. +# Until a better solution is found: reduce optimizations in the test runner. +test_x86_emulator.o: HOSTCFLAGS += -Og + test_x86_emulator.o: $(addsuffix .h,$(TESTCASES)) $(addsuffix -opmask.h,$(OPMASK)) -- 2.47.3 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 10:46:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 10:46:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249250.1546725 (Exim 4.92) (envelope-from ) id 1vzY7x-0000Do-RK; Mon, 09 Mar 2026 10:46:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249250.1546725; Mon, 09 Mar 2026 10:46:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzY7x-0000Dh-O9; Mon, 09 Mar 2026 10:46:21 +0000 Received: by outflank-mailman (input) for mailman id 1249250; Mon, 09 Mar 2026 10:46:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzY7w-0000Db-4z for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 10:46:20 +0000 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c107::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 30d65b15-1ba5-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 11:46:14 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by MN2PR03MB5296.namprd03.prod.outlook.com (2603:10b6:208:1e8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 10:46:10 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9678.024; Mon, 9 Mar 2026 10:46:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 30d65b15-1ba5-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TWGq8Ma3vVepB5jdjxODd//+uBbVBwQj/GMwIlLfFmCYCSeX5tD6YtwQgymPWT4FE2rWWbEEexP1fmT9rZrhwQL7RLZnIwzVYGBzMr88/GhkXEjrbEfOSiDCW0TlwU2FnrZRTSPwXCfutygZS1RRmdjf38fXl3nJqcFeMUERFwcwb6DrUEdooq8dWNWPJyS0aLnzt6rTTWSoD6BRmk7yGiALvbJdog2kB58gYZOiip+9Xq4JzMieFPxEJfKdRKvERccR7vYQOWYyezWcgaBh+SQIbDETIORsbNndAzRBdhiTWzkV0qsDRTr5BGtNzd5G+DRsb8onRcTfkumADbrm+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=pWuuO0DE7JddmloIvsWoWHqdKWz5S3CurWOhGgZGUO8=; b=Cd8CH1GK6WzGFLFqQ/ciNUhWyTNgUgcjmUU9uprasiegP4MBPLKJsHgg73a4qS09ZMBVGeY9a3u8u7bBk6jSO46at36HwrFqFcPgd/Z2a8KghBDL01nB8Z++4DqPmO2K1cFY5jqivwc/Gq9t0DGYIHd6Y/ppDaqoJ4BklCyb6B7ZbUJIi8bU1ID0I+PZBtYRV5TMOkd6/sO6cbQ5m41BpfuVRnwUIEAf/qNiSo145jhR58Yx3f+A1MvalB1eBRL+HDR6s3TNeLXAa08aMnqZ7ffeR2FcAUJ2ilmmT8lFxPdMvKSwHrkSfdHx3CRDZjhw1L8ibV3cQkBzbuH67/17UA== 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=pWuuO0DE7JddmloIvsWoWHqdKWz5S3CurWOhGgZGUO8=; b=SRWqf0p3fWd5xA8q0IZmzMWkU97CynTmDl1dwNwphC93WxfLzTfsdH8oX7S4NYIqCL+Pkne1/zbH+P+yWAh5iU257gvmZ27pLhovF9Z6iBMa0UAKiKhDFhbdLXIIYtXElW0poFojQX2yPT29PwR0QESHSoZ5vnHw938oWhUaL04= From: Edwin Torok To: Jan Beulich CC: Andrew Cooper , Roger Pau Monne , Anthony PERARD , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Topic: [PATCH v3 1/1] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Index: AQHcrYXnXQSbfSYkDE2XRiS+3V/VSLWl1toAgAAhtYCAAAj/gIAABzwA Date: Mon, 9 Mar 2026 10:46:10 +0000 Message-ID: References: <49d22b35-f5d8-4992-a32a-bb3f7c3e5ad2@suse.com> <5B5A0A1C-B7EA-47F2-8CF9-3000CF4414F1@citrix.com> <39057e2b-5d1e-41ff-b5d3-0e5aa4745d15@suse.com> In-Reply-To: <39057e2b-5d1e-41ff-b5d3-0e5aa4745d15@suse.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.400.21) 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: SA3PR03MB7419:EE_|MN2PR03MB5296:EE_ x-ms-office365-filtering-correlation-id: 0ba0f3d9-cb43-4985-007b-08de7dc913a0 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700021; x-microsoft-antispam-message-info: aC4BbU9TDrM3XaNjeNjppYp/6nm/CbNx6Vg/LlZl5nG20ChHjNxR16HHLzOJs2i5Heahv/dACbcQ9/Amkt4nrXRkqbdImMpxG/BCMpUr10Zl4XMT4HzUbbZyBNSCDA2G960PKorr6ILmlSnPKCK8+3tQv7AgZb4kIuGm32OYqwxAX5+CM6BRnbBY0DDbjfWxrfK0ZenEUg1rYHnBGuPsLcoS/9nP54GjQiJz0FtHctLIA0k7eAGfogmcnid1vw6g/4RS2NkUeJ2Vkgm1e5CXb9rJZ0ql6kOZOh1DKcrIJYpzGre/n+LeY3AbL2V6BrVcs6+6UFW/1lyNlgx4km9BBwENkuqo5L7wZKf+qehMf4I8cWwyTPdV36CiHzxIP2HY6FR2GiPz8PjzcbGsqgg3l8FHqRJYmSM1PhE2j0Y1SAZggVGDj4lrvwCzT0R0z+GgUid3nB28TD5/bSDRER4dSH/PjrCELY4MjYLAA7VUUl4wkr8Hgt7gSlM9Y9ZzgJia2EuqnrkstU9JBNn1V87Iu9Naq7W4pdkGtYHss0wWPXHY/KFlmCuO7aB9khZia8TMaRCIGuCtqgifxRsV6EIahmiqS5Ah9Z7b+5fQB8HjxaF+kkh4k3JlFcNG4Ga1jvYZCGtOy/wcFo8mY4M7JycwGZeaI6d+aZLmA2/V9sYEd9T9BoOv0y8BvegIb8CjTj7a0lUgHrO1RaVFqyZl43W6TibvDRMDgqgX72mxgZdhNoQ6lijQ5FlwHqLfxxdbWy60WU8KO5Q+xUNvB8RVwFNNnfHA+1IrDynhM0SmKiw4BWU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YTdIUnhtcm4zSFJWRU84bGI0SGNBdEFVYmxaanRjLzhlaFNBU2lCNlI2NlRS?= =?utf-8?B?cmVhVWpQeXdoRjVyd1BQZXpCbkFpWTRuRHU2LzZQdkJxZUpkU2t5ZXllc3dX?= =?utf-8?B?MnJiSHBJbVU3TzNHSlZXanJnMkxrNWQ1d01Zc1cvTitGNHlTeGRMZG9mSnNq?= =?utf-8?B?VWZXMXJkQUtRL3Z1TllINjFLdllaOXp5d0xkREVXTnNhMHM3U0JOdlJPT0gw?= =?utf-8?B?VlZFdEREaDZyUUtGc1VpWjE1cEhKb21EK0lFeURsR3F1M3VLWjZSWlJxSEhS?= =?utf-8?B?bzBCWHF5MndwZU5yYU8vc0ZaVFlBd1pBeFE5cHVaNjArRXg0cC9naG9mUDlG?= =?utf-8?B?MnNlai8xdm1BOVB3eHQwVmc1YTdzWHlJZ3U1OG1tSXBIRjJWK3hpZU81TFc4?= =?utf-8?B?dXJSQWNTUmU5MjRIS0oyMGRGNmlreEtTVnFaYUFIakJkeFNBS3FxSjR4cWdk?= =?utf-8?B?NjNHRmRWQmNBc1g2MkdIb0dLQ01mSWJyWVE1TlFwS2k1eTNKTVJiVDJaVkxv?= =?utf-8?B?MXpRZy9lQitNQmhBNFEzZ08yelNqamh6QmRZY1NhcjlGeFJud3AwazFoQWp4?= =?utf-8?B?dHY2dGxUNDVRMDFZQ1ZyK0JmVCtSVDhtV1phRmNOUmFLai9sRkNWOWtaOHNa?= =?utf-8?B?TTN5VGRMd1NtVmdNWlFoaDNHNmxRZVM5WHo3RHhxTUVpTFlMZjNrMlZpNXFa?= =?utf-8?B?NlBQa0FUbHVQckJVdGg1WlZJN2wyR0pvdEZzVnpmYmJEb2JlV0dJSzBUbUhQ?= =?utf-8?B?MjRUc2s2eTZZekhHa081bU9wOWY3clY0Ym9SWlBIekpsaFJTQlV2MTlYdzVz?= =?utf-8?B?WjY3QmpoNVZ1ZSs0Vys3TGM4M29EaEdlelNOZFBuL20zQkNucXBLQmxSR0tZ?= =?utf-8?B?SG1BR3c1WUtYTGFpeHo4T3hRam9TN3MzdmZqMEFRWE1NU0pKV0xQL1VkSzlo?= =?utf-8?B?VnJMM0cwMW00RHpMUVRyZFI0UmtmQ29Id1ZYbkFWS0htR2NGUnd0ODlrdGVk?= =?utf-8?B?RzREMG1EZWQ1MERBTVVRdHpBK0s1RnMwWGVrWFJHOVBoWWhpVGV6eENPbWpY?= =?utf-8?B?M0RoeHZqSkhhRWQ5Rk5TQm96cklhUkpOUTJra1ZiWUtrOGRCZGRzZ3pRM1dN?= =?utf-8?B?VGlKQUZIUW1JVDNudDNXY0ZDQkF5OHVzWVkxVnhmUnIwRFZ1QlFsZ1JNWXIy?= =?utf-8?B?OWVHaXFHaWJ6cWpVMnV2T1BZUDhqRTVqaWgyYmJ4UEYzQ1hnVnhPb1JmUlhF?= =?utf-8?B?VXB5aVljbjB6OWZ0aTdBaHUwbXJVMWhtUXhBWGU2VWdHODkvMURlSDFtRU5Q?= =?utf-8?B?ZldsbkJNRWtvL3dJN3RjWmVZeW1jOUw3OE1iaU1QNFZIbzhXSDg1a3RaS2sx?= =?utf-8?B?ZGQzdE4xSktuWkRjbUxrQmhDQVgzMWU5emRMS0M4U01lNFVqd0EwNTB4eExM?= =?utf-8?B?cVZYNlpTS2p1QTBJR0xjcjJpWmtwS01TMUt5S052cFFkZVVQdHhRMUFjdTFt?= =?utf-8?B?YjE2cXdGb3lKU0RPZkNaQUUwcFZMN0NBS3BBbVdlTnF3ak16YndrSDk3SHR5?= =?utf-8?B?cEM4ejVwQWVZNTNIMlcxS1R0Q25LSS9ZSXR1NnhvVnhRWGRnWEo5b2xuNkEr?= =?utf-8?B?Mk5jQUEwaGpBclJ3UVZqVGFkVm95R25sV2dqakoralh2Yzg3ZDdDTDRPL01s?= =?utf-8?B?VytqM0w0T2dxb1lMdUV4WUpUYjh4dHRZN1NFQ0svZkNxNGlyNzNGRnpuVGlt?= =?utf-8?B?c0FTaG5ncHBLY1FHaWlWZ3hLN0tJbGZTUWNnMlJqTnl5WkUyOEJ2OEtZdlNa?= =?utf-8?B?K0w1cXdxb05RZmlrZ3AwYWhOUnZRRUJaT1luWmFIMjR6amhDcGdJWE1OKzZ0?= =?utf-8?B?VXdQZklUS29qQnhmYUxPdHNramdSVHgyNDJFU1A0WFpzc0o1SkdiQU83WHJv?= =?utf-8?B?WTh3V3d4RE1BK2txWStxZzkvMlN5cFRPeWM1RmlVa2xVMmVnSHBWR3FmaW9t?= =?utf-8?B?amZxME1Bclc2QzVrYkNyUWFCSjFWRk5HbEtLRHhQWlg0eDBSU0ZVMkt2V1dH?= =?utf-8?B?Rm1MTEM5VzdSUlJxaXdlYmkwMFgrcUtialpDVGJPZHA2VUhpL1MrejRJOEtu?= =?utf-8?B?NVZuSGs2cTZYZFUrTUNUUDhSdXNWalRUbEZ6Y1hVVis5RVVFQWxxdlVWREZZ?= =?utf-8?B?UGVhTEh2aDBNTWxjV1kyYXROS0xZdXZUQUhDMUVkR1k3RTJBVWJCYmNNblNs?= =?utf-8?B?MGtqVnlXdEdBdTBJbU1GWWFSY2I1RU5nVVhnRmw4ZEpQM2M1QXhoNDl3NlJG?= =?utf-8?B?MWs3bEZHaWFld0dQUHFHRGQ5SGh5bHlsb1JrK3pLQTZDclBEK1Rzc0ZDd0Zr?= =?utf-8?Q?VMjxTDB38f6Dvp0I=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <4393FA9A41DAD145857FE1849610AA52@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ba0f3d9-cb43-4985-007b-08de7dc913a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 10:46:10.3967 (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: 3p9oTWOSJhRl620I7AzGwac+qUjTJZM+0mnswhGGEI2hCNqxW5zMa9Op8pYGaNCBRT/Ez5jTL1KXfUFX0QD93Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB5296 DQoNCj4gT24gOSBNYXIgMjAyNiwgYXQgMTA6MjAsIEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNl LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwOS4wMy4yMDI2IDEwOjQ5LCBFZHdpbiBUb3JvayB3cm90 ZToNCj4+PiBPbiA5IE1hciAyMDI2LCBhdCAwNzo0NywgSmFuIEJldWxpY2ggPGpiZXVsaWNoQHN1 c2UuY29tPiB3cm90ZToNCj4+PiBUaGVyZSdzDQo+Pj4gb25lIG90aGVyIHF1ZXN0aW9uIHRob3Vn aDogSXNuJ3QgLU8wIHRoZSBkZWZhdWx0PyBXaGVyZSB3b3VsZCBhbnkgb3RoZXINCj4+PiBvcHRp bWl6YXRpb24gc2V0dGluZyBjb21lIGZyb20gaW4gSE9TVENGTEFHUz8gQWgsIEkgc2VlIC4vQ29u ZmlnLm1rIGRvZXMNCj4+PiB0aGlzLCBmb3IgYW4gdW5jbGVhciB0byBtZSByZWFzb24uDQo+PiAN Cj4+IE9uZSBwb3NzaWJsZSByZWFzb24gSeKAmWQgZW5hYmxlIG9wdGltaXNhdGlvbnMgKGV2ZW4g Zm9yIG5vbi1wZXJmb3JtYW5jZSBjcml0aWNhbCBjb2RlKSBpcyB0byBnZXQgYmV0dGVyIHdhcm5p bmdzLg0KPj4gSSBsb29rZWQgdGhpcyB1cCwgYW5kIEkgc2VlIGl0IGlzIGFjdHVhbGx5IGRvY3Vt ZW50ZWQgaW4gdGhlIEdDQyBtYW51YWw6DQo+PiAiVGhlIGVmZmVjdGl2ZW5lc3Mgb2Ygc29tZSB3 YXJuaW5ncyBkZXBlbmRzIG9uIG9wdGltaXphdGlvbnMgYWxzbyBiZWluZyBlbmFibGVkLg0KPj4g Rm9yIGV4YW1wbGUsIC1Xc3VnZ2VzdC1maW5hbC10eXBlcyBpcyBtb3JlIGVmZmVjdGl2ZSB3aXRo IGxpbmstdGltZSBvcHRpbWl6YXRpb24uIA0KPj4gU29tZSBvdGhlciB3YXJuaW5ncyBtYXkgbm90 IGJlIGlzc3VlZCBhdCBhbGwgdW5sZXNzIG9wdGltaXphdGlvbiBpcyBlbmFibGVkLg0KPj4gV2hp bGUgb3B0aW1pemF0aW9uIGluIGdlbmVyYWwgaW1wcm92ZXMgdGhlIGVmZmljYWN5IG9mIHdhcm5p bmdzIGFib3V0IGNvbnRyb2wgYW5kIGRhdGEtZmxvdyBwcm9ibGVtcywNCj4+IGluIHNvbWUgY2Fz ZXMgaXQgbWF5IGFsc28gY2F1c2UgZmFsc2UgcG9zaXRpdmVzLuKAnQ0KPj4gDQo+PiBJbiBmYWN0 IHdhcm5pbmdzIHJlbHkgb24gb3B0aW1pc2F0aW9ucyBldmVuIG1vcmUgdGhhbiBJIHRob3VnaHQs IGRpZG7igJl0IGtub3cgYWJvdXQgbGluayB0aW1lIG9wdGltaXNhdGlvbnMgaGF2aW5nIGFuIGVm ZmVjdA0KPj4gKGZyb20gdGhlIGV4YW1wbGUgdGhhdCB3YXJuaW5nIGlzIG9ubHkgcmVsZXZhbnQg Zm9yIEMrKyBmb3Igbm93KQ0KPj4gDQo+PiBJIGNhbiBzZWUgd2h5IGluIGdlbmVyYWwgYSBjb21w aWxlciB3b3VsZCBkZWNpZGUgdG8gaW1wbGVtZW50IGl0IHRoYXQgd2F5IChpZiB5b3UgcnVuIGFu IGFuYWx5c2lzIHRvIGdldCBtb3JlIGFjY3VyYXRlDQo+PiBpbmZvcm1hdGlvbiBmb3Igc2hvd2lu ZyB3YXJuaW5ncyB0aGVuIHlvdSBtaWdodCBhcyB3ZWxsIHVzZSBpdCB0byBlbWl0IGJldHRlciBj b2RlKSwgYnV0IEkgd2lzaCB0aGF0IHdhc27igJl0IHRoZSBjYXNlLiANCj4+IEUuZy4geW91IG1h eSB3YW50IHRvIHVzZSBhIGxvdyBvcHRpbWlzYXRpb24gbGV2ZWwgdG8gZ2V0IGJldHRlciBkZWJ1 Z2dpbmcsIHdpdGhvdXQgZ2l2aW5nIHVwIG9uIHRoZSBiZXR0ZXIgd2FybmluZ3MuDQo+PiBUaGUg b25seSB3YXkgdG8gZG8gdGhhdCBjdXJyZW50bHkgaXMgdG8gYnVpbGQgaXQgdHdpY2UgKG9yIHJl bHkgb24gYSBDSSB0aGF0IGJ1aWxkcyB3aXRoIGRpZmZlcmVudCBmbGFncykuDQo+PiANCj4+IElm IHlvdSB3YW50IHRvIGNoYW5nZSBpdCBJ4oCZZCBzdWdnZXN0IHNldHRpbmcgaXQgYXQgbGVhc3Qg dG8gLU9nLCB3aGljaCBpcyByZWNvbW1lbmRlZCBvdmVyIE8wOg0KPj4gIkluIGNvbnRyYXN0IHRv IC1PMCwgdGhpcyBlbmFibGVzIC1mdmFyLXRyYWNraW5nLWFzc2lnbm1lbnRzIGFuZCAtZnZhci10 cmFja2luZyB3aGljaCBoYW5kbGUgZGVidWcgaW5mb3JtYXRpb24gaW4gdGhlIHByb2xvZ3VlIGFu ZCBlcGlsb2d1ZSBvZiBmdW5jdGlvbnMgYmV0dGVyIHRoYW4gLU8wLiINCj4gDQo+IEFuZCBkaWQg eW91IGNoZWNrIHRoYXQgLU9nIHdvcmtzIGZvciB0aGUgcHVycG9zZXMgaGVyZT8gSSdkIGluZGVl ZCBwcmVmZXIgdG8NCj4gdXNlIHRoYXQsIGlmIHdlIGNhbi4NCg0KDQpJdCBhdm9pZHMgdGhlIGR1 cGxpY2F0ZSBzeW1ib2wgZXJyb3Igd2l0aCB2ZXJzaW9uIG9mIENsYW5nIHRoYXQgSSBoYXZlLCBz byBJIGhhdmUgc2VudCBhIFY0IHRoYXQgdXNlcyAtT2cgYW5kIHRoZSB1cGRhdGVkIGNvbW1lbnRz Lg0KV2FzIGEgYml0IHdvcnJpZWQgdGhpcyBtaWdodCBub3Qgd29yayB3aXRoIG9sZCBHQ0NzLCBi dXQgQUZBSUNUIE9nIGlzIHN1cHBvcnRlZCBzaW5jZSA0LjgsIGFuZCB0aGUgbWluaW11bSBpcyA1 LjEuDQoNCkJlc3QgcmVnYXJkcywNCuKAlEVkd2luDQoNCj4gDQo+Pj4gUGVyaGFwcyB0aGF0IHdv dWxkIHdhbnQgbWVudGlvbmluZw0KPj4+IGhlcmUgdGhlbiBhcyB3ZWxsLg0KPj4gDQo+PiBIb3cg YWJvdXQ6DQo+PiANCj4+ICMgVGhlIGRlZmF1bHQgSE9TVENGTEFHUyBmcm9tICQoWEVOX1JPT1Qp L0NvbmZpZy5tayB3b3VsZCBzZXQNCj4+ICMgYSBub24temVybyBvcHRpbWlzYXRpb24gbGV2ZWwN Cj4+IA0KPj4gSeKAmWQgYXZvaWQgbWVudGlvbmluZyAtTzIsIGluIGNhc2UgdGhhdCBjaGFuZ2Vz Lg0KPiANCj4gT2YgY291cnNlLg0KPiANCj4gSmFuDQoNCg== From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:00:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:00:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249265.1546733 (Exim 4.92) (envelope-from ) id 1vzYLm-000327-2w; Mon, 09 Mar 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 1249265.1546733; Mon, 09 Mar 2026 11:00:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYLm-000320-0M; Mon, 09 Mar 2026 11:00:38 +0000 Received: by outflank-mailman (input) for mailman id 1249265; Mon, 09 Mar 2026 11:00:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYLl-00031u-Bh for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:00:37 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 333eb847-1ba7-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:00:36 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48539d21b76so7931725e9.1 for ; Mon, 09 Mar 2026 04:00: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-4853438017bsm197421125e9.0.2026.03.09.04.00.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 04:00:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 333eb847-1ba7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773054035; x=1773658835; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=cA8i4u7EhErBXPUzNIm8vTS/NqpkxaK6TrJ/JPQzfVM=; b=SRpJQcf7oCrXqnKUnjbAVX0zJVuYXCcRZ2GeAE5Lu1yUi+7tqfjnqH8Yh8mywzKuuk MFsKVATbR7TgLxozdbUTZYawspuO2T1AOByClFfrldX8TCKbngmWN5JBghcuLS3ziYX+ nr+YHQuy98Er9HhNVubuB3uP6nW56drRjV1nP/k42CfY1y7cVHxRse5iGOJ7Tx/Cpfka RPmuzPVdjo85hf4V1GCYCiV3b0RhKVYpsaR28umWCaI0dyLEHw/loy74FT3y6IDhwsif oQ6R7DlCj5wGOmn2MpbNWucIZQtjhdBOd0aJb2xBsNLUCC2IKMtvUsqE12szLprS/vaH DPsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773054035; x=1773658835; h=content-transfer-encoding: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; bh=cA8i4u7EhErBXPUzNIm8vTS/NqpkxaK6TrJ/JPQzfVM=; b=AVkgghhjy3YOcF8cZ9BsUtgfPpLsC4wqSlungcxzNzPCmvhlWzynSZYt3jXxRZdeNL Gk0mYx4JmN+Q3uF31giwKtHqkaRsN/PAtJrv+VXikI+4lhF+AEPL9aYE87OxeqnwOqUz 2LogzIxLyJlquByh6q+ZKe9hLO0FIRvE2FMA2Xycs6bzUdX0B+CgwXpycDqCMTQjhMB4 PEGtNiEodbY34QLXR8475knjU1wFfgkF+eyHdqpQxT/0CsrDeG7GQdNjal7HAvi9hFdv ZVwVYXOdt7hQ+I0p3veCRm9LwFmMcZ7OKIRsIw04fVFexBALQhPZvFsiJ5z3hhURYyQ5 nmQg== X-Forwarded-Encrypted: i=1; AJvYcCVz2MffjJil0lDwDxd4+84+G5x6DTzX98W/qEv3bEAVFWEh+2SwTpx5Pte0Jc/o0iPMq3NSIPFb4X4=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywz5ZXn4w+EpEMeuHxOBslvztnHQpNVShn9YMPAuRtylyK0g+kD o1Ka9lbVQgM6yOkf/OJqs9+K0Yfr5cUTzwAm58fbV/LjZtJ/b8r/PQZhg95N00Xm9w== X-Gm-Gg: ATEYQzz2xRKB4ep2Yi9+CihUWLPN2ZW9EjrdV+zQcZUCUV4yLAx0MIsnq0J5HxP0oRE BXdO9w2zWJSMVKVxsz0nK1tnFiZW1AnSwuQ/W7ufJqSrNzH37/z6pnTEvECrHiiCp26oPv8gmtI nBLqiW/PhIfznM7wcYJn7TEYwewCT+L0IRs6fqEkAuDM5TEfeUnJtMK0fbAK1sso8veSba0E0FB V1tqNigLIE2vYHzm/fbEDWCvgIupIzc+159DpQ8ersOkmwVKmMWPRVejXRLIyn528VbQU9iEVVV e5x6D0XgslSfcuk5oPmZfC68N86xTj8eLdJai5D/oi5Hz0KzSJBJUwMnC7pdf5MOGLbrTZam8Sl pcMkyWNBo0PpscKo0hMY+cPSQYUdQeenG4Iklx3qpr7bb4BbcsezExg1p/swo9IRBDktn3Xlw0p jBmk62dvyCOR93IfG4WOlOK+muP2OaTkrV+LCzC/YQyCBo8W6aTMIwvLqxAhOPC/X5f9q4wLSCO TGbC0CJY5oXGzs= X-Received: by 2002:a05:600d:41c9:b0:485:3911:b8c7 with SMTP id 5b1f17b1804b1-4853911bb1amr57874885e9.35.1773054035081; Mon, 09 Mar 2026 04:00:35 -0700 (PDT) Message-ID: Date: Mon, 9 Mar 2026 12:00:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 To: =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.03.2026 11:41, Edwin Török wrote: > clang would duplicate the loop body and end up with a double definition > of the symbol: > ``` > /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is already defined > /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is already defined > ``` > > Until a better solution is found: reduce optimizations in the test runner. > > Using -Os might also work, but we can't rely on the size optimization > always avoiding the duplication of asm blocks. > This is test code, not performance critical code, and -O0 is more future > proof. > However for debugging -Og is recommended over -O0, and this still > avoids the duplicate label problem. > > Signed-off-by: Edwin Török With the subject also switched to say -Og (will adjust while committing): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249275.1546752 (Exim 4.92) (envelope-from ) id 1vzYTR-0003vi-3c; Mon, 09 Mar 2026 11:08:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249275.1546752; Mon, 09 Mar 2026 11:08:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTQ-0003vb-Ul; Mon, 09 Mar 2026 11:08:32 +0000 Received: by outflank-mailman (input) for mailman id 1249275; Mon, 09 Mar 2026 11:08:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTP-0003iR-PJ for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:31 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4e289918-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:30 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by PAVPR03MB9775.eurprd03.prod.outlook.com (2603:10a6:102:312::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.23; Mon, 9 Mar 2026 11:08:26 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4e289918-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UNbYhsNNWLbxrbWO51Gle1Q32feoW3QMwvwGSzY4ZE3h9tzq/4VQ/hQ6P0CAaeo7FNUCMZxe90yHkdUEJ8BmFqvE7TU6ykvjZHk/oq/xCt4p+xt+5ujVUprBLsZjKPWLaKoPVgg1a3G9tWAnWCWwr78QXjDxzrWZQP7sHzQDG9bhsQ880QDjib5h7iH+9nFm+fawj3Vp2maj++bVwroZoa338/aXWqkvBOaBHlaHR2H5Nya2Vg9NIzIT1DD2tItmvtYwvG+kubHtYcs9FlFH0HZnDEm7m8vh6X9mMG2jtlodGDUBvsHe9I9mY+/Ax4+xoOcBU+x08xnPsrnU/vBASQ== 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=eKjBrBlYi81AwmoCTlVxMi0XuRHMmtnX6O2MuhzGwS8=; b=CtrNWDAgLUeFETsHbrhOK+MpnXKGofqk55o0mP0E7FSglvzz1pGwT3sgdDBc7m993EF188CpbPU9QCodFl50aq+AC0GMoTnDlIWxPhzIRzhWCa2siMdeMy1Tg2dlZqNxnnwgWgJEVFvlpYLGaEUgQKx9hTvkERHur0ki0EkLXZOs14MUNRQNKseOMiDlHzoeNzPBgor4qOXoCvQEFX2td2jT+D6/MHYKx7ArRboiDpyrlA/stGuUrf5EsQG7keqfyxOuof5UdnYuWz3TzsmKpoxXgN5LnjS6C6CuYeEUR5jGR8/FbsO4Ph4mbrNMf+qMNNeg6ff5Q25eTBqKT84C4A== 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=eKjBrBlYi81AwmoCTlVxMi0XuRHMmtnX6O2MuhzGwS8=; b=PTQEALWTxsHQoSAEnSmETyyHSgbGoD2+WgLhN6eApJn8vaIihQbvFeGj6ybODIGd01UrSVMFGN9sDsSW+ffq8JqDP84uYq3Z6zv4fEa9wc44KkRgcAtc18k587U/y0L7UclriuLM9BNOkbSHcH1CPSKunezzAlOXyPmCNbZk6GTaAB6bco56o6PQGK6PUuGKaMa/G5iKH72A4RCtjHEl1TAwUZTxNRoRw1el9cVGlfZwSfNXmukJfvI6v3GKCh+TxXeE6p7Wsm1CazHuMGRXPumDmlU0QDCebCyudufJC8koPBdTaKFx/2VPwmCid9CxCTwf7nMc02U6lMiRYe5kgw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Mykyta Poturai , Teddy Astie Subject: [PATCH v2 1/8] vpci: rename and export vpci_modify_bars Thread-Topic: [PATCH v2 1/8] vpci: rename and export vpci_modify_bars Thread-Index: AQHcr7UN7Q/q9Zlc+0i/1HMfYtl+WQ== Date: Mon, 9 Mar 2026 11:08:25 +0000 Message-ID: References: In-Reply-To: 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_|PAVPR03MB9775:EE_ x-ms-office365-filtering-correlation-id: 59e1b0c8-4252-4867-d6f1-08de7dcc3007 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021; x-microsoft-antispam-message-info: O7Ti40F72MuPHn/AiK/Uqkd3Z4k2+q1D2Qr6ZtRkmezp/ADgjLgmWoLiiTkSeRmV5hZfilh2lc3Tu9zDsG6w+sQgDGzMSUQTUVkH4F+DHhXCtolo/R53R1UA4ttqzSG2koUzrx2H+41YXU9kpNOs9cmV5nrKXo5zTQY6wcOb5gysccuwnjR7DL4wRMVgBWT6V/2VHxZIcLlSzuWu6sqKQdTyAhTHK3x9B/AqhGErHHHCRKo3RMLYzpIYh7yt86bmwvOGmbprJPJz0vieiwwS+R7vxKfiLuId9TvgQijk0z/I+GorL30YK8lOPn6kaXXLItMfciBSHYwHK3XFxxY/WkiKG09KHj1p0wZMTeMSHKh5WLTTe4caqR8DQJh6HJOpVhzc5u9vyue67UW+aAmDTGnEAdP4KMS7OQN/YmH3LSaycUeQZg8ESdDiymsE9mIKsfK1XfAWBWJdD+L5T0uUGFLFTvcI1sf2hA4NrX4MIi3i5S4N6L2gDcWbOdL3XPetuHI4MBL1dESOEX9S24t+aTpgsSXi/1FlgwFmDEzKHWb3R1x3QdBpd9GtWqU/+2U1IUDmnsf0vh5zpEn03HdENqc6FVS10Mp172Eg1S0zV+Q5f2PC4OFVaupwiTb0SspPkI34ZXMlyu65m/oXptbBLQ6DzhxH2aAXM4R/V+1NdH4Li2PEWdjSA94JGc8Mehrj55bWrUzhUxUnfXSv204QoIUKUyWMJX4uk7AeB4Oh6dLKwKlzwqIPVuBRI+ZxkuUYNTRPlyp8w3ar8l4f5HpJE8w1fBPPGGM1jV3ihxf6FMI= 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)(366016)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?T10TfFxg+Q6Beh2pyBHMUu0F7TExdPD3nIAZ/L7Dundx4p71bZ6VQqJqPg?= =?iso-8859-1?Q?eZ33+iO4wH05/d2SQP5aW0U9D4arpYgrPj7AjYcqtNMXSL6gibqkgB6PwM?= =?iso-8859-1?Q?/VFXuA+UKxoifPozxKl9CF29wB0vBznYueAhUar03v5m/OXO7Um7OcwHFx?= =?iso-8859-1?Q?XkCR8m5/xSfiOuFRYzRP0nAHM+1cButtZvyBtK+ATCjY2qEH4VXhZTcWOm?= =?iso-8859-1?Q?5rkt5sfrOM3L0WG6tSBw+9frEkIQFZMQ4aeaPAdkJYAZNMiJ83MFW0lgh3?= =?iso-8859-1?Q?BRrf6qooSsSG3JJ9tY/Vxh2kaxJz6DiS1npGkZOtl4Mab1K+bcKbmfZYbN?= =?iso-8859-1?Q?2dfKulaDEW0xsqCeN7I/cOFQcJGsuOZOELc7QCI6bI4WBWyKUaKnh6DEv8?= =?iso-8859-1?Q?3UBs77T4UtCe+G4JzUmE2T7XE07kUThv1oaWm8SrEfVDojMKcCoo7S3uUf?= =?iso-8859-1?Q?zXYSU0klr3eqFlssheVKvpnREYGUlWLrUQuNxOSybMiuLn3Y5KdV4nK+3f?= =?iso-8859-1?Q?Dfg1PYI4wcf5kOu2AY1mL44e8/6MyAfw83/RvjzhVRyCYOOb1KgIhMGhEX?= =?iso-8859-1?Q?Q+Mcvs8W1u2d5mx3YxtItdhJIGnjoPqvGzlVeAKHIaAb5UQcc4qBm8aY3K?= =?iso-8859-1?Q?4UXFZaFKToJO6Rq/TIbU9EYHWQifUgBrmA3Y9Kz8zqnIYfHGg9SJIZlbOh?= =?iso-8859-1?Q?iHMLEXkCjeBXi78/g91NgjSVICSfMw3okQUOwFVv21vs5834kKuJUpzlWd?= =?iso-8859-1?Q?nfM5DaGXoXf55mMkBaPA3nao1Vxb85Ye/PAJe891VTfpXuqB8mZcZc8dgw?= =?iso-8859-1?Q?vfqx8t9mBIp/fV70/SeRMichumv7P3nlNPrKgJmgWf6GXIAXB5WA7Gc8C4?= =?iso-8859-1?Q?nOLMUaoULiTSr8os9s1iLS2gWY2/CJ2iK/Ti+Miq4B01/AlcPsY5SxcTsg?= =?iso-8859-1?Q?+nfggLf+UlVvJdi/oS5A8l7ygHCjMkJivNLPIGpPDLbh9Ydym3xFOOc4HQ?= =?iso-8859-1?Q?qW5kV+zF7LoKbuJ6DvEZTSpoQNJz7Gk8ypE0lk0oxMvabURYpK0jKo3KLz?= =?iso-8859-1?Q?JKhieJgFBbRPpL6UD04B/NK2YDNBYlxeheAq7SWvEdhxSyBIzCkyjkzP3U?= =?iso-8859-1?Q?+NI2CjVwMgpwY0eXF/8QshL6kA9FcIj5xh13nsiLHZz6+0EIYrlehaXjw9?= =?iso-8859-1?Q?BjQh6KTxFTRxfQuNA6dqLh6S9pYmpfnCdL8IERKEJYZ/2CuUeAi2CW3Bz5?= =?iso-8859-1?Q?sCywEehndIuTSmQ3oaYE3DQoEH0LLyAmJIVJoSfklt0UeRcLkLyJIc/uZ2?= =?iso-8859-1?Q?t+0x85Ll4GHPO+KXrCRLMXpbEy0MyICbO02B8wo/BPebqnsrjT9+SUQ7ck?= =?iso-8859-1?Q?oGbPlPgYAZUgmgZvfGP872fn8tu3sP3EZKRslAZ2qsiQvvjgNBHTrG6tfZ?= =?iso-8859-1?Q?x5Z81CAB82oluGkaicsUn9QIQs1brVk0d0bWBwF5PCzsrl6r+dsGBQTH0K?= =?iso-8859-1?Q?0AWbFb4CCkktJG0wbbkMGIKQXGIq0iE3E4rYhhL5rZzM+Z5TQ5HabD+U9Q?= =?iso-8859-1?Q?3FMgTQZ75+hBo1hfcixrJDcfnjHghIq/hkkRnHUdKltpg8tq9/gsiuVrSb?= =?iso-8859-1?Q?3zCj9hg7WeXUE3JEu4S8OeCAf61VW2Zng+8dXxhMjRW4yEpR24w4PpEVqz?= =?iso-8859-1?Q?3bxmLrYvMXrrsQCWVjVR7wbCwM/fYfW6dzqcabCh2aIHlHtrWZHeJH3Nmn?= =?iso-8859-1?Q?x+W9eL/wjIkE+1UwsqMaDcbA81EsLP5VIhUi/RQ1MiXOpjwZh5vmznSP7a?= =?iso-8859-1?Q?56RvvFOjWnpA5FVxX9uU0qSmxyDHhhg=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: 59e1b0c8-4252-4867-d6f1-08de7dcc3007 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:25.6964 (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: BlPLie3bHHeOvHSRF4kOKH2ewat4OjMOV360X4SbCOCZfotcK/B+OAkQAAp0oykHdizm0DietFKYV2+dQ6IJPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9775 From: Stewart Hildebrand Export functions required for SR-IOV support. Signed-off-by: Stewart Hildebrand Signed-off-by: Mykyta Poturai Reviewed-by: Teddy Astie --- v1->v2 * Collect RBs --- xen/drivers/vpci/header.c | 16 +++++++++------- xen/include/xen/vpci.h | 3 +++ 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 739a5f610e..5202518e83 100644 --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -304,7 +304,7 @@ static void defer_map(const struct pci_dev *pdev, uint1= 6_t cmd, bool rom_only) raise_softirq(SCHEDULE_SOFTIRQ); } =20 -static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_= only) +int vpci_modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_on= ly) { struct vpci_header *header =3D &pdev->vpci->header; struct pci_dev *tmp; @@ -545,7 +545,7 @@ static void cf_check cmd_write( * memory decoding bit has not been changed, so leave everything a= s-is, * hoping the guest will realize and try again. */ - modify_bars(pdev, cmd, false); + vpci_modify_bars(pdev, cmd, false); else pci_conf_write16(pdev->sbdf, reg, cmd); } @@ -713,13 +713,15 @@ static void cf_check rom_write( * Pass PCI_COMMAND_MEMORY or 0 to signal a map/unmap request, note th= at * this fabricated command is never going to be written to the registe= r. */ - else if ( modify_bars(pdev, new_enabled ? PCI_COMMAND_MEMORY : 0, true= ) ) + else if ( vpci_modify_bars(pdev, + new_enabled ? PCI_COMMAND_MEMORY : 0, + true) ) /* * No memory has been added or removed from the p2m (because the a= ctual * p2m changes are deferred in defer_map) and the ROM enable bit h= as * not been changed, so leave everything as-is, hoping the guest w= ill * realize and try again. It's important to not update rom->addr i= n the - * unmap case if modify_bars has failed, or future attempts would + * unmap case if vpci_modify_bars has failed, or future attempts w= ould * attempt to unmap the wrong address. */ return; @@ -933,8 +935,8 @@ int vpci_init_header(struct pci_dev *pdev) /* * For DomUs, clear PCI_COMMAND_{MASTER,MEMORY,IO} and other * DomU-controllable bits in PCI_COMMAND. Devices assigned to DomUs wi= ll - * start with memory decoding disabled, and modify_bars() will not be = called - * at the end of this function. + * start with memory decoding disabled, and vpci_modify_bars() will no= t be + * called at the end of this function. */ if ( !is_hwdom ) cmd &=3D ~(PCI_COMMAND_VGA_PALETTE | PCI_COMMAND_INVALIDATE | @@ -1059,7 +1061,7 @@ int vpci_init_header(struct pci_dev *pdev) goto fail; } =20 - return (cmd & PCI_COMMAND_MEMORY) ? modify_bars(pdev, cmd, false) : 0; + return (cmd & PCI_COMMAND_MEMORY) ? vpci_modify_bars(pdev, cmd, false)= : 0; =20 fail: pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd); diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h index d6310104ea..a98ddbb32e 100644 --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -295,6 +295,9 @@ bool vpci_ecam_write(pci_sbdf_t sbdf, unsigned int reg,= unsigned int len, bool vpci_ecam_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int len, unsigned long *data); =20 +/* Map/unmap the BARs of a vPCI device. */ +int vpci_modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_on= ly); + #endif /* __XEN__ */ =20 #else /* !CONFIG_HAS_VPCI */ --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249274.1546744 (Exim 4.92) (envelope-from ) id 1vzYTP-0003ie-ST; Mon, 09 Mar 2026 11:08:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249274.1546744; Mon, 09 Mar 2026 11:08:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTP-0003iX-Nv; Mon, 09 Mar 2026 11:08:31 +0000 Received: by outflank-mailman (input) for mailman id 1249274; Mon, 09 Mar 2026 11:08:31 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTP-0003iR-6e for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:31 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4d7eae7c-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:29 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by PAVPR03MB9775.eurprd03.prod.outlook.com (2603:10a6:102:312::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.23; Mon, 9 Mar 2026 11:08:25 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4d7eae7c-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uOvZmtkZw3rwduwh2mSb8KdWHJwNlpBrMK/iYdDlDnYlHLyqMsDzx5cdCnz59SbRSfEWJecrTaJMdo4S2LTSj/CtJ+QWPhEzx++0oUR++ayKXZxlNTPINeqW64lhUTs8nQe32V8hX3sOsGjaFpQYUn6MBZE1zfK4B3X1h0ZtRspvrYs0/pPTHPAYGz3nQE990WSZV6QrI+oQAKE0W+K4Y58jIBHmf5qH16ahRTQ5yUrZGKDg7OZ5bheerl5Q/P04lgeHqA55HJ/W9lMpqxSKrfxZnLrN/F42r9ocRLZ9URIBIOZ1Nyvj+BdzJcTi/PdsUjP/Oq/ee6yvNAsFFUH9NQ== 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=ORmtUgXQjDNdy0TrDi9teNyaY6deTFrWqE/Nuuy8jbU=; b=D2t0GIiQCe0F9gBVDz1wFuh6V4FFchw0jIP9RSRhQrcdzPjcDzK0l6vDOm9EAALLWWK7690wBjYdiDH3K/LnINZeAIXNa9DCvAtzJKudF+IZD75ybE0nHUPcB4ddGQVTh/vuhNVz3BgnC+qPQNLcKPfvE2dom0J/qCyb0dNYRRfrABpdlPPDkOPSn9bgp63dUxZMKKb40bomw6bxb1k+BCr9pKnz0QdoaDQBxaauktYxmGFYgB1gXaHmXPvAUDeaY4l6d3axBGSWjzLcmaRh1LWwtK4DUJeP2GghpSiaAJf9GSVmtJM+ZP1Tgp2a7ThK/LtU8FwCPr6x3EGEy0dNPA== 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=ORmtUgXQjDNdy0TrDi9teNyaY6deTFrWqE/Nuuy8jbU=; b=mLdF77Iiv3Dh69B7B6JBqVS3ehRzNWWifz4h/jrut9sNzrm4UwjNmqI75+wlQVApxDF4vqvPjVWkmFznvnPRcMFX3igwo/8+RfAMsGX4hvgRYPXWbvA4qH/sYeoWLeBhGy9EvGaqPB/km3wz3PtD1AlnxkjQBiEHcJmLMaRF6vHGwe2DAHDIpsLJxhi4idr6EYqcG8lMO6u2zIBo08SDaxxDnjIOiQ+S4RdkWRuJrUTTsrKNnb+3co6xjnT/xVg8VXG/RWkaM6h9Mt6AG1L3ydoV4YMLvbFMTv7h200AWPKqho4ylezOvpOWwyqtWHeU4P4HbSVqvmw2SBIM4wAYJA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stewart Hildebrand , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , Stefano Stabellini , "Daniel P. Smith" Subject: [PATCH v2 0/8] Implement SR-IOV support for PVH Thread-Topic: [PATCH v2 0/8] Implement SR-IOV support for PVH Thread-Index: AQHcr7UMVee0NzcPjUC5JqPDg9DN/A== Date: Mon, 9 Mar 2026 11:08:25 +0000 Message-ID: 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_|PAVPR03MB9775:EE_ x-ms-office365-filtering-correlation-id: 5cf795bc-6e92-4c06-21c3-08de7dcc2f48 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7416014|38070700021; x-microsoft-antispam-message-info: oNd6p/lsyul6TjMoRq1/BBTIp92yn0toBKalNsVPofxTezZ3RD43jcHUM0XW+P/NPmf2IhmkGhCDnZkPpprrcBeYDX1MUOj3gjPf74za80BhTY6gdbeSPLT9VrgABtpJOJPr1KXwhbT2LMXFTspl4a/gYAyBEpjk95aKq4TepMX4qyuzzhaukh9D02S7XoyhwabpAgEhgeZ7muZMDFQHJNM6ktKYWN+2J2L97rnBJeesEcbiOUqpFtXTMwbZf00SLA50WbkjBfq3mL4imySrmApsjY2EvLJ2OT0gcegbRALwJmdnKL3Msc0ihtZd3eXAcHR1wILtyMy44aVeLkQ0bDKFpnmQw8Y0WtxbpXuBEOEHRhGACYxD2fxrE53vjFvhTdUbeY2YLoJTzL4NgTqy006w2qgmch4Iud3gBLjY7PnUFX3ueWguRd5Blo2nqt9HgPQOyuuSytvhWysputZvBXjV3ji0BdwXcAD2KAvSbE2dRM7jufmY+HeTPWCV3hIGAI0Zzc6gUPcBlI6OZzcp14kLj0KNbCCeFKtBBLEcTzXhUaXFMqjcgxj20LyLHMVJMOiKsEHGtbvYYcUqGcxJAscvxvZMtovroR3fi8dKSjOYMVjHJwJaWJ13UjH+vJWBMimKeI6+IYZJYsQCrLZdfue2cC3nflJINCC6hRNsS3x1ZYjraTtNnWxZcIPNMJG5+fJ0WvvVpCMtfdXYB1E5b29r7QCfqXIeWVdNrfEP/YVJmq9csrsOHCuYt42DACcxcLoQ9PjjVnCL1MjZI/uV5YE1DNv5Y9zCfJ9jZUl9+uQ= 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)(366016)(7416014)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RDlveWxSVlNMZkJwOCtIRU9CejVLUmJHbjlubS9ndXVyYlk0M2VlUkpWZzZM?= =?utf-8?B?akpZWWE2ZVcwMWJ2aTJqQ1YwSTZJaHRaUWRMQkg2bEptc3JyUFRJYncvMCt4?= =?utf-8?B?QXFkclZqeC9DVnNZRUNoeUZSdDdkYVJNbWZkQnJhNE1UbnJ3OEZxQUZHNVVy?= =?utf-8?B?ZFQyZVAvTGM5RG1aTU55NHNTcmhWUjNoVHBuYzk2Qm9hTDlkZ3RBZlV4OEVw?= =?utf-8?B?UitGNHZIOVpuc2orQzM5dDBIMThTL3EyTlpsWlJsajN5RVNDbm9QeGtNZE82?= =?utf-8?B?VU9SdFdQemhKMzQwOXJXd2gzVGRMK0NXRXRUeGVGOVlOTW4vcUFMZ2RvcW5y?= =?utf-8?B?YkczZTM3d2VyRktJSWdYa1ppWkZJcW1kTlNSTmZzSktMNHlyNWpIY0Nyei9O?= =?utf-8?B?OEJDdGEyU1lEVGlZK09jY1lISWNrYUxvRVBaNm9zN2s1Zm8vQlUxVnFRTFhw?= =?utf-8?B?ajJDdXdJdjFURUdFWHREMjliaEg0N3FLQ1dZSFJFbjZqTjZTeDlzZTFDSXZ2?= =?utf-8?B?TXJTMDBHbWplWFRuMm1MVFZ1NFNVOU5pZ2NXakdWNTEwcjlZNGUrd282U2Zk?= =?utf-8?B?LzNGY0ZQTUJ3KzhCYjJIR3dhZ0hJNnRjRE41QTdXZjZjY3FhVGxTcjZPTzdL?= =?utf-8?B?M1V3S3dtbEpvT3c1QkpBaDVaM1RTZUVhS2t1UmxWUzdEOFJVQTgzSEtDa21G?= =?utf-8?B?b1I3NnhIUTFHcHM1b0p4cFpXZ2h4ZkdkdEdKTzU5cEkxbVI5QUFERTdqenpn?= =?utf-8?B?MHRhRWdjWXFCVEp3bHNxc2pEcmZQeVdNSmF3MWVoOFlVUy9reWlwY3NNWlAz?= =?utf-8?B?QWNZT1ZlU0dTQzNlL3E4VzAzdDdmaGpQcWFDN0ZqREQrMCtXNXFyNUVuOFh1?= =?utf-8?B?RTZSc2tidVcwV2hWOWxHUkxCMEY2WlRMYTY0Mkg4ZU1yVGRNSkw5dVVaSkpF?= =?utf-8?B?b3VoVEtKc3p5VzUvNU1uVXhmMWVaYVRjM3VXWUdKSHNEVTNZOUVWZjdxNnlj?= =?utf-8?B?Z3pKMmQzc0plSmUwZVNGNUMyRXlvMDk1alkwV3d2ODI2bjdwcEZ2cFdyTUN3?= =?utf-8?B?dlgxTjNBdVZNZzNxNEF0d2wyUkpKWlBZRExhVnlrUnAvY0k5MmRoMWcybFpv?= =?utf-8?B?KzI5SDl4aGhKM2xkVVhwdmlpaDFTekc3OXV5eGdQNTk1VEdIUm9KMzlPQzZl?= =?utf-8?B?NmNabVFxWkc2a1RNM2doT0xla1E2VkMzOWFKLzh2YXR3aVVGY2pSZWE4WmlH?= =?utf-8?B?TkJHa2syZTF6QXBUM3V6TUVPWFJIY3Q5bG1mL0pIT0VOSVRKLzM3NmdPbjNC?= =?utf-8?B?cXNWMG8xUndPWnlSR092ZDdEU250bVpSWjNQSkJoS0t2aStrWStza3Fxd1c2?= =?utf-8?B?cTJzSDNnaHY2bEVINU4xaW1SNnVsWC80empENTRtTEZnOVhKa0RDeU5rS2xI?= =?utf-8?B?dUlFcU01WVhSNTQrWDJFZDlpenY5WDUwN2tocEV2YkFxdGR3ZStRSi9vRE1Z?= =?utf-8?B?WTZ3Mm1JeW1zTUYrRWF3L2ZFdEczR1RTem5qTXFIRHg5d0thd1VELzd5amti?= =?utf-8?B?TGlSWW1yWEZWUWR6M05xUGxmZUNYQUJxV3M4dkNvNkJMQVdTVzhOa3VtcEhY?= =?utf-8?B?U0QrdGgxaXBOdk1sU2tsNjBQQWRVY0pUVndCcDhKTURZYzFzSHpNY3VWR0V2?= =?utf-8?B?blVJQ09SK1hWZXVGVmYvUVdkK3lYbm91dzNoVWo1ajRRMXFMWXZubUtQSFJv?= =?utf-8?B?NW1GVVlFQml1bVhwc2daOC9HSnQrTk91QWwrWjRhT0x2MDRDcURVZ0ZSMlA5?= =?utf-8?B?c2RNYU1IRTdWbHdCTXJTSDZSL0dXemFsTFhMS3lvcVg4d2tqcnNNeU9lMWpz?= =?utf-8?B?clh4ejZ4dEJIQnFmbzRLekQ3YWdhQ1kzSkhLTFdYc2Jkc1N6QVJraHJVOGlv?= =?utf-8?B?bWp1cFN2L2ZtVnd3aUJ0V2NuakdpamxzTVd4R0VsU2VNR2VhTGh4QVJGeXll?= =?utf-8?B?R3Q2bm84UkJyaVh6M2NmQmVHTWN6Sk5uU3BPZlBRZTVONFc1QXptcGF0dG5w?= =?utf-8?B?ZnUrZFArNHZyM3U2Zi9aNURZT3lIZmhlTjNNaTVpYmFpL1FiZWhtQTRFWGRq?= =?utf-8?B?NWVWakVodm9saFpYSXBEZlpEQU9QWkg3UXFFMVI2cktHS0tTZTBtbS9RL09k?= =?utf-8?B?bEs1Z3J2dnpNU3p2S09BOEhMRTZlbVJPL1h6c3BmM2grdkFYV0U3K2I0SVBx?= =?utf-8?B?eHZ3RTJZUDg5V2s2M0lyTXNsWURmRmdiQUZEVGErd3NOUFFhaUM1WE5ERVBa?= =?utf-8?B?OGY4MWROTWdjV2J3Sk9rMFZKZDlHTi83VTNCNEdsWUtlM1drcWVOakN0c0JG?= =?utf-8?Q?LyMr27A75TKP/H0k=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <354D3193A0109744899CF9AFFC908DB1@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5cf795bc-6e92-4c06-21c3-08de7dcc2f48 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:25.2657 (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: Y6nt577vE8zQeTQPWZxag4XXYexzkbFuA5ed1RAvF0UnWPocUuicf9p//vdYucy4BKy+l/UvYEtQiodd0ASELg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR03MB9775 VGhpcyBzZXJpZXMgZW5hYmxlcyBzdXBwb3J0IGZvciBQQ0kgU1ItSU9WIGNhcGFiaWx0eSBmb3Ig UFZIIGRvbWFpbnMuDQpJdCBhbGxvd3MgRG9tMCB0byBlbmFibGUgYW5kIHVzZSBTUi1JT1Ygdmly dHVhbCBmdW5jdGlvbnMgYW5kIGZvciB0aGlzDQpmdW5jdGlvbnMgdG8gYmUgcGFzc2VkIHRvIGd1 ZXN0cy4NCg0KVG8gYWNoaWV2ZSB0aGlzLCBoYW5kbGVycyBmb3IgU1JJT1ZfQ09OVFJPTCByZWdp c3Rlcywgc2ltcGxpZmllZCBoYW5kbGVycw0KZm9yIFZGcyBoZWFkZXIsIGFuZCBzY2FubmluZyBm b3IgYWRkZWQgVkZzIHdlcmUgaW1wbGVtZW50ZWQgaW4gWGVuLg0KDQpDb3JlIGZ1bmN0aW9uYWxp dHkgaXMgYmFzZWQgb24gcHJldmlvdXMgd29ya1sxXS4NCg0KVGVzdGVkIG9uIFItQ2FyIFNwaWRl ciBib2FyZCB3aXRoIFNhbXN1bmcgTlZNZSBTU0QgQ29udHJvbGxlciA5ODAgYW5kIEludGVsDQpY NTUwVCBldGhlcm5ldCBjYXJkLg0KDQpbMV06IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL3hlbi1k ZXZlbC8yMDE4MDcxNzA5NDgzMC41NDgwNi0xLXJvZ2VyLnBhdUBjaXRyaXguY29tLw0KDQp2MS0+ djI6DQoqIHJld29yayB0aGUgc2VyaWVzIGZvciBWRiBkaXNjb3ZlcnkgaW4gWGVuDQoqIHNlcGFy YXRlIGRvYyBjaGFuZ2VzIGludG8gdGhlIGxhc3QgcGF0Y2gNCg0KDQpNeWt5dGEgUG90dXJhaSAo NCk6DQogIHZwY2k6IFVzZSBwZXJ2Y3B1IHJhbmdlcyBmb3IgQkFSIG1hcHBpbmcNCiAgdnBjaTog YWRkIGEgd2FpdCBvcGVyYXRpb24gdG8gdGhlIHZwY2kgdmNwdSBwZW5kaW5nIGFjdGlvbnMNCiAg cGNpL2lvbW11OiBDaGVjayB0aGF0IElPTU1VIHN1cHBvcnRzIHJlbW92aW5nIGRldmljZXMNCiAg ZG9jczogVXBkYXRlIFNSLUlPViBzdXBwb3J0IHN0YXR1cw0KDQpTdGV3YXJ0IEhpbGRlYnJhbmQg KDQpOg0KICB2cGNpOiByZW5hbWUgYW5kIGV4cG9ydCB2cGNpX21vZGlmeV9iYXJzDQogIHZwY2k6 IHJlbmFtZSBhbmQgZXhwb3J0IHZwY2lfZ3Vlc3RfbWVtX2Jhcl97cmVhZCx3cml0ZX0NCiAgdnBj aTogYWRkIFNSLUlPViBzdXBwb3J0IGZvciBQVkggRG9tMA0KICB2cGNpOiBhZGQgU1ItSU9WIHN1 cHBvcnQgZm9yIERvbVVzDQoNCiBTVVBQT1JULm1kICAgICAgICAgICAgICAgICAgICB8ICAgMiAt DQogeGVuL2NvbW1vbi9kb21haW4uYyAgICAgICAgICAgfCAgMjQgKysNCiB4ZW4vZHJpdmVycy9w YXNzdGhyb3VnaC9wY2kuYyB8ICAgNiArDQogeGVuL2RyaXZlcnMvdnBjaS9NYWtlZmlsZSAgICAg fCAgIDIgKy0NCiB4ZW4vZHJpdmVycy92cGNpL2hlYWRlci5jICAgICB8IDIyNiArKysrKysrKyst LS0tLS0tLS0NCiB4ZW4vZHJpdmVycy92cGNpL3NyaW92LmMgICAgICB8IDQyMCArKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrDQogeGVuL2RyaXZlcnMvdnBjaS92cGNpLmMgICAgICAg fCAgIDMgLQ0KIHhlbi9pbmNsdWRlL3hlbi92cGNpLmggICAgICAgIHwgIDQyICsrKy0NCiA4IGZp bGVzIGNoYW5nZWQsIDYwOCBpbnNlcnRpb25zKCspLCAxMTcgZGVsZXRpb25zKC0pDQogY3JlYXRl IG1vZGUgMTAwNjQ0IHhlbi9kcml2ZXJzL3ZwY2kvc3Jpb3YuYw0KDQotLSANCjIuNTEuMg0K From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249276.1546761 (Exim 4.92) (envelope-from ) id 1vzYTX-0004Di-CF; Mon, 09 Mar 2026 11:08:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249276.1546761; Mon, 09 Mar 2026 11: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 ) id 1vzYTX-0004Db-8o; Mon, 09 Mar 2026 11:08:39 +0000 Received: by outflank-mailman (input) for mailman id 1249276; Mon, 09 Mar 2026 11:08:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTV-0003iR-TL for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:37 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 521c8dc5-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:37 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08:27 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 521c8dc5-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nl8QLc9UdP4ObnHMHs2oJLNhVmBTPr7g7K/+hl+X37iwSZo8VxQXuDT8O90eGWeeO67dqMdQyQu16VlnC4z7czZ9hghgP0c7KmmAYV6OqRYZvwDbiCzEZdiB14C4uokcLH6QRS8pcc/uH9lseoX6LPkoXFED6XeY/7uaXGzN5rXpC3ZL916wDMYd8YEL+hBsJSqx1UPcbEkNwsg/tWsZO0d/bILruNZJEapkStxToql0n3FTuvV1Dw6SEsl3HSBwzgrpRMSUBxGydgadz8fgmfW9qIwRxwZc3kAXAvOObtAGmcDfqLTNbk2YByiFyCsN9IQm9BaD8UO6ZLbnlvHjSg== 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=pWzIGDE75yh52u15Xirf0pf0J8xYC99w/7XLPD+73E4=; b=RutKlxD6KyV5kxYSoeghtgKLH9y+5DtP0UA2c/EICN1DbJ8PVVGXnPWiHF4zhh+RhhFdyJr3k7WP+euOM8vpEnyiHvmBJgXyC6ubHCo1bvfDHMeSAJypI5ntTQtxgMAGEGgJb0W1zy9fPQ/5IT0Xc7kPv4aYXNISqe/4hYLO0V0erg4KL2kwKoLYOMHA83fNMJAI5oTih+SKjuKAhWQZQU8XxEcMOVu4thXBTcLZDIiKt3rH5+1pTVr64e1t7YFc6slmyP9G4Ym96GKgvhwedG+pHmJF0ELLumlxJ6CsMT8Nj3xdJXVZZ8P6L3/aNraWaQH+y6w/I84vOiQbXmbyug== 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=pWzIGDE75yh52u15Xirf0pf0J8xYC99w/7XLPD+73E4=; b=PHiJLcidbNn0dDFazHvU98HdYzaVw3FIO+hxVLLyOY+i8kZOlKOk8NaJ8+xoEzqpdR9Togc9youYXVngFNTl+TBD8BFSCJouCd7gi0eUORPifGY0LLHzbERZ+deNb/8HYog+6LrPWJc71IAWCYkcr/5xKXl6Cb+2hdESYSN+MoHwSdltFOZrxk65KdRM+XjYPWT+PWGkOx2Wr4SJPJWQ/yao6DoyvFNhAecaSm3nBQlWsOqzMbpuZ3BsqT5lxQoC9s9nah5GFtF+OJLybqkW0R/9d5ivDQaPDpZmZMue6Qg0XhKQkdkKe+kNFgPg0JlEcLYg3CF3u05ex15GUAB1vA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Mykyta Poturai , Teddy Astie Subject: [PATCH v2 2/8] vpci: rename and export vpci_guest_mem_bar_{read,write} Thread-Topic: [PATCH v2 2/8] vpci: rename and export vpci_guest_mem_bar_{read,write} Thread-Index: AQHcr7UNr/GbhVrPC0iBoBGfLfVFWg== Date: Mon, 9 Mar 2026 11:08:26 +0000 Message-ID: <5f364e8fddc83b9a7ae08945a91c38ae1648442a.1772806036.git.mykyta_poturai@epam.com> References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: acd06d94-67d8-467e-243d-08de7dcc3047 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: jsAlT0GNPi0IS2NxVOWAoYpQiAmM0cDPg2eh7bUOYeRfdqOZiE24yLU2/siQ0vDErl18i/1bIPp827lFJiULUMJja9zTPEE917ec7vu9/wdinp4p6luFKLa0RBLRvIGZnz+wq4BUz9TJYW20unLgZ4s1IllDFzIVOdjOueeRG7FX2PuZbj5ujnRzuDNihlTBggpt7F3cmn0IWa3tK6MVPki7XCFV6vGEPCVs4rW+x9/bgYb7mG8p11YBY51n6kwKrDQY+cdjYotq9CJEp6JiVpcK+nMVUse5tezCE7rFAvjSMDVYkPc/1q+BTxYPVAbG2Cjem3FF/TVSYAsEOvaQB+xbtDqs4oDAIDNKDanUrmQ9fsinWaIevRi7Xl4xtlkaFw+NXCD3bRXa0eoLvwtfHdntorHGu8yrfleOW10SM+4OUXUsZzNuBZfHXL4wN5F6pkJIB7rZAUDr2Uyoe+WqKP50344TSc0d849cvTtRP98dkuXCP2U0spUCXiPlE9ErqJPIfxPzyoMyQaJXqFrgWduaSKxLFUUk/BV5+EnvJljT8Jgs+1a2AcMnYDmw7mmMUlM1G5/BaAHI55Ks8DWUeqdI8n+oXD9AtLnI4vl4Nz14V0dMostCi0/FBQOyfcxoYwze8zpqnCudvtmYg7JImb84zFKxzlu7PqmPcVE5oiFR5oidqjs29LkIp7Keiv2ImlL9ciO2Avd1oOR8y5Ovwgof3Lkfs49r/31cWcGf6/m4YmlavTTVg/DYmMHN/fwE7jiymyYRhii15lWvD5GVL2d7ALPHqMTa0k7P1qwYpHk= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?auwvkiNQA2GZu4QqaB+cl/5cXA3UfuB8bj8To7PB0vkaqMTlTNkXZBok27?= =?iso-8859-1?Q?QNHUFEEa8DrXqOHczIp4lSVrBJY//w/tgiyRB6UPtld6zL11Kf95Pj3F6v?= =?iso-8859-1?Q?29Rx3LQpyGhaXUfIzyjWifCrXTC6/Sp9E7PCuJ1q5q532PGbhtg5Rj4HUc?= =?iso-8859-1?Q?C3UiAEVIgynCkfFKoH/JtJXftJw4cr22ynvTB23yxPP4bcJo+PxFjKSkWh?= =?iso-8859-1?Q?BhhpyA3I9TMRKPGLDnIKPOrlunZHtR3fWLqfhwvBW02Awif+5aMjuW+CXH?= =?iso-8859-1?Q?hcSGuLP2lYIJxCndVb9q14SoMYl5mQG+yirhQ5Dq4Bd820yigWBP2lCh9b?= =?iso-8859-1?Q?27mas/VjtjWTuqFzEVsfO+VVV39THkwSna/oiUYtHxe9Bte5dw3FYRReUQ?= =?iso-8859-1?Q?xU+IJ+ARY3FeDk/CGJN6pHJumqsLRFhaR3r1w69t6Lq9BDSmC5MT4ENYPe?= =?iso-8859-1?Q?+F62wN36nIJkLtOO4/rB7JpPTXRQE4cmLS2zqiEUd2lRI/xzlHFMHopMJL?= =?iso-8859-1?Q?kA8X00Y5+lNCLVxfc74YgZ1HpjC5pkRLK6s3Cdmxk2jGYKcT0HmkyV+CC4?= =?iso-8859-1?Q?17bQDmm0IVB99GeIoEX+zv76NtTdHmdw3VWfuFmRO8r55AK4QoV4y4X05j?= =?iso-8859-1?Q?B12c51r0Jz6VlrVvs3fm/XyTPDwbqF3r9AlC4x1pXswI08RGU4IIAJyjhu?= =?iso-8859-1?Q?u8z4nmtCPMvhEMTkP+0rCB9xAAScV+pAw/UVjWFXRoO5UIj9q1FZ1+0as/?= =?iso-8859-1?Q?bgiKBK50dm+g06qOHjuNgvB9paEjMfFOd09oJX9Rg2eVBfLZ2rRb64RwoN?= =?iso-8859-1?Q?KbfzBPRfyM2H7kV+W4KB4oI1PR/rXT7JDYGNSN1/ZPYQeBAhLWu/uPACRG?= =?iso-8859-1?Q?cjzPD3AzQsnHysFT0uC9VGKRj6hVNS+dUWynntMioFg0vLLqZ7wybjd7ki?= =?iso-8859-1?Q?IeDhANaeN1f6FY1lDlr44NoKyoH83/7dIRafhjPZxTVD6Ihwwbt9I//8Kp?= =?iso-8859-1?Q?rorBOjYJZu33PtwrpaLJ50cRgfIDDAoNcdNVvaQJ9tUw4Q7XmQE/AUvqC0?= =?iso-8859-1?Q?BBNguujleBwG/A6sYIk1KDtDcGkJbwmj2Cqp510FLoVUttWkKvVI70Y0Ql?= =?iso-8859-1?Q?W7y1Fs9sPID7zjoJf1EFdLfCVb2P8wVAiiHpeUn4EC0Z99xapNam7KjRCg?= =?iso-8859-1?Q?FsUQu5oLKZJYj5Lr4LssiY7T+SKXAbd+ntxcoagdO2ULpvurS2L494s7ez?= =?iso-8859-1?Q?kLnxJPECQeDZ2IadwkuSHJqkPWVdl17a4fSrnDXng82YW84BfmwevATjMf?= =?iso-8859-1?Q?DTqdBiMB5tT9P79T2pftUgOWPjC6w4Fb/4XPriKu65JEmD0mzWNyaWSQ7T?= =?iso-8859-1?Q?ITm4CSFR8oahilOd92EPPz17H1Lk34OG9mA9v/VuGNQO8NdQpUMxA5EXjs?= =?iso-8859-1?Q?TyMdDFfiuAQ7X8vBtkTM8rrcbbSUdRxZ25VheBk/7HoKKY3qOvuIM9BSIE?= =?iso-8859-1?Q?ReFGZJSNTOqnJKwbIxpkk/0STHCbTv2sEMQ9nuoX5LPMwsRPMT0bEdj9wZ?= =?iso-8859-1?Q?01EFDq343q7UGRJae5VpX1YfgErL+zrlYyagY+LU9IWVrSVIJrp3294m+1?= =?iso-8859-1?Q?N+CT9OeXDo/aD0uH0UqwjU7v9ulBHsevjUnbkYvpa8eLuBF9bWIun2fanS?= =?iso-8859-1?Q?7j44MNG1tVDw14wW1X+a/NB/bb3F1xs6arF1S0oBh1h1nWNoz6ltSb3iwS?= =?iso-8859-1?Q?gfS47j3K3RuFlthJZNKic8TwkMnOK/dS/DVeXWYiTOmn2N10MvC+75cZUZ?= =?iso-8859-1?Q?CpP+O+HxFHwYFVsosu768htF6eHgop8=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: acd06d94-67d8-467e-243d-08de7dcc3047 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:26.0310 (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: e4WSfxWyCKueygyCsJC6swW/fwfuIaiKHOdObpxVS2Z2PMvVr8qZJ/MGfx5o5EGYntWyDkhnExk2sy2//qMjIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 From: Stewart Hildebrand Export functions required for SR-IOV support. Signed-off-by: Stewart Hildebrand Signed-off-by: Mykyta Poturai Reviewed-by: Teddy Astie --- v1->v2: * collect RBs --- xen/drivers/vpci/header.c | 20 +++++++++++--------- xen/include/xen/vpci.h | 6 ++++++ 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 5202518e83..07ec991a12 100644 --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -610,9 +610,9 @@ static void cf_check bar_write( pci_conf_write32(pdev->sbdf, reg, val); } =20 -static void cf_check guest_mem_bar_write(const struct pci_dev *pdev, - unsigned int reg, uint32_t val, - void *data) +void cf_check vpci_guest_mem_bar_write(const struct pci_dev *pdev, + unsigned int reg, uint32_t val, + void *data) { struct vpci_bar *bar =3D data; bool hi =3D false; @@ -652,8 +652,8 @@ static void cf_check guest_mem_bar_write(const struct p= ci_dev *pdev, bar->guest_addr =3D guest_addr; } =20 -static uint32_t cf_check guest_mem_bar_read(const struct pci_dev *pdev, - unsigned int reg, void *data) +uint32_t cf_check vpci_guest_mem_bar_read(const struct pci_dev *pdev, + unsigned int reg, void *data) { const struct vpci_bar *bar =3D data; uint32_t reg_val; @@ -959,8 +959,9 @@ int vpci_init_header(struct pci_dev *pdev) bars[i].type =3D VPCI_BAR_MEM64_HI; rc =3D vpci_add_register(pdev->vpci, is_hwdom ? vpci_hw_read32 - : guest_mem_bar_read, - is_hwdom ? bar_write : guest_mem_bar_wr= ite, + : vpci_guest_mem_bar_read, + is_hwdom ? bar_write + : vpci_guest_mem_bar_write, reg, 4, &bars[i]); if ( rc ) goto fail; @@ -1018,8 +1019,9 @@ int vpci_init_header(struct pci_dev *pdev) bars[i].prefetchable =3D val & PCI_BASE_ADDRESS_MEM_PREFETCH; =20 rc =3D vpci_add_register(pdev->vpci, - is_hwdom ? vpci_hw_read32 : guest_mem_bar_r= ead, - is_hwdom ? bar_write : guest_mem_bar_write, + is_hwdom ? vpci_hw_read32 + : vpci_guest_mem_bar_read, + is_hwdom ? bar_write : vpci_guest_mem_bar_w= rite, reg, 4, &bars[i]); if ( rc ) goto fail; diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h index a98ddbb32e..dd233b8b03 100644 --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -78,6 +78,12 @@ void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsig= ned int size, uint32_t cf_check vpci_read_val( const struct pci_dev *pdev, unsigned int reg, void *data); =20 +void cf_check vpci_guest_mem_bar_write(const struct pci_dev *pdev, + unsigned int reg, uint32_t val, + void *data); +uint32_t cf_check vpci_guest_mem_bar_read(const struct pci_dev *pdev, + unsigned int reg, void *data); + /* Passthrough handlers. */ uint32_t cf_check vpci_hw_read8( const struct pci_dev *pdev, unsigned int reg, void *data); --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249277.1546770 (Exim 4.92) (envelope-from ) id 1vzYTY-0004TG-J6; Mon, 09 Mar 2026 11:08:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249277.1546770; Mon, 09 Mar 2026 11:08:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTY-0004St-FQ; Mon, 09 Mar 2026 11:08:40 +0000 Received: by outflank-mailman (input) for mailman id 1249277; Mon, 09 Mar 2026 11:08:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTW-0003iR-Te for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:38 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 52878060-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:37 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08:33 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52878060-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xqd8cYj7gy2TZSBOlBkbaLMT6N1GKSlKJkUPzNqCtkbo01FLxHG6Q3uxyJ03kCj5CQBdyLE97eueuXbMdLGhp58TCU/Db5WUa4egtwHZd/tU1LZ6cwIJ0nmmbNr3dEE26d9tfRYekoOn6VVQ8A6segUyG+WjZuKCR8v2JHUI2kT8TQfzNdy9OsffZ6RT762MrE88G3CgOPQ7yBQe937oNFVAYqH+QhdrMUZFI//ULZChed0DRB/nU4tswXTVpnZyrgdJ4Otv5Kjdu1KN9Ag8p9st0gaydhIcFSLlPoZks+FFfD44UVcmR8eec2OkyA3jdF6l77EQrW9LACucgkI28g== 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=TIjXoyluGNn9xI4dhnAjl42ZVBDPRjpiZelesPBUChw=; b=tWIRsOk2mLToM6/blopyO0HS0cFJh5OKhmN20RRJzSLN7EQxaO1YQJsRicwIuGMRd2o86sFbjps5qfVBPIj803vGM6DFaeLi4jCh/KQLmv2xzf28D0PHesuK8SaesgWeZmvKY3uYFfbU2EPEDfSNJF33nLs6bSJybtsWleeWeQOwGbqHDNTxp14to9kBVYZUNd+VfhgYocGAGC7VQFZS2OURF5kqmL6CWMxTYw2ORTsPX7GtY/Lq5pQ3VjJVDQ7gHMi8XCBIVa4pqAz3FEqoS+gZ0xH1v/loKFqvE8uquzBeYFrLRNUIgGMdwmwiIaPBKjxsS2ozjWwqAiuTnP2yxw== 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=TIjXoyluGNn9xI4dhnAjl42ZVBDPRjpiZelesPBUChw=; b=icksVjs0RBwAZ6amoj6d06hDrO0Vm8ttxzyCLQ8vMPtDNjkTZOI4HCbAandGHlQWxoWquwz7+wCIGzVEYVWnGCVWP66444diOPJCdLRoP7uKnkfBlHLKyfA+dwBReScg7tjKnA97s7qurwF6Yvu0PpDtXH+JCQ52S3fCmlt6hlLZ3WihALk41VgiThD8zYzSV6j2mK9jzDj3oCufaWg1NG0o/Z1OIKVU1iWjVaE3e8UJwyFeqJWxOX56JjQ0nfRvZuZkVjEtD10F0nog+4yPTn4BW+sLRWM5oi52wVUXW5ZFwqK4BMVDuejkbi2ugCvjIgEwqsyvucv469QiA33YhA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Mykyta Poturai Subject: [PATCH v2 7/8] vpci: add SR-IOV support for DomUs Thread-Topic: [PATCH v2 7/8] vpci: add SR-IOV support for DomUs Thread-Index: AQHcr7UO+MwgiaR8rkeSbkx2JKFNaw== Date: Mon, 9 Mar 2026 11:08:28 +0000 Message-ID: <4df03dab1dc6ce3ac7524b9f06641bc90889f743.1772806036.git.mykyta_poturai@epam.com> References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: c39d720f-7feb-489e-8530-08de7dcc3437 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: US12a8QYXxbqfc0jdD1/5pKn21z0T2D2rwo7FlXKT3EdnjTJZCMqDH+0JAvFGZ4HgxSunTdrHuAMmEnZ2lQdRqmoZjXV1thM7zTqP+0DkJkZyLwaf9NuTXH4pskfkUp24uzetDbOo/1F1D9hHaO3309t9Ci6N0ksFQzMYikrAMM5XLAVrcDvqI5aB+9drUCbkEIWJWwbd1LzdLPS8A+rJnIdHy5Kc95BC0Za5w7KYsrgEyRLjCy4kFzwnyzt3EGTUzv+/X1u3yDOeL87ZL2mwlxPrTtMSCk1PSxHk7Ge9mX3GUIoM6BBZfppLLsK4Pg7PJrS1keWL/BYbJafi4B/GxHGpNQ0RLvWU+LuSKSSrOlbRyuvvOkjOb8tyEjpN0x2evYPl2EpjGrEkMh0jir9jDYyi4zqmdGUYhvGuFvz/nQKAO1qjEwNXL4eTa0wn1dl0Z8B0TTsH1hBsVIZEkEwAwowuzxfy8sTv13xmNnYE1QjwjvY0LztSAPWRI3vujdXzeY/8Kh870Ix8GZ/4w+m36mPZRVLXTTdSiS3VJiyypTzCQDRl09w98UEzQSi1cWgeOchvcq+Woeu0HF7M28LtdcAR0p2/RW2I7gYnKkY3rudMdBClwbmZ9hALoYuJXN+PEoiHgOZSacRcqqWggM6lBEXtV5HFSZ3BbsQB5H2t7jvvsldGwQRfRKfKxNqUG3JKNfBXApPolQVFwAik6TyulJLxWlJ+foTwp7dvLkXEwI+QPA7toerZdfQntqYEBAAJj35gUaByObicO7eK3Y1lJFPa22FBTT3XYkuZcHMN5g= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?KB3hOanFokbhrM5e0rg3V3DBJYCU2FKzvsTbQg+5FOCYkKS84zN3n0w0Y4?= =?iso-8859-1?Q?oWn3z6xqkj9i1vRpZYarCkSmSjEUcfdsgvq64vfjcZxcqDoX8Ncoc2V2ld?= =?iso-8859-1?Q?nw/B0eN+zr0lIKWEFdmxnRqJQt2MIc9b4r3a8CiANYtv+U1m4HlCFwEnCC?= =?iso-8859-1?Q?dlowIZYZEQf5gqS2RKon7mk8hqq3vcPz1DQXf0THb5ldQzIV3057lL6+gq?= =?iso-8859-1?Q?yZH1k+7B5iEH5cJ2wFGN6WM/YZuKsUWf2a97uCuGgU6CxbPPlGI8F7kK/s?= =?iso-8859-1?Q?VsfWF594DD0U4SJ8+ly5KtZpDHUDCVxEOlk7fdVOM8SvzTI54dq7mhtVFn?= =?iso-8859-1?Q?QWqu+SiSoEeSaN8T0WCT+pjOaAOLpH9nUm920lNaGGrdvlvfJqibh4GaVd?= =?iso-8859-1?Q?K6SI/OBsEbxohI1h/lhQFBMlEscLB3S7IubLII4onqirnwUnvmlYkHUa7E?= =?iso-8859-1?Q?eXOe8N2oA1glHLkM1uVQ9QLZj7dmDmWKfx4U7Vh6vsNpqooCMOCYShNuFw?= =?iso-8859-1?Q?xiDmvbwQfebkgsyvp/sMcZydEQjFxFS2IR0U8h9V7198QQ4lpZULG59IN4?= =?iso-8859-1?Q?n+c+lunwo70yYnWJYf1K3/9Q+Sv5YTeVqTLza3grTsYFfnYdMjzErRV5HM?= =?iso-8859-1?Q?OjZ7cHIfz9CnFTglcnnBOckHBpxvF64zSa/RNK6GC9FEh3NjkP4bNsu5QM?= =?iso-8859-1?Q?Qiu1xuM4KaTBRHfPFosLPt/cZUE7Rg7FbBGeohloV+tamF5bDI08Z45xl2?= =?iso-8859-1?Q?X9sXAn16lAf17bCvHo7E8XAHR3IobvU15r+KLADohicRevUnb4NUXi6YiQ?= =?iso-8859-1?Q?MIrUCWlJLvrkHItPouXrHW8jhteFG5cEDIdjSPg/c7AisMsyLa48l8Nt6S?= =?iso-8859-1?Q?BtgP7rZTso9B6SzdNloXeCMFMe29dsehmzPyPfCeEUuGMMrPoXBu+71DID?= =?iso-8859-1?Q?wCKL4OZvB52I1NeK0AiuLhizpsKo2QDzK02uGhHcMK9a5VYoAbLum+7wxz?= =?iso-8859-1?Q?PyN2ZYvqhwIcbrdkOd8FKZGiV1lpS7KRrBQIo/+5/Dhe9nVG8If+P5VXS3?= =?iso-8859-1?Q?rXLrWxGNthf4yQkXRht3EDJoUsUoKAjytrpQaYstt/jkdrLEQPZNzbL2Wb?= =?iso-8859-1?Q?StYLGT5jdutavNVvWUi3aIpIPioCmY1ppHA1C/6FH72GNxKCgIzGCHzzge?= =?iso-8859-1?Q?5rPyiLVHjlYVfcwOK5ztmBeXYNiAq11lXvBVlA2DUkqTVpyYcOTDBcbQjy?= =?iso-8859-1?Q?udRRGKg4p3RDlLGWrLvn6Uz/QNAp/ARKfevoakkMWOys2vxAzg4/2Y4E8d?= =?iso-8859-1?Q?XAzUbs5ANpgJmKOYK0vJgZ4zTMa6EZOD6s6LUrde2v/aNtKB4k+FhV7xYi?= =?iso-8859-1?Q?IEZw11YEy4RG1Xl3kLd7MjaZyfeeuM//rGhCAIsJtU1GKdzRtMMRk1tQfS?= =?iso-8859-1?Q?i0gQsSwyxC4ASf1lqw2c8Kwq/pBzAaJnxRpHeoQlI1kJkqjeBlQfZ7ddcv?= =?iso-8859-1?Q?UdZ4GkdW3HhX+Pmmgr4uaMe7t639r9UswIipVryQxat7AjhO7QbhIIemjq?= =?iso-8859-1?Q?A9ZAFzADlIWkRFA2uj624bFXO/Ic5SOAoIUYOeYfDZNlYnThhLxtBg1nKb?= =?iso-8859-1?Q?+niyNwIKhRZFza6DvQc4/5zacnjBX83P4Av5XYbEGf+s7g4qRrGaTHLq+d?= =?iso-8859-1?Q?neo5jl5T2qiqfyGOsrN50nvF+AQFqYWqUdeaL7od1V7KTPCXJmIyakmQbr?= =?iso-8859-1?Q?CJgEd7N8CLeVXvc6nfuwK/N0kLnvTdKkr8SQczhaZMZTcmz9UBm/cvwu/d?= =?iso-8859-1?Q?vo3UOo/8qRNr20wwF4I0WXMIGv77Pa0=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: c39d720f-7feb-489e-8530-08de7dcc3437 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:28.2601 (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: meoYxEVlFmzSkLtlCLYWjSmiZZc//L3Tpt8twbzfGmw+BEdX8crR9YtB07/y3I+FNpb2m5sHjJZze57NBLbIlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 From: Stewart Hildebrand SR-IOV virtual functions have simplified configuration space such as Vendor ID is derived from the physical function and Device ID comes from SR-IOV extended capability. Emulate those, so we can provide VID/DID pair for guests which use PCI passthrough for SR-IOV virtual functions. Emulate guest BAR register values based on PF BAR values for VFs. This allows creating a guest view of the normal BAR registers and emulates the size and properties as it is done during PCI device enumeration by the guest. Note, that VFs ROM BAR is read-only and is all zeros, but VF may provide access to the PFs ROM via emulation and is not implemented. Signed-off-by: Stewart Hildebrand Signed-off-by: Mykyta Poturai --- v1->v2: * remove VF register handlers covered by init_header * set guest addr unconditionally --- xen/drivers/vpci/sriov.c | 57 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/xen/drivers/vpci/sriov.c b/xen/drivers/vpci/sriov.c index 6f691149e9..1c408d1c6b 100644 --- a/xen/drivers/vpci/sriov.c +++ b/xen/drivers/vpci/sriov.c @@ -303,6 +303,63 @@ int vf_init_header(struct pci_dev *vf_pdev) sriov_pos =3D pci_find_ext_capability(pf_pdev, PCI_EXT_CAP_ID_SRIOV); ctrl =3D pci_conf_read16(pf_pdev->sbdf, sriov_pos + PCI_SRIOV_CTRL); =20 +#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT + if ( pf_pdev->domain !=3D vf_pdev->domain ) + { + uint16_t vid =3D pci_conf_read16(pf_pdev->sbdf, PCI_VENDOR_ID); + uint16_t did =3D pci_conf_read16(pf_pdev->sbdf, + sriov_pos + PCI_SRIOV_VF_DID); + struct vpci_bar *bars =3D vf_pdev->vpci->header.bars; + unsigned int i; + + rc =3D vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, + PCI_VENDOR_ID, 2, (void *)(uintptr_t)vid); + if ( rc ) + return rc; + + rc =3D vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, + PCI_DEVICE_ID, 2, (void *)(uintptr_t)did); + if ( rc ) + return rc; + + /* Hardcode multi-function device bit to 0 */ + rc =3D vpci_add_register(vf_pdev->vpci, vpci_read_val, NULL, + PCI_HEADER_TYPE, 1, + (void *)PCI_HEADER_TYPE_NORMAL); + if ( rc ) + return rc; + + rc =3D vpci_add_register(vf_pdev->vpci, vpci_hw_read32, NULL, + PCI_CLASS_REVISION, 4, NULL); + if ( rc ) + return rc; + + for ( i =3D 0; i < PCI_SRIOV_NUM_BARS; i++ ) + { + switch ( pf_pdev->vpci->sriov->vf_bars[i].type ) + { + case VPCI_BAR_MEM32: + case VPCI_BAR_MEM64_LO: + case VPCI_BAR_MEM64_HI: + rc =3D vpci_add_register(vf_pdev->vpci, vpci_guest_mem_bar= _read, + vpci_guest_mem_bar_write, + PCI_BASE_ADDRESS_0 + i * 4, 4, &bar= s[i]); + if ( rc ) + return rc; + break; + default: + rc =3D vpci_add_register(vf_pdev->vpci, vpci_read_val, NUL= L, + PCI_BASE_ADDRESS_0 + i * 4, 4, + (void *)0); + if ( rc ) + return rc; + break; + } + } + + } +#endif /* CONFIG_HAS_VPCI_GUEST_SUPPORT */ + if ( (pf_pdev->domain =3D=3D vf_pdev->domain) && (ctrl & PCI_SRIOV_CTR= L_MSE) ) { rc =3D vpci_modify_bars(vf_pdev, PCI_COMMAND_MEMORY, false, false)= ; --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249278.1546779 (Exim 4.92) (envelope-from ) id 1vzYTZ-0004iM-SZ; Mon, 09 Mar 2026 11:08:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249278.1546779; Mon, 09 Mar 2026 11:08:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTZ-0004iD-NR; Mon, 09 Mar 2026 11:08:41 +0000 Received: by outflank-mailman (input) for mailman id 1249278; Mon, 09 Mar 2026 11:08:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTX-0003iR-Tl for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:40 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 52cadce9-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:38 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08:33 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 52cadce9-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=drDPO9QznwPw0acjwL60yGPkwYzkpG+GVxUg97cIyKdC8Alk1uuH9lIjqjP3fCVRdLsYzf+YHNXhkSPGfvF8xzE7qc1So/gbYXSvYkWTrmLgUAl13UNrYYjfSZSqeMqy1nz08kZCruUqUFTOlt8QZWyde+NLu6OsPtmEbTnwj1TE1Tw2ZRQQgf31DqFFOKGHSlzF4ayo8/J1cyMdMkzFoZhpmdefd0B3IC0UzTHIMpEX1iNBxdxIWUtdz13jD/S6Lqg8fItYBahvzjoNZqTtLatmFZ+iagPnsreqBkK6aQzlatYz4zn/yUzaqFd74FfWRIwba/8y8nCvZAG9eo6GWQ== 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=jPd7eg99vjV5lo4tppv9T3tRyoUFlgTQOLxJi+eBzBY=; b=EKYqFMaPdpQTh/zZ2YFaEOLR70yWeWBwNJnhgjAUgLktNpTc/94GJVYvhfqjp+Ps2z+OzciGn99Mu1qI17/uymfDKIvC6uyNWwQ9scyEZOyDsJhY++bLI1B2iJKHcB+4UJu19bVfgU9HOFNGHWPJnABi5XBSfv4K9kTy01jcDn63ilY28lDKxErLcxOk9UpA7suJCLgjnu0BsCIhuCjh2WXbZrCWQMRAFo6OZ5k4xDP5u3flf7wLtZL4WeUkhmPQ4+kazVj6wX7fjtULLQtcT2Pb84Y7zFXhp8+UwXlCpoaawhdDJpiiCjGhFtzdZC1U9Flpq9PGgm8X1Ckqk7egbA== 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=jPd7eg99vjV5lo4tppv9T3tRyoUFlgTQOLxJi+eBzBY=; b=Tskh8JBL0HRr4v1du1eU5NDPUlYOzC6HBpi2nkCyI32VTBNkas3enBg/A2Xd83Bi5ZtEdloPJEAVWOEGu0z2O9PEVI1A4/suqvuHHUvB9FTYACkUIjkNlYrkTyiQgNs3MgibVQ6/yoyASTBEeAZsvF2O2GI69LamtSaTFya2dVbUsp/Y6Gf/JHkncMU44H6G+3BIBVI9o3RftDp/1yYansXhg30528W/8obQsbxXU9F7vtol4LBffdto9MQ6CEEhE5eNMemM9woLQm6jAxCpHqiukhTvo5sOqpa3Vw/rYsNdkubz033t1gQCNtwAfJiNv/ORplaMwy1uNFkM5Z+VZQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Stewart Hildebrand , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , "Daniel P. Smith" , Mykyta Poturai Subject: [PATCH v2 6/8] vpci: add SR-IOV support for PVH Dom0 Thread-Topic: [PATCH v2 6/8] vpci: add SR-IOV support for PVH Dom0 Thread-Index: AQHcr7UOJDdt9SAQzUinWXRod1IIzA== Date: Mon, 9 Mar 2026 11:08:27 +0000 Message-ID: References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: a4840fa3-50ac-4db8-4211-08de7dcc33f4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: XhqXnexDxH+jMPCZSI2iTGH4fAKsHP/TaJ5qdrYQEG9NxZTUt+ZizIX7OqlIGrmmQNhPcT2Q6I+zmQmDTVYB6IjrQM+hv0eUcAqAmhlRe4IFtROYQH65TBnIQSkGT7971kgTFzZKQ+haQyDjrMifzzTlkUSOY6xP0w99q6pE4gmAyka0fSkPVSNfefH2wZ2aASsJoU6R4C6mbYWl/C3B0TuCZzIXEvlIS00W/mlwgj25cY1bUOcsuBroiouS2mTHlU/jJ0DiDi9WBh+4ObCRGJJFL8HOZkjlb5nXKnZUy5k4BnODpZNHY5QaQKfpQHlR9cgPYTDZVFNUgBkc7AG5ER2aVoX+HCG/Ylr3IwhB6DBaobgg6cVIu8qm0V5vDn2ePp4GFCiD7XXDJE/PSZTT2dLwJigXELskmeZM+M48+RUxvX1YcNZtnSIJ3h7eu0M2t6Tp9tydNpHJtinaVnf9w1K3uHzFhM6jUb3R5JsoJ6yq8kjcWk6zhBioa2l/AdUlym0zP1PJCpyLKSxuWMAC+9LmDtGpxU8YWdEjCdKfAljNpPnt6g/UtU2mpDZNAWUd4Wp7FEgLdjq0Q4pBROhDsc36OCJ8hB3KZHCYaWEjN/0An8UGXpxtE9nxN2XMmFavMLSMtB78DBv4kKmcbQdcrlq8yIzhnQZSxfVYKGfviSPSLR9tsS9GfX1s30AbQsylKDp7fcyJuzxnmE69s9SKjahM4gs2U+jhTAGRo46evMA2hH9JFMIxNtaW+yj/hUmHdg2BXTOQ/jeVeq2DdQv5wAUdwu/GX+EKzuUp/ecDyAo= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QnlBUU55aEJXU1hXVlpkdlFzamtvcGVYdFFtSk02S2RVNWRPTzgwbFlkSkZI?= =?utf-8?B?M25tMVZGZVVITEtzbGE5dnY3RDk5K3g1VmdpN0M0ZzQ2eEZLU0dKLzJ6aHhh?= =?utf-8?B?eHEzcUJUYzcrQXZQa3lQSk93bDd0VG9Xa2s2V1hDcDNxMzI0SkVMekhOVEE1?= =?utf-8?B?M2ZHWjRuR1NkcXRXSFhmeXRTZmFlTjU4cTlvM2tzMVhhMkZZQ1ZDQjNDNzRN?= =?utf-8?B?TXdmS0JiMGlDazdsaTZ4alYyQytyNnF4OEFNeXNyZXNlWllWQ1ZjTUlVUmhp?= =?utf-8?B?R1lIYU1UaWdlZHhMV29RVjhoMk8zQjF2dTdwMzVDYXY3Wkl3V3pTTHFHOXJT?= =?utf-8?B?RXRMYTJZcXo0YmxKNFVxdjBzSHBqVTVzalVEcXBhWkhBOXVxd2JHY2pwMU9o?= =?utf-8?B?Um1VV2dHR1pUOXNCUTJnc0syTU5IR25lUjVULzhDVXkyY1cxVVd4WGhsOEEw?= =?utf-8?B?NkVtYjJzOWhJTkt1Yi9CR0c0ZEdDYzVINXJaWFFodjdnVlh4RkNlNkNmNlpa?= =?utf-8?B?YnBxeUVGcGtmbngzcFNSU2tiTmE5R09qVVlWVXFYZWY1U0pnZEtrYmRBQ0xU?= =?utf-8?B?QWwrL09RVnRjTDNtNjJ2L0lxb0pTZ1hkOGk3ZXF4WHFFc3NhbWY0amp4Z0dM?= =?utf-8?B?bklFSjBWOXRLbnhwRFFCV0ZVdUNKYXl0K1FlbHJPUFNURnlVd3FqVmtNdUl6?= =?utf-8?B?U0lQQks0NmRFT1pQL3dtWFZOVVYyOE5HWkdGVVV6Qmg2K1NSS0wrazdGTnhT?= =?utf-8?B?eVdKbkorYWpqT3lUZUxPb3dkZkJlaGFIMklndWdhSWx2NFZJZU96MlVTQXN6?= =?utf-8?B?eVByVDZaUmxHd1RPM2ttV1JTdExRa2NhVDc2OUl6ZGwvQTdZdWdhMm1NaWk0?= =?utf-8?B?Qm9zbTQwa21JTWg1clZqMEZIK00wZThoNzRxNW1qNU9Zb1U1M1g0UFMrcUYy?= =?utf-8?B?aDBSZDU4aUVmS3VSUEJNcGZyK1V2TWVYTVV6SWQvL3lTTksvZksxaGExMHZ0?= =?utf-8?B?OEU5SGdNYWVXSmJyL1Z6ZzhpUS9Wb2pvUTc1SThhSW4zNmNDR09IZitwQTc4?= =?utf-8?B?N3FaSzNwNjZhWnpTVGk0cWtFWEt6bllBNzllY3grMyt3SDA2eG5SUlVrdFpv?= =?utf-8?B?ak4vQndaODdEOFZWaHplMUNGVWgwWlRLRWwyQTFabTJzWWczcFk2QjZ6S3ky?= =?utf-8?B?WHNXcys4UWRiMTd3VGdhNWxaUTNYM1p4VDZnU3Fmc2lFZEJhUmY2eWQrVGVX?= =?utf-8?B?N0Y4OThYTlZuWUdTdHhGNHNKVTl6NUNYaGZLYkdxeHNXYStBdjRyeEMrU2lT?= =?utf-8?B?T3pkV1BKcUFkV0tMWm1ZRXJJNndrVG10STZ2SzArS0E2K2UyUmNtTk5sSzNz?= =?utf-8?B?UVc3cUp4amZUQ09tOHB4V3F2Z0hhbFUxRndMM0FuT2RkSmZ0bmVnVExEY3RP?= =?utf-8?B?MG5RaVJqblFzTUtxRkE5TEl3RW9KdS84Ylp0YjdVZkt6T3A1S0pKbm1WazYz?= =?utf-8?B?WHo1MUJXRXZ5QkRVYnk0YThJL0c0emQ2VU5ZUGVQL1EvN0dKSW1mM1hLcmd1?= =?utf-8?B?SnM1UkhnOXpnSlhyOFQ2ZEs2cDJjbEI3SkV5R3BTV1JFZFBlMTZpK2JNdkFo?= =?utf-8?B?S2VHbjRJNEpNdTNVMndFQmtFT2Q0QmtPanl5d3BpZWxWRHpwc0x0OTkxT3FS?= =?utf-8?B?b2RWY2h3STVTdlpFZTM2TjhuNmZVS1grSEt4RkcwTmh6RjR1RXFPMWswcUJG?= =?utf-8?B?RU0rQWNISXBPNWJHRVd0R2x3K2MxT3BpbkIwSER4Mi90UE5XQkRGNkVSYzFO?= =?utf-8?B?d09wVCthbndiR3duLzI2U2NPRkNaWjJDNHJmY2tmL0VOVS93QzRKUWlNUHB5?= =?utf-8?B?K3JpUU5jemJvcTNTVUlkNjNScTQ5OHo5SmNUR2lZcGJDRXZnREw5cml0TEpt?= =?utf-8?B?VjBQcnBrNUZ6VkZMQW41aUdJRDhWYnFZMkxVZXJ5eHRPUnpTVXlNM0R2a2Ew?= =?utf-8?B?TlZMRGxROWZQSGJWaXZUdlJhS1NoVlBVdmRBblVUaExHZGkwektFbDdxTExu?= =?utf-8?B?S1I4MXUvc0lncmVYUXZ2WEFDUWRmRzZXdndXYUI4SUZSTlJBSlVQM05TSXQy?= =?utf-8?B?dkw0NHppREtHeXNPVTJFSDZmQ0x1RGFwRWY1K0FYbjlObGlmQTBOWEVXb2ly?= =?utf-8?B?SFcrZlJuTGRRZXpoUkNYR2Q0NUV5YWd0NncweHpBTHoyb2M2YWNPT0FVMDZJ?= =?utf-8?B?WkpscmY5WEs4K1FEd2s0ZUh5NGFUWjBSSUVLU2Z4NTZRR3pwMHArZlZFT0hI?= =?utf-8?B?NUVLbG5VSVNQbUdDeEJjM3ZjeGU4Q3h5MGE2eWFhRVQveHpBOVdJUXprVUI1?= =?utf-8?Q?MeeManXb2lAi6PCk=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <69B3D15764319041A131EA3108B1172A@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4840fa3-50ac-4db8-4211-08de7dcc33f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:27.8941 (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: 9BASa2I4w+dmNwlYiFCzgAnqInA92UBy8aXw+UHqa35h6k0NMcuf62Ir0aP7NWyel7uBhdMAsqyHVQ7JcnFgJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 RnJvbTogU3Rld2FydCBIaWxkZWJyYW5kIDxzdGV3YXJ0LmhpbGRlYnJhbmRAYW1kLmNvbT4NCg0K VGhpcyBjb2RlIGlzIGV4cGVjdGVkIHRvIG9ubHkgYmUgdXNlZCBieSBwcml2aWxlZ2VkIGRvbWFp bnMsDQp1bnByaXZpbGVnZWQgZG9tYWlucyBzaG91bGQgbm90IGdldCBhY2Nlc3MgdG8gdGhlIFNS LUlPViBjYXBhYmlsaXR5Lg0KDQpJbXBsZW1lbnQgUlcgaGFuZGxlcnMgZm9yIFBDSV9TUklPVl9D VFJMIHJlZ2lzdGVyIHRvIGR5bmFtaWNhbGx5DQptYXAvdW5tYXAgVkYgQkFSUy4gUmVjYWxjdWxh dGUgQkFSIHNpemVzIGJlZm9yZSBtYXBwaW5nIFZGcyB0byBhY2NvdW50DQpmb3IgcG9zc2libGUg Y2hhbmdlcyBpbiB0aGUgc3lzdGVtIHBhZ2Ugc2l6ZSByZWdpc3Rlci4NCg0KQWxsb3cgZm9yY2lu ZyB2cGNpX21vZGlmeV9iYXJzIHRvIG5vdCBkZWZlciB0aGUgYWN0dWFsIG1hcHBpbmcgY2hhbmdl cywNCndoaWNoIGlzIG5lZWRlZCB0byBmaXggdGhlIHNlcXVlbnRpYWwgY2FsbHMgdG8gdnBjaV9t b2RpZnlfYmFycyB3aGVuDQplbmFibGluZyBWRnMgZnJvbSBEb20wLg0KDQpTaWduZWQtb2ZmLWJ5 OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NClNpZ25lZC1vZmYtYnk6 IFN0ZXdhcnQgSGlsZGVicmFuZCA8c3Rld2FydC5oaWxkZWJyYW5kQGFtZC5jb20+DQpTaWduZWQt b2ZmLWJ5OiBNeWt5dGEgUG90dXJhaSA8bXlreXRhX3BvdHVyYWlAZXBhbS5jb20+DQotLS0NCnYx LT52MjoNCiogc3dpdGNoIHRvIFZGIGRpc2NvdmVyeSBieSBYZW4NCiogZml4IHNlcXVlbnRpYWwg dnBjaV9tb2RpZnlfYmFycyBjYWxscw0KKiBtb3ZlIGRvY3VtZW50YXRpb24gY2hhbmdlcyB0byBh IHNlcGFyYXRlIGNvbW1pdA0KLS0tDQogeGVuL2RyaXZlcnMvdnBjaS9NYWtlZmlsZSB8ICAgMiAr LQ0KIHhlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgfCAgMTcgKy0NCiB4ZW4vZHJpdmVycy92cGNp L3NyaW92LmMgIHwgMzYzICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQog eGVuL2luY2x1ZGUveGVuL3ZwY2kuaCAgICB8ICAxMiArLQ0KIDQgZmlsZXMgY2hhbmdlZCwgMzg1 IGluc2VydGlvbnMoKyksIDkgZGVsZXRpb25zKC0pDQogY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9k cml2ZXJzL3ZwY2kvc3Jpb3YuYw0KDQpkaWZmIC0tZ2l0IGEveGVuL2RyaXZlcnMvdnBjaS9NYWtl ZmlsZSBiL3hlbi9kcml2ZXJzL3ZwY2kvTWFrZWZpbGUNCmluZGV4IGE3YzhhMzBhODkuLmZlMWU1 N2I2NGQgMTAwNjQ0DQotLS0gYS94ZW4vZHJpdmVycy92cGNpL01ha2VmaWxlDQorKysgYi94ZW4v ZHJpdmVycy92cGNpL01ha2VmaWxlDQpAQCAtMSwyICsxLDIgQEANCi1vYmoteSArPSB2cGNpLm8g aGVhZGVyLm8gcmViYXIubw0KK29iai15ICs9IHZwY2kubyBoZWFkZXIubyByZWJhci5vIHNyaW92 Lm8NCiBvYmotJChDT05GSUdfSEFTX1BDSV9NU0kpICs9IG1zaS5vIG1zaXgubw0KZGlmZiAtLWdp dCBhL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNpL2hlYWRlci5j DQppbmRleCAyODQ5NjRmMGQ0Li5jNTVjMzM4MGQ0IDEwMDY0NA0KLS0tIGEveGVuL2RyaXZlcnMv dnBjaS9oZWFkZXIuYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KQEAgLTI2NCw3 ICsyNjQsNyBAQCBib29sIHZwY2lfcHJvY2Vzc19wZW5kaW5nKHN0cnVjdCB2Y3B1ICp2KQ0KICAg ICByZXR1cm4gZmFsc2U7DQogfQ0KIA0KLXN0YXRpYyBpbnQgX19pbml0IGFwcGx5X21hcChzdHJ1 Y3QgZG9tYWluICpkLCBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCitzdGF0aWMgaW50IGFw cGx5X21hcChzdHJ1Y3QgZG9tYWluICpkLCBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDE2X3QgY21kKQ0KIHsNCiAgICAgc3RydWN0 IHZwY2lfaGVhZGVyICpoZWFkZXIgPSAmcGRldi0+dnBjaS0+aGVhZGVyOw0KQEAgLTMyMyw3ICsz MjMsOCBAQCBzdGF0aWMgdm9pZCBkZWZlcl9tYXAoY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYs IHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCiAgICAgcmFpc2Vfc29mdGlycShTQ0hFRFVM RV9TT0ZUSVJRKTsNCiB9DQogDQotaW50IHZwY2lfbW9kaWZ5X2JhcnMoY29uc3Qgc3RydWN0IHBj aV9kZXYgKnBkZXYsIHVpbnQxNl90IGNtZCwgYm9vbCByb21fb25seSkNCitpbnQgdnBjaV9tb2Rp ZnlfYmFycyhjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLCBib29sIHJv bV9vbmx5LA0KKyAgICAgICAgICAgICAgICAgICAgIGJvb2wgbm9fZGVmZXIpDQogew0KICAgICBz dHJ1Y3QgdnBjaV9oZWFkZXIgKmhlYWRlciA9ICZwZGV2LT52cGNpLT5oZWFkZXI7DQogICAgIHN0 cnVjdCBwY2lfZGV2ICp0bXA7DQpAQCAtNTE5LDcgKzUyMCw3IEBAIGludCB2cGNpX21vZGlmeV9i YXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29u bHkpDQogICAgICAgICBkID0gZG9tX3hlbjsNCiAgICAgfQ0KIA0KLSAgICBpZiAoIHN5c3RlbV9z dGF0ZSA8IFNZU19TVEFURV9hY3RpdmUgKQ0KKyAgICBpZiAoIHN5c3RlbV9zdGF0ZSA8IFNZU19T VEFURV9hY3RpdmUgfHwgbm9fZGVmZXIgKQ0KICAgICB7DQogICAgICAgICAvKg0KICAgICAgICAg ICogTWFwcGluZ3MgbWlnaHQgYmUgY3JlYXRlZCB3aGVuIGJ1aWxkaW5nIERvbTAgaWYgdGhlIG1l bW9yeSBkZWNvZGluZw0KQEAgLTU2Niw3ICs1NjcsNyBAQCBzdGF0aWMgdm9pZCBjZl9jaGVjayBj bWRfd3JpdGUoDQogICAgICAgICAgKiBtZW1vcnkgZGVjb2RpbmcgYml0IGhhcyBub3QgYmVlbiBj aGFuZ2VkLCBzbyBsZWF2ZSBldmVyeXRoaW5nIGFzLWlzLA0KICAgICAgICAgICogaG9waW5nIHRo ZSBndWVzdCB3aWxsIHJlYWxpemUgYW5kIHRyeSBhZ2Fpbi4NCiAgICAgICAgICAqLw0KLSAgICAg ICAgdnBjaV9tb2RpZnlfYmFycyhwZGV2LCBjbWQsIGZhbHNlKTsNCisgICAgICAgIHZwY2lfbW9k aWZ5X2JhcnMocGRldiwgY21kLCBmYWxzZSwgZmFsc2UpOw0KICAgICBlbHNlDQogICAgICAgICBw Y2lfY29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIHJlZywgY21kKTsNCiB9DQpAQCAtNzM2LDcgKzcz Nyw3IEBAIHN0YXRpYyB2b2lkIGNmX2NoZWNrIHJvbV93cml0ZSgNCiAgICAgICovDQogICAgIGVs c2UgaWYgKCB2cGNpX21vZGlmeV9iYXJzKHBkZXYsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIG5ld19lbmFibGVkID8gUENJX0NPTU1BTkRfTUVNT1JZIDogMCwNCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdHJ1ZSkgKQ0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB0cnVlLCBmYWxzZSkgKQ0KICAgICAgICAgLyoNCiAgICAgICAgICAqIE5vIG1lbW9yeSBo YXMgYmVlbiBhZGRlZCBvciByZW1vdmVkIGZyb20gdGhlIHAybSAoYmVjYXVzZSB0aGUgYWN0dWFs DQogICAgICAgICAgKiBwMm0gY2hhbmdlcyBhcmUgZGVmZXJyZWQgaW4gZGVmZXJfbWFwKSBhbmQg dGhlIFJPTSBlbmFibGUgYml0IGhhcw0KQEAgLTk1NCw2ICs5NTUsOSBAQCBpbnQgdnBjaV9pbml0 X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiANCiAgICAgaGVhZGVyLT5ndWVzdF9jbWQg PSBjbWQ7DQogDQorICAgIGlmICggcGRldi0+aW5mby5pc192aXJ0Zm4gKQ0KKyAgICAgICAgcmV0 dXJuIHZmX2luaXRfaGVhZGVyKHBkZXYpOw0KKw0KICAgICAvKiBEaXNhYmxlIG1lbW9yeSBkZWNv ZGluZyBiZWZvcmUgc2l6aW5nLiAqLw0KICAgICBpZiAoICFpc19od2RvbSB8fCAoY21kICYgUENJ X0NPTU1BTkRfTUVNT1JZKSApDQogICAgICAgICBwY2lfY29uZl93cml0ZTE2KHBkZXYtPnNiZGYs IFBDSV9DT01NQU5ELCBjbWQgJiB+UENJX0NPTU1BTkRfTUVNT1JZKTsNCkBAIC0xMDYyLDcgKzEw NjYsOCBAQCBpbnQgdnBjaV9pbml0X2hlYWRlcihzdHJ1Y3QgcGNpX2RldiAqcGRldikNCiAgICAg ICAgICAgICBnb3RvIGZhaWw7DQogICAgIH0NCiANCi0gICAgcmV0dXJuIChjbWQgJiBQQ0lfQ09N TUFORF9NRU1PUlkpID8gdnBjaV9tb2RpZnlfYmFycyhwZGV2LCBjbWQsIGZhbHNlKSA6IDA7DQor ICAgIHJldHVybiAoY21kICYgUENJX0NPTU1BTkRfTUVNT1JZKQ0KKyAgICAgICAgICAgICAgICA/ IHZwY2lfbW9kaWZ5X2JhcnMocGRldiwgY21kLCBmYWxzZSwgZmFsc2UpIDogMDsNCiANCiAgZmFp bDoNCiAgICAgcGNpX2NvbmZfd3JpdGUxNihwZGV2LT5zYmRmLCBQQ0lfQ09NTUFORCwgY21kKTsN CmRpZmYgLS1naXQgYS94ZW4vZHJpdmVycy92cGNpL3NyaW92LmMgYi94ZW4vZHJpdmVycy92cGNp L3NyaW92LmMNCm5ldyBmaWxlIG1vZGUgMTAwNjQ0DQppbmRleCAwMDAwMDAwMDAwLi42ZjY5MTE0 OWU5DQotLS0gL2Rldi9udWxsDQorKysgYi94ZW4vZHJpdmVycy92cGNpL3NyaW92LmMNCkBAIC0w LDAgKzEsMzYzIEBADQorLyogU1BEWC1MaWNlbnNlLUlkZW50aWZpZXI6IEdQTC0yLjAtb25seSAq Lw0KKy8qDQorICogSGFuZGxlcnMgZm9yIGFjY2Vzc2VzIHRvIHRoZSBTUi1JT1YgY2FwYWJpbGl0 eSBzdHJ1Y3R1cmUuDQorICoNCisgKiBDb3B5cmlnaHQgKEMpIDIwMjYgQ2l0cml4IFN5c3RlbXMg UiZEDQorICovDQorDQorI2luY2x1ZGUgPHhlbi9zY2hlZC5oPg0KKyNpbmNsdWRlIDx4ZW4vdnBj aS5oPg0KKyNpbmNsdWRlIDx4c20veHNtLmg+DQorDQorc3RhdGljIGludCB2Zl9pbml0X2JhcnMo Y29uc3Qgc3RydWN0IHBjaV9kZXYgKnZmX3BkZXYpDQorew0KKyAgICBpbnQgdmZfaWR4Ow0KKyAg ICB1bnNpZ25lZCBpbnQgaTsNCisgICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBmX3BkZXYgPSB2 Zl9wZGV2LT5wZl9wZGV2Ow0KKyAgICBzdHJ1Y3QgdnBjaV9iYXIgKmJhcnMgPSB2Zl9wZGV2LT52 cGNpLT5oZWFkZXIuYmFyczsNCisgICAgc3RydWN0IHZwY2lfYmFyICpwaHlzZm5fdmZfYmFycyA9 IHBmX3BkZXYtPnZwY2ktPnNyaW92LT52Zl9iYXJzOw0KKyAgICB1bnNpZ25lZCBpbnQgc3Jpb3Zf cG9zID0gcGNpX2ZpbmRfZXh0X2NhcGFiaWxpdHkocGZfcGRldiwNCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9FWFRfQ0FQX0lEX1NSSU9W KTsNCisgICAgdWludDE2X3Qgb2Zmc2V0ID0gcGNpX2NvbmZfcmVhZDE2KHBmX3BkZXYtPnNiZGYs DQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmlvdl9wb3MgKyBQQ0lf U1JJT1ZfVkZfT0ZGU0VUKTsNCisgICAgdWludDE2X3Qgc3RyaWRlID0gcGNpX2NvbmZfcmVhZDE2 KHBmX3BkZXYtPnNiZGYsDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz cmlvdl9wb3MgKyBQQ0lfU1JJT1ZfVkZfU1RSSURFKTsNCisNCisgICAgdmZfaWR4ID0gdmZfcGRl di0+c2JkZi5zYmRmIC0gKHBmX3BkZXYtPnNiZGYuc2JkZiArIG9mZnNldCk7DQorICAgIGlmICgg dmZfaWR4IDwgMCApDQorICAgICAgICByZXR1cm4gLUVJTlZBTDsNCisNCisgICAgaWYgKCBzdHJp ZGUgKQ0KKyAgICB7DQorICAgICAgICBpZiAoIHZmX2lkeCAlIHN0cmlkZSApDQorICAgICAgICAg ICAgcmV0dXJuIC1FSU5WQUw7DQorICAgICAgICB2Zl9pZHggLz0gc3RyaWRlOw0KKyAgICB9DQor DQorICAgIC8qDQorICAgICAqIFNldCB1cCBCQVJzIGZvciB0aGlzIFZGIG91dCBvZiBQRidzIFZG IEJBUnMgdGFraW5nIGludG8gYWNjb3VudA0KKyAgICAgKiB0aGUgaW5kZXggb2YgdGhlIFZGLg0K KyAgICAgKi8NCisgICAgZm9yICggaSA9IDA7IGkgPCBQQ0lfU1JJT1ZfTlVNX0JBUlM7IGkrKyAp DQorICAgIHsNCisgICAgICAgIGJhcnNbaV0uYWRkciA9IHBoeXNmbl92Zl9iYXJzW2ldLmFkZHIg KyB2Zl9pZHggKiBwaHlzZm5fdmZfYmFyc1tpXS5zaXplOw0KKyAgICAgICAgYmFyc1tpXS5ndWVz dF9hZGRyID0gYmFyc1tpXS5hZGRyOw0KKyAgICAgICAgYmFyc1tpXS5zaXplID0gcGh5c2ZuX3Zm X2JhcnNbaV0uc2l6ZTsNCisgICAgICAgIGJhcnNbaV0udHlwZSA9IHBoeXNmbl92Zl9iYXJzW2ld LnR5cGU7DQorICAgICAgICBiYXJzW2ldLnByZWZldGNoYWJsZSA9IHBoeXNmbl92Zl9iYXJzW2ld LnByZWZldGNoYWJsZTsNCisgICAgfQ0KKw0KKyAgICByZXR1cm4gMDsNCit9DQorDQorLyogTXVz dCBiZSBjYWxsZWQgZm9ybSB2cGNpX3Byb2Nlc3NfcGVuZGluZyBjb250ZXh0ICovDQorc3RhdGlj IGludCBtYXBfdmZzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZl9wZGV2LCB1aW50MTZfdCBjbWQp DQorew0KKyAgICBzdHJ1Y3QgcGNpX2RldiAqdmZfcGRldjsNCisgICAgaW50IHJjOw0KKw0KKyAg ICBBU1NFUlQocndfaXNfd3JpdGVfbG9ja2VkKCZwZl9wZGV2LT5kb21haW4tPnBjaV9sb2NrKSk7 DQorDQorICAgIGxpc3RfZm9yX2VhY2hfZW50cnkodmZfcGRldiwgJnBmX3BkZXYtPnZmX2xpc3Qs IHZmX2xpc3QpIHsNCisgICAgICAgIHJjID0gdnBjaV9tb2RpZnlfYmFycyh2Zl9wZGV2LCBjbWQs IGZhbHNlLCB0cnVlKTsNCisgICAgICAgIGlmICggcmMgKQ0KKyAgICAgICAgew0KKyAgICAgICAg ICAgIGdwcmludGsoWEVOTE9HX0VSUiwgImZhaWxlZCB0byAlcyBWRiAlcHA6ICVkXG4iLA0KKyAg ICAgICAgICAgICAgICAgICAgKGNtZCAmIFBDSV9DT01NQU5EX01FTU9SWSkgPyAibWFwIiA6ICJ1 bm1hcCIsDQorICAgICAgICAgICAgICAgICAgICAmdmZfcGRldi0+c2JkZiwgcmMpOw0KKyAgICAg ICAgICAgIHJldHVybiByYzsNCisgICAgICAgIH0NCisgICAgfQ0KKw0KKyAgICByZXR1cm4gMDsN Cit9DQorDQorDQorc3RhdGljIGludCBzaXplX3ZmX2JhcnMoc3RydWN0IHBjaV9kZXYgKnBmX3Bk ZXYsIHVuc2lnbmVkIGludCBzcmlvdl9wb3MpDQorew0KKyAgICAvKg0KKyAgICAgKiBOQjogYSBu b24tY29uc3QgcGNpX2RldiBvZiB0aGUgUEYgaXMgbmVlZGVkIGluIG9yZGVyIHRvIHVwZGF0ZQ0K KyAgICAgKiB2Zl9ybGVuLg0KKyAgICAgKi8NCisgICAgc3RydWN0IHZwY2lfYmFyICpiYXJzOw0K KyAgICB1bnNpZ25lZCBpbnQgaTsNCisgICAgaW50IHJjID0gMDsNCisNCisgICAgQVNTRVJUKHJ3 X2lzX3dyaXRlX2xvY2tlZCgmcGZfcGRldi0+ZG9tYWluLT5wY2lfbG9jaykpOw0KKyAgICBBU1NF UlQoIXBmX3BkZXYtPmluZm8uaXNfdmlydGZuKTsNCisgICAgQVNTRVJUKHBmX3BkZXYtPnZwY2kt PnNyaW92KTsNCisNCisgICAgLyogUmVhZCBCQVJzIGZvciBWRnMgb3V0IG9mIFBGJ3MgU1ItSU9W IGV4dGVuZGVkIGNhcGFiaWxpdHkuICovDQorICAgIGJhcnMgPSBwZl9wZGV2LT52cGNpLT5zcmlv di0+dmZfYmFyczsNCisgICAgLyogU2V0IHRoZSBCQVJzIGFkZHJlc3NlcyBhbmQgc2l6ZS4gKi8N CisgICAgZm9yICggaSA9IDA7IGkgPCBQQ0lfU1JJT1ZfTlVNX0JBUlM7IGkgKz0gcmMgKQ0KKyAg ICB7DQorICAgICAgICB1bnNpZ25lZCBpbnQgaWR4ID0gc3Jpb3ZfcG9zICsgUENJX1NSSU9WX0JB UiArIGkgKiA0Ow0KKyAgICAgICAgdWludDMyX3QgYmFyOw0KKyAgICAgICAgdWludDY0X3QgYWRk ciwgc2l6ZTsNCisNCisgICAgICAgIGJhciA9IHBjaV9jb25mX3JlYWQzMihwZl9wZGV2LT5zYmRm LCBpZHgpOw0KKw0KKyAgICAgICAgcmMgPSBwY2lfc2l6ZV9tZW1fYmFyKHBmX3BkZXYtPnNiZGYs IGlkeCwgJmFkZHIsICZzaXplLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBDSV9C QVJfVkYgfA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgoaSA9PSBQQ0lfU1JJT1Zf TlVNX0JBUlMgLSAxKSA/IFBDSV9CQVJfTEFTVA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6IDApKTsNCisNCisgICAgICAgIC8q DQorICAgICAgICAgKiBVcGRhdGUgdmZfcmxlbiBvbiB0aGUgUEYuIEFjY29yZGluZyB0byB0aGUg c3BlYyB0aGUgc2l6ZSBvZg0KKyAgICAgICAgICogdGhlIEJBUnMgY2FuIGNoYW5nZSBpZiB0aGUg c3lzdGVtIHBhZ2Ugc2l6ZSByZWdpc3RlciBpcw0KKyAgICAgICAgICogbW9kaWZpZWQsIHNvIGFs d2F5cyB1cGRhdGUgcmxlbiB3aGVuIGVuYWJsaW5nIFZGcy4NCisgICAgICAgICAqLw0KKyAgICAg ICAgcGZfcGRldi0+cGh5c2ZuLnZmX3JsZW5baV0gPSBzaXplOw0KKw0KKyAgICAgICAgaWYgKCAh c2l6ZSApDQorICAgICAgICB7DQorICAgICAgICAgICAgYmFyc1tpXS50eXBlID0gVlBDSV9CQVJf RU1QVFk7DQorICAgICAgICAgICAgY29udGludWU7DQorICAgICAgICB9DQorDQorICAgICAgICBi YXJzW2ldLmFkZHIgPSBhZGRyOw0KKyAgICAgICAgYmFyc1tpXS5ndWVzdF9hZGRyID0gYWRkcjsN CisgICAgICAgIGJhcnNbaV0uc2l6ZSA9IHNpemU7DQorICAgICAgICBiYXJzW2ldLnByZWZldGNo YWJsZSA9IGJhciAmIFBDSV9CQVNFX0FERFJFU1NfTUVNX1BSRUZFVENIOw0KKw0KKyAgICAgICAg c3dpdGNoICggcmMgKQ0KKyAgICAgICAgew0KKyAgICAgICAgY2FzZSAxOg0KKyAgICAgICAgICAg IGJhcnNbaV0udHlwZSA9IFZQQ0lfQkFSX01FTTMyOw0KKyAgICAgICAgICAgIGJyZWFrOw0KKw0K KyAgICAgICAgY2FzZSAyOg0KKyAgICAgICAgICAgIGJhcnNbaV0udHlwZSA9IFZQQ0lfQkFSX01F TTY0X0xPOw0KKyAgICAgICAgICAgIGJhcnNbaSArIDFdLnR5cGUgPSBWUENJX0JBUl9NRU02NF9I STsNCisgICAgICAgICAgICBicmVhazsNCisNCisgICAgICAgIGRlZmF1bHQ6DQorICAgICAgICAg ICAgQVNTRVJUX1VOUkVBQ0hBQkxFKCk7DQorICAgICAgICB9DQorICAgIH0NCisNCisgICAgcmMg PSByYyA+IDAgPyAwIDogcmM7DQorDQorICAgIHJldHVybiByYzsNCit9DQorDQorc3RydWN0IGNh bGxiYWNrX2RhdGEgew0KKyAgICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldjsNCisgICAgdW5z aWduZWQgaW50IHBvczsNCisgICAgdWludDMyX3QgdmFsdWU7DQorICAgIGJvb2wgZW5hYmxlIDog MTsNCisgICAgYm9vbCBkaXNhYmxlIDogMTsNCisgICAgYm9vbCBtYXAgOiAxOw0KKyAgICBib29s IHVubWFwIDogMTsNCit9Ow0KKw0KK3N0YXRpYyB2b2lkIGNmX2NoZWNrIGNvbnRyb2xfd3JpdGVf Y2Iodm9pZCAqZGF0YSkNCit7DQorICAgIHN0cnVjdCBjYWxsYmFja19kYXRhICpjYiA9IGRhdGE7 DQorICAgIGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2ID0gY2ItPnBkZXY7DQorICAgIHVpbnQx Nl90IG9mZnNldCA9IHBjaV9jb25mX3JlYWQxNihwZGV2LT5zYmRmLCBjYi0+cG9zICsgUENJX1NS SU9WX1ZGX09GRlNFVCk7DQorICAgIHVpbnQxNl90IHN0cmlkZSA9IHBjaV9jb25mX3JlYWQxNihw ZGV2LT5zYmRmLCBjYi0+cG9zICsgUENJX1NSSU9WX1ZGX1NUUklERSk7DQorICAgIHN0cnVjdCB2 cGNpX3NyaW92ICpzcmlvdiA9IHBkZXYtPnZwY2ktPnNyaW92Ow0KKyAgICBpbnQgcmMgPSAwOw0K KyAgICB1bnNpZ25lZCBpbnQgaTsNCisNCisgICAgaWYgKCBjYi0+dW5tYXAgKQ0KKyAgICB7DQor ICAgICAgICB3cml0ZV9sb2NrKCZwZGV2LT5kb21haW4tPnBjaV9sb2NrKTsNCisgICAgICAgIG1h cF92ZnMocGRldiwgMCk7DQorICAgICAgICB3cml0ZV91bmxvY2soJnBkZXYtPmRvbWFpbi0+cGNp X2xvY2spOw0KKyAgICB9DQorDQorICAgIGlmICggY2ItPmVuYWJsZSB8fCBjYi0+ZGlzYWJsZSAp DQorICAgIHsNCisgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgc3Jpb3YtPm51bV92ZnM7IGkrKyAp DQorICAgICAgICB7DQorICAgICAgICAgICAgY29uc3QgcGNpX3NiZGZfdCB2Zl9zYmRmID0gew0K KyAgICAgICAgICAgICAgICAuc2JkZiA9IHBkZXYtPnNiZGYuc2JkZiArIG9mZnNldCArIHN0cmlk ZSAqIGksDQorICAgICAgICAgICAgfTsNCisNCisgICAgICAgICAgICBpZiAoIGNiLT5lbmFibGUg KQ0KKyAgICAgICAgICAgIHsNCisgICAgICAgICAgICAgICAgY29uc3Qgc3RydWN0IHBjaV9kZXZf aW5mbyBpbmZvID0gew0KKyAgICAgICAgICAgICAgICAgICAgLmlzX3ZpcnRmbiA9IHRydWUsDQor ICAgICAgICAgICAgICAgICAgICAuaXNfZXh0Zm4gPSBmYWxzZSwNCisgICAgICAgICAgICAgICAg ICAgIC5waHlzZm4uYnVzID0gcGRldi0+c2JkZi5idXMsDQorICAgICAgICAgICAgICAgICAgICAu cGh5c2ZuLmRldmZuID0gcGRldi0+c2JkZi5kZXZmbiwNCisgICAgICAgICAgICAgICAgfTsNCisg ICAgICAgICAgICAgICAgcmMgPSBwY2lfYWRkX2RldmljZSh2Zl9zYmRmLnNlZywgdmZfc2JkZi5i dXMsIHZmX3NiZGYuZGV2Zm4sDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg JmluZm8sIHBkZXYtPm5vZGUpOw0KKyAgICAgICAgICAgIH0NCisgICAgICAgICAgICBpZiAoIGNi LT5kaXNhYmxlICkNCisgICAgICAgICAgICAgICAgcmMgPSBwY2lfcmVtb3ZlX2RldmljZSh2Zl9z YmRmLnNlZywgdmZfc2JkZi5idXMsIHZmX3NiZGYuZGV2Zm4pOw0KKw0KKyAgICAgICAgICAgIGlm ICggcmMgJiYgcmMgIT0gLUVOT0RFVikNCisgICAgICAgICAgICAgICAgZ3ByaW50ayhYRU5MT0df RVJSLCAiZmFpbGVkIHRvICVzIFZGICVwcDogJWRcbiIsDQorICAgICAgICAgICAgICAgICAgICAg ICAgY2ItPmVuYWJsZSA/ICJhZGQiIDogInJlbW92ZSIsICZ2Zl9zYmRmLCByYyk7DQorICAgICAg ICB9DQorICAgIH0NCisNCisgICAgaWYgKCBjYi0+bWFwICkNCisgICAgew0KKyAgICAgICAgd3Jp dGVfbG9jaygmcGRldi0+ZG9tYWluLT5wY2lfbG9jayk7DQorICAgICAgICByYyA9IG1hcF92ZnMo cGRldiwgUENJX0NPTU1BTkRfTUVNT1JZKTsNCisNCisgICAgICAgIGlmICggcmMgKQ0KKyAgICAg ICAgICAgIG1hcF92ZnMocGRldiwgMCk7DQorICAgICAgICB3cml0ZV91bmxvY2soJnBkZXYtPmRv bWFpbi0+cGNpX2xvY2spOw0KKyAgICB9DQorDQorICAgIHBjaV9jb25mX3dyaXRlMTYocGRldi0+ c2JkZiwgY2ItPnBvcyArIFBDSV9TUklPVl9DVFJMLCBjYi0+dmFsdWUpOw0KKyAgICB4ZnJlZShj Yik7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIGNmX2NoZWNrIGNvbnRyb2xfd3JpdGUoY29uc3Qgc3Ry dWN0IHBjaV9kZXYgKnBkZXYsIHVuc2lnbmVkIGludCByZWcsDQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCB2YWwsIHZvaWQgKmRhdGEpDQorew0KKyAgICB1bnNp Z25lZCBpbnQgc3Jpb3ZfcG9zID0gcmVnIC0gUENJX1NSSU9WX0NUUkw7DQorICAgIHN0cnVjdCB2 cGNpX3NyaW92ICpzcmlvdiA9IHBkZXYtPnZwY2ktPnNyaW92Ow0KKyAgICBzdHJ1Y3QgY2FsbGJh Y2tfZGF0YSAqY2IgPSBOVUxMOw0KKyAgICB1aW50MTZfdCBjb250cm9sID0gcGNpX2NvbmZfcmVh ZDE2KHBkZXYtPnNiZGYsIHJlZyk7DQorICAgIGJvb2wgbWVtX2VuYWJsZWQgPSBjb250cm9sICYg UENJX1NSSU9WX0NUUkxfTVNFOw0KKyAgICBib29sIG5ld19tZW1fZW5hYmxlZCA9IHZhbCAmIFBD SV9TUklPVl9DVFJMX01TRTsNCisgICAgYm9vbCBlbmFibGVkID0gY29udHJvbCAmIFBDSV9TUklP Vl9DVFJMX1ZGRTsNCisgICAgYm9vbCBuZXdfZW5hYmxlZCA9IHZhbCAmIFBDSV9TUklPVl9DVFJM X1ZGRTsNCisNCisgICAgQVNTRVJUKCFwZGV2LT5pbmZvLmlzX3ZpcnRmbik7DQorDQorICAgIGlm ICggbmV3X2VuYWJsZWQgPT0gZW5hYmxlZCAmJiBuZXdfbWVtX2VuYWJsZWQgPT0gbWVtX2VuYWJs ZWQgKQ0KKyAgICB7DQorICAgICAgICBwY2lfY29uZl93cml0ZTE2KHBkZXYtPnNiZGYsIHJlZywg dmFsKTsNCisgICAgICAgIHJldHVybjsNCisgICAgfQ0KKw0KKyAgICBjYiA9IHh6YWxsb2Moc3Ry dWN0IGNhbGxiYWNrX2RhdGEpOw0KKw0KKyAgICBpZiAoICFjYiApDQorICAgIHsNCisgICAgICAg IGdwcmludGsoWEVOTE9HX0VSUiwNCisgICAgICAgICAgICAgICAgIiVwcDogVW5hYmxlIHRvIGFs bG9jYXRlIG1lbW9yeSBmb3IgU1ItSU9WIGVuYWJsZVxuIiwNCisgICAgICAgICAgICAgICAgcGRl dik7DQorICAgICAgICByZXR1cm47DQorICAgIH0NCisNCisgICAgY2ItPnBkZXYgPSBwZGV2Ow0K KyAgICBjYi0+cG9zID0gc3Jpb3ZfcG9zOw0KKyAgICBjYi0+dmFsdWUgPSB2YWw7DQorICAgIGNi LT5tYXAgPSBuZXdfbWVtX2VuYWJsZWQgJiYgIW1lbV9lbmFibGVkOw0KKyAgICBjYi0+dW5tYXAg PSAhbmV3X21lbV9lbmFibGVkICYmIG1lbV9lbmFibGVkOw0KKyAgICBjYi0+ZW5hYmxlID0gbmV3 X2VuYWJsZWQgJiYgIWVuYWJsZWQ7DQorICAgIGNiLT5kaXNhYmxlID0gIW5ld19lbmFibGVkICYm IGVuYWJsZWQ7DQorDQorICAgIGN1cnJlbnQtPnZwY2kudGFzayA9IFdBSVQ7DQorICAgIGN1cnJl bnQtPnZwY2kud2FpdC5jYWxsYmFjayA9IGNvbnRyb2xfd3JpdGVfY2I7DQorICAgIGN1cnJlbnQt PnZwY2kud2FpdC5kYXRhID0gY2I7DQorICAgIGN1cnJlbnQtPnZwY2kud2FpdC5lbmQgPSBOT1co KTsNCisNCisgICAgaWYgKCBjYi0+ZW5hYmxlICkNCisgICAgew0KKyAgICAgICAgc2l6ZV92Zl9i YXJzKChzdHJ1Y3QgcGNpX2RldiAqKXBkZXYsIHNyaW92X3Bvcyk7DQorDQorICAgICAgICAvKg0K KyAgICAgICAgICogT25seSB1cGRhdGUgdGhlIG51bWJlciBvZiBhY3RpdmUgVkZzIHdoZW4gZW5h YmxpbmcsIHdoZW4NCisgICAgICAgICAqIGRpc2FibGluZyB1c2UgdGhlIGNhY2hlZCB2YWx1ZSBp biBvcmRlciB0byBhbHdheXMgcmVtb3ZlIHRoZSBzYW1lDQorICAgICAgICAgKiBudW1iZXIgb2Yg VkZzIHRoYXQgd2VyZSBhY3RpdmUuDQorICAgICAgICAgKi8NCisgICAgICAgIHNyaW92LT5udW1f dmZzID0gcGNpX2NvbmZfcmVhZDE2KHBkZXYtPnNiZGYsDQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzcmlvdl9wb3MgKyBQQ0lfU1JJT1ZfTlVNX1ZGKTsNCisgICAg ICAgIC8qDQorICAgICAgICAgKiBOQjogVkZFIG5lZWRzIHRvIGJlIGVuYWJsZWQgYmVmb3JlIGNh bGxpbmcgcGNpX2FkZF9kZXZpY2Ugc28gWGVuDQorICAgICAgICAgKiBjYW4gYWNjZXNzIHRoZSBj b25maWcgc3BhY2Ugb2YgVkZzLiBGSVhNRSBjYXN0aW5nIGF3YXkgY29uc3QtbmVzcw0KKyAgICAg ICAgICogdG8gbW9kaWZ5IHZmX3JsZW4NCisgICAgICAgICAqLw0KKyAgICAgICAgcGNpX2NvbmZf d3JpdGUxNihwZGV2LT5zYmRmLCByZWcsIGNvbnRyb2wgfCBQQ0lfU1JJT1ZfQ1RSTF9WRkUpOw0K KyAgICAgICAgLyoNCisgICAgICAgICAqIFRoZSBzcGVjIHN0YXRlcyB0aGF0IHRoZSBzb2Z0d2Fy ZSBtdXN0IHdhaXQgYXQgbGVhc3QgMTAwbXMgYmVmb3JlDQorICAgICAgICAgKiBhdHRlbXB0aW5n IHRvIGFjY2VzcyBWRiByZWdpc3RlcnMgd2hlbiBlbmFibGluZyB2aXJ0dWFsIGZ1bmN0aW9ucw0K KyAgICAgICAgICogb24gdGhlIFBGLg0KKyAgICAgICAgICovDQorDQorICAgICAgICBjdXJyZW50 LT52cGNpLndhaXQuZW5kID0gTk9XKCkgKyBNSUxMSVNFQ1MoMTAwKTsNCisgICAgfQ0KK30NCisN CitpbnQgdmZfaW5pdF9oZWFkZXIoc3RydWN0IHBjaV9kZXYgKnZmX3BkZXYpDQorew0KKyAgICBj b25zdCBzdHJ1Y3QgcGNpX2RldiAqcGZfcGRldjsNCisgICAgdW5zaWduZWQgaW50IHNyaW92X3Bv czsNCisgICAgaW50IHJjID0gMDsNCisgICAgdWludDE2X3QgY3RybDsNCisNCisgICAgQVNTRVJU KHJ3X2lzX3dyaXRlX2xvY2tlZCgmdmZfcGRldi0+ZG9tYWluLT5wY2lfbG9jaykpOw0KKw0KKyAg ICBpZiAoICF2Zl9wZGV2LT5pbmZvLmlzX3ZpcnRmbiApDQorICAgICAgICByZXR1cm4gMDsNCisN CisgICAgcGZfcGRldiA9IHZmX3BkZXYtPnBmX3BkZXY7DQorICAgIEFTU0VSVChwZl9wZGV2KTsN CisNCisgICAgcmMgPSB2Zl9pbml0X2JhcnModmZfcGRldik7DQorICAgIGlmICggcmMgKQ0KKyAg ICAgICAgcmV0dXJuIHJjOw0KKw0KKyAgICBzcmlvdl9wb3MgPSBwY2lfZmluZF9leHRfY2FwYWJp bGl0eShwZl9wZGV2LCBQQ0lfRVhUX0NBUF9JRF9TUklPVik7DQorICAgIGN0cmwgPSBwY2lfY29u Zl9yZWFkMTYocGZfcGRldi0+c2JkZiwgc3Jpb3ZfcG9zICsgUENJX1NSSU9WX0NUUkwpOw0KKw0K KyAgICBpZiAoIChwZl9wZGV2LT5kb21haW4gPT0gdmZfcGRldi0+ZG9tYWluKSAmJiAoY3RybCAm IFBDSV9TUklPVl9DVFJMX01TRSkgKQ0KKyAgICB7DQorICAgICAgICByYyA9IHZwY2lfbW9kaWZ5 X2JhcnModmZfcGRldiwgUENJX0NPTU1BTkRfTUVNT1JZLCBmYWxzZSwgZmFsc2UpOw0KKyAgICAg ICAgaWYgKCByYyApDQorICAgICAgICAgICAgcmV0dXJuIHJjOw0KKyAgICB9DQorDQorICAgIHJl dHVybiByYzsNCit9DQorDQorc3RhdGljIGludCBjZl9jaGVjayBpbml0X3NyaW92KHN0cnVjdCBw Y2lfZGV2ICpwZGV2KQ0KK3sNCisgICAgdW5zaWduZWQgaW50IHBvczsNCisNCisgICAgQVNTRVJU KCFwZGV2LT5pbmZvLmlzX3ZpcnRmbik7DQorDQorICAgIHBvcyA9IHBjaV9maW5kX2V4dF9jYXBh YmlsaXR5KHBkZXYsIFBDSV9FWFRfQ0FQX0lEX1NSSU9WKTsNCisNCisgICAgaWYgKCAhcG9zICkN CisgICAgICAgIHJldHVybiAwOw0KKw0KKyAgICBpZiAoIHhzbV9yZXNvdXJjZV9zZXR1cF9wY2ko WFNNX1BSSVYsIHBkZXYtPnNiZGYuYmRmKSApDQorICAgIHsNCisgICAgICAgIHByaW50ayhYRU5M T0dfRVJSDQorICAgICAgICAgICAgICAgIiVwcDogU1ItSU9WIGNvbmZpZ3VyYXRpb24gdW5zdXBw b3J0ZWQgZm9yIHVucHJpdiAlcGRcbiIsDQorICAgICAgICAgICAgICAgJnBkZXYtPnNiZGYsIHBk ZXYtPmRvbWFpbik7DQorICAgICAgICByZXR1cm4gMDsNCisgICAgfQ0KKw0KKyAgICBwZGV2LT52 cGNpLT5zcmlvdiA9IHh6YWxsb2Moc3RydWN0IHZwY2lfc3Jpb3YpOw0KKyAgICBpZiAoICFwZGV2 LT52cGNpLT5zcmlvdiApDQorICAgICAgICByZXR1cm4gLUVOT01FTTsNCisNCisgICAgcmV0dXJu IHZwY2lfYWRkX3JlZ2lzdGVyKHBkZXYtPnZwY2ksIHZwY2lfaHdfcmVhZDE2LCBjb250cm9sX3dy aXRlLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcG9zICsgUENJX1NSSU9WX0NUUkws IDIsIE5VTEwpOw0KK30NCisNCitzdGF0aWMgaW50IGNmX2NoZWNrIGNsZWFudXBfc3Jpb3YoY29u c3Qgc3RydWN0IHBjaV9kZXYgKnBkZXYsIGJvb2wgaGlkZSkNCit7DQorICAgIGlmICggaGlkZSAp DQorICAgICAgICByZXR1cm4gMDsNCisNCisgICAgWEZSRUUocGRldi0+dnBjaS0+c3Jpb3YpOw0K Kw0KKyAgICByZXR1cm4gMDsNCit9DQorDQorUkVHSVNURVJfVlBDSV9FWFRDQVAoU1JJT1YsIGlu aXRfc3Jpb3YsIGNsZWFudXBfc3Jpb3YpOw0KKw0KKy8qDQorICogTG9jYWwgdmFyaWFibGVzOg0K KyAqIG1vZGU6IEMNCisgKiBjLWZpbGUtc3R5bGU6ICJCU0QiDQorICogYy1iYXNpYy1vZmZzZXQ6 IDQNCisgKiB0YWItd2lkdGg6IDQNCisgKiBpbmRlbnQtdGFicy1tb2RlOiBuaWwNCisgKiBFbmQ6 DQorICovDQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUveGVuL3ZwY2kuaCBiL3hlbi9pbmNsdWRl L3hlbi92cGNpLmgNCmluZGV4IDQ3Y2RiNTRkNDIuLmFlNWYzYjcyNzQgMTAwNjQ0DQotLS0gYS94 ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQorKysgYi94ZW4vaW5jbHVkZS94ZW4vdnBjaS5oDQpAQCAt NDUsNiArNDUsNyBAQCB0eXBlZGVmIHN0cnVjdCB7DQogICAgIFJFR0lTVEVSX1ZQQ0lfQ0FQQUJJ TElUWShQQ0lfRVhUX0NBUF9JRF8jI25hbWUsIG5hbWUsIGZpbml0LCBmY2xlYW4sIHRydWUpDQog DQogaW50IF9fbXVzdF9jaGVjayB2cGNpX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2 KTsNCitpbnQgX19tdXN0X2NoZWNrIHZmX2luaXRfaGVhZGVyKHN0cnVjdCBwY2lfZGV2ICpwZGV2 KTsNCiANCiAvKiBBc3NpZ24gdlBDSSB0byBkZXZpY2UgYnkgYWRkaW5nIGhhbmRsZXJzLiAqLw0K IGludCBfX211c3RfY2hlY2sgdnBjaV9hc3NpZ25fZGV2aWNlKHN0cnVjdCBwY2lfZGV2ICpwZGV2 KTsNCkBAIC0xNDYsNyArMTQ3LDYgQEAgc3RydWN0IHZwY2kgew0KICAgICAgICAgICogdXBvbiB0 byBrbm93IHdoZXRoZXIgQkFScyBhcmUgbWFwcGVkIGludG8gdGhlIGd1ZXN0IHAybS4NCiAgICAg ICAgICAqLw0KICAgICAgICAgYm9vbCBiYXJzX21hcHBlZCAgICAgIDogMTsNCi0gICAgICAgIC8q IEZJWE1FOiBjdXJyZW50bHkgdGhlcmUncyBubyBzdXBwb3J0IGZvciBTUi1JT1YuICovDQogICAg IH0gaGVhZGVyOw0KIA0KICAgICAvKiBNU0kgZGF0YS4gKi8NCkBAIC0yMDAsNiArMjAwLDEzIEBA IHN0cnVjdCB2cGNpIHsNCiAgICAgICAgICAgICBzdHJ1Y3QgdnBjaV9hcmNoX21zaXhfZW50cnkg YXJjaDsNCiAgICAgICAgIH0gZW50cmllc1tdOw0KICAgICB9ICptc2l4Ow0KKw0KKyAgICBzdHJ1 Y3QgdnBjaV9zcmlvdiB7DQorICAgICAgICAvKiBQRiBvbmx5ICovDQorICAgICAgICBzdHJ1Y3Qg dnBjaV9iYXIgdmZfYmFyc1tQQ0lfU1JJT1ZfTlVNX0JBUlNdOw0KKyAgICAgICAgdWludDE2X3Qg bnVtX3ZmczsNCisgICAgfSAqc3Jpb3Y7DQorDQogI2lmZGVmIENPTkZJR19IQVNfVlBDSV9HVUVT VF9TVVBQT1JUDQogICAgIC8qIEd1ZXN0IFNCREYgb2YgdGhlIGRldmljZS4gKi8NCiAjZGVmaW5l IElOVkFMSURfR1VFU1RfU0JERiAoKHBjaV9zYmRmX3QpeyAuc2JkZiA9IH4wVSB9KQ0KQEAgLTMy Myw3ICszMzAsOCBAQCBib29sIHZwY2lfZWNhbV9yZWFkKHBjaV9zYmRmX3Qgc2JkZiwgdW5zaWdu ZWQgaW50IHJlZywgdW5zaWduZWQgaW50IGxlbiwNCiAgICAgICAgICAgICAgICAgICAgIHVuc2ln bmVkIGxvbmcgKmRhdGEpOw0KIA0KIC8qIE1hcC91bm1hcCB0aGUgQkFScyBvZiBhIHZQQ0kgZGV2 aWNlLiAqLw0KLWludCB2cGNpX21vZGlmeV9iYXJzKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2 LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHkpOw0KK2ludCB2cGNpX21vZGlmeV9iYXJzKGNv bnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29ubHksDQor ICAgICAgICAgICAgICAgICAgICAgYm9vbCBub19kZWZlcik7DQogDQogI2VuZGlmIC8qIF9fWEVO X18gKi8NCiANCi0tIA0KMi41MS4yDQo= From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249279.1546784 (Exim 4.92) (envelope-from ) id 1vzYTa-0004p9-EG; Mon, 09 Mar 2026 11:08:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249279.1546784; Mon, 09 Mar 2026 11:08:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTa-0004nX-84; Mon, 09 Mar 2026 11:08:42 +0000 Received: by outflank-mailman (input) for mailman id 1249279; Mon, 09 Mar 2026 11:08:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTY-0003iR-Ty for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:41 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 533635de-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:39 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08: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%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 533635de-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JNvNmbgqDJK2L+vIoJyA85Uf7OEmPgIqHSQjq71ibsxBxaJV/uNZzMWDWczahzoMxf9+/T54BiUq4qYALg1OgRHUlT5tR90ligM7ibKaWvxouoX5ij49BkTi9ALDbmVTOCvbEcwBSmxU1UojQ+o0Nl6ukA0/NQ4qFI193HWJqeFSzKzhR3bBa5g3DLh8x5Sd0NN+NmRZsm6m+qF4wKuoI93E8clFIsJTqffgZodd8cCi7QSauJ1fqqsU/JKE84HeKtDwhCN0QWPhyN5uoqQ+9SKL+FrkNMboqZSPI7AJ698qX2CXTC05ZHhiTy4Rv6ogswmhPPmP8vwh4RYD32geyQ== 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=as8HXwLx1Zl9o2iQtPqGLoGRGBXmJbz5GSTKA8wbpEg=; b=txDinyKu++Xk3mujU58GFWCEgby8z98yN6d8TAyvbNE1DluG9ZTNoCltTH2DWv+PHcQ62LestJKNB3qdLvlMdqCptsomW54Vco0clgt3JnPZDXxU0GrgaIHSLL4NhEnm9Bzergq1d9FnAcdATILM0kEtMSXqvGVNyg4jJN3bZcXTA4IU1mf/msVWm4qoacZm5Y4b+mITmJdK+V587V7OVvkAyZUDepSQVTO/1VCzsrPrMKvUncMdtjRwuEfX3uZTKUad8LzONANuANdxd2NbATIpNbRJUzXTVCQfbj/qI6pbt6nRj38uGhbYiQeLdP6nHVF3p43zUs3AefCHwicTDQ== 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=as8HXwLx1Zl9o2iQtPqGLoGRGBXmJbz5GSTKA8wbpEg=; b=YM3ClKHI1XPlEwOAyXw2zRDGkOJ5KRE+ltfnNHslT062QWDp80yk4fMtSlAsRda2PQhWrGil+5WERPFJpMLyvWEkGRnSPmsS6SXitl9mFnXovLTfyXLl5ySoynbqniR/lKqiag6MEBoVf4hULpBp79oEekvveEG4yzEuNfaADUiYf0H8K+KNKZgMiZRlnty+Z1lCZK21CKaqNjzMOIvM99CS/pe02V9AKn6LD+fnx1Jr+a261VGN03Rm3vUtwfgN8Batt4oScq31YtVHa8EdDRjPsW8pJYqTMm5yTCmuQjwbeS6gnmPZuvQ59jqpej+UPFwRQcs3WHpsZlx8qmFodQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Stewart Hildebrand Subject: [PATCH v2 4/8] vpci: add a wait operation to the vpci vcpu pending actions Thread-Topic: [PATCH v2 4/8] vpci: add a wait operation to the vpci vcpu pending actions Thread-Index: AQHcr7UNjpbdOXJQP0qdir/zrd85oQ== Date: Mon, 9 Mar 2026 11:08:26 +0000 Message-ID: References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: 9ba41daa-adda-4cbc-6641-08de7dcc3287 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: FgBkkkf5bQYCe5NIp3tiTwRBx5GxGX5OdGalTuAAIPC53cH+NHwLxFtKgRA79kB7vkr2ELmJqixBxsg/yGFosUEd/O0YwjsVUFw9H3pEAE6BeS9HwTe9l2OoUYmgpKgJMLo6AutEH36CO59lcBZJ/KOKNgSZ3vviafFTb1Pg3pDco9I0r4m7QCi1zQ22qbebJj342FvHie2uUFSQ48YMBEo+ROmNGbBsk3TzcCYdkZTu42QFA43pVIoYu+gEQzWAgLFNfZJayXbILBQ5tnH5bkeEiVPL9ZJYzDrE5yg1xDApeCkPBQbQVS7vzKeDcVMnaa3qL60c1wHLVxybZ415z/Ey4Sb/VUO+vAyUltW/Zh3Iq49+GRc5SMU38r3qZGKsb2lDKmcrCjzDybLuBZYKcd0WfDiEKIYGrvG1LGRoM4o/wv8AJi45EECRjp31MAUeL+dqRRStLhIxhhig/aAmLN6zCyc/Dq2CfmrwD59IDr6R2FlJVvve8E1jTUNjPhZ15CbHCi0l2EF+Z73XkRQlnIdnCNxvqmAFkEVqjKm638PITQaLmwpNvJGRpdmPGErWRnVVKdOyB7dqU3L80kJwfAcVj9/ZYAf//Sjj4ipRl/s8WD4eMt4XsM8/Ci7HWHeY1IK14enPg3Xgf49EOojbB8d4Pc+IwDGx3XVkG9FhmJ/iMNtdv7jWQVMcolT/XFoQSf3JGY0aoIph28l6KSy/gVbzZ4/mC2sx6mZfvQtB8nbN6m1VEtDjmyv8RT4tdtfK4LBnyKCKUeGSVUWT7mcbv7phPWvbaDWIFefp88Oz0q0= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eUxoTEtMcFJnanFUeFpxTjdsb2VoWDhMTktoRXFUZ2w2aFlMdnJvM1VoMEVv?= =?utf-8?B?U05MZVZHaVB1ellZWnA4L25aVGplVlpUWGdHQ3ZBbGdGRlQwYU82VlBVWHMr?= =?utf-8?B?NnV5Z0xzNWpwU0ZPTlRjYkhURWJqdlJjSDVIRUp0SlJ5MmFUS29FRUNjeVhq?= =?utf-8?B?SnhicWVtS2hrdHZEejVLY1NMdW40d3ZBS1ZzWVRqeEJyTk9DNkdNa1dWNno5?= =?utf-8?B?TFMyZXg0OVNpYnBvb1NuMGNORVNLZ2QxS3FuWEg5S2NUdlUyS3Ard3JVeEQy?= =?utf-8?B?MnBKSnVqTE9VQW9ubHR3WUlsVmRvQmRiOUVUWmRmZEtXZ3BmdkE4RjR2anpz?= =?utf-8?B?TTgzM3U5NGszazVrSU9XbXVXWnU4YlYyYkt6dlpHRWR5Zll0YkxhMFBPSVZR?= =?utf-8?B?QUlFRU1TU2M3K2I3VEJhSkVhcUpaMlJLczljVStYb0NYa2lsdGtvd013aVJj?= =?utf-8?B?K1VZdWlTRVVjRTROVU8rbmEyNkdKdXh4d2syTjYvcDdqWGRwR2pPalNncGJO?= =?utf-8?B?bmNZQ0dkVDVpZVhUZllOSUtpN09oY1VFejhvbmc3OThYUTVFTVhtcFBGMVdD?= =?utf-8?B?UnRSNGx2Tmw4eUN6RUxmVE5mL3ptTWRocmZYb2VoMEtOVGpzRWNmV3ppYkFY?= =?utf-8?B?Zi9RcFZoYmdGdEVRZk9JMTVFRERSbUZMOG5lczB0b3lPaEZDcFRvdkhHS2VZ?= =?utf-8?B?K0NNcmZtaEViK0xmTDhmOG1QdFdNcWhHOEF1UzBQbDFpRUZxMXMrMU53SEti?= =?utf-8?B?ejBOVkZGU2ovSHBleDFyVXdyeTdZU0FCWldGbC9FREdZNmtjd0hVbDdsbTNi?= =?utf-8?B?RmlyOGlMWHZuMXFmeXpZeHg3MkZCN1U0b25xbnM5N2pPMjg1MDN4L2NlSzAy?= =?utf-8?B?TkYxUEo3TXRHc3VjNEJCa242K2FuZkV5QnlKVk1TRkpXcHc4bUUrLzhRZ1p6?= =?utf-8?B?aENJWEZZVDJ3bEFjeW0wN1d0dXJMRnBaL1NkMC8zb0M2L1RaWlRSa2pyMmMr?= =?utf-8?B?dmh4MTFPcEd4ZGRzR3o2cSs3WXQxQ25YRUhMYjJqWXBqQm5jYmJlMWJGMFRs?= =?utf-8?B?VEJpT0s0eFNZbldGSU9nSU1YVkJyS3RFMnlKYWh4WkVuazRldnhpNmJIaHJi?= =?utf-8?B?TjBudUlleWdBOUh1NlpabXZaU0J6bEZRYnVPelNHREhjaEQzdElNcTNIV3hl?= =?utf-8?B?L0NWbHJJc3gvZlNVR0tOeWpOZjVUYnE2elNNdzdXQlZvQTdqb1VxWnp3T2hP?= =?utf-8?B?aG1GWVczaS9QQW13ek5NTWE0d3dIdFkvVmhUUkJweXpTS0l2V0haVGFUeHMy?= =?utf-8?B?ZEMzaHFhRUhDRzNDS1BnMmJyYUJJK0puQUFYWTJYT2NLdWtnTDVRa2E0Nk5p?= =?utf-8?B?bnRmY0FDMUh1M0E4ek9FNytFbkJLMXFDZlZLUE0xTE5hb1MvTUlQdVpRNW85?= =?utf-8?B?RDFKcm5NZzFFVUZYMlFWeE9BamxHa00wTEorbzRjSEZ0a25ISnlSYzFjT3h6?= =?utf-8?B?OTl4b3NRYXhKSVdEK2NMZzhaQ0tGdXNMYjZKVkFPWGtiQ0luSlZPdUVFb2lI?= =?utf-8?B?V1hUcW9qdXdHQk5QR3F4RTkveDVQbStGYzFUK2VWTy9UMmtqMmIrek5acW9M?= =?utf-8?B?RnFwQWlTNk1KY05WcHlpRmJMNlJmTkpxSE1DWUxhT0VhbHhxRFFFeGIvMGor?= =?utf-8?B?ditYMjNMeVdDRFFDT3U1ekhhZDVZUzNFN1gxbkRrU2UrMTUvVldnZjN1eUZP?= =?utf-8?B?TFp2T0RFSmIvZW81MlRhNTU4ZkdRQ1htSFpoVjlBMkcwdXpPR0h4UWs3OVMx?= =?utf-8?B?WE9rQnErSC80MmY3T2RrZ0JHM0NrT1BHajVZZzZ5UklRWHhGU1poTzBHRWtL?= =?utf-8?B?cjU4NlgvdHo0MlYrZExRdEpuMnBleU10WVIwODhhNnF2SUk3WElXSGJEWjhs?= =?utf-8?B?V0RVU1dSTThUamtkcmxzVVVWUGhLeUlUdkYwYXNTb0NUeHVsanA3NkgzVFcr?= =?utf-8?B?OEZPV2NralpHL3JmdTh6aHlJQkx1S3JSbjc0WjRvL2ZhRTdGT3JPU2hTVnBI?= =?utf-8?B?SHpJekNPcVFzRFNVb3crclJzMFV1ZTc2T3cxWTA2TGhueUZXckRWQTlJZDlV?= =?utf-8?B?N21saUJROG5kTGlHNVRlNGFhR3ZmL2czYmhNRW5mdXdya0JwQ2Q3d1ZVQ2Ja?= =?utf-8?B?M0V1TzlFOTQxZU4wbE16ak4rUkg5YWp5eVVkN1hDMHN4SXJKRkhHTkdmUGQy?= =?utf-8?B?ZkpINWtRL1VQdE05VzFrb29tWjBNOS9LUUdiK2xuYnIyQXFKSkhMaW41dGpG?= =?utf-8?B?ZnNyOTlzYjNrcklkUzNoK29GejdNdnVJZ1BGRWdDMUM1bXYydmlTczVYLzJH?= =?utf-8?Q?YE9MyvWmuNlzAoG4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <32432DDDF70C5D40839E4418016DD16E@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: PAVPR03MB10102.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ba41daa-adda-4cbc-6641-08de7dcc3287 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:26.9721 (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: dURlGtTLDghS1KYqIh8m0pMYhb9AQHdXq/yp2sOUZDoK+L1+rfAUoIe6S36WqqtLzt3CZjd6Xt1BmJnhhxSUrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 VGhpcyBhbGxvd3Mgd2FpdGluZyBhIHNwZWNpZmllZCBudW1iZXIgb2YgY3ljbGVzIG9uIHRoZSB2 Y3B1LiBPbmNlIHRoZQ0Kd2FpdCBoYXMgZmluaXNoZWQgYSBjYWxsYmFjayBpcyBleGVjdXRlZC4N Cg0KTm90ZSB0aGF0IHRoaXMgaXMgc3RpbGwgbm90IHVzZWQsIGJ1dCBpbnRyb2R1Y2VkIGhlcmUg aW4gb3JkZXIgdG8NCnNpbXBsaWZ5IHRoZSBjb21wbGV4aXR5IG9mIHRoZSBwYXRjaGVzIHRoYXQg YWN0dWFsbHkgbWFrZSB1c2Ugb2YgaXQuDQoNClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25u w6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KU2lnbmVkLW9mZi1ieTogTXlreXRhIFBvdHVyYWkg PG15a3l0YV9wb3R1cmFpQGVwYW0uY29tPg0KLS0tDQp2MS0+djI6DQoqIG5ldyBwYXRjaA0KLS0t DQogeGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYyB8IDEyNSArKysrKysrKysrKysrKysrKysrKysr LS0tLS0tLS0tLS0tLS0tLQ0KIHhlbi9pbmNsdWRlL3hlbi92cGNpLmggICAgfCAgMTkgKysrKysr DQogMiBmaWxlcyBjaGFuZ2VkLCA5MCBpbnNlcnRpb25zKCspLCA1NCBkZWxldGlvbnMoLSkNCg0K ZGlmZiAtLWdpdCBhL3hlbi9kcml2ZXJzL3ZwY2kvaGVhZGVyLmMgYi94ZW4vZHJpdmVycy92cGNp L2hlYWRlci5jDQppbmRleCBjYjY0ZDliOWZjLi4yODQ5NjRmMGQ0IDEwMDY0NA0KLS0tIGEveGVu L2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0KKysrIGIveGVuL2RyaXZlcnMvdnBjaS9oZWFkZXIuYw0K QEAgLTE3NSw3NiArMTc1LDkyIEBAIHN0YXRpYyB2b2lkIG1vZGlmeV9kZWNvZGluZyhjb25zdCBz dHJ1Y3QgcGNpX2RldiAqcGRldiwgdWludDE2X3QgY21kLA0KIA0KIGJvb2wgdnBjaV9wcm9jZXNz X3BlbmRpbmcoc3RydWN0IHZjcHUgKnYpDQogew0KLSAgICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAq cGRldiA9IHYtPnZwY2kucGRldjsNCi0gICAgc3RydWN0IHZwY2lfaGVhZGVyICpoZWFkZXIgPSBO VUxMOw0KLSAgICB1bnNpZ25lZCBpbnQgaTsNCi0NCi0gICAgaWYgKCAhcGRldiApDQotICAgICAg ICByZXR1cm4gZmFsc2U7DQotDQotICAgIHJlYWRfbG9jaygmdi0+ZG9tYWluLT5wY2lfbG9jayk7 DQotDQotICAgIGlmICggIXBkZXYtPnZwY2kgfHwgKHYtPmRvbWFpbiAhPSBwZGV2LT5kb21haW4p ICkNCisgICAgc3dpdGNoICggdi0+dnBjaS50YXNrICkNCiAgICAgew0KLSAgICAgICAgdi0+dnBj aS5wZGV2ID0gTlVMTDsNCi0gICAgICAgIHJlYWRfdW5sb2NrKCZ2LT5kb21haW4tPnBjaV9sb2Nr KTsNCi0gICAgICAgIHJldHVybiBmYWxzZTsNCi0gICAgfQ0KLQ0KLSAgICBoZWFkZXIgPSAmcGRl di0+dnBjaS0+aGVhZGVyOw0KLSAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUoaGVhZGVy LT5iYXJzKTsgaSsrICkNCisgICAgY2FzZSBNT0RJRllfTUVNT1JZOg0KICAgICB7DQotICAgICAg ICBzdHJ1Y3QgdnBjaV9iYXIgKmJhciA9ICZoZWFkZXItPmJhcnNbaV07DQotICAgICAgICBzdHJ1 Y3QgcmFuZ2VzZXQgKm1lbSA9IHYtPnZwY2kuYmFyX21lbVtpXTsNCi0gICAgICAgIHN0cnVjdCBt YXBfZGF0YSBkYXRhID0gew0KLSAgICAgICAgICAgIC5kID0gdi0+ZG9tYWluLA0KLSAgICAgICAg ICAgIC5tYXAgPSB2LT52cGNpLmNtZCAmIFBDSV9DT01NQU5EX01FTU9SWSwNCi0gICAgICAgICAg ICAuYmFyID0gYmFyLA0KLSAgICAgICAgfTsNCi0gICAgICAgIGludCByYzsNCisgICAgICAgIGNv bnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2ID0gdi0+dnBjaS5tZW1vcnkucGRldjsNCisgICAgICAg IHN0cnVjdCB2cGNpX2hlYWRlciAqaGVhZGVyID0gTlVMTDsNCisgICAgICAgIHVuc2lnbmVkIGlu dCBpOw0KIA0KLSAgICAgICAgaWYgKCByYW5nZXNldF9pc19lbXB0eShtZW0pICkNCi0gICAgICAg ICAgICBjb250aW51ZTsNCisgICAgICAgIGlmICggIXBkZXYgKQ0KKyAgICAgICAgICAgIGJyZWFr Ow0KIA0KLSAgICAgICAgcmMgPSByYW5nZXNldF9jb25zdW1lX3JhbmdlcyhtZW0sIG1hcF9yYW5n ZSwgJmRhdGEpOw0KKyAgICAgICAgcmVhZF9sb2NrKCZ2LT5kb21haW4tPnBjaV9sb2NrKTsNCiAN Ci0gICAgICAgIGlmICggcmMgPT0gLUVSRVNUQVJUICkNCisgICAgICAgIGlmICggIXBkZXYtPnZw Y2kgfHwgKHYtPmRvbWFpbiAhPSBwZGV2LT5kb21haW4pICkNCiAgICAgICAgIHsNCisgICAgICAg ICAgICB2LT52cGNpLm1lbW9yeS5wZGV2ID0gTlVMTDsNCiAgICAgICAgICAgICByZWFkX3VubG9j aygmdi0+ZG9tYWluLT5wY2lfbG9jayk7DQotICAgICAgICAgICAgcmV0dXJuIHRydWU7DQorICAg ICAgICAgICAgYnJlYWs7DQogICAgICAgICB9DQogDQotICAgICAgICBpZiAoIHJjICkNCisgICAg ICAgIGhlYWRlciA9ICZwZGV2LT52cGNpLT5oZWFkZXI7DQorICAgICAgICBmb3IgKCBpID0gMDsg aSA8IEFSUkFZX1NJWkUoaGVhZGVyLT5iYXJzKTsgaSsrICkNCiAgICAgICAgIHsNCi0gICAgICAg ICAgICBzcGluX2xvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KLSAgICAgICAgICAgIC8qIERpc2Fi bGUgbWVtb3J5IGRlY29kaW5nIHVuY29uZGl0aW9uYWxseSBvbiBmYWlsdXJlLiAqLw0KLSAgICAg ICAgICAgIG1vZGlmeV9kZWNvZGluZyhwZGV2LCB2LT52cGNpLmNtZCAmIH5QQ0lfQ09NTUFORF9N RU1PUlksDQotICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZhbHNlKTsNCi0gICAgICAgICAg ICBzcGluX3VubG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQorICAgICAgICAgICAgc3RydWN0IHZw Y2lfYmFyICpiYXIgPSAmaGVhZGVyLT5iYXJzW2ldOw0KKyAgICAgICAgICAgIHN0cnVjdCByYW5n ZXNldCAqbWVtID0gdi0+dnBjaS5iYXJfbWVtW2ldOw0KKyAgICAgICAgICAgIHN0cnVjdCBtYXBf ZGF0YSBkYXRhID0gew0KKyAgICAgICAgICAgICAgICAuZCA9IHYtPmRvbWFpbiwNCisgICAgICAg ICAgICAgICAgLm1hcCA9IHYtPnZwY2kubWVtb3J5LmNtZCAmIFBDSV9DT01NQU5EX01FTU9SWSwN CisgICAgICAgICAgICAgICAgLmJhciA9IGJhciwNCisgICAgICAgICAgICB9Ow0KKyAgICAgICAg ICAgIGludCByYzsNCisNCisgICAgICAgICAgICBpZiAoIHJhbmdlc2V0X2lzX2VtcHR5KG1lbSkg KQ0KKyAgICAgICAgICAgICAgICBjb250aW51ZTsNCiANCi0gICAgICAgICAgICAvKiBDbGVhbiBh bGwgdGhlIHJhbmdlc2V0cyAqLw0KLSAgICAgICAgICAgIGZvciAoIGkgPSAwOyBpIDwgQVJSQVlf U0laRShoZWFkZXItPmJhcnMpOyBpKysgKQ0KLSAgICAgICAgICAgICAgICBpZiAoICFyYW5nZXNl dF9pc19lbXB0eSh2LT52cGNpLmJhcl9tZW1baV0pICkNCi0gICAgICAgICAgICAgICAgICAgICBy YW5nZXNldF9wdXJnZSh2LT52cGNpLmJhcl9tZW1baV0pOw0KKyAgICAgICAgICAgIHJjID0gcmFu Z2VzZXRfY29uc3VtZV9yYW5nZXMobWVtLCBtYXBfcmFuZ2UsICZkYXRhKTsNCiANCi0gICAgICAg ICAgICB2LT52cGNpLnBkZXYgPSBOVUxMOw0KKyAgICAgICAgICAgIGlmICggcmMgPT0gLUVSRVNU QVJUICkNCisgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgIHJlYWRfdW5sb2NrKCZ2LT5k b21haW4tPnBjaV9sb2NrKTsNCisgICAgICAgICAgICAgICAgcmV0dXJuIHRydWU7DQorICAgICAg ICAgICAgfQ0KIA0KLSAgICAgICAgICAgIHJlYWRfdW5sb2NrKCZ2LT5kb21haW4tPnBjaV9sb2Nr KTsNCisgICAgICAgICAgICBpZiAoIHJjICkNCisgICAgICAgICAgICB7DQorICAgICAgICAgICAg ICAgIHNwaW5fbG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQorICAgICAgICAgICAgICAgIC8qIERp c2FibGUgbWVtb3J5IGRlY29kaW5nIHVuY29uZGl0aW9uYWxseSBvbiBmYWlsdXJlLiAqLw0KKyAg ICAgICAgICAgICAgICBtb2RpZnlfZGVjb2RpbmcocGRldiwgdi0+dnBjaS5tZW1vcnkuY21kICYg flBDSV9DT01NQU5EX01FTU9SWSwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZh bHNlKTsNCisgICAgICAgICAgICAgICAgc3Bpbl91bmxvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0K Kw0KKyAgICAgICAgICAgICAgICAvKiBDbGVhbiBhbGwgdGhlIHJhbmdlc2V0cyAqLw0KKyAgICAg ICAgICAgICAgICBmb3IgKCBpID0gMDsgaSA8IEFSUkFZX1NJWkUoaGVhZGVyLT5iYXJzKTsgaSsr ICkNCisgICAgICAgICAgICAgICAgICAgIGlmICggIXJhbmdlc2V0X2lzX2VtcHR5KHYtPnZwY2ku YmFyX21lbVtpXSkgKQ0KKyAgICAgICAgICAgICAgICAgICAgICAgIHJhbmdlc2V0X3B1cmdlKHYt PnZwY2kuYmFyX21lbVtpXSk7DQorDQorICAgICAgICAgICAgICAgIHYtPnZwY2kubWVtb3J5LnBk ZXYgPSBOVUxMOw0KKw0KKyAgICAgICAgICAgICAgICByZWFkX3VubG9jaygmdi0+ZG9tYWluLT5w Y2lfbG9jayk7DQogDQotICAgICAgICAgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHYtPmRv bWFpbikgKQ0KLSAgICAgICAgICAgICAgICBkb21haW5fY3Jhc2godi0+ZG9tYWluKTsNCisgICAg ICAgICAgICAgICAgaWYgKCAhaXNfaGFyZHdhcmVfZG9tYWluKHYtPmRvbWFpbikgKQ0KKyAgICAg ICAgICAgICAgICAgICAgZG9tYWluX2NyYXNoKHYtPmRvbWFpbik7DQogDQotICAgICAgICAgICAg cmV0dXJuIGZhbHNlOw0KKyAgICAgICAgICAgICAgICBicmVhazsNCisgICAgICAgICAgICB9DQog ICAgICAgICB9DQotICAgIH0NCi0gICAgdi0+dnBjaS5wZGV2ID0gTlVMTDsNCisgICAgICAgIHYt PnZwY2kubWVtb3J5LnBkZXYgPSBOVUxMOw0KIA0KLSAgICBzcGluX2xvY2soJnBkZXYtPnZwY2kt PmxvY2spOw0KLSAgICBtb2RpZnlfZGVjb2RpbmcocGRldiwgdi0+dnBjaS5jbWQsIHYtPnZwY2ku cm9tX29ubHkpOw0KLSAgICBzcGluX3VubG9jaygmcGRldi0+dnBjaS0+bG9jayk7DQorICAgICAg ICBzcGluX2xvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KKyAgICAgICAgbW9kaWZ5X2RlY29kaW5n KHBkZXYsIHYtPnZwY2kubWVtb3J5LmNtZCwgdi0+dnBjaS5tZW1vcnkucm9tX29ubHkpOw0KKyAg ICAgICAgc3Bpbl91bmxvY2soJnBkZXYtPnZwY2ktPmxvY2spOw0KIA0KLSAgICByZWFkX3VubG9j aygmdi0+ZG9tYWluLT5wY2lfbG9jayk7DQorICAgICAgICByZWFkX3VubG9jaygmdi0+ZG9tYWlu LT5wY2lfbG9jayk7DQorDQorICAgICAgICBicmVhazsNCisgICAgfQ0KKyAgICBjYXNlIFdBSVQ6 DQorICAgICAgICBpZiAoIE5PVygpIDwgdi0+dnBjaS53YWl0LmVuZCApDQorICAgICAgICAgICAg cmV0dXJuIHRydWU7DQorICAgICAgICB2LT52cGNpLndhaXQuY2FsbGJhY2sodi0+dnBjaS53YWl0 LmRhdGEpOw0KKyAgICAgICAgYnJlYWs7DQorICAgIGNhc2UgTk9ORToNCisgICAgICAgIHJldHVy biBmYWxzZTsNCisgICAgfQ0KIA0KKyAgICB2LT52cGNpLnRhc2sgPSBOT05FOw0KICAgICByZXR1 cm4gZmFsc2U7DQogfQ0KIA0KQEAgLTI5NSw5ICszMTEsMTAgQEAgc3RhdGljIHZvaWQgZGVmZXJf bWFwKGNvbnN0IHN0cnVjdCBwY2lfZGV2ICpwZGV2LCB1aW50MTZfdCBjbWQsIGJvb2wgcm9tX29u bHkpDQogICAgICAqIGlzIG1hcHBlZC4gVGhpcyBjYW4gbGVhZCB0byBwYXJhbGxlbCBtYXBwaW5n IG9wZXJhdGlvbnMgYmVpbmcNCiAgICAgICogc3RhcnRlZCBmb3IgdGhlIHNhbWUgZGV2aWNlIGlm IHRoZSBkb21haW4gaXMgbm90IHdlbGwtYmVoYXZlZC4NCiAgICAgICovDQotICAgIGN1cnItPnZw Y2kucGRldiA9IHBkZXY7DQotICAgIGN1cnItPnZwY2kuY21kID0gY21kOw0KLSAgICBjdXJyLT52 cGNpLnJvbV9vbmx5ID0gcm9tX29ubHk7DQorICAgIGN1cnItPnZwY2kubWVtb3J5LnBkZXYgPSBw ZGV2Ow0KKyAgICBjdXJyLT52cGNpLm1lbW9yeS5jbWQgPSBjbWQ7DQorICAgIGN1cnItPnZwY2ku bWVtb3J5LnJvbV9vbmx5ID0gcm9tX29ubHk7DQorICAgIGN1cnItPnZwY2kudGFzayA9IE1PRElG WV9NRU1PUlk7DQogICAgIC8qDQogICAgICAqIFJhaXNlIGEgc2NoZWR1bGVyIHNvZnRpcnEgaW4g b3JkZXIgdG8gcHJldmVudCB0aGUgZ3Vlc3QgZnJvbSByZXN1bWluZw0KICAgICAgKiBleGVjdXRp b24gd2l0aCBwZW5kaW5nIG1hcHBpbmcgb3BlcmF0aW9ucywgdG8gdHJpZ2dlciB0aGUgaW52b2Nh dGlvbg0KZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3hlbi92cGNpLmggYi94ZW4vaW5jbHVkZS94 ZW4vdnBjaS5oDQppbmRleCBmYTY1NDU0NWU1Li40N2NkYjU0ZDQyIDEwMDY0NA0KLS0tIGEveGVu L2luY2x1ZGUveGVuL3ZwY2kuaA0KKysrIGIveGVuL2luY2x1ZGUveGVuL3ZwY2kuaA0KQEAgLTIx Miw3ICsyMTIsMjYgQEAgc3RydWN0IHZwY2lfdmNwdSB7DQogICAgIC8qIFBlci12Y3B1IHN0cnVj dHVyZSB0byBzdG9yZSBzdGF0ZSB3aGlsZSB7dW59bWFwcGluZyBvZiBQQ0kgQkFScy4gKi8NCiAg ICAgY29uc3Qgc3RydWN0IHBjaV9kZXYgKnBkZXY7DQogI2lmZGVmIF9fWEVOX18NCisgICAgZW51 bSB7DQorICAgICAgICBOT05FLA0KKyAgICAgICAgTU9ESUZZX01FTU9SWSwNCisgICAgICAgIFdB SVQsDQorICAgIH0gdGFzazsNCiAgICAgc3RydWN0IHJhbmdlc2V0ICpiYXJfbWVtW1BDSV9IRUFE RVJfTk9STUFMX05SX0JBUlMgKyAxXTsNCisgICAgdW5pb24gew0KKyAgICAgICAgc3RydWN0IHsN CisgICAgICAgICAgICAvKiBTdG9yZSBzdGF0ZSB3aGlsZSB7dW59bWFwcGluZyBvZiBQQ0kgQkFS cy4gKi8NCisgICAgICAgICAgICBjb25zdCBzdHJ1Y3QgcGNpX2RldiAqcGRldjsNCisgICAgICAg ICAgICB1aW50MTZfdCBjbWQ7DQorICAgICAgICAgICAgYm9vbCByb21fb25seSA6IDE7DQorICAg ICAgICB9IG1lbW9yeTsNCisgICAgICAgIHN0cnVjdCB7DQorICAgICAgICAgICAgLyogU3RvcmUg d2FpdCBzdGF0ZS4gKi8NCisgICAgICAgICAgICBzX3RpbWVfdCBlbmQ7DQorICAgICAgICAgICAg dm9pZCAoKmNhbGxiYWNrKSh2b2lkICopOw0KKyAgICAgICAgICAgIHZvaWQgKmRhdGE7DQorICAg ICAgICB9IHdhaXQ7DQorICAgIH07DQogI2VuZGlmDQogICAgIHVpbnQxNl90IGNtZDsNCiAgICAg Ym9vbCByb21fb25seSA6IDE7DQotLSANCjIuNTEuMg0K From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249280.1546796 (Exim 4.92) (envelope-from ) id 1vzYTb-0005BN-N0; Mon, 09 Mar 2026 11:08:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249280.1546796; Mon, 09 Mar 2026 11: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 ) id 1vzYTb-0005Aq-IG; Mon, 09 Mar 2026 11:08:43 +0000 Received: by outflank-mailman (input) for mailman id 1249280; Mon, 09 Mar 2026 11:08:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTZ-0003iR-UA for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:41 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 53a1cd69-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:39 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08: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%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 53a1cd69-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=umqdO+OX5PucfeKcvu4wVdnZsYjWf+IqS49sNdKVg+VPg7B90AQayl2p+Hh3hB+Pvxf/ifgBaRrUEeK4R3vcn/WHuByk69QzfUA4phNjmpGDscaC53D8afyoElkTW22zPMnruz29Q4Oe8mc2mAqWVIHGAqeI4vTDBFjojoKtMz08ZuVThlq7oYokrLWvWWqG26k0FSjDjpRnwZSPEmZfsIvEIaaOnTRdC2xPOVB3OncBTRoQ1MYhj0FRhNwdHKH8wQw9f5pesRN+Y/EMk5ZGUiL4e/cWOMPddtdhcHFa5NA8TjKQcRA4UXH2lMzqM01OTx4Kj2w++i97S5pW0siGrA== 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=YOUp/hM8Mfho1OBtuL27ZRMzjlpOJY9US27a6WY94g4=; b=eOF7p8Mp5YP0DvPVx71TGejxYorK5R30noHdTP8m+QukpePE/vJqHekPltSuZ9dSbaLMFq0EknZidAk5pS8vlryI/ZZsaGsnZSL9ddD7RBOAGGBqAXYpiqBW/FoaIhpR3OJv9MmP6M1QuQawXjz/wJQjy7RAlN/UwHb/eNxZQdSdshLM6UR+oeOWwromGi72KJGozZVWuslHBAEg1EPK3YiIAiE3WEFW3HVyVxuIoCgctKauqLRuTWHRd8H7YviL+g3NzXxxgziFrXaEEPEf2YtidNGLeYCABewmJxDgQTQI+TGCXM+x7GB0jeP9R+grd5h+T82BUMp5MnHcxPZdVw== 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=YOUp/hM8Mfho1OBtuL27ZRMzjlpOJY9US27a6WY94g4=; b=UnWdGs2MYb/G8XrKT98/qp1aCJF2wG/fuPc75Rd6vLIy9IsyzBmI2cKQG8STI7VEcYnMKH0jZ6DAMtdWS/lsi4ktg4rrSfKkcxk8TQ3Gixheqqd85cxpYnKb1kBh8t4PnroxWgSgIzGHNfGHtdwMsRxXG8O/7iOZfRdKm8nwWqH1jNlAtI0oc+rfnpcmZI1DVO4NEbTAljTRSnqjPlZsYnK76sAAatnWeDvaVvXhwG0ykI4avvkgnY0PEQkv1w3rQMviTmvbTvqpYGTpAfmRrlEsT2DRiiCx6bLN1KY+B1gH6KOHGIrKvvt9QYsmxSg0jFD9oe2GD41t/42LnfXGcA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: [PATCH v2 5/8] pci/iommu: Check that IOMMU supports removing devices Thread-Topic: [PATCH v2 5/8] pci/iommu: Check that IOMMU supports removing devices Thread-Index: AQHcr7UOnGwu40XXHUWWV8IGnIja1A== Date: Mon, 9 Mar 2026 11:08:27 +0000 Message-ID: <0ba0f0a8a7db5c762fa59e2eec627199c023f8b9.1772806036.git.mykyta_poturai@epam.com> References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: c684ad2a-66bb-428c-6f87-08de7dcc32c1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: AXXT3QIz7oRpjcsqQ0pFqIoWteZ+eX+KlnT4L3c9V9fNfJDJTfPg0OzSIlE474qZDJmN8pD2SQFYUS5pm4hWJze3YtSmOD1+URh4sffyoRu8Qd7qPSxBnCTbsir6S6rZhrW7Fy6F3/Fh2kzWi93DM11xR+M3myXHq0gGP0UMPjT/vT+WCiPzCrYf8GfuSTGFvzUx7poM9xe+s27mTDwzYYJl2hcQCqXvJfCIwCiCSVSebq00ryyhlDsw1Bnv3wtwV5KOmG8F6WdxIAvQlqBM3lVF6jjsmsgY6xs/2RBK1/0NdsGisdycRaUxuKKgdB9QKcRkJxnHcaIhE7jap6oEm4gQikg9NCZPsIqQTAQnlD9ZREbRMpTqQ4nr3KqJyyh6f9Z0gZoyFTluM400LFzzmQGyeccFKny3MJdeVcuVOld+qHzh1fa18axj3XpvsBBeraAsDMqXVe6UT9nEHD3ZnrlOnBX1rQtSq6qdIRDoU4ov46GQIqrPznHuOVtBLqDrfpoAFzXTX9dimpwgZ8gPxTf0whyWl+vCLdM7vDOY4Yf+gHtEQddob6s98VJsnEB1Kt6X5lzDatbqxF3oVQh9E6pkG3pZ94tnRlQCUxwl71+Qr5+tU7kb01DgFvnO2UW1jup4lpGIqJXhJMy0642sEyWG25Mo6uJXHuzuBAStdxljgyb+u1mcRC9mro7vnIPG3ceCLRX0Aepw4KMK/OkWeMvomCI09sbY4+FswT4cwTYZtIoxP+L4lIxuIo0gBTRtLkt91yxo9/3W4p/f6FU7Joi22+l7sQcvqT9wYDMpz4U= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Dr6A+9qrm8mFQwM5XB1Bx6nlB82GevkgQrkrChnnCWS7+0eoTKsO8VU/m0?= =?iso-8859-1?Q?FkdOlQ6kak+0NtS8++f18eVE3n4J4ow++SizF68QMn/9Yol2EL1YB2PPlF?= =?iso-8859-1?Q?TKyJpxttvTgophvM1zfwH/p66UoHLvsAV74mVP0WZ7Mw0Os2aztrNhZwqr?= =?iso-8859-1?Q?4YbmpWin3tbufTKrCN44IMcvpftth4/dxsC3J7EtmJVknVPt6pRzO1RFsr?= =?iso-8859-1?Q?BScS33HKxBOc1GK7zBuTP4iroIoLpREuM4mlSbRvbn8NV9w8tYK5tIaEw1?= =?iso-8859-1?Q?Sq4ko0XAfcVN9k4oYxHgHJ5Wv0ZXgZhivB3k0O66J33PZ6vHl+sFjDKvNp?= =?iso-8859-1?Q?eOiENj8jBbsUqOAhrGL/Uf5I94y5H7r+FoYNMb/vYLx1dXA2GXeVhj08H+?= =?iso-8859-1?Q?VqXR6F1Lz6hBmE48JVl1q3TOg6R2cMnFywcPhJhe1s/LdZmSdtn5vpdqXR?= =?iso-8859-1?Q?ni0odqy/OQAKTXhDLDtStUFBHtnE2BTa7Of877rgFPV1WFOp6JgXobDYUZ?= =?iso-8859-1?Q?J3mA006yd6re13VXcLdYTRhaQqtMMt27ryrPh+1WWy/Vpf06+yYYCUoP8W?= =?iso-8859-1?Q?ok5s5KePTnDU/gEbLGscLpUuD/5vH7H1udJVtmP8OULORV5IWhPnDkx0H7?= =?iso-8859-1?Q?xMrguCz5VrFtgmK2UHiF5/EK6vzBba1R0SsXgT4JLGRTcKtLzwUA1cg8mC?= =?iso-8859-1?Q?585PZ8aXzMvo8Ylq/MsnHyNxpASS3wP4+Mbl4bQETyS0uZ5MEaHSu5O4df?= =?iso-8859-1?Q?0U5TWH8t65g8g395bTRGxKbFWFGxrg1vxtvUd3D7bzzyPdWmjMvWdNqmq1?= =?iso-8859-1?Q?xGCEODTCSKzC62ekYOGgoTR9oEj3vauBxIyz5SyyEZPzH1qYoInMMLA3GX?= =?iso-8859-1?Q?sdCh+DINZ045OAZcCjJojJDItqIDwG7G6h1vFWfCiIfTSQi+43jSnNO6Va?= =?iso-8859-1?Q?w04bSDBB5LP69UgL7ytEiTUfEve/Mzby9hndB61viCiuyTAq5SPXAz9UxY?= =?iso-8859-1?Q?3WaxAIIBjpqosF7KxK9b4KqXcDCdYdDQ03vhcEYDOztooA3e2o+TJ446rA?= =?iso-8859-1?Q?fiGWh/yg5xfFlxo2yDozP6m7/c0FGbPXmh3YXpwk6f+KEkqFv9uVYHJi+S?= =?iso-8859-1?Q?8FFnHbrrK4bSRM/FnhojxY4CXr/tck/Q+PXplrLbVXAt/kTozwJArnNEi+?= =?iso-8859-1?Q?bbNFrI70a+pFXOvDXX8K4RBgrnSkFmbxTo/Jj1YnD1Smy3ODGK8/gOWLBe?= =?iso-8859-1?Q?AocqidWjgX2zL411v/Hl5lc3D1+YPZoe14m7WCzbzFWEOeH7DHHaENn3of?= =?iso-8859-1?Q?1js+Nph0+rvzkXZTHapoo9f1xlfoW8fpo/G157F5S2KLi24sh8rnYIHoY9?= =?iso-8859-1?Q?MTDTl5kaZdHrgpYtCuLQSMm3rfKFymLqUDMtSNWS4pg4XpWCagoze2X52Q?= =?iso-8859-1?Q?cKk8g86WgOrEpk0Rn57ntTCM4U6szcMiGQP3U6x4fda+wmDVwbHkBu946I?= =?iso-8859-1?Q?zLHkKm7MAJQxYfHFFP4TE7uW7hEA9tZsXCk9s0i0/Zyy9/A/tsQbPWnQV7?= =?iso-8859-1?Q?BfYQB0xZBDHjwX7B8xBZSSraxSEJilkvig0zuEfccYLqBNqd9z9x6z3dEz?= =?iso-8859-1?Q?aoVHERTU0lKzBAP+0ZOmlEouhYURkINfUOvFUaHB7C6TyItoZ7cA7fq6jT?= =?iso-8859-1?Q?3IPPNzW+aKLhHZgYkranl64LfH5VecrQb2qldbsN3nh8wH8fToqpPQYtTm?= =?iso-8859-1?Q?oYWO863cxr7rQNnzySlkbC7p50kRy4StN8KVTpXGgqSSdwTbUGSDdaKoiq?= =?iso-8859-1?Q?HZIpJjBQwL77H1vOJ8o5Dg0TV9lXrFQ=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: c684ad2a-66bb-428c-6f87-08de7dcc32c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:27.4268 (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: JnvUHuIWekIYrnFJeUMcgMYD6aJ4ohgGw9zI3gNqMsz0vwo9XvhikNeGn28edFsBLOhfV8cGoLb81UPrD2FGMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 before trying to remove them. Some IOMMU platforms, such as SMMU-V3 and IPMMU-VMSA don't support removing devices. Trying to call remove_device will result in a crash. So check that platform_ops have remove_device set before calling it. Signed-off-by: Mykyta Poturai --- v1->v2: * new patch --- xen/drivers/passthrough/pci.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c index 464bb0fee4..704eb6e19f 100644 --- a/xen/drivers/passthrough/pci.c +++ b/xen/drivers/passthrough/pci.c @@ -1545,6 +1545,12 @@ static int iommu_remove_device(struct pci_dev *pdev) if ( !is_iommu_enabled(pdev->domain) ) return 0; =20 + if ( !hd->platform_ops->remove_device ) + { + printk(XENLOG_ERR "IOMMU: remove_device not supported by platform\= n"); + return -EOPNOTSUPP; + } + for ( devfn =3D pdev->devfn ; pdev->phantom_stride; ) { int rc; --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249281.1546806 (Exim 4.92) (envelope-from ) id 1vzYTd-0005SE-1C; Mon, 09 Mar 2026 11:08:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249281.1546806; Mon, 09 Mar 2026 11:08:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTc-0005Ra-S1; Mon, 09 Mar 2026 11:08:44 +0000 Received: by outflank-mailman (input) for mailman id 1249281; Mon, 09 Mar 2026 11:08:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTa-0003iR-UV for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:42 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 53e0db43-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:40 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08:34 +0000 Received: from PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb]) by PAVPR03MB10102.eurprd03.prod.outlook.com ([fe80::b8c6:f37a:987a:beb%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 53e0db43-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jxWOtq7Ket8+vHZ1LjOEdZw9ahGNiYEpdifGh/lgGsUS4A8LYZ6UyoUgvBfDY+nKtGDHKAaq+t74o3p6LTvwZiMZGOMXd3DHTIp7/4RlWv8a8e9a5IouEnxbBLX6d/JJJoEUCHgjuv3yRQXwNm5XUl7zOFGiFfETR6YEqMgl4w0QZZmgjuX+zoNpWw+5E6xEeEMb9C5YWSNFhwD3pF7Sr7nLSUKaJnE9Z1JmbbB8g16OnU4SWBQUtSGgs9U1UlJOhyz32wc5kknmnYpClkNQBU3YmcgLahKn+FX/g6GNiXOKdJAKmBHClZD7R5z95XCum4ShWsvLd0LFyY6vmFPXIg== 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=IqQ9wzGtIwcLcpHstce4KsP+TKXKqpd4rz2ohRjKgNM=; b=vuo3GlXuAraeL20W61I3y0pWNfChfYlqv2AAyxDMJ4Dm25cc5CS5Eej3ByFoU2LiLSk4Iu79ECM113/dH82A94SFD24G4yquCWvrPMOiAybFKf3tXUuqOj0wh2JbhzCQLL9ROJuK9s/qU7uvQwsMBjfy/4sK+mn0i216YaaYBiKhB7Z/sQ9mW9f32xF5XDw7EeRsf6hv81nhOiBK0uN0loYz6CKH3WMok+AOpjLU7KzYyo8kPCNgXd9zj+KcolxrIyhSK+6Axz/RAaLyMhrnlefC9pMhwR93GOO5YSMqJsyw3eyuAbGIqqf4pInmIMhnbud16M2ckBKrXY2d52U1ag== 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=IqQ9wzGtIwcLcpHstce4KsP+TKXKqpd4rz2ohRjKgNM=; b=W57iWa9SEqPzaCtzjOuEnb6OKBC9o4weC9pzbAs12ZPhL4MF1AetZONY4T1zJGW3MG1PX2VLeIjINM9AAdS0ryoLb3nqg4wCPnXZbvEbPhUX+/vaau8Tl30OHQx8W8gd/7KdVdEQ6ge1TEpX3jWEdd9Q+SMHGcFCaM1XGCmjhshbQCMk797F/GxNmYo6S3uPDUOhbezbmP0sSrT/yXTIDmgJo7dDf23IX9rW7vKvR5yCa8LmyCuYzS/v9ewBSyZMySOe4dTwGJbeba2X1+FgDg0Tc40cr8J1hxP5ODFEthMob+j+iI3K4EaJVxIfwsqgvSdeynzEE+tRK9Z8LTSIrQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: [PATCH v2 8/8] docs: Update SR-IOV support status Thread-Topic: [PATCH v2 8/8] docs: Update SR-IOV support status Thread-Index: AQHcr7UOSOcW7ORQ4E6npAgqHkuyvg== Date: Mon, 9 Mar 2026 11:08:28 +0000 Message-ID: <955759c5a770a8be54b6e7ae020915c78576005a.1772806036.git.mykyta_poturai@epam.com> References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: ab6758fb-bd77-4c08-7f76-08de7dcc346d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: U8BY+OVTyQQHbwJSV5kZ3zhS0KgozOBhG5hs6OoiV7pTvl8C/SL4VyXljcZlhMDHFJd8Xtly3eqirOudMscRKCLGPcnX4tOb6gM8l/A66m29DHSyJj/WYZXrSDN52aLyxCRCKKrqT0pZ8BbMLfukPU9HQovHxPzpoyLL2zs3tZMRGAL8Zcp0Es3AhJ5K5D8TSAeGE7Ngs0C/eukTJPTyQc7U+4ypgu+wIWkXYk3UdnbxI/uP6WnExvBtazZlg5o1n2FdZzqphrordaSiMPD+1aX23py7cHEcW9ncEQPprAbTgQ2c/m9c/NMBHEfdaE9Z5Y2c+j2pbOY/e12b5MnJKzB6alYTV0Bm6YI8+LxjiNS+ik/jPJFUdH6OAUucf3DD8gFb86Fce6KnJiwUdNBS4wHmJ/Ig2xswAk62JRz+xusJfwMCr5ddpGfsjQyP4UvQ3wh37t+P3tM9/62N+tF2O7dR075AKLbKaMJD/hTEsSjvceATTYavyDK21arUU7PPL+BRKYFoN1QQ3Hnjl8DWPMJxeAFR8FDXtzzxSjMm75hm82zArBgmPAxy+Q9iZho6e0m22VyeoJhCsJhs6dbTrQaIQE3z6j3bdUsMnKFIa2rzH0IFFL7iauv58Mw1xMUzWiPqveU4J+Qeb31D548jXPxDyxRcrFnsWTxC9CDGwYoGUrbrqkIxSBQWFtg4ZERre6pZWUjN4cJfxkvVUPe5TVIyw/y2GAwebgjMeIRVocOf16VOxtZG+B5Zf5PtruqIn9N707JxQ+YnAvqL5mjtIFS3KItTcTDWtmvW39W4Cl0= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?HpRAy9xWLFZhyTlImjxTAzMMHIaBc80VZlvSia/5WdWvi7aokfQXm5bzbk?= =?iso-8859-1?Q?mX1pHzSi5qK7IYWu2/BTTLhYawBkZBQFWDUHRMmU8aubobClzC7X5DS/eU?= =?iso-8859-1?Q?NkrOX9wzznBwlyJv2qENWdrZSN5Q61qf9SM3kE99760RbGQi2cmMOFpTnU?= =?iso-8859-1?Q?OnsgGUBkB/7Cnr1sNVMRhvbdFsUrlJ34v6GB6k5K0w8TngbeTazN8pRfwC?= =?iso-8859-1?Q?tfktw3t4rYbdpuyrVEnh5J6RUZkHB3U56SLwRPop4qRIOkukgm/H1Rb6Qt?= =?iso-8859-1?Q?VfcG9Vk6+UZuzaolEfQTSlfGQNTlH3s0Z/e4+9pdTGt651ODAeObXg3pSk?= =?iso-8859-1?Q?b+U9aAttoOZo+ZnAN3Rz05RaNep8EPsl45BONFd8nOCurOfGbolRcwN6FE?= =?iso-8859-1?Q?bn7/a0YVDe4011MCX4D/CLeA6TLpuyhGX9GOQoLsMZ/hJ1QGIM55LpVvdi?= =?iso-8859-1?Q?i7Fnyni2XwBf4cRiRCzAZhYoI1pTxMmbv1CSp4QU4+iCsJys62NF8POrxC?= =?iso-8859-1?Q?/d30JZr3U3e3OWe4tCvkpdmQxXw3xtjihnoS1OD5zkEdoMXESgFtuBgoDp?= =?iso-8859-1?Q?PbPMvwqqY5uNOANMI5U0bYlYZOcyiWKmnvLJQimNfBegdcMaUeo35FpxDo?= =?iso-8859-1?Q?5DW0GnN/TxxGtpp5RCksonRZLM/khe377X9L89wdUYsemS3/8GIL4sb2jZ?= =?iso-8859-1?Q?eBXaeaKBUhmewrS5hKWOgBT3WgR+JTyXny+I0pQ9lN4398B8FI+4ZuszjP?= =?iso-8859-1?Q?d5mL1mFITlED6k/nIjaskR4dRmuIlUprzO9MVd7htz9x3LrBxiujlgM/iV?= =?iso-8859-1?Q?DF1GH4JtQPFj0JcpeSUM9Hg7wZSlbPLl/gtvUZMKh4r9fT3DIiSqO37Con?= =?iso-8859-1?Q?+wLZrdvhaV9HRWb2rRM1nosv6kJoLpMiyMroKjglxFWsJv0SkLziLq9/sX?= =?iso-8859-1?Q?xnmfIcPNcUN6dks3+eNBVQIpLhSXgeY2OABVI8jlp+j6rBURttTx7vdtQA?= =?iso-8859-1?Q?49LrPBY/hqmbQiAuhYlt1Tyd+J34AxXS3e41Wzw7YuGLcvu4ZmXRKOcRNB?= =?iso-8859-1?Q?i6pBhlVQEa/q88m+JhN/cauOTJHcrxdV2FDf/YdHpYjtwM6rnlaW8bpYfx?= =?iso-8859-1?Q?R+rN5XvDd5VmmjLTZ5q42P3FvW09nO/z0ZQt7fVY2Baa5hahVNBuX8uK8Z?= =?iso-8859-1?Q?Z7owXDQ0pMs89cxf2PBoV0gglbJUyyuqZsrSRCQ4edB2eLe9IdMytw+K/D?= =?iso-8859-1?Q?evcdepVrvGMgGt+anrlCMheBSuogwsDcIKvGjxsLUg0XVHqho8Skd8zb+C?= =?iso-8859-1?Q?JhSkxow8NaWiRpR5gh77MBIn67zqN2VNH0Cbjw85rmXa0LoSYxmfNeC5kP?= =?iso-8859-1?Q?SGMdT3DB+flWDt17koFHv0gPpIME8wTTDxosNS20mALu3zZU92OsCKtqCk?= =?iso-8859-1?Q?YRg7BQgfWsmeNK0X3pbe/iY/GULWMyIPSp0N6e5TEzSng8HRXNEhQNJDNE?= =?iso-8859-1?Q?YJ64IftVlSBEW6HX120IAwbyj9yzWSVzQOka0gpQTikiTgAVss2nBfurE+?= =?iso-8859-1?Q?1N9463YE+b2h+P6rgonBEO3K86+gtCOSojkINcrDwe4JJvaLSPjK7/oCZG?= =?iso-8859-1?Q?8QdD+r/yv6/C18LO8qKzV62s1TknsPHMkeQGqLJQkrHd2dIRgM0X86QAPW?= =?iso-8859-1?Q?42IFBfmiOUlhowJZ8l1d8sobbmhYxGhhJZAAb/q8dC1mx30iy5kyAxDEg+?= =?iso-8859-1?Q?+nxaMQvEUgo3PFYZJnDsX12cSQA//2Pugj2NLKiJyN1Y6XttYn/sVLpnsY?= =?iso-8859-1?Q?1nyPqHG70vv9qdIJjf+DAKK+0LbY8c0=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: ab6758fb-bd77-4c08-7f76-08de7dcc346d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:28.6501 (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: MwmSREvtmI4/tGJs/xbNq0uQQsHq9KAnOQHmoE5+rJon2T7bonKvu3Hduy/Wg+LE9nNH7KuT7FJRQHQ+bqFyvw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 Signed-off-by: Mykyta Poturai --- v1->v2: * new patch --- SUPPORT.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/SUPPORT.md b/SUPPORT.md index d441bccf37..c01853fe7e 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -170,8 +170,6 @@ unexpected behavior or issues on some hardware. =20 At least the following features are missing on a PVH dom0: =20 - * PCI SR-IOV. - * Native NMI forwarding (nmi=3Ddom0 command line option). =20 * MCE handling. --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 11:08:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 11:08:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249282.1546811 (Exim 4.92) (envelope-from ) id 1vzYTd-0005Z8-ML; Mon, 09 Mar 2026 11:08:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249282.1546811; Mon, 09 Mar 2026 11:08:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTd-0005Y4-EW; Mon, 09 Mar 2026 11:08:45 +0000 Received: by outflank-mailman (input) for mailman id 1249282; Mon, 09 Mar 2026 11:08:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzYTb-0003iR-Ui for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 11:08:44 +0000 Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c207::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 54167cf5-1ba8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 12:08:40 +0100 (CET) Received: from PAVPR03MB10102.eurprd03.prod.outlook.com (2603:10a6:102:30d::12) by AS2PR03MB9695.eurprd03.prod.outlook.com (2603:10a6:20b:60d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 11:08: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%5]) with mapi id 15.20.9678.020; Mon, 9 Mar 2026 11:08:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 54167cf5-1ba8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ufKkM76nCFoPrt5Nn8II0vupQM7nW/336xjv7ote/dWX1jCAEb+FUlBOww6D/nRnlSP9tgza5euNjWkJy7SuCPHBC42g+hZ+rVVzaafrdSd3aXlAlR9JY2LwVSpE4jST4vo0hGZ1uCWNWQL9qqOB+hPBfcG3c4evtbG1g6TelD9k/Iy+QvRmG7cQB6eaWs0N7T5KUcuj/M0ThNe1+IIkAlg8jKN1hheOBznmnK5ONJWfUdNLW5lX4DXq9/IoVoXm0a6i0LDmSXMjlW27vmYZs2bIR+kZ/QdP86YW+0Yh35B3eaK2CQGeq3j7unaPM+mA9r480SOPc9yEv9CzUYD8Lw== 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=lcvxHQYqTk81Exw11I8k3Jy5Hv2/V72aWoUK5BU4wB4=; b=mN8JHW05k2jAsw76jSA4mNSFSLtzHXVfoOrkLgaugGJipBe18LPeGUGmhazMaCP0zC9sHb4/ZY7JNldSCMDKXXGz0/UbQUb7EMTo2A1NzeZ+/qZ/UDl1Y4kVug23m7chgT0/Cbiehq0MuXsAn3g+ZNkyQ7kWZzFmHB6XZyEzPJlJbeT/yQmtj0obZA5WQds3dpQLsL84k94076O1N3s6obHNS0qpdu5FdSlyrKCi3Nu4/nstkovJRgWwxS+HpcdDXFtx+ubc47ZUSAFQGXDJRp1zPfHiJOGbp8YdvauvRwxjEimAI+wbzCrVVQlNI06Wi8w2kFZ8uyyp/YzIIUh8Zw== 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=lcvxHQYqTk81Exw11I8k3Jy5Hv2/V72aWoUK5BU4wB4=; b=AclPR2nCcBzYHoAcRYSokkEwWghc+D66VDw0SrktIt1283aZ0eQT8Ii41ZfanK6NlKBrqOJIgt+i7n7s8Y/HpuI0SMRUlfIIALMFEih8kMl2lI+OLfkhaWFhcRCQimkBGYCkEoCBEnNlV2MZvOkdIxQm1o+khaLHSaz2rAfmmbXKeh+YAFBJzwUvtVW0O1NB9vrBh1Nam/HaB16jqhBDwQ3PkAH50sGp5KWtLzf5Zv40OuTcIJ8pRpWW4jLjU8zlG+3zaDpJzMpFqHGXMCjRyRazMVL2lkky2OWhEQKnVptd5JT1Ml8tqsVaX3a6FEfLOkSrOsBl9xe92EtlEohEQg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini , Stewart Hildebrand Subject: [PATCH v2 3/8] vpci: Use pervcpu ranges for BAR mapping Thread-Topic: [PATCH v2 3/8] vpci: Use pervcpu ranges for BAR mapping Thread-Index: AQHcr7UNO3bwYqCdZkmfzVSjd86SfA== Date: Mon, 9 Mar 2026 11:08:26 +0000 Message-ID: <43ce584a124f0bd07e641934e15e5ab56548e1ba.1772806036.git.mykyta_poturai@epam.com> References: In-Reply-To: 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_|AS2PR03MB9695:EE_ x-ms-office365-filtering-correlation-id: c0ae7012-27d0-4fa2-b807-08de7dcc3252 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|38070700021; x-microsoft-antispam-message-info: VNTL2Y5weYB5w5gs2pnkOUmxLsZO4RZe41Or3CD8FPQYOdnQrT9c1YD88R+lbtnFX43mKxY9N2OTA66yE5HJ1KsB8MeUdwFYSRRVnSKuAYm3l3UoCgr4iQLF33HHldNqV7hOvqH7eZov+YW2LA7ZklXea/DpO0PPqHSE8UXTAOFE01JRTHJmyzP6qxcclQq6ltClMc72JQ1GmrhJlwdl6Tz1yglC2lOEcpEyxCbYUy+KLnSztlz4TI5lf3aExlZSHB01eGg70GreP76bGGAEr+KAa4HoJ1ATWetF1ppiMRBqR3KbF1SPCSKIuQY3Ck9NqlvKhOPmEjJq6+3uiAtSV56VS5eoBsf/GwA3Uy6vrjTjNQBMSMSB221+thbqKBKZ3zj1RmzDryx4RcpDSEQoEqqn7a7VXAK633FwHXnj28wPwiJknMWmaYuOtHiKk08a9+KyJV1bjt8uEKWmTIRIm3cLFsRe6JrjSDaUl9LukexVYfWizc6V5RGp8w3J64yQb5ptDP+4jjMq1gTwpO0tGODZfj9yZaDq7H79hgyG5BITA8Hbpts7dNnKNz0b9eTmb9QDC9IYhvFuCJMCe6Kq0zZ2dem2sJ50c18duICIN7pSuoFPjrsmzYjHPKub6dhlmZlKCOy/MMynFWYTraeBKCM5DL1b3lPmfZa9aG8WQ8xpRozzstDdBSWFwvrdfOlV6oraSBvOsKZLBTXFn+U98TPAX92Yo5dRa9PMZT9HAqzYiYRelCNFhhGjKeNmJbFJIED6wWS/+S8SXm1+TO9u5CQDTTofWtXblNBWn4UOvrk= 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)(366016)(376014)(1800799024)(38070700021);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?q2DbLmAQC1qUooapjiJkp0rfFBwH97vOEOJyEtZPwGq1gBvbvYdDmNi9PE?= =?iso-8859-1?Q?plJ99S5TfoEuejISpnhV5QdnxKcQqXGpI4cHb3MvqP9ZKnAnbc27R83x5A?= =?iso-8859-1?Q?7FdLNRlL2NpOuxQ4gTwnGE2VgH3+WKH63AprLfO1/lVVSDAJLd/pr7LC1W?= =?iso-8859-1?Q?Jrvz7d6QKuEDJOoyUsjkJf7C0qzK3f4npZgXfo0pofEvV00Z/jzCqSoulK?= =?iso-8859-1?Q?hDTC8yUgVYn74yLgNDpOg3XHt20qlvJKFFibfAS3BW48Z3T0jOQPfIcpRO?= =?iso-8859-1?Q?+/5gQQkgI/3My+84ljsDG+toI9vIXLkhzcM/X432gUOYu7q/MjnzSSsppx?= =?iso-8859-1?Q?WsCEV/h/BQAWXisIevHQ1ImBfWnDX2RSBSovCCsPfNEfSwNy93zwuCCTnq?= =?iso-8859-1?Q?2/uLEmJVk02WoCZPZ00kgI7GCEI2wAM+ne2FhY4GkOffkM0T2mIXzh1arp?= =?iso-8859-1?Q?IjLbr//8FZGj+B5VgWAHklR/wEghmj1xJ4vC9r76tb6pYwu7fwMN6f4GZ2?= =?iso-8859-1?Q?iXO01l7Jp8sODHhGPylBy12UJLRkkQbAeCYCE747y6zxabvEpMIUccIDSq?= =?iso-8859-1?Q?OfIIcW7h69HqqOF1CVyXWT8fFdNGknMiB1cUXFiUzMDihJWxi05p0wDkLN?= =?iso-8859-1?Q?SEbgYzrf3eXQj5TbQk4S8FhnTuZBoSCNgQb1wgKuiuJ1Zew+PhE0c37BqT?= =?iso-8859-1?Q?IuoaN9oV4Rf2z87Ly7aztX2Mst+5irxniuXWbI2wNSvL8qn0Tt+KLy+J6a?= =?iso-8859-1?Q?kNxV1TW/npgxeUPbFfRp7DzBfAgEwmlGSwVmakoLfX3m2X8A9Pv5N+MxXh?= =?iso-8859-1?Q?VZ7WNcuw3dGqX7YUYsRgnmH0VIbwa7O1XqbM7FJ8UbGfnsW+CHrikXF9kY?= =?iso-8859-1?Q?RxqFURv976dRhbwLSOIpeH9HOgTfRrVl4lzoNPK8NKg2XvWazDmoqMkgM9?= =?iso-8859-1?Q?cL+E+O1ym/WqdjKx563zIkte6UA3dM+fmKmBJvr6H+zgl5TvXVSwRXr5kt?= =?iso-8859-1?Q?owjotReVRy0l9EqmbHDFlVKRAL2BJQYcKw/mdQBoWJc9DNzopbJvKTIM+g?= =?iso-8859-1?Q?atmj3IuvITbOEf+bZj5DRbdfn/HQxqOOcV16JHJT/sJcfgF+j3ef57rSf4?= =?iso-8859-1?Q?VPND6G+6+xLh4Q9ytOfquQMgtPTDhLrZzJ07fNxLlThYdigpCHpVG2Cimi?= =?iso-8859-1?Q?0PfTVo8pHIBSjNBTsFMw2bTgUPHgE43CGVP4qbFsTI0rIv+h0RKmaPWdsq?= =?iso-8859-1?Q?E72GJBzDOWr8p5AyViPrCuHFGChRCNOq3AmtPDWZ/4hiAnMEvO7/52syP1?= =?iso-8859-1?Q?/TlwoBvaSn9N+qmbnTmJBNAptIdh55s4/pTYP4Hn0Pz4Ik167kz4AGjxFe?= =?iso-8859-1?Q?LVivL4uj97Sm0XKbPulbuM4R8yS3YqsIWg2L9sxxcH13blM2ZvUhlWuK7z?= =?iso-8859-1?Q?vtZg7wbNoQXGeNscN38eGMdKNRHIexQ7vFTjKKeub6E0WqkWI3mGpZA1zJ?= =?iso-8859-1?Q?pQ/bDZdB5Ystzpnumq3C5jLH/R+kja+TSyvWddR84qnOrAd9EB4t4L2+hJ?= =?iso-8859-1?Q?0MNQ+ZBmrrE+0mzAeJJaXDv+OCqP1xAy/Vo/q+8G2w4IZuNEExUyTEJtTZ?= =?iso-8859-1?Q?ZyDrZr/ZIXRzt7c7QCvLsDBFDaebAFJqMxwJ3058FHSN78m7CxcLufSIRM?= =?iso-8859-1?Q?X+6MS35BBDJ8lySTo3hxSbuJqN3Udc0xkG6EMb2ZImVXuP9z5tGFcHaF/Z?= =?iso-8859-1?Q?DPnF3uHd0/P3toJg5TfjjOVoHBjYbI/1d//7tjqVQZV8NDR+pr72AgS2Ky?= =?iso-8859-1?Q?EyGtafCu53X38MKgDep3Pn1p8XVBRK4=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: c0ae7012-27d0-4fa2-b807-08de7dcc3252 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 11:08:26.5055 (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: eLbz4qPsJRc/HbrUPT1Xz/A5Ny+whi4Npp/OF4pyateOeuH6YOUVL/gICYaDdbjIINrbqlxJNDwLsmU3mBtL4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9695 There is no need to store ranges for each PCI device, as they are only used during the mapping/unmapping process and can be reused for each device. This also allows to avoid the need to allocate and destroy rangesets for each device. Signed-off-by: Mykyta Poturai --- v1->v2: * new patch --- xen/common/domain.c | 24 ++++++++++++++ xen/drivers/vpci/header.c | 66 ++++++++++++++------------------------- xen/drivers/vpci/vpci.c | 3 -- xen/include/xen/vpci.h | 4 ++- 4 files changed, 51 insertions(+), 46 deletions(-) diff --git a/xen/common/domain.c b/xen/common/domain.c index e06174fca7..76b0163616 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -454,6 +454,14 @@ static int vcpu_teardown(struct vcpu *v) */ static void vcpu_destroy(struct vcpu *v) { +#ifdef CONFIG_HAS_VPCI + int i; + + for ( i =3D 0; i < ARRAY_SIZE(v->vpci.bar_mem); i++ ) + if ( v->vpci.bar_mem[i] ) + rangeset_destroy(v->vpci.bar_mem[i]); + +#endif free_vcpu_struct(v); } =20 @@ -511,6 +519,22 @@ struct vcpu *vcpu_create(struct domain *d, unsigned in= t vcpu_id) if ( arch_vcpu_create(v) !=3D 0 ) goto fail_sched; =20 +#ifdef CONFIG_HAS_VPCI + { + int i; + + for ( i =3D 0; i < ARRAY_SIZE(v->vpci.bar_mem); i++ ) + { + char str[32]; + + snprintf(str, sizeof(str), "%pv:BAR%u", v, i); + v->vpci.bar_mem[i] =3D rangeset_new(d, str, RANGESETF_no_print= ); + if ( !v->vpci.bar_mem[i] ) + goto fail_sched; + } + } +#endif + d->vcpu[vcpu_id] =3D v; if ( vcpu_id !=3D 0 ) { diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 07ec991a12..cb64d9b9fc 100644 --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -195,6 +195,7 @@ bool vpci_process_pending(struct vcpu *v) for ( i =3D 0; i < ARRAY_SIZE(header->bars); i++ ) { struct vpci_bar *bar =3D &header->bars[i]; + struct rangeset *mem =3D v->vpci.bar_mem[i]; struct map_data data =3D { .d =3D v->domain, .map =3D v->vpci.cmd & PCI_COMMAND_MEMORY, @@ -202,10 +203,10 @@ bool vpci_process_pending(struct vcpu *v) }; int rc; =20 - if ( rangeset_is_empty(bar->mem) ) + if ( rangeset_is_empty(mem) ) continue; =20 - rc =3D rangeset_consume_ranges(bar->mem, map_range, &data); + rc =3D rangeset_consume_ranges(mem, map_range, &data); =20 if ( rc =3D=3D -ERESTART ) { @@ -223,8 +224,8 @@ bool vpci_process_pending(struct vcpu *v) =20 /* Clean all the rangesets */ for ( i =3D 0; i < ARRAY_SIZE(header->bars); i++ ) - if ( !rangeset_is_empty(header->bars[i].mem) ) - rangeset_purge(header->bars[i].mem); + if ( !rangeset_is_empty(v->vpci.bar_mem[i]) ) + rangeset_purge(v->vpci.bar_mem[i]); =20 v->vpci.pdev =3D NULL; =20 @@ -259,13 +260,14 @@ static int __init apply_map(struct domain *d, const s= truct pci_dev *pdev, for ( i =3D 0; i < ARRAY_SIZE(header->bars); i++ ) { struct vpci_bar *bar =3D &header->bars[i]; + struct rangeset *mem =3D current->vpci.bar_mem[i]; struct map_data data =3D { .d =3D d, .map =3D true, .bar =3D bar }= ; =20 - if ( rangeset_is_empty(bar->mem) ) + if ( rangeset_is_empty(mem) ) continue; =20 - while ( (rc =3D rangeset_consume_ranges(bar->mem, map_range, - &data)) =3D=3D -ERESTART ) + while ( (rc =3D rangeset_consume_ranges(mem, map_range, &data)) = =3D=3D + -ERESTART ) { /* * It's safe to drop and reacquire the lock in this context @@ -330,12 +332,13 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint= 16_t cmd, bool rom_only) for ( i =3D 0; i < ARRAY_SIZE(header->bars); i++ ) { struct vpci_bar *bar =3D &header->bars[i]; + struct rangeset *mem =3D current->vpci.bar_mem[i]; unsigned long start =3D PFN_DOWN(bar->addr); unsigned long end =3D PFN_DOWN(bar->addr + bar->size - 1); unsigned long start_guest =3D PFN_DOWN(bar->guest_addr); unsigned long end_guest =3D PFN_DOWN(bar->guest_addr + bar->size -= 1); =20 - if ( !bar->mem ) + if ( !mem ) continue; =20 if ( !MAPPABLE_BAR(bar) || @@ -353,7 +356,7 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16= _t cmd, bool rom_only) continue; } =20 - ASSERT(rangeset_is_empty(bar->mem)); + ASSERT(rangeset_is_empty(mem)); =20 /* * Make sure that the guest set address has the same page offset @@ -368,7 +371,7 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16= _t cmd, bool rom_only) return -EINVAL; } =20 - rc =3D rangeset_add_range(bar->mem, start_guest, end_guest); + rc =3D rangeset_add_range(mem, start_guest, end_guest); if ( rc ) { printk(XENLOG_G_WARNING "Failed to add [%lx, %lx]: %d\n", @@ -379,12 +382,12 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint= 16_t cmd, bool rom_only) /* Check for overlap with the already setup BAR ranges. */ for ( j =3D 0; j < i; j++ ) { - struct vpci_bar *prev_bar =3D &header->bars[j]; + struct rangeset *prev_mem =3D current->vpci.bar_mem[j]; =20 - if ( rangeset_is_empty(prev_bar->mem) ) + if ( rangeset_is_empty(prev_mem) ) continue; =20 - rc =3D rangeset_remove_range(prev_bar->mem, start_guest, end_g= uest); + rc =3D rangeset_remove_range(prev_mem, start_guest, end_guest)= ; if ( rc ) { gprintk(XENLOG_WARNING, @@ -394,7 +397,7 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16= _t cmd, bool rom_only) } } =20 - rc =3D pci_sanitize_bar_memory(bar->mem); + rc =3D pci_sanitize_bar_memory(mem); if ( rc ) { gprintk(XENLOG_WARNING, @@ -411,14 +414,14 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint= 16_t cmd, bool rom_only) unsigned long end =3D PFN_DOWN(vmsix_table_addr(pdev->vpci, i) + vmsix_table_size(pdev->vpci, i) - 1); =20 - for ( j =3D 0; j < ARRAY_SIZE(header->bars); j++ ) + for ( j =3D 0; j < ARRAY_SIZE(current->vpci.bar_mem); j++ ) { - const struct vpci_bar *bar =3D &header->bars[j]; + struct rangeset *mem =3D current->vpci.bar_mem[j]; =20 - if ( rangeset_is_empty(bar->mem) ) + if ( rangeset_is_empty(mem) ) continue; =20 - rc =3D rangeset_remove_range(bar->mem, start, end); + rc =3D rangeset_remove_range(mem, start, end); if ( rc ) { gprintk(XENLOG_WARNING, @@ -468,8 +471,9 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16= _t cmd, bool rom_only) for ( j =3D 0; j < ARRAY_SIZE(header->bars); j++) { const struct vpci_bar *bar =3D &header->bars[j]; + struct rangeset *mem =3D current->vpci.bar_mem[j]; =20 - if ( !rangeset_overlaps_range(bar->mem, start, end) || + if ( !rangeset_overlaps_range(mem, start, end) || /* * If only the ROM enable bit is toggled check ag= ainst * other BARs in the same device for overlaps, bu= t not @@ -480,7 +484,7 @@ int vpci_modify_bars(const struct pci_dev *pdev, uint16= _t cmd, bool rom_only) bar->type =3D=3D VPCI_BAR_ROM) ) continue; =20 - rc =3D rangeset_remove_range(bar->mem, start, end); + rc =3D rangeset_remove_range(mem, start, end); if ( rc ) { gprintk(XENLOG_WARNING, @@ -733,18 +737,6 @@ static void cf_check rom_write( } } =20 -static int bar_add_rangeset(const struct pci_dev *pdev, struct vpci_bar *b= ar, - unsigned int i) -{ - char str[32]; - - snprintf(str, sizeof(str), "%pp:BAR%u", &pdev->sbdf, i); - - bar->mem =3D rangeset_new(pdev->domain, str, RANGESETF_no_print); - - return !bar->mem ? -ENOMEM : 0; -} - static int vpci_init_capability_list(struct pci_dev *pdev) { int rc; @@ -989,10 +981,6 @@ int vpci_init_header(struct pci_dev *pdev) else bars[i].type =3D VPCI_BAR_MEM32; =20 - rc =3D bar_add_rangeset(pdev, &bars[i], i); - if ( rc ) - goto fail; - rc =3D pci_size_mem_bar(pdev->sbdf, reg, &addr, &size, (i =3D=3D num_bars - 1) ? PCI_BAR_LAST : 0); if ( rc < 0 ) @@ -1046,12 +1034,6 @@ int vpci_init_header(struct pci_dev *pdev) 4, rom); if ( rc ) rom->type =3D VPCI_BAR_EMPTY; - else - { - rc =3D bar_add_rangeset(pdev, rom, num_bars); - if ( rc ) - goto fail; - } } else if ( !is_hwdom ) { diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c index f66f50c8ba..af61b521b0 100644 --- a/xen/drivers/vpci/vpci.c +++ b/xen/drivers/vpci/vpci.c @@ -357,9 +357,6 @@ void vpci_deassign_device(struct pci_dev *pdev) } spin_unlock(&pdev->vpci->lock); =20 - for ( i =3D 0; i < ARRAY_SIZE(pdev->vpci->header.bars); i++ ) - rangeset_destroy(pdev->vpci->header.bars[i].mem); - xfree(pdev->vpci); pdev->vpci =3D NULL; } diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h index dd233b8b03..fa654545e5 100644 --- a/xen/include/xen/vpci.h +++ b/xen/include/xen/vpci.h @@ -118,7 +118,6 @@ struct vpci { uint64_t guest_addr; uint64_t size; uint64_t resizable_sizes; - struct rangeset *mem; enum { VPCI_BAR_EMPTY, VPCI_BAR_IO, @@ -212,6 +211,9 @@ struct vpci { struct vpci_vcpu { /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */ const struct pci_dev *pdev; +#ifdef __XEN__ + struct rangeset *bar_mem[PCI_HEADER_NORMAL_NR_BARS + 1]; +#endif uint16_t cmd; bool rom_only : 1; }; --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:18:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:18:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249369.1546836 (Exim 4.92) (envelope-from ) id 1vzZYa-0001L3-Sl; Mon, 09 Mar 2026 12:17:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249369.1546836; Mon, 09 Mar 2026 12: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 ) id 1vzZYa-0001Kr-Pl; Mon, 09 Mar 2026 12:17:56 +0000 Received: by outflank-mailman (input) for mailman id 1249369; Mon, 09 Mar 2026 12:17:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZYZ-0001Jp-Ix for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:17:55 +0000 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fe727f8e-1bb1-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 13:17:52 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id 88508EC0273; Mon, 9 Mar 2026 08:17:51 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 09 Mar 2026 08:17:51 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Mar 2026 08:17:50 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe727f8e-1bb1-11f1-b164-2bf370ae4941 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=fm1; t=1773058671; x=1773145071; bh=xqkqiee5wa QOwJic/qsVej/NyQDtai116ygtpOvqQAM=; b=Sma89FvAZfg+PfEybOMR7l/fwT rxENHYi4ncZEa/Cg+/5PzFbUUvwuinrTDsBQn7HkwnumkDeFXEGob8/urYR50baK KKncY2UTXLfQKHjyZXzIBHBv/Py2Jpa1jbYo2yPGipUoTyx1Ur/e0sjUYc7o0h+j ywa+7LxcqG5EoIQaRrtxkfo1Y/tATDtOskwUuXcC6j3AzZIUo0OhX11bTA9NsrUs Hj1bVc+93nY5ENe9TSWYH8JA3ZSesapebYIeDyZjw6525B/jRZG0SqNaEzud8CEb YPnnkRJFfrV0IklTGSuGceBLrYazGDHyOyRPmLsozdy1PRCnBX7Nu346xpzg== 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=fm1; t=1773058671; x= 1773145071; bh=xqkqiee5waQOwJic/qsVej/NyQDtai116ygtpOvqQAM=; b=o 3iJf9fGiYSG9zva9TE/RZ7hSCNjmmW6wXi4FKXEC+5meY9aPS80pmTumuDiyxO7g 77YfnaYpXPF/7WPg+gTlyBkvXykVWlpZO4Om4XhspdH9oZfKPdG13UzrInX2EiV8 bS3jq3pxx48r32/u5C/zDOx5wKGPX6Zsfy1MkavSS4F7wG3SDdWaJdLSyO0Ezl/g 9dpM6OKMlm6mmlZ8ijSt//ypG1zO4IwPfJ8eaMOmR7mFQFitQqmX5iHEUUf6X34F /Rqm9NFp+sVeaCPeGVk9GBLdUODZOTpLBMD/olink7HCU3vpGB4Gop7nzBWlh2mU 33H2yW+SpGJGZOiNzcJnQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeektdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefguedu hefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeejpd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhg vghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehsohhumhihrghjhihothhishgrrh hkrghrvdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhi shhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghkse hinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdprhgtphhtthhopegrrhgusges khgvrhhnvghlrdhorhhgpdhrtghpthhtohepihhlihgrshdrrghprghlohguihhmrghsse hlihhnrghrohdrohhrghdprhgtphhtthhopehlihhnuhigqdgvfhhisehvghgvrhdrkhgv rhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: linux-kernel@vger.kernel.org Cc: Soumyajyotii Ssarkar , xen-devel@lists.xenproject.org, =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Ard Biesheuvel , Ilias Apalodimas , linux-efi@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)) Subject: [PATCH 1/2] efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV Date: Mon, 9 Mar 2026 13:17:22 +0100 Message-ID: <952b54025f836c19f57d7207d3881cacf937a50a.1773058629.git-series.marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Xen doesn't give direct access to the EFI memory map, but provides a hypercall interface for it. efi_mem_desc_lookup() was already adjusted in aca1d27ac38a "efi: xen: Implement memory descriptor lookup based on hypercall" to (optionally) use it. Now make efi_mem_type() and efi_mem_attributes() use common efi_mem_desc_lookup() too. This also reduces code duplication a bit. efi_mem_type() retains separate check for -ENOTSUPP error case (even though no caller seems to rely on this currently). Signed-off-by: Marek Marczykowski-Górecki --- drivers/firmware/efi/efi.c | 27 +++++++++------------------ 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index b2fb92a..36efc92 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -983,18 +983,12 @@ char * __init efi_md_typeattr_format(char *buf, size_t size, */ u64 efi_mem_attributes(unsigned long phys_addr) { - efi_memory_desc_t *md; + efi_memory_desc_t md; - if (!efi_enabled(EFI_MEMMAP)) + if (efi_mem_desc_lookup(phys_addr, &md)) return 0; - for_each_efi_memory_desc(md) { - if ((md->phys_addr <= phys_addr) && - (phys_addr < (md->phys_addr + - (md->num_pages << EFI_PAGE_SHIFT)))) - return md->attribute; - } - return 0; + return md.attribute; } /* @@ -1007,18 +1001,15 @@ u64 efi_mem_attributes(unsigned long phys_addr) */ int efi_mem_type(unsigned long phys_addr) { - const efi_memory_desc_t *md; + const efi_memory_desc_t md; - if (!efi_enabled(EFI_MEMMAP)) + if (!efi_enabled(EFI_MEMMAP) && !efi_enabled(EFI_PARAVIRT)) return -ENOTSUPP; - for_each_efi_memory_desc(md) { - if ((md->phys_addr <= phys_addr) && - (phys_addr < (md->phys_addr + - (md->num_pages << EFI_PAGE_SHIFT)))) - return md->type; - } - return -EINVAL; + if (efi_mem_desc_lookup(phys_addr, &md)) + return -EINVAL; + + return md.type; } int efi_status_to_err(efi_status_t status) -- git-series 0.9.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:18:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:18:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249368.1546826 (Exim 4.92) (envelope-from ) id 1vzZYW-00016x-MY; Mon, 09 Mar 2026 12:17:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249368.1546826; Mon, 09 Mar 2026 12: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 ) id 1vzZYW-00016q-JE; Mon, 09 Mar 2026 12:17:52 +0000 Received: by outflank-mailman (input) for mailman id 1249368; Mon, 09 Mar 2026 12:17:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZYU-00016k-ID for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:17:50 +0000 Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fb77f53f-1bb1-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:17:47 +0100 (CET) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 29D1D14000F3; Mon, 9 Mar 2026 08:17:46 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Mon, 09 Mar 2026 08:17:46 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Mar 2026 08:17:44 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb77f53f-1bb1-11f1-9ccf-f158ae23cfc8 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=fm1; t=1773058666; x=1773145066; bh=YpKQcaQQ0Co1PPHvvVGmm/YJrK5gAvd6 rTDRRxrgn/w=; b=Qhw3R8LlnKvaO+yPoBNDyI+Es8t1LeIdR95zYRIF1L9oojUK f/r0cWYGZJ0SNPeGM0MweELryPe7qmse5wH3RENIm/DRKmiSfs1fdo8OGMFUqtXw zGUkE82iPbtHmG4qdWBRSco3hNSD5nhgMnm6c50Ncawl6DeadoqL2lQol6H47YqL M9huUn6CBWxxK3ltASxuRARSlMu43KcfvOiuIr0lPASFtI6rrO1qFLgC8U1jGEmC xmrK6mXIgrG4P33as8TLvdaCgOCMdU094eLgYot8ApTBLQg9REkhydWmMOFLfy1a eNiO03mOq9td+PGwWWib3KpMq2XGLmEkznw3Cg== 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= fm1; t=1773058666; x=1773145066; bh=YpKQcaQQ0Co1PPHvvVGmm/YJrK5g Avd6rTDRRxrgn/w=; b=DFa9/9QmMsHdzfHVzfbaS9LHCjf7/BIHA6rrRoeXiRkQ J15KQ2vtiHoNOUhF/nqFsXdi7Ew4TTaM3H/oiv0o5Dq5pxYtLYwJMh+bsf+qCbPX 0zUSs1UEOODu2o3C6rfwbMQyZicWhjjmcJVZE/5IyIxhW+CVWeBvZvA4U1AhuokZ zQgNy2B7r0726DN39nOD0fkXMUl/h5HMtIVtHL4xsk98UxD5NSB/WHTX+QlQv692 7LBc6gxn2rCqDnMcQAV/kUgrfXqiQqwVUqDOgQmg6FtZOj4m2y2Q3GTa8oN4zuNo CjX5KSWaGP0rguhIFVGsYqZ+vY1w154or5fJkcp4sQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeektdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghkucfo rghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvhhish hisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeekkeeiveek ueehfeegveejveevuedtjeeiveeguefhvdffueetfedtuddvueetveenucffohhmrghinh epkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsg drtghomhdpnhgspghrtghpthhtohepjedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht oheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpth htohepshhouhhmhigrjhihohhtihhsrghrkhgrrhdvfeesghhmrghilhdrtghomhdprhgt phhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh dprhgtphhtthhopehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggs rdgtohhmpdhrtghpthhtoheprghruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhope hilhhirghsrdgrphgrlhhoughimhgrsheslhhinhgrrhhordhorhhgpdhrtghpthhtohep lhhinhhugidqvghfihesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: linux-kernel@vger.kernel.org Cc: Soumyajyotii Ssarkar , xen-devel@lists.xenproject.org, =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Ard Biesheuvel , Ilias Apalodimas , linux-efi@vger.kernel.org Subject: [PATCH 0/2] Allow using BGRT table under Xen dom0 Date: Mon, 9 Mar 2026 13:17:21 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit For a long time Xen was invalidating BGRT table as it was reclaiming BootServicesData memory (where boot graphics is located). This is now changing, and the boot graphics is preserved. This series has necessary changes to actually make Linux use the preserved graphics. This is a companion series to Xen side at https://lore.kernel.org/xen-devel/20260305191810.31033-1-soumyajyotisarkar23@gmail.com/ CC: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org Cc: Ard Biesheuvel (maintainer:EXTENSIBLE FIRMWARE INTERFACE (EFI)) Cc: Ilias Apalodimas (reviewer:EXTENSIBLE FIRMWARE INTERFACE (EFI)) Cc: linux-efi@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)) Marek Marczykowski-Górecki (2): efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV efi: Enable BGRT loading under Xen drivers/firmware/efi/efi-bgrt.c | 7 +++++-- drivers/firmware/efi/efi.c | 27 +++++++++------------------ 2 files changed, 14 insertions(+), 20 deletions(-) base-commit: 7e1526209cf972f51281558f1cb979d18e49cdd1 -- git-series 0.9.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:18:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:18:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249370.1546844 (Exim 4.92) (envelope-from ) id 1vzZYd-0001Zv-3V; Mon, 09 Mar 2026 12:17:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249370.1546844; Mon, 09 Mar 2026 12: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 ) id 1vzZYd-0001Zo-0v; Mon, 09 Mar 2026 12:17:59 +0000 Received: by outflank-mailman (input) for mailman id 1249370; Mon, 09 Mar 2026 12:17:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZYb-00016k-QY for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:17:57 +0000 Received: from fout-a8-smtp.messagingengine.com (fout-a8-smtp.messagingengine.com [103.168.172.151]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 006211b1-1bb2-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:17:55 +0100 (CET) Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id D0090EC04DC; Mon, 9 Mar 2026 08:17:54 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Mon, 09 Mar 2026 08:17:54 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Mar 2026 08:17:53 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 006211b1-1bb2-11f1-9ccf-f158ae23cfc8 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=fm1; t=1773058674; x=1773145074; bh=vxQTTI3dqC AbknZWRjEqDbjVPMeCodcJdMqbuNqpGws=; b=stkVUOnKviF3cZ0l4UHwr7x8TD iQxAuWDpin2T6RvJFpnaPTD5gwimiUMx0k+WR7+ruRUG/cnD+kNbkWrNPw6o8p5E nOTkm501LswWKF9AZmCC6mwEQIFaOTzuWdjscdi0stunYP3g6ytAFpGZ/K2eP9rX +MWqvvQHhYpOGzZC7lKrGp7kig9sjdMhlSq4DogKW8GXPfbjiu60om2aITYYuEmW 3PzgHGQ8BpFb7NGaTTpXOTOZmq3Dc1m/ozSUk7mf9odJpqRIbeq40SgPoV9tG2zx LbNHIkwPgGoUgMZ7O7NRdZpy869uohejeJoSakkOT9WlpzUVtXritXmqKKCg== 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=fm1; t=1773058674; x= 1773145074; bh=vxQTTI3dqCAbknZWRjEqDbjVPMeCodcJdMqbuNqpGws=; b=u OhkoL1EE/l9xCqGN4gPTo4U3frn5K1lfoODCx0Tmxhodn43l1oYPT8iqiVSqwcHc 9XArMpkDY9NXe6ZfhhV0oQvqG8P/Pa7uM3m7zyFOVbi7vWo00jsnsh0liH3d4YXR 6PwC6S03/TPB020MFP18n1bHxe/Ip9Y/LjIW/1xmroOTzX13t7HBQgm7tO6IGsz8 RFo93xsHiY5aKdC75/2PyQSuq4Hs0eJoznfce6CsAo3v4VwVaegtJvgHwWyd6/C0 BoxOZQw3Y9AMBHr3ZZ80K6Y8aUGAKsNhrKQIuAd/chMqEzCqDjFli4bZX8gw43Uo o5HiaAUqTErTvi213XCXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeektdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhephffvvefufffkofgjfhggtgfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpefguedu hefgvdefheehudejheefudevueeghfekhfehleegveduteeuiedugffgffenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrhgvkhes ihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhnsggprhgtphhtthhopeejpd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhg vghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehsohhumhihrghjhihothhishgrrh hkrghrvdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhi shhtshdrgigvnhhprhhojhgvtghtrdhorhhgpdhrtghpthhtohepmhgrrhhmrghrvghkse hinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdprhgtphhtthhopegrrhgusges khgvrhhnvghlrdhorhhgpdhrtghpthhtohepihhlihgrshdrrghprghlohguihhmrghsse hlihhnrghrohdrohhrghdprhgtphhtthhopehlihhnuhigqdgvfhhisehvghgvrhdrkhgv rhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i1568416f:Fastmail From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: linux-kernel@vger.kernel.org Cc: Soumyajyotii Ssarkar , xen-devel@lists.xenproject.org, =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Ard Biesheuvel , Ilias Apalodimas , linux-efi@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)) Subject: [PATCH 2/2] efi: Enable BGRT loading under Xen Date: Mon, 9 Mar 2026 13:17:23 +0100 Message-ID: X-Mailer: git-send-email 2.52.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The BGRT table can be parsed if EFI_PARAVIRT is enabled, even if EFI_MEMMAP is not. Xen will take care of preserving the image even if EfiBootServicesData memory is reclaimed already, or invalidate the table if it didn't preserve it - in both cases accesing the table itself under virt is safe. Also allow the ESRT to be in reclaimable memory, as that is where future Xen versions will put it. This is similar approach as was taken for ESRT table in 01de145dc7fb "efi: Actually enable the ESRT under Xen". Signed-off-by: Marek Marczykowski-Górecki --- drivers/firmware/efi/efi-bgrt.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c index 6aafdb6..1da4515 100644 --- a/drivers/firmware/efi/efi-bgrt.c +++ b/drivers/firmware/efi/efi-bgrt.c @@ -29,11 +29,12 @@ void __init efi_bgrt_init(struct acpi_table_header *table) void *image; struct bmp_header bmp_header; struct acpi_table_bgrt *bgrt = &bgrt_tab; + int mem_type; if (acpi_disabled) return; - if (!efi_enabled(EFI_MEMMAP)) + if (!efi_enabled(EFI_MEMMAP) && !efi_enabled(EFI_PARAVIRT)) return; if (table->length < sizeof(bgrt_tab)) { @@ -62,7 +63,9 @@ void __init efi_bgrt_init(struct acpi_table_header *table) goto out; } - if (efi_mem_type(bgrt->image_address) != EFI_BOOT_SERVICES_DATA) { + mem_type = efi_mem_type(bgrt->image_address); + if (mem_type != EFI_BOOT_SERVICES_DATA && + mem_type != EFI_ACPI_RECLAIM_MEMORY) { pr_notice("Ignoring BGRT: invalid image address\n"); goto out; } -- git-series 0.9.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:22:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:22:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249394.1546855 (Exim 4.92) (envelope-from ) id 1vzZcp-0003bw-LU; Mon, 09 Mar 2026 12:22:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249394.1546855; Mon, 09 Mar 2026 12:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZcp-0003bp-Gk; Mon, 09 Mar 2026 12:22:19 +0000 Received: by outflank-mailman (input) for mailman id 1249394; Mon, 09 Mar 2026 12:22:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZco-0003bj-56 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:22:18 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9711b72a-1bb2-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:22:08 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTx326qbkz2lL for ; Mon, 9 Mar 2026 12:22:06 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 638f3f823d7f4ab28270cf3473175c76; Mon, 09 Mar 2026 12:22:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9711b72a-1bb2-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773058927; x=1773328927; bh=pzRefWKHPO4gtPDK77mGxGQotz5Vl0Qyd4vFEZa7/Gk=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=h5HANp9yM3I2+mqmE13/b7WJAI6z+2Osg38VIC3WcuQuGniRsk3eNugV4GJeBrX4n 7LIUkNNHC0vyCwf/RnoQ+AQacgA0CXTdz8Qr2wdG8zcEZe79nG+n4Y0F9LLMxJSj7Q Mc4WS5QinrVUgapQU14QeS0HcaYJq/PePZf+0VhxePFFc4tVv5bH+3qijnBwCbl0zu wNxP6jUWAIP/6FmWI24n1pp1gdz/O3Gfz4erZfR3WZYg41KSt9Dc5Qnh8gdk1E9L5U wqNd0jsMKJOsl27Q3OmqEiGjDQBqMFkPDRZQV+0dF0KV1Cl2SL0BfO3WBiYl5l7TGE rvdXYGhPWsdiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773058927; x=1773319427; i=anthony.perard@vates.tech; bh=pzRefWKHPO4gtPDK77mGxGQotz5Vl0Qyd4vFEZa7/Gk=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=h/bygIiy1vv6mW5R3i8adcMxUnvv3MpjZ12soLwjk2tZelPqOvuNurLLvfv/x2gJz thwOxa/c2lLdGUzB9o9FK3ne9jowZaqjuEJtz+Th5s+67PYID/qcxPxoGbPRv0JL5s NZvBeFGkHRqdrxAizHrUk/VA57/njMJARJsLCI9WCpkdd7Yaq7m1upY2NCOIBA4VbJ v+cYh/xbmOee2Wi9XthF4/yQjfLaBxHurzxKg3wGSMAzQ2HRB066mYjBwX4Ql+BYjW v3pbJihYu364q2oKygi2pmBCgH3Btg7WNgMiJB/SCmvucXjb091ok9JMfYjKd5b6Yv VdFA6Q3uJxzQw== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v6]=20xen/domain:=20introduce=20DOMID=5FANY?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773058924994 To: dmukhin@ford.com Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, jbeulich@suse.com, julien@xen.org, michal.orzel@amd.com, roger.pau@citrix.com, sstabellini@kernel.org Message-Id: References: <20260307025451.3148078-2-dmukhin@ford.com> In-Reply-To: <20260307025451.3148078-2-dmukhin@ford.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.638f3f823d7f4ab28270cf3473175c76?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:22:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, Mar 06, 2026 at 06:54:52PM -0800, dmukhin@ford.com wrote: > diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c > index bfc9149096a3..79af2958d170 100644 > --- a/tools/libs/light/libxl_create.c > +++ b/tools/libs/light/libxl_create.c > @@ -666,7 +666,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, > } > > for (;;) { > - uint32_t local_domid; > + uint32_t local_domid = DOMID_INVALID; Surely, this change is unnecessary? > bool recent; > > if (info->domid == RANDOM_DOMID) { > @@ -681,8 +681,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, > continue; > > local_domid = v; > + } else if (libxl_domid_valid_guest(local_domid)) { You meant to check `info->domid`, right? > + local_domid = info->domid; > } else { > - local_domid = info->domid; /* May not be valid */ > + local_domid = DOMID_ANY; > } Cheers, -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249407.1546873 (Exim 4.92) (envelope-from ) id 1vzZlM-0005bp-VS; Mon, 09 Mar 2026 12:31:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249407.1546873; Mon, 09 Mar 2026 12:31:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlM-0005af-QC; Mon, 09 Mar 2026 12:31:08 +0000 Received: by outflank-mailman (input) for mailman id 1249407; Mon, 09 Mar 2026 12:31:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlL-0005Rm-81 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:07 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d65d34a9-1bb3-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:31:04 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFM1TNbz1XLF7d for ; Mon, 9 Mar 2026 12:31:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 7632bac910874125b6f28e7074afe0a8; Mon, 09 Mar 2026 12:31:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d65d34a9-1bb3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059463; x=1773329463; bh=jYo3ibCaaXE6o3VshQXsD68O/WvKsje9Jyl33S4ybjc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=jlUk3StiwCUfMddo7aJqdYhPn/7b1GgHWCpg8BVaaHVLlzegSLS+0WSqvQ5rcU4U/ TMLixJbD8qAlNKnkI+sf0x3Bgr+QLg7CL8tNuhRL0j5gfOLT8s3OL8XkhxDxHNgAea EpL8C2qOLsHf0TvQKC4IP5vLwuU1gUM8N+VygHYLJdr0eU4CrttxO+S1Z9R5E2hzV7 kV05q7+9BgHWUjXPN8cxPpQnpMVdy77FCGH0G5NWuJjqfXvXWV4xzDYlWuwGP4NS75 iYe1b32t+gaEv44TPIxp3DKubIBU4mDQ2M01ObhQ/7X4n7WMFCstVvaLE7knVuaqrG eUXdMcyvSB37Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059463; x=1773319963; i=julian.vetter@vates.tech; bh=jYo3ibCaaXE6o3VshQXsD68O/WvKsje9Jyl33S4ybjc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=MeN2GrZoOwok5InfyDmVIlwaghm/gDenRVb9V4tRw9NzSxVw3+zPu/XURKTAmANOR +va0zwayQHZAsR2i3crmziHqrscnXYw8AS2GorETTl4pI8imarWetI59ADga6S8pcY BkjSrSZg0TAJWSdsfb1VRkYddO6P3Cc/qlIe9jyEWVdgnnRlbr0/VzPBDaKITIBY+A n5wRHkVB3Z/e1AncrJo+ZGEw6tw9N8kItN2IQIhCKbmihBgpXEuvXCshZn8BffNtT1 C2F9/KDQr0Lha27aHZPcSIyRMjWfss3iqq04+QHjbasctWoDDGDy83cyrt0cXeTxUD CO+t1xS5/ib8A== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=202/7]=20x86/msi:=20Define=20extended=20destination=20ID=20masks=20and=20IO-APIC=20RTE=20fields?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059461979 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-2-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.7632bac910874125b6f28e7074afe0a8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit x2APIC guests with more than 128 vCPUs need destination IDs beyond the 8-bit range provided by the standard MSI address and IO-APIC RTE fields. The Intel spec allows bits 11:5 of the MSI address and bits 55:49 of the IO-APIC RTE to carry the high 7 bits of the destination ID when the platform advertises support, expanding the range to 15 bits total. Add MSI_ADDR_EXT_DEST_ID_MASK for the extended MSI address bits, and IO_APIC_REDIR_{DEST,EXT_DEST}_MASK with a VIOAPIC_RTE_DEST() helper to extract the combined 15-bit destination from an IO-APIC RTE. Extend the IO-APIC RTE save/restore struct with an ext_dest_id field, and add XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK plus XEN_DOMCTL_VMSI_X86_FULL_DEST() to the domctl MSI gflags interface so callers can pass and extract the full destination ID through the existing pt_irq_bind path. Signed-off-by: Julian Vetter --- Changes in V3: - Addressed comments from Jan - Replaced reserved field by generically named reserved2 - Added proper constants for the shift of the upper bits of the MSI/RTE IDs - Added reference for the MSI_ADDR_EXT_DEST_ID_MASK --- xen/arch/x86/hvm/vioapic.c | 2 +- xen/arch/x86/include/asm/hvm/vioapic.h | 13 +++++++++++++ xen/arch/x86/include/asm/msi.h | 10 +++++++++- xen/include/public/arch-x86/hvm/save.h | 4 +++- xen/include/public/domctl.h | 18 ++++++++++++------ 5 files changed, 38 insertions(+), 9 deletions(-) diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index b9acdd8af6..d7a4105a57 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -616,7 +616,7 @@ static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h */ if ( e->fields.reserve || e->fields.reserved[0] || e->fields.reserved[1] || - e->fields.reserved[2] || e->fields.reserved[3] ) + e->fields.reserved[2] || e->fields.reserved2 ) return -EINVAL; } diff --git a/xen/arch/x86/include/asm/hvm/vioapic.h b/xen/arch/x86/include/asm/hvm/vioapic.h index 68af6dce79..5d7da5a092 100644 --- a/xen/arch/x86/include/asm/hvm/vioapic.h +++ b/xen/arch/x86/include/asm/hvm/vioapic.h @@ -32,6 +32,19 @@ #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_ID_UPPER_BITS 8 +#define VIOAPIC_RTE_DEST(rte) \ + (MASK_EXTR((rte), IO_APIC_REDIR_DEST_MASK) | \ + (MASK_EXTR((rte), IO_APIC_REDIR_EXT_DEST_MASK) << \ + VIOAPIC_RTE_DEST_ID_UPPER_BITS)) + #define VIOAPIC_DEFAULT_BASE_ADDRESS 0xfec00000U #define VIOAPIC_MEM_LENGTH 0x100 diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h index 00059d4a3a..8d87d0c10d 100644 --- a/xen/arch/x86/include/asm/msi.h +++ b/xen/arch/x86/include/asm/msi.h @@ -51,9 +51,17 @@ #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_UPPER_BITS 8 +#define MSI_ADDR_DEST_ID_MASK 0x00ff000 #define MSI_ADDR_DEST_ID(dest) (((dest) << MSI_ADDR_DEST_ID_SHIFT) & MSI_ADDR_DEST_ID_MASK) +/* + * Per the Intel x2APIC specification, 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 + /* MAX fixed pages reserved for mapping MSIX tables. */ #define FIX_MSIX_MAX_PAGES 512 diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index 9c4bfc7ebd..483097d940 100644 --- 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; }; diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 8f6708c0a7..6d425e34ac 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -615,12 +615,14 @@ struct xen_domctl_bind_pt_irq { struct { uint8_t gvec; uint32_t gflags; -#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0x0000ff -#define XEN_DOMCTL_VMSI_X86_RH_MASK 0x000100 -#define XEN_DOMCTL_VMSI_X86_DM_MASK 0x000200 -#define XEN_DOMCTL_VMSI_X86_DELIV_MASK 0x007000 -#define XEN_DOMCTL_VMSI_X86_TRIG_MASK 0x008000 -#define XEN_DOMCTL_VMSI_X86_UNMASKED 0x010000 +#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0x0000ff +#define XEN_DOMCTL_VMSI_X86_DEST_ID_BITS 8 +#define XEN_DOMCTL_VMSI_X86_RH_MASK 0x000100 +#define XEN_DOMCTL_VMSI_X86_DM_MASK 0x000200 +#define XEN_DOMCTL_VMSI_X86_DELIV_MASK 0x007000 +#define XEN_DOMCTL_VMSI_X86_TRIG_MASK 0x008000 +#define XEN_DOMCTL_VMSI_X86_UNMASKED 0x010000 +#define XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK 0xfe0000 uint64_aligned_t gtable; } msi; @@ -630,6 +632,10 @@ struct xen_domctl_bind_pt_irq { } u; }; +#define XEN_DOMCTL_VMSI_X86_FULL_DEST(gflags) \ + (MASK_EXTR((gflags), XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | \ + (MASK_EXTR((gflags), XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK) << \ + XEN_DOMCTL_VMSI_X86_DEST_ID_BITS)) /* Bind machine I/O address range -> HVM address range. */ /* XEN_DOMCTL_memory_mapping */ -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249410.1546904 (Exim 4.92) (envelope-from ) id 1vzZlP-0006Oz-6x; Mon, 09 Mar 2026 12:31:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249410.1546904; Mon, 09 Mar 2026 12:31:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlO-0006Mu-V6; Mon, 09 Mar 2026 12:31:10 +0000 Received: by outflank-mailman (input) for mailman id 1249410; Mon, 09 Mar 2026 12:31:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlN-0005Rm-S6 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:09 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d85bf670-1bb3-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:31:07 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFN0mS4z1XLF8g for ; Mon, 9 Mar 2026 12:31:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 441784b254ef4839bf5042d28ceb1d2a; Mon, 09 Mar 2026 12:31:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d85bf670-1bb3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059464; x=1773329464; bh=yBW+Fz2L+XcrjXyP9HkaoTV/8bPAxt7aYNJZwU0t0XE=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Xp5sdVjacc8RnFuJfvcwe/ETbTNzpRkkisANXtaG+bzfnCJCTnHgu0a52lBF5xaQm 9I6r45bJF7sle0zkAau8V8Qz625BoaABloS3uIVZYlCT2HpAN2ip/w499YIodnudLi pKJg1OOWdw3dsMLn41ltdBg8I27RyAk6QLWisSzIluNlrC9q5iN25+3prPNktHr+/c hiRPu6/qaA2lTVYXFi1XBPfsAAOjYFNQIhWGbcJHRj3mxMI9whVJ41O4IfZZwGY99S og25ajL4U9VNjrnBY9bVnCmypEnWDc3sAh2rosxZM0H0oEYvbamYcZpVGymiuxbsfq 390Y1somR984w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059464; x=1773319964; i=julian.vetter@vates.tech; bh=yBW+Fz2L+XcrjXyP9HkaoTV/8bPAxt7aYNJZwU0t0XE=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=K4A7jHYikj0Wkbrr2AKIEeyof7Rq8okhJSvjsk6pwZDMfA3sBluTQdl91wwTm74xK JEhHOxh6IP9/0Eoi0bUduHJRP+2itT4u7+emMqbGGm48BdA6pzJj+gnDetw68ltFfR 5gjQInr3qaSTYVRBoM6q9ZeREdvOMvf51a3fkGKEjWKw2ElrHoh5OTbgpy/jJBJdBX rPkQnucPDz8WjCKAt8YTV9sB9i38KecEFMN3xIgHX6w7R3RgejpKEaEXvVEMkv0niP rgi2ixNZS295D20Dst9Whsdw3065WciTgevDdQQvojunNwQj+SCuprzlwoYNXcGl7A NFhcxTqpk7V3Q== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=205/7]=20x86/dmop:=20Add=20XEN=5FDMOP=5F{bind,unbind}=5Fpt=5Fmsi=5Firq=20DM=20ops?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059462800 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-5-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.441784b254ef4839bf5042d28ceb1d2a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Add two DM ops for MSI passthrough IRQs. These new DM ops take the raw MSI address and data fields rather than a 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. Signed-off-by: Julian Vetter --- Changes in V3: - New patch addressing feedback from Roger --- tools/include/xendevicemodel.h | 37 ++++++++++++ tools/libs/devicemodel/core.c | 44 ++++++++++++++ xen/arch/x86/hvm/dm.c | 102 +++++++++++++++++++++++++++++++++ xen/include/public/hvm/dm_op.h | 23 ++++++++ xen/include/xlat.lst | 1 + 5 files changed, 207 insertions(+) diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h index 227e7fd810..0d5d7b0ff1 100644 --- a/tools/include/xendevicemodel.h +++ b/tools/include/xendevicemodel.h @@ -375,6 +375,43 @@ int xendevicemodel_nr_vcpus( */ int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid); +/** + * This function binds a passthrough physical IRQ to a guest MSI vector + * using raw MSI address/data fields. Unlike XEN_DOMCTL_bind_pt_irq, + * this interface supports extended (15-bit) destination IDs by having + * Xen decode the MSI address internally. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm domid the domain id to be serviced. + * @parm machine_irq the physical IRQ number (pirq). + * @parm gvec the guest interrupt vector. + * @parm msi_addr the MSI address (0xfeexxxxx, includes extended dest ID). + * @parm msi_data the MSI data (vector, delivery mode, trigger mode). + * @parm gtable the MSI-X table base GFN, or 0 for plain MSI. + * @parm unmasked if non-zero, leave the IRQ unmasked after binding. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_bind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data, uint64_t gtable, + int unmasked); + +/** + * This function unbinds a passthrough physical IRQ previously bound + * with xendevicemodel_bind_pt_msi_irq. + * + * @parm dmod a handle to an open devicemodel interface. + * @parm domid the domain id to be serviced. + * @parm machine_irq the physical IRQ number (pirq). + * @parm gvec the guest interrupt vector. + * @parm msi_addr the MSI address. + * @parm msi_data the MSI data. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_unbind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data); + #endif /* XENDEVICEMODEL_H */ /* diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index 8e619eeb0a..4a52fe4750 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -645,6 +645,50 @@ int xendevicemodel_nr_vcpus( return 0; } +int xendevicemodel_bind_pt_msi_irq( + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, + uint8_t gvec, 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->gvec = gvec; + 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, + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data) +{ + struct xen_dm_op op; + struct xen_dm_op_bind_pt_msi_irq *data; + + memset(&op, 0, sizeof(op)); + + op.op = XEN_DMOP_unbind_pt_msi_irq; + data = &op.u.bind_pt_msi_irq; + + data->machine_irq = machine_irq; + data->gvec = gvec; + data->data = msi_data; + data->addr = msi_addr; + + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); +} + int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid) { return osdep_xendevicemodel_restrict(dmod, domid); diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c index 3b53471af0..3d530d948f 100644 --- a/xen/arch/x86/hvm/dm.c +++ b/xen/arch/x86/hvm/dm.c @@ -7,12 +7,15 @@ #include #include #include +#include +#include #include #include #include #include #include +#include #include #include @@ -322,6 +325,25 @@ static int inject_event(struct domain *d, return 0; } +static uint32_t msi_addr_to_gflags(uint64_t addr, uint32_t data, bool masked) +{ + uint32_t tmp = (uint32_t)addr; + + return MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_DEST_ID_MASK), + XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_EXT_DEST_ID_MASK), + XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK) | + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_REDIRECTION_MASK), + XEN_DOMCTL_VMSI_X86_RH_MASK) | + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_DESTMODE_MASK), + XEN_DOMCTL_VMSI_X86_DM_MASK) | + MASK_INSR(MASK_EXTR(data, MSI_DATA_DELIVERY_MODE_MASK), + XEN_DOMCTL_VMSI_X86_DELIV_MASK) | + MASK_INSR(MASK_EXTR(data, MSI_DATA_TRIGGER_MASK), + XEN_DOMCTL_VMSI_X86_TRIG_MASK) | + (masked ? 0 : XEN_DOMCTL_VMSI_X86_UNMASKED); +} + int dm_op(const struct dmop_args *op_args) { struct domain *d; @@ -350,6 +372,8 @@ int dm_op(const struct dmop_args *op_args) [XEN_DMOP_relocate_memory] = sizeof(struct xen_dm_op_relocate_memory), [XEN_DMOP_pin_memory_cacheattr] = sizeof(struct xen_dm_op_pin_memory_cacheattr), [XEN_DMOP_nr_vcpus] = sizeof(struct xen_dm_op_nr_vcpus), + [XEN_DMOP_bind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), + [XEN_DMOP_unbind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), }; rc = rcu_lock_remote_domain_by_id(op_args->domid, &d); @@ -607,6 +631,83 @@ 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; + struct xen_domctl_bind_pt_irq bind = { + .machine_irq = data->machine_irq, + .irq_type = PT_IRQ_TYPE_MSI, + }; + int irq; + + rc = -EINVAL; + if ( data->pad0 || data->pad1 ) + break; + + if ( data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED ) + break; + + irq = domain_pirq_to_irq(d, bind.machine_irq); + + rc = -EPERM; + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) + break; + + bind.u.msi.gvec = data->gvec; + bind.u.msi.gflags = + msi_addr_to_gflags(data->addr, data->data, + !(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED)); + bind.u.msi.gtable = data->gtable; + + rc = -ESRCH; + if ( is_iommu_enabled(d) ) + { + pcidevs_lock(); + rc = pt_irq_create_bind(d, &bind); + pcidevs_unlock(); + } + if ( rc < 0 ) + printk(XENLOG_G_ERR + "pt_irq_create_bind failed (%ld) for dom%d\n", + rc, d->domain_id); + break; + } + + case XEN_DMOP_unbind_pt_msi_irq: + { + const struct xen_dm_op_bind_pt_msi_irq *data = + &op.u.bind_pt_msi_irq; + struct xen_domctl_bind_pt_irq bind = { + .machine_irq = data->machine_irq, + .irq_type = PT_IRQ_TYPE_MSI, + }; + int irq; + + rc = -EINVAL; + if ( data->pad0 || data->pad1 ) + break; + + irq = domain_pirq_to_irq(d, bind.machine_irq); + + rc = -EPERM; + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) + break; + + rc = -ESRCH; + if ( is_iommu_enabled(d) ) + { + pcidevs_lock(); + rc = pt_irq_destroy_bind(d, &bind); + pcidevs_unlock(); + } + if ( rc < 0 ) + printk(XENLOG_G_ERR + "pt_irq_destroy_bind failed (%ld) for dom%d\n", + rc, d->domain_id); + break; + } + default: rc = ioreq_server_dm_op(&op, d, &const_op); break; @@ -643,6 +744,7 @@ CHECK_dm_op_remote_shutdown; CHECK_dm_op_relocate_memory; CHECK_dm_op_pin_memory_cacheattr; CHECK_dm_op_nr_vcpus; +CHECK_dm_op_bind_pt_msi_irq; int compat_dm_op( domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) bufs) diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h index 2bf0fdc1ae..fd0f3a6a99 100644 --- a/xen/include/public/hvm/dm_op.h +++ b/xen/include/public/hvm/dm_op.h @@ -444,6 +444,28 @@ 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; + /* IN - guest vector */ + uint8_t gvec; + uint8_t pad0; + uint16_t pad1; + /* IN - MSI data (vector, delivery, trigger) */ + uint32_t data; + /* IN - flags */ + uint32_t flags; +#define XEN_DMOP_MSI_FLAG_UNMASKED (1u << 0) + /* IN - MSI address (0xfeexxxxx, includes ext dest) */ + uint64_aligned_t addr; + /* IN - MSI-X table base GFN, 0 for MSI */ + uint64_aligned_t gtable; +}; +typedef struct xen_dm_op_bind_pt_msi_irq xen_dm_op_bind_pt_msi_irq_t; + struct xen_dm_op { uint32_t op; uint32_t pad; @@ -468,6 +490,7 @@ struct xen_dm_op { xen_dm_op_relocate_memory_t relocate_memory; xen_dm_op_pin_memory_cacheattr_t pin_memory_cacheattr; xen_dm_op_nr_vcpus_t nr_vcpus; + xen_dm_op_bind_pt_msi_irq_t bind_pt_msi_irq; } u; }; diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index 9d08dcc4bb..9236394786 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -107,6 +107,7 @@ ? dm_op_map_mem_type_to_ioreq_server hvm/dm_op.h ? dm_op_modified_memory hvm/dm_op.h ? dm_op_nr_vcpus hvm/dm_op.h +? dm_op_bind_pt_msi_irq hvm/dm_op.h ? dm_op_pin_memory_cacheattr hvm/dm_op.h ? dm_op_relocate_memory hvm/dm_op.h ? dm_op_remote_shutdown hvm/dm_op.h -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249409.1546898 (Exim 4.92) (envelope-from ) id 1vzZlO-0006He-LX; Mon, 09 Mar 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 1249409.1546898; Mon, 09 Mar 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 ) id 1vzZlO-0006HW-HV; Mon, 09 Mar 2026 12:31:10 +0000 Received: by outflank-mailman (input) for mailman id 1249409; Mon, 09 Mar 2026 12:31:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlM-0005Rm-Rz for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:08 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d7b9d31f-1bb3-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:31:06 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFM3ypbz1XLF7l for ; Mon, 9 Mar 2026 12:31:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 18a1a1d1df8149379ba464e21f873ad8; Mon, 09 Mar 2026 12:31:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d7b9d31f-1bb3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059463; x=1773329463; bh=Mx7xiEpCf87KqJdZ5mo3DMQmHNKXahVe5TvPx89UTcQ=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=q4fxtnhuffHtZoXaXfGXNRFa+aF9DMczP4kP9e0mvKQY803coNgRiq0HdwZQpSZUJ I2+6JYiuEN5FW9kcHAYlrCaJXmD7TrlzpiNxlIY5FiBgb3SC5i1v9wPrRmywMsoIeM mOUrNcE+xUDqj7jBDcGOf/aeQMtS25pxgbre0yzIULd6JfMUBVKTJmir4730lVEuAs L7q+A7SjSnO72FmBsQqNG+0Hnp0SbHEk7v+9OmcjaJQ7HevaGSoOLAPkUqAFTw7F5R V/3hNxH6sZkzMhBBU+6Xv2GaMikQmKES924VsOJh3R2wkIrLIKqtnsc/mbMaNNI38R +znp5tfH+de/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059463; x=1773319963; i=julian.vetter@vates.tech; bh=Mx7xiEpCf87KqJdZ5mo3DMQmHNKXahVe5TvPx89UTcQ=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=QwXrRM0B4KQ7VTIFOhOnI/cKO8u9el1Gi4Qp67yPPSq89B7vmTGRM1UJ6oybNkGiP aon7NlViXYTsPa5JbUEsz7PaKx8jY3Gpyhh+A/41ABgbsBzfUiVxqgD6XapRBupUiV xLglYlL7EkOrJO/SlYMxEcZVkDqQyrM87z+sgZZ4ooxZgAasZCdX4XK9XpzYsFbNKm oz64x5R8FyU9iKMqQKcIzNelqkjnVsn9UeVO8X2waE7UEUOjAWzov7JrZ/68biSF/U SRLm2S+jmmMKuAzCzeYigfGk578/Yzq1cHxKdO+5zwKKV1PW5GV0S0oY+F8Ksh3SU4 Xm5g8a5RVbhmQ== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=203/7]=20x86/hvm:=20Support=20extended=20destination=20IDs=20in=20virtual=20MSI=20and=20IO-APIC?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059462248 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-3-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.18a1a1d1df8149379ba464e21f873ad8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Use the newly defined masks to extract the full 15-bit destination ID from guest MSI addresses and IO-APIC RTEs. In hvm_inject_msi() combine the standard bits [19:12] with the extended bits [11:5] of the MSI address into a 15-bit destination ID for LAPIC delivery. Increase the dest parameter of vmsi_deliver() and hvm_girq_dest_2_vcpu_id() from uint8_t to uint32_t. In vmsi_deliver_pirq() extract the full destination from gflags via XEN_DOMCTL_VMSI_X86_FULL_DEST(). In msi_gflags() pack the extended bits from the MSI address into the new XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK field of gflags. In vioapic_deliver() read the combined 15-bit destination using the VIOAPIC_RTE_DEST() macro. Extend ioapic_check() to check for extended destination bits set in a domain that does not advertise XEN_HVM_CPUID_EXT_DEST_ID and refuse to restore the IO-APIC state, preventing silent interrupt misrouting after live migration. Signed-off-by: Julian Vetter --- Changes in V3: - Added additional check to the vioapic_check that makes sure that the extended bits are not set for domains that don't support it - Addressed comments from Jan -> Replaced all constants by a proper define --- xen/arch/x86/hvm/irq.c | 11 ++++++++++- xen/arch/x86/hvm/vioapic.c | 21 +++++++++++++++++++-- xen/arch/x86/hvm/vmsi.c | 8 +++++--- xen/arch/x86/include/asm/hvm/hvm.h | 4 ++-- 4 files changed, 36 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 5f64361113..b520fc1150 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -374,7 +374,16 @@ 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 (8 bits). + * Extended MSI destination address bits 11:5 (7 more bits). + * + * As XEN_HVM_CPUID_EXT_DEST_ID is advertised, the guest may use bits 11:5 + * for high destination ID bits, expanding to 15 bits total. Guests unaware + * of this feature set these bits to 0, so this is backwards-compatible. + */ + uint32_t dest = (MASK_EXTR(tmp, MSI_ADDR_EXT_DEST_ID_MASK) << MSI_ADDR_DEST_ID_BITS) | + MASK_EXTR(tmp, MSI_ADDR_DEST_ID_MASK); uint8_t dest_mode = !!(tmp & MSI_ADDR_DESTMODE_MASK); uint8_t delivery_mode = (data & MSI_DATA_DELIVERY_MODE_MASK) >> MSI_DATA_DELIVERY_MODE_SHIFT; diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index d7a4105a57..9602572dc4 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -411,7 +411,9 @@ static void ioapic_inj_irq( static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) { - uint16_t dest = vioapic->redirtbl[pin].fields.dest_id; + uint32_t dest = ((uint32_t)vioapic->redirtbl[pin].fields.ext_dest_id << + VIOAPIC_RTE_DEST_ID_UPPER_BITS) | + vioapic->redirtbl[pin].fields.dest_id; uint8_t dest_mode = vioapic->redirtbl[pin].fields.dest_mode; uint8_t delivery_mode = vioapic->redirtbl[pin].fields.delivery_mode; uint8_t vector = vioapic->redirtbl[pin].fields.vector; @@ -618,6 +620,21 @@ static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h e->fields.reserved[0] || e->fields.reserved[1] || e->fields.reserved[2] || e->fields.reserved2 ) return -EINVAL; + + /* + * An RTE in the saved state has ext_dest_id bits set. Check that + * the destination Xen has extended destination ID support enabled, + * otherwise interrupt routing to APIC IDs > 255 would be broken + * after restore. + */ + if ( e->fields.ext_dest_id && !d->arch.hvm.ext_dest_id_enabled ) + { + printk(XENLOG_G_ERR "HVM restore: %pd IO-APIC RTE %u has " + "extended destination ID bits set but " + "XEN_HVM_CPUID_EXT_DEST_ID is not enabled\n", + d, i); + return -EINVAL; + } } return 0; @@ -659,7 +676,7 @@ static int cf_check ioapic_load(struct domain *d, hvm_domain_context_t *h) return 0; } -HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, NULL, ioapic_load, 1, +HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, ioapic_check, ioapic_load, 1, HVMSR_PER_DOM); void vioapic_reset(struct domain *d) diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c index 27b1f089e2..36ea898ac7 100644 --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -66,7 +66,7 @@ static void vmsi_inj_irq( int vmsi_deliver( struct domain *d, int vector, - uint8_t dest, uint8_t dest_mode, + uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t trig_mode) { struct vlapic *target; @@ -109,7 +109,7 @@ 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; + uint32_t dest = XEN_DOMCTL_VMSI_X86_FULL_DEST(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; @@ -125,7 +125,7 @@ void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq_dpci) } /* Return value, -1 : multi-dests, non-negative value: dest_vcpu_id */ -int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t dest_mode) +int hvm_girq_dest_2_vcpu_id(struct domain *d, uint32_t dest, uint8_t dest_mode) { int dest_vcpu_id = -1, w = 0; struct vcpu *v; @@ -802,6 +802,8 @@ static unsigned int msi_gflags(uint16_t data, uint64_t addr, bool masked) */ return MASK_INSR(MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK), XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | + MASK_INSR(MASK_EXTR(addr, MSI_ADDR_EXT_DEST_ID_MASK), + XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK) | MASK_INSR(MASK_EXTR(addr, MSI_ADDR_REDIRECTION_MASK), XEN_DOMCTL_VMSI_X86_RH_MASK) | MASK_INSR(MASK_EXTR(addr, MSI_ADDR_DESTMODE_MASK), diff --git a/xen/arch/x86/include/asm/hvm/hvm.h b/xen/arch/x86/include/asm/hvm/hvm.h index 7d9774df59..11256d5e67 100644 --- a/xen/arch/x86/include/asm/hvm/hvm.h +++ b/xen/arch/x86/include/asm/hvm/hvm.h @@ -295,11 +295,11 @@ uint64_t hvm_get_guest_time_fixed(const struct vcpu *v, uint64_t at_tsc); int vmsi_deliver( struct domain *d, int vector, - uint8_t dest, uint8_t dest_mode, + uint32_t dest, uint8_t dest_mode, uint8_t delivery_mode, uint8_t trig_mode); struct hvm_pirq_dpci; void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci *pirq_dpci); -int hvm_girq_dest_2_vcpu_id(struct domain *d, uint8_t dest, uint8_t dest_mode); +int hvm_girq_dest_2_vcpu_id(struct domain *d, uint32_t dest, uint8_t dest_mode); enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack); -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249408.1546881 (Exim 4.92) (envelope-from ) id 1vzZlN-0005kz-EF; Mon, 09 Mar 2026 12:31:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249408.1546881; Mon, 09 Mar 2026 12:31:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlN-0005iM-7c; Mon, 09 Mar 2026 12:31:09 +0000 Received: by outflank-mailman (input) for mailman id 1249408; Mon, 09 Mar 2026 12:31:07 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlL-0005Rm-Rt for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:07 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d6d7e0fc-1bb3-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:31:05 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFM5n8nz38S for ; Mon, 9 Mar 2026 12:31:03 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 032a1be8fa454067a55673a79402ae81; Mon, 09 Mar 2026 12:31:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d6d7e0fc-1bb3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059463; x=1773329463; bh=I8BSfceyMGDNtjYI3I25tiqYMa8WyFnZJjroIloiPck=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=N3Nmv77Jl5i5MvG8JhByUKf2yn8GJwFJ+NhVaZ03LuU15bHhn0cdXq+IV9UuBgmNw TlKV13ESA04obF1pkFU+wTZnw5nkqyMJD4eBv8iZ9rXqvy836iZ4zhWWlgln+b6oyC 5KGpte28suw+5Pt9jkNS5g8n4y7bG1k38yeJhlj0PCs3iG7yDA+uPiJiSDmgb+e55T ByFCgJJnGVM1tqIPGaEsUskPVcgKDmduSF1LDEYB2e3d0KdQkcvGvNXWHUtAo4S0kA J7jE/MmnGasuut8uWHuIg6760MjGfnTW3y2j78yp9xkt9oBqHC+qaeme7h9TaQGxEz Oe9PcKMQhdO9g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059463; x=1773319963; i=julian.vetter@vates.tech; bh=I8BSfceyMGDNtjYI3I25tiqYMa8WyFnZJjroIloiPck=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=GfgUDR6hb/VtLN1mNSdipyZVxtJ8oGhRwQTayso00UGGCk6umpwiTe5LZIHMHoyp0 NfE+bYJSItrDRqyu8pnOJXG27s/8+3vm0dssXX2ESxQFVvjucIJfMppMH77Byz9R1/ wDrPU7/fElu9tn+gccoJoPJJ2PoUBeUxHDb8IRj1RfYLLCFk5P2lbts/Ck9spqYKiI EkRyY1eXL7suuyt6bqUbOH1/FPftR8OaIebEp61NA/yXlVGBoENpoYc2H22SY3ufQy 4BMF3GNQrl7FC6cAEJP6tixZ8bnxFx0NLk2AZFwsbW25TzQw/qVIIJ4ZDOpmqv2zsl A0oB3TB8rHvIQ== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=204/7]=20x86/passthrough:=20Use=20extended=20destination=20ID=20in=20PT=20MSI=20bind/unbind?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059462530 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-4-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.032a1be8fa454067a55673a79402ae81?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit In pt_irq_create_bind() and _hvm_dpci_msi_eoi() replace the bare MASK_EXTR(..., XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) calls with XEN_DOMCTL_VMSI_X86_FULL_DEST() so that the high 7 destination ID bits stored in XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK are included when computing the target vCPU for MSI passthrough IRQs. Increase the local dest and delivery_mode variables to uint32_t to match. Signed-off-by: Julian Vetter --- Changes in V3: - New patch, but no changes to previous patchset --- xen/drivers/passthrough/x86/hvm.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/xen/drivers/passthrough/x86/hvm.c b/xen/drivers/passthrough/x86/hvm.c index b73bb55055..9c3c8d28d6 100644 --- a/xen/drivers/passthrough/x86/hvm.c +++ b/xen/drivers/passthrough/x86/hvm.c @@ -281,7 +281,7 @@ int pt_irq_create_bind( { case PT_IRQ_TYPE_MSI: { - uint8_t dest, delivery_mode; + uint32_t dest, delivery_mode; bool dest_mode; int dest_vcpu_id; const struct vcpu *vcpu; @@ -357,8 +357,7 @@ int pt_irq_create_bind( } } /* Calculate dest_vcpu_id for MSI-type pirq migration. */ - dest = MASK_EXTR(pirq_dpci->gmsi.gflags, - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); + dest = XEN_DOMCTL_VMSI_X86_FULL_DEST(pirq_dpci->gmsi.gflags); 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); @@ -807,8 +806,7 @@ static int cf_check _hvm_dpci_msi_eoi( if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) && (pirq_dpci->gmsi.gvec == vector) ) { - unsigned int dest = MASK_EXTR(pirq_dpci->gmsi.gflags, - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); + unsigned int dest = XEN_DOMCTL_VMSI_X86_FULL_DEST(pirq_dpci->gmsi.gflags); bool dest_mode = pirq_dpci->gmsi.gflags & XEN_DOMCTL_VMSI_X86_DM_MASK; if ( vlapic_match_dest(vcpu_vlapic(current), NULL, 0, dest, -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249405.1546863 (Exim 4.92) (envelope-from ) id 1vzZlM-0005S9-DL; Mon, 09 Mar 2026 12:31:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249405.1546863; Mon, 09 Mar 2026 12:31:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlM-0005S2-A1; Mon, 09 Mar 2026 12:31:08 +0000 Received: by outflank-mailman (input) for mailman id 1249405; Mon, 09 Mar 2026 12:31:06 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlK-0005Rg-C0 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:06 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d65fa84b-1bb3-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 13:31:04 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFL73SNz1XLF70 for ; Mon, 9 Mar 2026 12:31:02 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 5eefd4314b3e45ecbcba532335bdac2c; Mon, 09 Mar 2026 12:31:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d65fa84b-1bb3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059463; x=1773329463; bh=LPUSRZy9qbQfIjlYcjFoK4c3M47t8H8Qjn7lVPwxHIc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=IlK72gfVVI0bjEt0VlLAGDMNP0Ak+ZFY1zcNbV9VvcZpV0PDto5Sb8wQ9txK7om6d Uu6jfuuqF/rM99GlgGJExbilrzM3L5DTRQ/0nFW6ADUilgB/jf8BDwPYT2wik8oan9 Qzaix2tre1Nwe5CjjfoF5qpvD6D9JAfSFaR4zNJ2LXScWjvGi5j/ghveRVNQbEx5VY XU8BQ5pgZ9/9YxO6ERNWKRUJ8vJ3D/SxRFxLnQBFIOQQHkYKNLbKFL9FCCWo9xRjs2 MxSxO5mc+cXAZa5eG40cFias3JOxA98rYEo1Ky3Wy4ohDeX5mLTKUSTpGwYop+QKiY fg6OwyOEtQWgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059463; x=1773319963; i=julian.vetter@vates.tech; bh=LPUSRZy9qbQfIjlYcjFoK4c3M47t8H8Qjn7lVPwxHIc=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=t7VofPXt+WCaTpPamHs+teK68iMvC1j5UYKHBUnZOo65YBWj5wLgE0Wyj+srdDxIq WrKJiwRUv48qHBMgE7Vzmq/F2v34yAh9UmMK4F7yg8GyJexWoop44ud2W18JZDVD3c AsGL1Sc+0920gsHYq2BEClHipC0lod0cn+VSjT4bSXLLUb3zf+f9ICbCc2I6J6rGB9 0GJP2wkqFNJm38YjeYF19mT770BRjPbPdL0G1lXNbFjwiR+Xbk9mpcZM1vlx1PAXo5 RP38njTYdJIdu17BW8Sj/XODekSh16Vn51JBt0dVnrLSPnIJYP8vVw59VTGTd8dO4O ZWNuQBmKszp5g== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=201/7]=20x86/vioapic:=20Add=20ioapic=5Fcheck()=20to=20validate=20IO-APIC=20state=20before=20restore?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059461627 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.5eefd4314b3e45ecbcba532335bdac2c?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:02 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Register a check callback for the IOAPIC HVM save/restore entry, following the pattern established by vpic_check() for the virtual PIC. The function first verifies the target domain actually has a virtual IO-APIC, returning -ENODEV otherwise. It then iterates all redirection table entries and rejects any saved state where reserved bit fields are non-zero, ensuring the state being loaded, represents actually reachable hardware state before the restore is committed. Signed-off-by: Julian Vetter --- Changes in V3: - As suggested by Jan, added new patch that does a generic check of the vIOAPIC state before migration --- xen/arch/x86/hvm/vioapic.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index 7c725f9e47..b9acdd8af6 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -594,6 +594,35 @@ int vioapic_get_trigger_mode(const struct domain *d, unsigned int gsi) return vioapic->redirtbl[pin].fields.trig_mode; } +static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h) +{ + const HVM_SAVE_TYPE(IOAPIC) *s; + unsigned int i; + + if ( !has_vioapic(d) ) + return -ENODEV; + + s = hvm_get_entry(IOAPIC, h); + if ( !s ) + return -ENODATA; + + for ( i = 0; i < ARRAY_SIZE(s->redirtbl); i++ ) + { + const union vioapic_redir_entry *e = &s->redirtbl[i]; + + /* + * Check to-be-loaded values are within valid range, for them to + * represent actually reachable state. + */ + if ( e->fields.reserve || + e->fields.reserved[0] || e->fields.reserved[1] || + e->fields.reserved[2] || e->fields.reserved[3] ) + return -EINVAL; + } + + return 0; +} + static int cf_check ioapic_save(struct vcpu *v, hvm_domain_context_t *h) { const struct domain *d = v->domain; -- 2.51.0 -- | Vates XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249406.1546867 (Exim 4.92) (envelope-from ) id 1vzZlM-0005VH-Lp; Mon, 09 Mar 2026 12:31:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249406.1546867; Mon, 09 Mar 2026 12:31:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlM-0005V8-HP; Mon, 09 Mar 2026 12:31:08 +0000 Received: by outflank-mailman (input) for mailman id 1249406; Mon, 09 Mar 2026 12:31:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlL-0005Rg-08 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:07 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d741b392-1bb3-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 13:31:05 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFN4WnPz3XY for ; Mon, 9 Mar 2026 12:31:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id d8fdfcace5ef4539a0100fc8b528ea67; Mon, 09 Mar 2026 12:31:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d741b392-1bb3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059464; x=1773329464; bh=8FwzySD+VeRkqwNwwXfc+WPkvCmclVAnI84/IjWUKr8=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=DayO3pkTxMSxj2crN/XuedBvQAcLuCPvhClPTG8WAfDUCtOGC/0Uhs3lQULL2ALCk nCo+5jUp8tdPdIgDkhJjlIk8jZS6GZNo8mptT+rSsgh8r1pG77NMw+/5/dmqdmYjLH 5epSZ6OYkbLMkW+ecNLu17v/etX31oB5QZTFWvPk/AHUI+Ywdy8hZHyD5NvAexgZGX KtVV6KB0SgnkN40ah7ZP4+RCo5Lilyr6JEHC8Mo09zkDkymRWYoaq58TANQy/Q+gxp YT98rVTFJPhpx/NF05GzpE8bxjCkG4UrURO2Jl6vt+PCNpQKMWQBrfCV6YWJ7m0mcY ydm0h/nfB6HuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059464; x=1773319964; i=julian.vetter@vates.tech; bh=8FwzySD+VeRkqwNwwXfc+WPkvCmclVAnI84/IjWUKr8=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=HyiVpcp/2a1swNSndKKpodpq10hyD8LvqiN9/+/aa3P5tC9zEKyubtXVn7vOUj02F oWNxLjQmYVaaXIiEdR6oMgpqbIkRzvDX18Cnlsw2rnsHuk2ihC0GgrGxOmhT1YIKuv gmSVSkY3MOa1q7ON6mvhpRw2CT3z5//jcS9kGMYUQ3uR9ccDtQWBt7nXVLOY9a+DFu lXijYXiQoJWTRWKIxmZZ0JBEz1/BcH5xtGE3pfJEmxUEckhoVwZZYqSHKN7EmLctbe Fcej+8YS4Wx+61MI/SzjGdJTTVHOE3krefmTjZhYk1QI/nulZ5lFUfqafzbI3NsMRa rhWYvAnhEl+Cg== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=207/7]=20x86/cpuid:=20Advertise=20XEN=5FHVM=5FCPUID=5FEXT=5FDEST=5FID=20when=20device=20model=20opts=20in?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059463359 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-7-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.d8fdfcace5ef4539a0100fc8b528ea67?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Set the XEN_HVM_CPUID_EXT_DEST_ID bit in the HVM hypervisor CPUID leaf only when the device model has called XEN_DMOP_enable_ext_dest_id, signalling it will use XEN_DMOP_bind_pt_msi_irq for passthrough MSIs. This guarantees that Xen will decode the extended destination bits from the raw MSI address internally, so the device model does not need to understand the encoding itself. This ensures that an old device model that still uses XEN_DOMCTL_bind_pt_irq will not trigger extended ID usage in the guest, preserving backwards compatibility. However a device model that calls XEN_DMOP_enable_ext_dest_id then has to use XEN_DMOP_{bind,unbind}_pt_msi_irq, and enables support for x2APIC destination IDs above 255. Signed-off-by: Julian Vetter --- Changes in V3: - Addressed feedback from Jan and Roger -> Don't advertise the XEN_HVM_CPUID_EXT_DEST_ID unconditionally --- xen/arch/x86/cpuid.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index 5decfad8cd..c1f82f83ea 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -148,6 +148,18 @@ static void cpuid_hypervisor_leaves(const struct vcpu *v, uint32_t leaf, res->a |= XEN_HVM_CPUID_DOMID_PRESENT; res->c = d->domain_id; + /* + * Advertise extended destination ID support only when the device model + * has opted in via XEN_DMOP_enable_ext_dest_id, making sure it will + * use XEN_DMOP_bind_pt_msi_irq for passthrough MSI (passing raw + * addr/data so Xen can decode extended bits). This allows guests to + * use bits 11:5 of the MSI address and bits 55:49 of the IO-APIC RTE + * for additional destination ID bits, expanding the addressable APIC + * ID range from 8 to 15 bits. + */ + if ( d->arch.hvm.ext_dest_id_enabled ) + res->a |= XEN_HVM_CPUID_EXT_DEST_ID; + /* * Per-vCPU event channel upcalls are implemented and work * correctly with PIRQs routed over event channels. -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:31:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:31:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249411.1546915 (Exim 4.92) (envelope-from ) id 1vzZlQ-0006lv-Dl; Mon, 09 Mar 2026 12:31:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249411.1546915; Mon, 09 Mar 2026 12:31:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlQ-0006lT-9G; Mon, 09 Mar 2026 12:31:12 +0000 Received: by outflank-mailman (input) for mailman id 1249411; Mon, 09 Mar 2026 12:31:11 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzZlO-0005Rm-SE for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:31:10 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d944a38b-1bb3-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:31:08 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fTxFN1w12z1XLF8j for ; Mon, 9 Mar 2026 12:31:04 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 38f089334e9845c5a00cae713d259456; Mon, 09 Mar 2026 12:31:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d944a38b-1bb3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773059464; x=1773329464; bh=8+F/N10Okp6RfYj1zYdJt0ofiEUV907OfuUloITkdiw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=wSM3FQH5mNlY+zX9aKEo3rsRUwYf0BWwg/YLlRJBE2J6wDfRxNgQTpCfIStEaJDpW /PXz9cff2jtHpHQpm16eZvp2Wu6aCvYH7qMcKHnC3+Gj1urYIoIfoOGJIk7CKOsYB1 pmFgtQh24WlxT0oh67lWZB8r8SuwjXQw9E2tWt8X3xkI0hyM+Ia0C8qJ8GBMbxhh48 UEL7ABQEALS9WfdUREsprMnlUh6G5clXeb5BdLvdNikrygLFrtCjnm39JamFoJGuoB uJU7YjzCTOYO/3aeEn2p9fnXr7PAHSdKV8nPlBvBaaD0Ul39TZUl9R5tPaNMsgAExi cgDrMuJsD8ELg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773059464; x=1773319964; i=julian.vetter@vates.tech; bh=8+F/N10Okp6RfYj1zYdJt0ofiEUV907OfuUloITkdiw=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=SfTmeYvB+GVhEgrnLB1artUKzYiFGONKBzb8OMJzg8NDKlJOhts2mSQVROHVr0PZy z6dPHOnPb8ZjvWmw9wahgVSh/XGlknesZxa+5g5hD8WFLrabRjIqMroUlYqh7Rhi7a 3Qdz+HVwDfKgT5k3JaIafvH5GmoNqfeiBlR+W/poOsr9b2uHpiDTJnVz41iBoTDQzZ uGktBdWo1Xs7berDVb+QtCOjzrb01NkhsiZdSG5Qav5q02pa0FW7e9kuE73cAc+Z9Y PyvcZ//bXzJzQmeQbLn/+imle9ZG3JvmJy9jdMuIGltJg3NgPklHARCdInrBpOHRHL lfLLIQvv+P7cg== From: "Julian Vetter" Subject: =?utf-8?Q?[PATCH=20v3=206/7]=20x86/dmop:=20Add=20XEN=5FDMOP=5Fenable=5Fext=5Fdest=5Fid=20DM=20op?= X-Mailer: git-send-email 2.51.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773059463079 To: xen-devel@lists.xenproject.org Cc: "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Stefano Stabellini" , "Juergen Gross" , "Julien Grall" , "Julian Vetter" Message-Id: <20260309123055.880050-6-julian.vetter@vates.tech> In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> References: <20260309123055.880050-1-julian.vetter@vates.tech> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.38f089334e9845c5a00cae713d259456?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 12:31:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Xen cannot simply advertise XEN_HVM_CPUID_EXT_DEST_ID to the guest without knowing that the device model will handle extended destination IDs correctly for passthrough MSIs. A device model that still uses XEN_DOMCTL_bind_pt_irq would pass only the low 8 bits of the destination ID, misrouting interrupts to vCPUs with APIC IDs greater than 255. So, add a DM op XEN_DMOP_enable_ext_dest_id that the device model can call during domain setup (before vCPUs are started) to signal that it will use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings. When called, Xen sets ext_dest_id_enabled in struct hvm_domain, so it's visible to the guest via CPUID. Signed-off-by: Julian Vetter --- Changes in V3: - New patch addressing feedback from Roger --- tools/include/xendevicemodel.h | 14 ++++++++++++++ tools/libs/devicemodel/core.c | 10 ++++++++++ xen/arch/x86/hvm/dm.c | 5 +++++ xen/arch/x86/include/asm/hvm/domain.h | 7 +++++++ xen/include/public/hvm/dm_op.h | 9 +++++++++ 5 files changed, 45 insertions(+) diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h index 0d5d7b0ff1..270d76fe9c 100644 --- a/tools/include/xendevicemodel.h +++ b/tools/include/xendevicemodel.h @@ -412,6 +412,20 @@ int xendevicemodel_unbind_pt_msi_irq( xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, uint8_t gvec, uint64_t msi_addr, uint32_t msi_data); +/** + * This function signals to Xen that this device model will use + * xendevicemodel_bind_pt_msi_irq() for all passthrough MSI bindings. + * After this call, Xen will advertise XEN_HVM_CPUID_EXT_DEST_ID to the + * guest, enabling 15-bit destination IDs. Must be called before the + * guest vCPUs are started! + * + * @parm dmod a handle to an open devicemodel interface. + * @parm domid the domain id to be serviced. + * @return 0 on success, -1 on failure. + */ +int xendevicemodel_enable_ext_dest_id( + xendevicemodel_handle *dmod, domid_t domid); + #endif /* XENDEVICEMODEL_H */ /* diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index 4a52fe4750..03838aa37b 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -689,6 +689,16 @@ int xendevicemodel_unbind_pt_msi_irq( return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); } +int xendevicemodel_enable_ext_dest_id( + xendevicemodel_handle *dmod, domid_t domid) +{ + struct xen_dm_op op = { + .op = XEN_DMOP_enable_ext_dest_id, + }; + + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); +} + int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid) { return osdep_xendevicemodel_restrict(dmod, domid); diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c index 3d530d948f..7738400540 100644 --- a/xen/arch/x86/hvm/dm.c +++ b/xen/arch/x86/hvm/dm.c @@ -374,6 +374,7 @@ int dm_op(const struct dmop_args *op_args) [XEN_DMOP_nr_vcpus] = sizeof(struct xen_dm_op_nr_vcpus), [XEN_DMOP_bind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), [XEN_DMOP_unbind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), + [XEN_DMOP_enable_ext_dest_id] = 0, }; rc = rcu_lock_remote_domain_by_id(op_args->domid, &d); @@ -708,6 +709,10 @@ int dm_op(const struct dmop_args *op_args) break; } + case XEN_DMOP_enable_ext_dest_id: + d->arch.hvm.ext_dest_id_enabled = true; + break; + default: rc = ioreq_server_dm_op(&op, d, &const_op); break; diff --git a/xen/arch/x86/include/asm/hvm/domain.h b/xen/arch/x86/include/asm/hvm/domain.h index abf9bc448d..770bc96970 100644 --- a/xen/arch/x86/include/asm/hvm/domain.h +++ b/xen/arch/x86/include/asm/hvm/domain.h @@ -105,6 +105,13 @@ struct hvm_domain { /* Compatibility setting for a bug in x2APIC LDR */ bool bug_x2apic_ldr_vcpu_id; + /* + * Set by the device model via XEN_DMOP_enable_ext_dest_id to indicate + * it uses XEN_DMOP_bind_pt_msi_irq (raw MSI addr/data) for passthrough. + * Controls advertisement of XEN_HVM_CPUID_EXT_DEST_ID to the guest. + */ + bool ext_dest_id_enabled; + /* hypervisor intercepted msix table */ struct list_head msixtbl_list; diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h index fd0f3a6a99..2814fe1c3d 100644 --- a/xen/include/public/hvm/dm_op.h +++ b/xen/include/public/hvm/dm_op.h @@ -447,6 +447,15 @@ 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 +/* + * 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 + struct xen_dm_op_bind_pt_msi_irq { /* IN - physical IRQ (pirq) */ uint32_t machine_irq; -- 2.51.0 -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 12:52:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 12:52:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249475.1546926 (Exim 4.92) (envelope-from ) id 1vza5i-0003QD-Vv; Mon, 09 Mar 2026 12:52:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249475.1546926; Mon, 09 Mar 2026 12:52:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vza5i-0003Q6-RY; Mon, 09 Mar 2026 12:52:10 +0000 Received: by outflank-mailman (input) for mailman id 1249475; Mon, 09 Mar 2026 12:52:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vza5h-0003Q0-Mv for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 12:52:09 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c6f9d7fa-1bb6-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 13:52:06 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 839E6600AE; Mon, 9 Mar 2026 12:52:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DDC24C4AF09; Mon, 9 Mar 2026 12:52:04 +0000 (UTC) Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id C5D69F40069; Mon, 9 Mar 2026 08:52:03 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Mon, 09 Mar 2026 08:52:03 -0400 Received: by mailuser.phl.internal (Postfix, from userid 501) id 999C9700065; Mon, 9 Mar 2026 08:52:03 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c6f9d7fa-1bb6-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773060725; bh=+l3GAe2jq8eBBZZbhrY4uib7DNJV8apVKmihOAiT6Gw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=TSHrbFKPoRXfsXlhpwIxl3kZJwS2F2BttFk5QfPdMtO/2V51HyX6rtBr4NBX7fAnm Mbo12H210Mu0rxpwX3x/oqe8N+CIQ1mUlnZIhdoYNbU87xSCxSCgXUoF4bHd6DbwKL +j3OY3s1TM2gTxkaNs9J/IL2QVgVH5IxrNLE7MfKcJzecIH3329B0ZuHStfd7xZVaf 22b7kkG0HghO1/nWUHDjQHfrEUUYYxXoIdcvDQSPYVjLfLisQaKQqnPzaqg7HmmYlz 7bNv+jsnCFNqTQbCbDvjVrZ0nnUx4ye+D9QI0EaF1Hfh3XWKkSdZs4NO48m/Ck6zau udgcC2oFo/FuA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvjeekudehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpeefhefgtefgkefhgfdvffdukeejheeuvedthfdtiefhleejhfefjeffieeu jeefteenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprghrugdomhgvshhmthhprghuthhhphgv rhhsohhnrghlihhthidqudeijedthedttdejledqfeefvdduieegudehqdgrrhgusgeppe hkvghrnhgvlhdrohhrghesfihorhhkohhfrghrugdrtghomhdpnhgspghrtghpthhtohep iedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepshhouhhmhigrjhihohhtihhsrg hrkhgrrhdvfeesghhmrghilhdrtghomhdprhgtphhtthhopehmrghrmhgrrhgvkhesihhn vhhishhisghlvghthhhinhhgshhlrggsrdgtohhmpdhrtghpthhtohepihhlihgrshdrrg hprghlohguihhmrghssehlihhnrghrohdrohhrghdprhgtphhtthhopeigvghnqdguvghv vghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehlihhnuh igqdgvfhhisehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidq khgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: ice86485a:Fastmail X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: Al3Xjs-asQIN Date: Mon, 09 Mar 2026 13:51:43 +0100 From: "Ard Biesheuvel" To: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , linux-kernel@vger.kernel.org Cc: "Soumyajyotii Ssarkar" , xen-devel@lists.xenproject.org, "Ilias Apalodimas" , linux-efi@vger.kernel.org Message-Id: <2f8e9891-ef08-4094-ae86-c1b6d2dbe06c@app.fastmail.com> In-Reply-To: References: Subject: Re: [PATCH 0/2] Allow using BGRT table under Xen dom0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 9 Mar 2026, at 13:17, Marek Marczykowski-G=C3=B3recki wrote: > For a long time Xen was invalidating BGRT table as it was reclaiming > BootServicesData memory (where boot graphics is located). This is now = changing, > and the boot graphics is preserved. This series has necessary changes = to > actually make Linux use the preserved graphics. > > This is a companion series to Xen side at > https://lore.kernel.org/xen-devel/20260305191810.31033-1-soumyajyotisa= rkar23@gmail.com/ > > CC: Soumyajyotii Ssarkar > Cc: xen-devel@lists.xenproject.org > Cc: Ard Biesheuvel (maintainer:EXTENSIBLE FIRMWARE=20 > INTERFACE (EFI)) > Cc: Ilias Apalodimas (reviewer:EXTENSIBL= E=20 > FIRMWARE INTERFACE (EFI)) > Cc: linux-efi@vger.kernel.org (open list:EXTENSIBLE FIRMWARE INTERFACE=20 > (EFI)) > > Marek Marczykowski-G=C3=B3recki (2): > efi: make efi_mem_type() and efi_mem_attributes() work on Xen PV > efi: Enable BGRT loading under Xen > > drivers/firmware/efi/efi-bgrt.c | 7 +++++-- > drivers/firmware/efi/efi.c | 27 +++++++++------------------ > 2 files changed, 14 insertions(+), 20 deletions(-) > Looks good to me - if nobody else has any concerns, I'll queue this up f= or v7.1 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 13:26:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 13:26:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249496.1546962 (Exim 4.92) (envelope-from ) id 1vzaco-000855-SD; Mon, 09 Mar 2026 13:26:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249496.1546962; Mon, 09 Mar 2026 13:26:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzaco-00084y-Pc; Mon, 09 Mar 2026 13:26:22 +0000 Received: by outflank-mailman (input) for mailman id 1249496; Mon, 09 Mar 2026 13:26:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzaco-00084s-8e for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 13:26:22 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8ed9c572-1bbb-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 14:26:20 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM8PR03MB6232.namprd03.prod.outlook.com (2603:10b6:8:3d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 13:26:12 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.023; Mon, 9 Mar 2026 13:26:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8ed9c572-1bbb-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=TtP1QJ7VIkT8vd01GEBRFmexd1GmbKxOds8N2Kulda2UQ8skGGSM8YkZ3v0wI1bcw4/vAQ8F1gSs3Vp7TbLHPXdo34qMgj6WofGRhYiV0rwas3w7zKEePUpHdf+4+mL+yVSpQqDsWk/ZVRJnSi8jqT/SnXEYDjzTiJ2ZxWh9q2InL+0g8yp5f52+lLShpx9nBcsIh6CjDxM+o42cHpNYwZzow3qMYvRb8ylthvYG4O6aeTdvGMNrTda8Ns7nEAbEYhUkXxhO8RnjvEQVoBQ2tskfd/0iDgddrKHbFeAJZ0ILiCfWaLSWaYh4R8F4zqAlYW88rPuVdKErhViqhudWWA== 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=l7n5O3eHZxb0m8XX25UCo/ymu9WkcyBzlfUUnlzR+e0=; b=SwYcl3vsX6lc3NyItOTZfRqRI8YPGO7T8YYIe/aLcMG824v8bHl2Y4erjXRzfZRaWH0375CTx3OiEZ+KJ17/qmCsv/eCTNVUPbKyPeEBTnIqhd3zqO1WU8C47LDyosydPwOHhLOW99d3vqe6RcjK5rsd3fPgYYsIyE2xgTY3roCGUNL4YioQGwbT4jCQ2ZAfFMGjhlt00qDYDBTqTlJLV/7gH4CoHFqb7pqbyjpZIvBmlzZtT7j4VhhGetommWF9xi49fAYk0dwFeqBCrB4E+XJHqK2OPUAIRLv2o7dLe6YRQvpoWYoliS8zSVLuLtv4w2Ys4hrgU+dIQdMMHkGi5g== 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=l7n5O3eHZxb0m8XX25UCo/ymu9WkcyBzlfUUnlzR+e0=; b=sNQ0LbAUiotXBWKd2Xyh6Fgg6wE0C81HqB5qUpjka3dA9CqmwWbGGi7jrS/jJZvylx3zMBCRiXgb2rLyYw068dSfoKHvldaCW3xQUwNntTdW4Zlr7fdtL298km74RnRUPD9+4DNqkJKFSuO+gCMxGeKt9C133Nz2fLMeZEg0lBE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Mon, 9 Mar 2026 14:26:09 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall Subject: Re: [PATCH v3 6/7] x86/dmop: Add XEN_DMOP_enable_ext_dest_id DM op Message-ID: References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-6-julian.vetter@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260309123055.880050-6-julian.vetter@vates.tech> X-ClientProxiedBy: MA2P292CA0022.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250::11) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM8PR03MB6232:EE_ X-MS-Office365-Filtering-Correlation-Id: d86c132f-f008-4dec-c434-08de7ddf6ec9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024; X-Microsoft-Antispam-Message-Info: XvzjhGbOF+VlJKbv6FeAQhjk6ewuC8gBz+x929U6CY8F0q+e6jl+Q1Z/SQQdR8l50vXCxdpOfWtdnL7R+tDa9g+o6e4unvOUYMQ3tKkce5PuJnmHYMP9fri1iKxvNI26AGNcAun6gkjvjH9cx84MQs+shrqGtOxVG5hDLz04xz5dp3JvSwNm+9MkLIkqUB7eLIIoHgzFEnIz61FIHm3p68IxwtOqMzS8bQF5AiDOmGQ1CabWTOk92/JtRxQ5vhugorFqlhzj96SWKkMYY00bA/RpmzVx3RiRzfeY+PcNF1xRcg7WAzS87FRWDmkPPJMDuo7i49zZvj9D7NKw5WgWajl7AR+y+lau2rcocusyhlRhGZIfCC9SMXU02Aq2uFoHTeFIfwcfmh3QyMJwP+ZG5IaI5JAuo4PF04CaEuRnlpqbG6GWm64Lgb+LDm4imfgx/ciQOoTtPHYaGgVCeOM+RVNrkEf7/S0/t6Doeqsb9AAlpzzpIVDzHQ5F+I7AfPOdS1qR8SNMfd1SCHVNaMT3E3y4ErvYIBKC2SHP0cdSFjlp1mTYKKeV5WgfeJcZEN9A963aFmCy+nTeOoZPwDuitZ/hcXQ0xNoH2BUWATd9VU/Zwt9/njjdeAayuyDiOi9gEzNe21FprBUx3vW7EDTQKoniPmFeUytMJTuqgOzU1ZTyMvV4+6em5B/Hmbv/iJ3IQGCAAoGW1PUlnM6ls93CMEECnNZIhP8kxfVDc7838uo= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b3cxalVBZWFGVGtxRmY3cVMrUGlwUkQrNnZXZDE4Yit1SDFUdDkyaGwyZUJQ?= =?utf-8?B?dTdDYnVoVXZkbjBSdExpTUdnaDl2QjEveVA5aU9zTzF1aW44QlBJUENRSlVw?= =?utf-8?B?eGxva2JiS2pZSVFFbmVWUVdXUzJWWWcxTW16cXQyeVRFdTJkQ0Q1R3d4djNN?= =?utf-8?B?aHBSRXZuc3hRWUFBMTlKSkxxKzVlbVhGTTIvam1IRktZZDJtaFFLUjFLMnFN?= =?utf-8?B?SG14ODd1M0x6aGE2NVI4UWMvbWNUOFhNKzB4N24ySkdsYU52ODQzdk16M2E2?= =?utf-8?B?WUI1TW1wWFVsSXFrQmorbDFyaFVrVlVoV2ZFUjd4Tmh4NUpIRldqbVlGbllC?= =?utf-8?B?QlJsYUZoS2piNTg1bDNMRW5VbGw1a2YvUDdINUFCa1FBS2RHR2xvRzRwUU1a?= =?utf-8?B?bHlDekNGTHlxVDQxQ2lmTGlGS0xXY0d6WHI0Q3hwODhQVEdjY3NzMi8zb2J2?= =?utf-8?B?azZ2Mk44QWxlL0I5MFc5TlcwQUFsempEVmxScmNUQzZVYnVab2Y5SmpiUEpw?= =?utf-8?B?d2xWcmdjN1pGT1ZZbW1YR0pLVHZGZUtUTXNuRzFHdCtYNXFpRGJOTzl3cGpq?= =?utf-8?B?eHRYcUtUaUVIajdaZEI1RS9EWk1BTURiNzZVcUhVOW9zRldlTTF6YzJZcWRP?= =?utf-8?B?WVRTUHIvUFVPaFBTdWVXQlJKT09pbEdDVDJMZTZzaEhwUXRobHluQVlwbzg5?= =?utf-8?B?UjdHOXd4SHMwdkxMb1JrVHBwRHc5bjlpNm5SRXBERVRtaHJPVVdCSXVBVjJt?= =?utf-8?B?Mm5BWVFoZW9STE04WkpGc2ttTXBoc3Q3ZThhbWt4c3dXZ1RiNUNjbE5DRW1Z?= =?utf-8?B?RGx6OUVDWDl4b0dUeFYzMHlrOEZUMWd6V3d1K0FxcWZLeW5DWUpOazR6Mysz?= =?utf-8?B?dCtLZ2xUQ3VIT3VxMktPVXpMaDk5SVp6a1NUZkhMSDZ5VVBoWk8zK3hzaG9P?= =?utf-8?B?OVl1NncwTnBTbHFNQWFhRURzWEk5V2hhU3BDV25FaGlZMmdFeVJGbzZJUHpY?= =?utf-8?B?aWVzWVZZTEVGYVd1VnZjbXlLVjR2RHhvVnZGZDl1TE5rR3pveXExdHVqZ1E1?= =?utf-8?B?aHoxclFGa1FsVHFsYkF5UFlhdlVrTHBDOXUwTUtHUHpoU3ZXVmZVVUdSeFZz?= =?utf-8?B?aUhqbWZkU1JDcVhUalhsTWk5cHp6dnZSK2o3Sk1zMnRIV29SVE4yajBoUHFX?= =?utf-8?B?Vld5WHEwZjBuc1Znc3BXQ0hnbmU0UmZUMmFub3g5clR5ekZRcnhSL3pPcjVZ?= =?utf-8?B?aWNTTmFFZjdCMlB1TTBZU2k1WUJYay9IcklncnU5a1JHMy9hUWlGMXJxbGhu?= =?utf-8?B?d1IrVGpFcE94amptbmgwTzc2UmtUb01VTGV1THg1Z2dCckNJVHhDNHEzMU9l?= =?utf-8?B?ZUxZVGk1QUpoZGNSNXQwS2YzZjNMWjZiaFhXNlBBMkUvRG5jVmR3YlBsU3l4?= =?utf-8?B?OVprL24rQTNUMnBTanF4SjZVbUdRL3JGNHlLL2I2ZXAzSWVGUXRVOWtaQTdn?= =?utf-8?B?SmppTlo4aUNOUk5vOStDenp3akc1SzVjOUhXWkIyRmhVb2x5djlRdmhPY0hv?= =?utf-8?B?STEvbzlIaE02T0RpRUFhVW94Ry9aVkJqeExvS2tZVzRPWUhyOTd6QW1VaHJJ?= =?utf-8?B?b0hHWkVZMytsOVhCK2pESkJuU3UrbmM1WW54WGZIcmxNMUxWZlk4NlB5V2lP?= =?utf-8?B?WkUzcVczK01kNjdPVVdLM3U5T1lyU1hvaitkNFo5dnI0UUZVVS9MY0R1VFRi?= =?utf-8?B?bStDVElUZi9WdksvTUI1bW1KaG1RTkZ1ZStmSk5GaVh1bkR2SVRaRm5KTk1I?= =?utf-8?B?MkxCaFpIYlNMbVJxaG5nN1I0S01kWC84NWE2RHFMMmJKMVBUOUl6Zk9oc1Za?= =?utf-8?B?MWtIM2hLcWN4MlFOUTFIRW8zODVuc3IwZm00Z2lqMmdrT2Y5WGVNZHZiNUtB?= =?utf-8?B?Y0hFMnJBRlpnUm1MbWxVY09Xd0Q2YW45bzRncHFtV1E3UjFCVEhXNWhxUUhQ?= =?utf-8?B?Ni9teEhvZ2dmM3FBSXBzM2hpc1dxWFB1OEduU3J6ekNySTdKSEZ6ZnVUWUpa?= =?utf-8?B?OVg3cFNHZm00TzQ5NmpqWFU0cm9IeUMrU0ZGWG1BdDV3MXVWYmFrVEZPQWtx?= =?utf-8?B?TEtLR3lJRmxKSjZrZ05WU1VGc29uQ041TlZQZm1YQ2RGV3lXK1FVTURtTisv?= =?utf-8?B?RjhqcDlGcWJONFgvM2JCcXhCalB1cmtwRGlMajlpVFZLd2J2V1JiUElpVVVP?= =?utf-8?B?dGdSZ2svSzJieHpkM09mekdOTURDYkx6Q3hHN0tDa2MyNVRZU1piKzVmeE9a?= =?utf-8?B?K1JHcTAwaEU0R1Z5b3VEemhWRGdVd2NsbmNtRGlnQkxUWTFKRDc5UT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: d86c132f-f008-4dec-c434-08de7ddf6ec9 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 13:26:12.6036 (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: L3K97Ok4AZtVeGd2zeztPi9LMX5A+ytvOFRakzvERwUiWLj5aeePk0Ir2yQqRxM4QEdlGmlZ6JM2TXGTf1fAFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR03MB6232 On Mon, Mar 09, 2026 at 12:31:03PM +0000, Julian Vetter wrote: > Xen cannot simply advertise XEN_HVM_CPUID_EXT_DEST_ID to the guest > without knowing that the device model will handle extended destination > IDs correctly for passthrough MSIs. A device model that still uses > XEN_DOMCTL_bind_pt_irq would pass only the low 8 bits of the destination > ID, misrouting interrupts to vCPUs with APIC IDs greater than 255. So, > add a DM op XEN_DMOP_enable_ext_dest_id that the device model can call > during domain setup (before vCPUs are started) to signal that it will > use XEN_DMOP_bind_pt_msi_irq for all passthrough MSI bindings. When > called, Xen sets ext_dest_id_enabled in struct hvm_domain, so it's > visible to the guest via CPUID. Have you considered whether you could re-use the padding in XEN_DMOP_create_ioreq_server to signal whether the device model supports Extended ID parsing? Also, you might want some negotiation between multiple ioreq servers on the same domain. IOW: is multiple ioreq servers are registered ahead of the domain having finished creation you could level whether extended ID should be announced. For ioreqs that are registered after the domain have started you need to enforce the currently set Extended ID support. If the domain is running, and Extended ID is advertised you must prevent registering any new ioreq that doesn't support Extended ID. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 09 13:38:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 13:38:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249507.1546973 (Exim 4.92) (envelope-from ) id 1vzaoo-0001Mk-UI; Mon, 09 Mar 2026 13:38:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249507.1546973; Mon, 09 Mar 2026 13: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 ) id 1vzaoo-0001Md-QP; Mon, 09 Mar 2026 13:38:46 +0000 Received: by outflank-mailman (input) for mailman id 1249507; Mon, 09 Mar 2026 13:38:45 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzaon-0001MX-QD for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 13:38:45 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 48fdf30f-1bbd-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 14:38:42 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by IA1PR03MB8047.namprd03.prod.outlook.com (2603:10b6:208:596::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 13:38:29 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.023; Mon, 9 Mar 2026 13:38:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48fdf30f-1bbd-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Jhp+xVVhAZo2OX+UivxzzwGfZOmP9aacCe5it+UQEt3ShqeRA71Dvq6NDCtmJmaSZQozDuxT3Jfc20oGGF9X02PvykoTGGve3O/STervJ1t7eL6u86SmXFAbNaG75v+cjm1JTQraJuts9DSS3UATc5EB+9mAMkpg10rUWyBqGRBCMuNz4yi/JYQEIUxzWciJDy/jyV1jUvomfWbK5UWc+UZ3kfBV5V/dMfCrCXcYIcr9o4NNyKMkPUONtovToBlmYQPddDgWvmh4XCuKDdEe6DCE9q0cbz4hHh4LoAxtg1XRCxBXcuZkQOPtnVil6Ia19p/FlFJf5EBveBtRx9D/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=N3Kjmze1PvonsWyS6ZRnDjxJM008BAiAB/e5vCFFx6s=; b=gvZ1Cd5o/KOKbvMJxIGcvLjLlrQ3aHXEYrhn3C9YJmtnwbZMAHcFP2SGtrlJvVv9ynSzWsCJag1CgE7Trisi6+SI10SskfFku9qZd/0iFOfO0ZbOdT3fBlbs1n8Js/lXIuuCfWjmM0tMKydYUJRtaiG6LEeF8kG0wztUBoqZcK8wJfIITq9Z//dxBx6A9NyW3YIErdRcT+gl4yjpklwV2cbmfCAfMOXJK9Dng5mQs1MCuA/ZZNizHUiGKhM5yMSRdc7Sj4OnGBU1stsRnf22ps10SAsGwajgN3M9PRSR6iAL4awW0lW6r0/G0K+4ykHx4kQ4U8KVVgYGCIeE9V8W4w== 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=N3Kjmze1PvonsWyS6ZRnDjxJM008BAiAB/e5vCFFx6s=; b=V4zrfeiZc5cjjwV1ixVQLLUMwqDQXW008VuzSdO26v3wvmA4NrkCsuJkL9gtiaem/pGWbgCAP3d8LTpAFCqgzgR4VxAg02nv5WYk8E5IiLehNdtvDGVXytgd2w76cHIGxbJxDc861y+FIPsNRVR1nzCGlWzptbf0fqUfP2uZZ2g= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Mon, 9 Mar 2026 14:38:34 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall Subject: Re: [PATCH v3 5/7] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM ops Message-ID: References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-5-julian.vetter@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260309123055.880050-5-julian.vetter@vates.tech> X-ClientProxiedBy: BL0PR05CA0016.namprd05.prod.outlook.com (2603:10b6:208:91::26) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|IA1PR03MB8047:EE_ X-MS-Office365-Filtering-Correlation-Id: c62b4e96-6767-4c1a-fae5-08de7de12a9a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7053199007; X-Microsoft-Antispam-Message-Info: m7ffxQikZYey/DUm2ZrptAXIWCtLw5dpYBso9/Cm5UFUN86kCJe2IlqX7ZsnSY7rIAx3uU/6AY59TaEgd6YZ8xBMEdomaz+V0FONaU1ymNAFMGZUHXvCtCxVyFIzNdGYoTHSBQqrpTGbzovTNSe3RtsN5Km05rpFbHCdAXNzlkGjLkrYECkBB1m4EILB1CNGseYLlDU5ENmv/l6NMJhFkzE6yND1FpfQKJji0goZCFvFwzEEuJcYZQ0S2ltisHCQhs97RAVU44VtSpsl+PTb0d4/t8tb+IXeU4sY16NcQljChmUglH7q0cxmz/lCUPDfe6YFcf3Sp/Gv5PcbwriVofR2aZweQL1+HHZ9ogfOyTPUvVTcaRYGRMEPxnEbC6KVYnzZ/0ZWnxLpruOgtyJvy+Sf2onoD3nduJm/MSy8IXiw2BOXsExv+nXQvtmoVNNNf7VwV48mbBe7zWlQXZ3wKVoE53qcg0qIMihXNGZO6KQ4odq6EFIOTHzot4dxL8c+MAT/znutd923itTzDuaCbuPgXhMBr5hVczzP97Vjwl0kd4+fuc9UZxklGFZv6MpG6MTVPoJt8pJJ0vb5ojbWoQ8lE7ESBtcFj2S2q6K/ClIRrpEJrSbtOldOJBcbF6aLwcb8imPc2bvcfZhtDqOYAUYRhI/HJMltekIKwQX1DxNksZHmXOOaJ/18ND6ib0mO X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M2Y0STRMN0U5UExTa04vK3QrRUQyQ1A0MytoTVVsQ0hpdU1Ba0d0T1V0WFVj?= =?utf-8?B?ckRLOHVNMTNiZUtyTWsxYXhDYVF6WnJtVU9ramNzOWU4VUFvYjdhZGRFNVVS?= =?utf-8?B?ZWd4WTB4ZEJVekJSdDJlUXhPMFBVMGZkSDF5dDR0V1lZcEg2dEFxNUI2Z20r?= =?utf-8?B?b01EbjFSQmNGOStkQjZhU05CZm13Q2xackxjQjFSSHdYR3BpdWJ4ek0wUFBV?= =?utf-8?B?Z2FjUUZiNDJ3NmJGMnJVK2dGaTZpcmRZc2xEV0wrZ0I1QWhCZ0FJYTB6cWhG?= =?utf-8?B?eUFCZWMyN2d2VXJKOVpBTXZGTFVZQkFmTkI1ZEtGdzB2MFIyYU1Ua0x6WXF6?= =?utf-8?B?YmZTN3piWjBaRUgxNytFSWd3ZitoZlFrRkl1Z0xRU1hCOWt5N0dnbUpTeGRS?= =?utf-8?B?dSt4K2Y3cWVyN3Y2ZWFINUcrTGw5Q1RtMHR0Q0dDL0pYSGNYMDlQQUZ4ODVS?= =?utf-8?B?OUJSSzIwbjl0dXZyM0dGVDJjVXVaVGJHNm9CWTVhbmg0d1RWNkNpNWo2QkFE?= =?utf-8?B?UHFRQk5iUWxrYnlVVUxRUVFUTW5Xa1hva0Z6NlFpU0U5TDNkQUVVTDZPQkNK?= =?utf-8?B?bDM0YjBrQUFTNGNpSitLSjQxVnR5c2VTbTVNQklDa2pJWGtYOXcvbit1cU82?= =?utf-8?B?dGJvcGh3UGI3Qy9rUjNNckZJVE9rZVBza3NReitQVmFhS0lnaFhFSE51c3hp?= =?utf-8?B?dFhkV2FuSWRFcGkreGVlY0hRVFZpOE5jOFpVR1kvTjBJaGxZc0t2dzZsRGZO?= =?utf-8?B?L0d4dzZiblY0d0tsSndZRk1SY01VL2xIbjEya2p3ZHNXRnM4bmVUNWRJcTZ4?= =?utf-8?B?bXFMSkNrbEV3NkhWVlFNbmFNRStRcEZyUmpHNFdsSnBPVk1VdUpSY3d4SEVp?= =?utf-8?B?aUU3L2plYTJTaWlYUkVrYVloajkwQ256OWcyaFgvcEpJNmpTdkVKUjEvd2V5?= =?utf-8?B?dUZqNTF0ZTR2WVNSM2pWT0VXVTRHZkZXWU9ERWE5bE4zYVJrQSttTWxaZGdU?= =?utf-8?B?cnNwVkg2VE5VNHBqdWZBRE0xUzJMRnV3azJ4Ui92d2ROV2ZSRkVSeURUd09Q?= =?utf-8?B?MlVzK1c5bHV4Y0dtR0FobGpyYzVHWU43T05RbS9xNlZYWHkzTGxKd0tTYk96?= =?utf-8?B?cVI3V2xEbWZwdXVpR1RpUHdGNVp3V3RMQjBrZng5emdTK1V2MTNRbFJiU3hL?= =?utf-8?B?akxoNDZXa010NHhHZm9oQ3ZpRTBvbFhXQUU1a1lzTDVQYjBObHRqdG1iR1la?= =?utf-8?B?THR0T2FFZWJCWWRqVmIvSHFvdGZKTGpodmhzZGhVYzdQMGk1Zmt4bk1YNXNi?= =?utf-8?B?OW9QT09KVTVVZkdyT1hldUFaSkdQYVRtTWwzd3lUZ3d2R0FVWFBPZlNYMHpV?= =?utf-8?B?THVJRVBaN1hXTVhGSW50d0J2SzNHRHlWM01yTWxvdFJGOEI4L2lRZDJGQzdY?= =?utf-8?B?VkN1MkhKZjk2LzNTNWFkd29IT0g3QlpmSjFuNllmSnVLQlNaa29xNEF4U2JV?= =?utf-8?B?VXVHdk1YbmVrZEhtbkNwVkRDT0xDSisxSWlDZHJaQkMraEgrQW9KbzZBSXRU?= =?utf-8?B?ZHVKeHNPT3VSMjEwVm0wMTBHQlJWUGtDVW0zM01tUzYxcGxSc28zUXc2b2xv?= =?utf-8?B?bmpCb0RZRkJjanhJcXJoSmJ6eml6Ynl1YlJyUnF1c2FYR0ZYM3U2OXplUTd2?= =?utf-8?B?SzBUSy9ONVJ5Z0NWVXROZThlSWlYSCsvM0xoRDh2NlA0ZDJxNW9pNThLYVdJ?= =?utf-8?B?QjFFanJjZU5sQXRnSU9YYzRzYk5qODF6QkVvclBYRitGUjFxcWJ3VWJVNk1s?= =?utf-8?B?Sk1zN2xTSzJEeWt6dDNCNURkMWR1anBwMmlBdHhsVEZINjJiczcyUHZIRzl5?= =?utf-8?B?V3h1UURKSUhOMzlqeWVnbDVNcDArMkQ4RVovWHhGRFlndGx2ellERUhWZ3B0?= =?utf-8?B?QmtvbW4xTE5iN1BOL1hWUnVwL3crUU1GT2NlcXJMR2hiRFgySEVucGFKVmRn?= =?utf-8?B?TjJvSXFTTGNOd3ZSMVZGME53VDMzZnpNRXJ0c0dwSTdUd1JoYzdGTEFPVGMy?= =?utf-8?B?aGV5dUtmUjJoYlY4bis2OE82eFFtanlYWlRSblRqK1lwS2RaS1dvT1VNem9r?= =?utf-8?B?QXd5WWk2RnVaUVlhNXBGMkcyQk5nZHFCcmUyVFRqQ3hHU3FteU12VWRwK2lv?= =?utf-8?B?QjMrcVAvMG1wKy9YRklBZVFYQVJnbXZFMVZZNmlna1RPMmo2N3MvYUR4MEI5?= =?utf-8?B?dThWeGc3TFBmdUhwRkMwa2pZRTB4L1hJQXEwa0lxNUhVUVc0KzRoTkcvSERI?= =?utf-8?B?MHN1SnNPUmcwOXR3MjNvWTNjQ3BRcSs1OHo0N2V5aWhNRFhRRE81QT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: c62b4e96-6767-4c1a-fae5-08de7de12a9a X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 13:38:37.2181 (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: WwoeFWTCqD4wZ3/MnOOkC6Q89Buj+m2a4ULdojm3GufTiLP1l7YQS7/X4o3WLiiNp0GVSWCgmkMgi2+a0j18fQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR03MB8047 On Mon, Mar 09, 2026 at 12:31:03PM +0000, Julian Vetter wrote: > Add two DM ops for MSI passthrough IRQs. These new DM ops take the raw > MSI address and data fields rather than a 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. > > Signed-off-by: Julian Vetter > --- > Changes in V3: > - New patch addressing feedback from Roger > --- > tools/include/xendevicemodel.h | 37 ++++++++++++ > tools/libs/devicemodel/core.c | 44 ++++++++++++++ > xen/arch/x86/hvm/dm.c | 102 +++++++++++++++++++++++++++++++++ > xen/include/public/hvm/dm_op.h | 23 ++++++++ > xen/include/xlat.lst | 1 + > 5 files changed, 207 insertions(+) > > diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h > index 227e7fd810..0d5d7b0ff1 100644 > --- a/tools/include/xendevicemodel.h > +++ b/tools/include/xendevicemodel.h > @@ -375,6 +375,43 @@ int xendevicemodel_nr_vcpus( > */ > int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid); > > +/** > + * This function binds a passthrough physical IRQ to a guest MSI vector > + * using raw MSI address/data fields. Unlike XEN_DOMCTL_bind_pt_irq, > + * this interface supports extended (15-bit) destination IDs by having > + * Xen decode the MSI address internally. > + * > + * @parm dmod a handle to an open devicemodel interface. > + * @parm domid the domain id to be serviced. > + * @parm machine_irq the physical IRQ number (pirq). > + * @parm gvec the guest interrupt vector. > + * @parm msi_addr the MSI address (0xfeexxxxx, includes extended dest ID). > + * @parm msi_data the MSI data (vector, delivery mode, trigger mode). > + * @parm gtable the MSI-X table base GFN, or 0 for plain MSI. > + * @parm unmasked if non-zero, leave the IRQ unmasked after binding. > + * @return 0 on success, -1 on failure. > + */ > +int xendevicemodel_bind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, > + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data, uint64_t gtable, > + int unmasked); > + > +/** > + * This function unbinds a passthrough physical IRQ previously bound > + * with xendevicemodel_bind_pt_msi_irq. > + * > + * @parm dmod a handle to an open devicemodel interface. > + * @parm domid the domain id to be serviced. > + * @parm machine_irq the physical IRQ number (pirq). > + * @parm gvec the guest interrupt vector. > + * @parm msi_addr the MSI address. > + * @parm msi_data the MSI data. > + * @return 0 on success, -1 on failure. > + */ > +int xendevicemodel_unbind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, > + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data); > + > #endif /* XENDEVICEMODEL_H */ > > /* > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > index 8e619eeb0a..4a52fe4750 100644 > --- a/tools/libs/devicemodel/core.c > +++ b/tools/libs/devicemodel/core.c > @@ -645,6 +645,50 @@ int xendevicemodel_nr_vcpus( > return 0; > } > > +int xendevicemodel_bind_pt_msi_irq( > + xendevicemodel_handle *dmod, domid_t domid, uint32_t machine_irq, > + uint8_t gvec, 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->gvec = gvec; > + 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, > + uint8_t gvec, uint64_t msi_addr, uint32_t msi_data) > +{ > + struct xen_dm_op op; > + struct xen_dm_op_bind_pt_msi_irq *data; > + > + memset(&op, 0, sizeof(op)); > + > + op.op = XEN_DMOP_unbind_pt_msi_irq; > + data = &op.u.bind_pt_msi_irq; > + > + data->machine_irq = machine_irq; > + data->gvec = gvec; > + data->data = msi_data; > + data->addr = msi_addr; > + > + return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op)); > +} > + > int xendevicemodel_restrict(xendevicemodel_handle *dmod, domid_t domid) > { > return osdep_xendevicemodel_restrict(dmod, domid); > diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c > index 3b53471af0..3d530d948f 100644 > --- a/xen/arch/x86/hvm/dm.c > +++ b/xen/arch/x86/hvm/dm.c > @@ -7,12 +7,15 @@ > #include > #include > #include > +#include > +#include > #include > #include > #include > > #include > #include > +#include > #include > > #include > @@ -322,6 +325,25 @@ static int inject_event(struct domain *d, > return 0; > } > > +static uint32_t msi_addr_to_gflags(uint64_t addr, uint32_t data, bool masked) > +{ > + uint32_t tmp = (uint32_t)addr; > + > + return MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_DEST_ID_MASK), > + XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | > + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_EXT_DEST_ID_MASK), > + XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK) | > + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_REDIRECTION_MASK), > + XEN_DOMCTL_VMSI_X86_RH_MASK) | > + MASK_INSR(MASK_EXTR(tmp, MSI_ADDR_DESTMODE_MASK), > + XEN_DOMCTL_VMSI_X86_DM_MASK) | > + MASK_INSR(MASK_EXTR(data, MSI_DATA_DELIVERY_MODE_MASK), > + XEN_DOMCTL_VMSI_X86_DELIV_MASK) | > + MASK_INSR(MASK_EXTR(data, MSI_DATA_TRIGGER_MASK), > + XEN_DOMCTL_VMSI_X86_TRIG_MASK) | > + (masked ? 0 : XEN_DOMCTL_VMSI_X86_UNMASKED); > +} > + > int dm_op(const struct dmop_args *op_args) > { > struct domain *d; > @@ -350,6 +372,8 @@ int dm_op(const struct dmop_args *op_args) > [XEN_DMOP_relocate_memory] = sizeof(struct xen_dm_op_relocate_memory), > [XEN_DMOP_pin_memory_cacheattr] = sizeof(struct xen_dm_op_pin_memory_cacheattr), > [XEN_DMOP_nr_vcpus] = sizeof(struct xen_dm_op_nr_vcpus), > + [XEN_DMOP_bind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), > + [XEN_DMOP_unbind_pt_msi_irq] = sizeof(struct xen_dm_op_bind_pt_msi_irq), > }; > > rc = rcu_lock_remote_domain_by_id(op_args->domid, &d); > @@ -607,6 +631,83 @@ 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; > + struct xen_domctl_bind_pt_irq bind = { > + .machine_irq = data->machine_irq, > + .irq_type = PT_IRQ_TYPE_MSI, > + }; > + int irq; > + > + rc = -EINVAL; > + if ( data->pad0 || data->pad1 ) > + break; > + > + if ( data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED ) > + break; > + > + irq = domain_pirq_to_irq(d, bind.machine_irq); > + > + rc = -EPERM; > + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) > + break; > + > + bind.u.msi.gvec = data->gvec; > + bind.u.msi.gflags = > + msi_addr_to_gflags(data->addr, data->data, > + !(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED)); > + bind.u.msi.gtable = data->gtable; Retrofitting the new interface into the old one seems weird. I would do it the other way around - implement the old bind domctl on top of an interface that's more suited for the new DM op. That way you avoid having to expand gflags with extended destination field. > + > + rc = -ESRCH; > + if ( is_iommu_enabled(d) ) > + { > + pcidevs_lock(); > + rc = pt_irq_create_bind(d, &bind); > + pcidevs_unlock(); > + } > + if ( rc < 0 ) > + printk(XENLOG_G_ERR > + "pt_irq_create_bind failed (%ld) for dom%d\n", > + rc, d->domain_id); > + break; > + } > + > + case XEN_DMOP_unbind_pt_msi_irq: > + { > + const struct xen_dm_op_bind_pt_msi_irq *data = > + &op.u.bind_pt_msi_irq; > + struct xen_domctl_bind_pt_irq bind = { > + .machine_irq = data->machine_irq, > + .irq_type = PT_IRQ_TYPE_MSI, > + }; > + int irq; > + > + rc = -EINVAL; > + if ( data->pad0 || data->pad1 ) > + break; > + > + irq = domain_pirq_to_irq(d, bind.machine_irq); > + > + rc = -EPERM; > + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) > + break; > + > + rc = -ESRCH; > + if ( is_iommu_enabled(d) ) > + { > + pcidevs_lock(); > + rc = pt_irq_destroy_bind(d, &bind); > + pcidevs_unlock(); > + } > + if ( rc < 0 ) > + printk(XENLOG_G_ERR > + "pt_irq_destroy_bind failed (%ld) for dom%d\n", > + rc, d->domain_id); > + break; > + } > + > default: > rc = ioreq_server_dm_op(&op, d, &const_op); > break; > @@ -643,6 +744,7 @@ CHECK_dm_op_remote_shutdown; > CHECK_dm_op_relocate_memory; > CHECK_dm_op_pin_memory_cacheattr; > CHECK_dm_op_nr_vcpus; > +CHECK_dm_op_bind_pt_msi_irq; > > int compat_dm_op( > domid_t domid, unsigned int nr_bufs, XEN_GUEST_HANDLE_PARAM(void) bufs) > diff --git a/xen/include/public/hvm/dm_op.h b/xen/include/public/hvm/dm_op.h > index 2bf0fdc1ae..fd0f3a6a99 100644 > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -444,6 +444,28 @@ 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; > + /* IN - guest vector */ > + uint8_t gvec; If you pass the address and data MSI fields there's no need to also pass the vector, this can be obtained by Xen from the MSI fields? > + uint8_t pad0; > + uint16_t pad1; > + /* IN - MSI data (vector, delivery, trigger) */ > + uint32_t data; > + /* IN - flags */ > + uint32_t flags; > +#define XEN_DMOP_MSI_FLAG_UNMASKED (1u << 0) > + /* IN - MSI address (0xfeexxxxx, includes ext dest) */ > + uint64_aligned_t addr; > + /* IN - MSI-X table base GFN, 0 for MSI */ > + uint64_aligned_t gtable; > +}; > +typedef struct xen_dm_op_bind_pt_msi_irq xen_dm_op_bind_pt_msi_irq_t; > + > struct xen_dm_op { > uint32_t op; > uint32_t pad; > @@ -468,6 +490,7 @@ struct xen_dm_op { > xen_dm_op_relocate_memory_t relocate_memory; > xen_dm_op_pin_memory_cacheattr_t pin_memory_cacheattr; > xen_dm_op_nr_vcpus_t nr_vcpus; > + xen_dm_op_bind_pt_msi_irq_t bind_pt_msi_irq; > } u; > }; > > diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst > index 9d08dcc4bb..9236394786 100644 > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -107,6 +107,7 @@ > ? dm_op_map_mem_type_to_ioreq_server hvm/dm_op.h > ? dm_op_modified_memory hvm/dm_op.h > ? dm_op_nr_vcpus hvm/dm_op.h > +? dm_op_bind_pt_msi_irq hvm/dm_op.h > ? dm_op_pin_memory_cacheattr hvm/dm_op.h > ? dm_op_relocate_memory hvm/dm_op.h > ? dm_op_remote_shutdown hvm/dm_op.h > -- > 2.51.0 > > > > -- > Julian Vetter | Vates Hypervisor & Kernel Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech > From xen-devel-bounces@lists.xenproject.org Mon Mar 09 14:15:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 14:15:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249525.1546999 (Exim 4.92) (envelope-from ) id 1vzbOV-0006h6-Sb; Mon, 09 Mar 2026 14:15:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249525.1546999; Mon, 09 Mar 2026 14:15:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbOV-0006gz-Pg; Mon, 09 Mar 2026 14:15:39 +0000 Received: by outflank-mailman (input) for mailman id 1249525; Mon, 09 Mar 2026 14:15:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbOU-0006gs-3p for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 14:15:38 +0000 Received: from CY3PR05CU001.outbound.protection.outlook.com (mail-westcentralusazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c112::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70cbc5a7-1bc2-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 15:15:36 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA6PR03MB7830.namprd03.prod.outlook.com (2603:10b6:806:42a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 14:15:29 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.023; Mon, 9 Mar 2026 14:15:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70cbc5a7-1bc2-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fUVf/R6q+LHYBCiF9piyj1uuWEH+7m3ElnZjC4Eokc9jq2xwdcUxjT3DJ0HkbDS+JUpz7mJzxjzyXDPWoTAKpTJINOzI6EtyT0ewa9qFxhVpjkM7kYrfkEViD3jCoIjEqezi/LVXQLfduW29eJT7M/WLDAXNOZ1Zhxboo478vfJfhXwLdBQwfJtfgJ/ULKyD9C38F/2qCPboY9oipwYe2J3LZ3HwZoP67tZ8qqBKj0+XoOYEDUZLfNzwOcI9XY/JfETnbYOGqWJQwdYfYf5Ej6H58a7ABLn+rbzJ35FzV0nwvyTn+9Yle3AqGW6gL5aQ3liCzDnrA3eiTWK48/F97w== 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=80fCUVdzrqGKZAn6+lCyvIb3dy6nmA1vd/zWivUKgGA=; b=f9K4R/leup7uDzOoVoQHyGvqz4rnmgzYh7DY0HWp3set9J55YdR3HqntDqHd3LB5HB0fuSyy+jJJ4YR//giBj7j4jWWS9HP63v+k9y1MB/at+Z6lBn/dZ963W6iTgaUXVGWp5a27pBs78ne+vqw3nVwXAH0YNknuZevnn/CO13yoOxTZXNmbOR8LewBuyVqd2Fom6wADDCFu1Dbu+fOw/t20C4Q87xU+V4i0oJ3biJAVwquYNJ1UhWvqutTnIO16ydXvqN7ZBqdlFR5zrols/kBV0hbshcl96/OG0xOGu8lfvDNfHEz6owUWwO+z2mdEIpW0QnsKMMSqjazaDVcbCw== 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=80fCUVdzrqGKZAn6+lCyvIb3dy6nmA1vd/zWivUKgGA=; b=zmiT2dquSlEUM3kCcD4oRK1j7FtGsGo2wEmNbC4RB9DJeYu5bpzZs7oHkQZcj7YfPFsrT2S5K4OTCTqcPUSqhjhC4l5xf3nAAbdHZ99YWCNe5d1j0WM21US5oJGOs/m9UyAVuP8xdgYH9CjCGgjRCk8qbQ+D78d8gW0FFGyVHVk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Mon, 9 Mar 2026 15:15:26 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Edwin =?utf-8?B?VMO2csO2aw==?= Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Anthony PERARD Subject: Re: [PATCH v4] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Message-ID: References: Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA2P292CA0011.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA6PR03MB7830:EE_ X-MS-Office365-Filtering-Correlation-Id: 986a7618-eb85-4f7e-c607-08de7de65123 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: kjnGVeKdISmXwx1mK2dlriFjC6uZ86cQZl8jgWT159efEdjl7IRyBFwKxhMG5l54i4qAiPY8b+OJP2RQsrEUYkOM/F6rjNXplnmL2a+FAKgzYOkfS55wCMPQVu7XamHwoaxON39IEaXhsXYBoAL+7NBmtX72hscsYBiCGR56GmWpslKwT4jMRvkV2b+Pk0CRMz8suwIPzawigI8T+xw+PmeKXosxJMhuZ5yuxTnGRFCwjA37+zKGUYaHpwKHp7aZB/SjvcE57y/dgFGThj4ZgUxSHe9YJ1RN7/W6YRKGdIAsHgEkmYnBaVVnKA7CzgjFXCTNuepzBkVpeeORmbhWyxQzVc7G9En8HFYvQR+NGaZAXWwUznHaTymZkIRDLL/rd46vvw+Km84RgXgm9iS7Gj7Ji13j5C5PNmssfZDByELypEdeRwSI/nYB6BNZ3USjAFVrnyZIipu8wKR22kaA1qYfji8+l3R6aqjT7+JWS7vO3hJ0Y1+BUifaJpGoPFuiaQI1xi26Xeve6dU49zJgmKfsrbm7wTs7Eyq9CfsFTWmpscsq0exS2EKhVExPdCDgdme+0Wc7LJn8J7jUq5+eDEIejlvmAx1EwZZ1SfuK+rmmnJMt6LLcrREtzfAsPJqtKW8x5FsPAWIe2ey/DlEr9fbdzu56OrDl2e51YzYdUP07SmkSnsdMKuYe3tp6Qba+aM65QMDjhY9KBqMkJ8YTprEEsx8zjRYFFDQy2tbRVac= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bU5NZHFrUVRENFNTNzA0cnAwbC9BQytzcDlUMFBKY044LzNwWSs3KzNpbVU4?= =?utf-8?B?dkNHOCtXWlk4ZGVhbVZWSCs1TndHMWVNaHhTdDRtYU9oZWZtM2hRRlZnYmVX?= =?utf-8?B?MmorSEN2U044QkJmN0NMZGZKY081dS9QcURaYVF6R2NLWUNmK0NKK25BMWkv?= =?utf-8?B?bEZaY1k1cHFPeFRVR0dRQ3VwU1MvQjlvQTFqTFA0MDNvNHBMOWhnZUVTREdV?= =?utf-8?B?VmFXTlFuL0tSejZQb1RDL1NGUjBXUWtWNysza0liUTZaNEo5QWNjTnN4RXhS?= =?utf-8?B?ck5ZbjI3VHNoWklhOVA2SWc0WFlJQVJFRVVVbkVoRDBiQndwZy9YZmNOTzF4?= =?utf-8?B?MlZGRVFwUnVocy85VXlXcUVYMEpJaGdoSVZIcUs1eFFBd2lmckQ5bGtjOFBh?= =?utf-8?B?YjBxdlkyL2g0cEdtbzdsZ01ZdXBxLzRMN1hWa1hpbE96ZmJBWVpqclpDN1N2?= =?utf-8?B?aUQrQm1rM0x6MFVxdkZ0eTVvWVp4dUU3TWFqZ1YrNytNNDRmVHlVUnhBTEVC?= =?utf-8?B?ZitEbG5HcktYQjM5SEJmWWdIN2c2NmZoeENTaG4xWUpWdHZSOE8rYTAvZWl0?= =?utf-8?B?MVdnY1F4QTE5T2hSenpKMlN2TG9qN05wY3p2b1VTQnliZWZLa3oxeU11WU1Z?= =?utf-8?B?TVNEcDAvUlhoaWNZMS9wU2JobjlkRENRRHlxT3BoL0E4UzIrcUkxMHRSVUFi?= =?utf-8?B?QU5YdHVrMkxON25xYTByOWgzNmZPekpvWGhROHN4WWxPb05GQ2twLzUrMWtD?= =?utf-8?B?MU9udFpOcER5RzlGRm5aK1Q2QmhKR3FmOVZvdjdKYUZjWjR1NXVDb1RoQ2xW?= =?utf-8?B?cTVXV2duMzhhSmVhU2VEajdaWjkrYnA4c3ByVENERExJWVIzT1oxWThlcGRR?= =?utf-8?B?TzRRbUZTM0IxaWFZOUpPRStVOVR1Z3RMT0hmR1FUTW5wZlozVXhnOHdZNUhn?= =?utf-8?B?Mm91WFI0bWJvMzZlWlIzaW9nb0l0aklGU0hkcUZoS1BrMEgrSU8ycGhBUU5D?= =?utf-8?B?ckNaN0lKZkM0b29YWWlWYmE0SEFYczZCdnNMT0ZYQ3RXSGJmWVlpZzNlMDd1?= =?utf-8?B?VnpYRERKbG9XVTRpZjlxNWYyK21DaEkyeGxGTGF6a3ZqbDR1cWMyK1dmTXZB?= =?utf-8?B?YWhIVG9ZTjdCU0ExaEpHUHljWVkvUWRIQ3pXQUdGbUkxNGFzQUZ3alp0OFNn?= =?utf-8?B?WDkvWWdnTUVJcWlZTEQwejdMV1Q1SjBQbkRzSU44MXBJZUVEc203bXJWRHBH?= =?utf-8?B?NGpTUGpXTkM0YllYNXJCVXlKYll2aVlxS0NJY3FxUU4zQ0xzeE9PQnZnZGNk?= =?utf-8?B?ZFpiOWRieUQ3QXhnTWdHeU5DckRyRzlIWlJtNzEzY3pmdXlmcFFLZVRMMkdo?= =?utf-8?B?THc1Z0tidXF4YWVNNWlRSWxPblRjckJoTmRlK1FUQkkrZWs0NzVmRGZxaEZQ?= =?utf-8?B?bi9ITC9rOS9YTnkvNUV2aDJjLzZ3UUZOYUxEVm5WLzhuVHJLb1RLN0E5MnAy?= =?utf-8?B?bHlrci9NMVovYnB0eGpKSllUNHg2V3k5TXVuYWRNZXlUQUgvVkppOVpUMVhJ?= =?utf-8?B?YU5ZQ0NCamRHaVZFWmc1T2wyZW5rc3hVODUya1VrM1hhS2hJR2x2YnIyNzd0?= =?utf-8?B?R2svOUswUVdpcld4YVc4RmpHMTdBZ1hVbiswM3BHcHlUZTZMZE9YM0Qwd3VQ?= =?utf-8?B?L3NUaVBaVEVQV0pZaFgzUnhzS2RIUUhScmtYZWpxSHYzOUk3Q2FkbXQ4UTZZ?= =?utf-8?B?TlhPc2Iza0ZuRXJSbFQvcDIyc012aHd3TmpqMGxENUhMMkk5d2I1N0RmTXJz?= =?utf-8?B?VTF3UlM5UDdCWlZNbStPMHNhRWJhWExaangvOXRtMFVSb0lpMmI4ZlRjYklU?= =?utf-8?B?d2Y3OTB1bzBhRmpLbEttNTc4NDVSMCt0bUE5U3BON3RnUVNMQmRxa0Z0VjJl?= =?utf-8?B?THNDQU9WQzBkdGJscTNmYlVrRUh5Umt6WThmdzNOQ1NPQ09CZEVuZjhDVVRY?= =?utf-8?B?Z1NVNnNPN3A0TUF2SDBtVDF5eTArWGNKellTYjk3SGlRa2taakFuc3A5Z2RZ?= =?utf-8?B?dFpyODdKKzdYNlhOWVY0NDJkMkFuaHFRN2tBeXhITjhidVFzZnQxOENzUmVP?= =?utf-8?B?VWJMMDRGaEZiMWhKSkdTTTlBL0FKeXdUU1VSOUdmckR2ZXgzQllZLzFnUUxk?= =?utf-8?B?NXdvZmFrZ1JtU0JFVnRDbFJmbENqRGYzZmlPaFdaYnFEeVFsdExhbXdmYmZN?= =?utf-8?B?bERjYlJ0MDRDRmR1WlZUZlo5clduVTJLUSs4S3JHTWsxMlBzSjFNS0ZjWHpS?= =?utf-8?B?eEZuL0pBMGJRLy84SWNJK080K1pRT01PR3lLYndHSUpVSjZteFhaUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 986a7618-eb85-4f7e-c607-08de7de65123 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 14:15:29.3110 (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: mV2JQ7RgZMvrxFy4dmr0LLpCGSoZUkwdlck4HpgJ8rmbn7CCyJXFSGct7zy2CBvIqI8JjtAsGwYmMLs5bXka5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7830 On Mon, Mar 09, 2026 at 10:41:35AM +0000, Edwin Török wrote: > clang would duplicate the loop body and end up with a double definition > of the symbol: > ``` > /tmp/test_x86_emulator-0f3576.s:27823: Error: symbol `vmovsh_to_mem' is already defined > /tmp/test_x86_emulator-0f3576.s:27825: Error: symbol `.Lvmovsh_to_mem_end' is already defined > ``` > > Until a better solution is found: reduce optimizations in the test runner. > > Using -Os might also work, but we can't rely on the size optimization > always avoiding the duplication of asm blocks. > This is test code, not performance critical code, and -O0 is more future > proof. > However for debugging -Og is recommended over -O0, and this still > avoids the duplicate label problem. > > Signed-off-by: Edwin Török Building the x86 emulator test harness is currently gated on: ifneq ($(clang),y) SUBDIRS-$(CONFIG_X86) += x86_emulator endif So I think there should be a further patch (or done here) that removed this check. And then we should also run the test harness from one of the LLVM FreeBSD builds ideally. Have you tested with a full LLVM based toolchain (so also using LLVM linker?) Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 09 14:37:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 14:37:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249535.1547010 (Exim 4.92) (envelope-from ) id 1vzbjE-00015U-Hm; Mon, 09 Mar 2026 14:37:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249535.1547010; Mon, 09 Mar 2026 14:37:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbjE-00015N-DP; Mon, 09 Mar 2026 14:37:04 +0000 Received: by outflank-mailman (input) for mailman id 1249535; Mon, 09 Mar 2026 14:37:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbjC-00015G-UI for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 14:37:03 +0000 Received: from BYAPR05CU005.outbound.protection.outlook.com (mail-westusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c000::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 6dd13596-1bc5-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 15:37:00 +0100 (CET) Received: from SA3PR03MB7419.namprd03.prod.outlook.com (2603:10b6:806:39c::6) by SJ0PR03MB5408.namprd03.prod.outlook.com (2603:10b6:a03:279::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 14:36:56 +0000 Received: from SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc]) by SA3PR03MB7419.namprd03.prod.outlook.com ([fe80::8254:2aeb:5a33:a6dc%6]) with mapi id 15.20.9678.024; Mon, 9 Mar 2026 14:36:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6dd13596-1bc5-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=O7biId/RZDq2zRT2MEMUxGAbRn1zhiREYSmSZQfSQbK5VtB2s0LUeNXPKxMBgesm53hLs2ZWT4PYhV/SrgEhYJTgYfCKTTGppLY0XMq4Ipt/hEyEpShWktDJjO7YLO+5+16+AnUWJy2JbhtLLH7ZhsO0YWGuGmA5tpDJAwXbqqGVJHQ5R3YYOGgAS2PCyytc7rRmN50BiIMYz3nejjc28rJjDaZObIC4QGIj/a0e4ECLA8y1yXWOK8P58yiDX/DUGFbP9W+2uyySUsfR4gWQ2LwoS4N259pIN4nmxJdIhbVOnVADAcSdoF7QNsaJ2wd7GyKqCdv7+FRJYPPuWf8tzQ== 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=OMn9meAwVwU60QdOvQPVGX3C2BUIMnIRG9tYAyWqk3Y=; b=Cbutw7C/zwXUyfD8hgKat7VXiJ7CRV0mU8GgTU68SmzwFoL78cuJTs0rWuPJFFGfdcHY5UsnQ36aQzNespF1UDTkns6d68zTHU6FMW+O8waNYzQ/+sXvvmSS/KgcNA6Wc5vcP9mHlPXdmit/0CdHjxYzFa1BzuUOf6CNhTB6XW2Qo01rJ3HdJg2qMMgoZ1gG2OWUiR4Sy1UQGCcKIwUvl1NDCEUEeMLIuqBCv/K3MLqL65OKnxUATeOoP3Z0k60WjglujnYIQIF4RpBDms7e7DUEqWfHuXW+DPuG831qgS/iy5c/TQ3rkkZEFYJIBPoLyrnsrYlRAqWHiLpS2nT/3Q== 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=OMn9meAwVwU60QdOvQPVGX3C2BUIMnIRG9tYAyWqk3Y=; b=gnIyPzcab0Of8ra0nZwtiOUJxSxfp3HQfMX3td6dyUI/8tHAFGbHolfz+SBvH6xHdmqNC5eiHkeEpsYn0th/nS8fHiRw+lXRpR8wQI0H54LwZOPqOmtW3nfCzIDUlZRwfknlg+VMBqLiszWAQQVmMfSy4JSHTUKhcUkrYfFFL2s= From: Edwin Torok To: Roger Pau Monne CC: "xen-devel@lists.xenproject.org" , Jan Beulich , Andrew Cooper , Anthony PERARD Subject: Re: [PATCH v4] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Topic: [PATCH v4] tools/tests/x86_emulator: avoid duplicate symbol error with clang: use -O0 Thread-Index: AQHcr7FQiijdIWu12E6i9XJI47BDXrWmPvcAgAAF8wA= Date: Mon, 9 Mar 2026 14:36:55 +0000 Message-ID: <630D14BE-E962-47EC-A2DD-4E152FA32EFE@citrix.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3864.400.21) 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: SA3PR03MB7419:EE_|SJ0PR03MB5408:EE_ x-ms-office365-filtering-correlation-id: 7d8bc039-6db6-4e6c-6353-08de7de95032 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700021; x-microsoft-antispam-message-info: EstzD/jhn+QNFAsBQh97VuUMUJicasaGV8JRqg+/WnXaDM3b/9RVOm2BhJCb+/fcvP2BxCUniXfTnNDBoOUtBMyVM4PNRkEY08lbBqyxPPlIVuq5cmhMUanRTI58AM+HzaWkfkx+FCWogBhY3h42WBJgp4Yz8BhYa5b3CPZX9DShqgO8RJQoU1jEKXziNx3gPN/khwO6Pe6GDcRJTIx6VNo5dYMV5JP6J07xkoH8+x/M6/o1WeoGjar7EdAb3Zx+KZWIb9JjjHUAHDZWFytvprvKe5v//0mRRWXniBwBNACIh9pHwi1NeiEkhKL6UG5OczTk4Kv1S6BdVtgb4CxEsSYEJWYBRKG5IOOJ4TneQEloMvQx4GVpk6OyX89q/9VTcrlUhNrmm3QC4p3UBvjrIG/1pZJGU7ZCoUfU9IkFUXAlK3gUZ6GmKdBkXxnJPGAIU6q/521ZEMOcqxnZrqWcOCJNZypPm0KMSiMesynN+6F0fb45yJy7IY1YDd/D9aJ6whqeIZHINMa4J+KU5ZNfC+nmcd90OaNxWvvvHUPaDaZslPq8nCwdxMt41MJYOnx6Rgc6smJYBa2Y8LNCRy5MTRQVi2Dh2Xs7MBrITGQGaVnsUWoXTGSscLJxogam9qSNjfrv2KDeesmt0oURZ8/3jvlkZxVeL3+bi/50unXYvtwOvjaGqV3hF12gJqO+/6fSLEyrWlgSSEA07GuGM+pgeWWmxPlyryAuVMUtbDcP6KtNLlBD8/HDpeOABAURum+U x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA3PR03MB7419.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700021);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cG84cnpCaFNCSG5zMjZFV2dkTmZncHFrRXB1NUF6NWpyYWRPWTZLeDNvV3B1?= =?utf-8?B?WFdTL1ZlRVprdUpOc01ESU5KYjUzcGwvNHJnN1NQd3ZkQ1dFV3dNOFpoY3pt?= =?utf-8?B?N21OTmVaUHBPQ3lJeFMydHRvK0wrTElXTU9BT2lnSUVIY2MyR2N1aXcvNFl1?= =?utf-8?B?VXFBeXZGczdwcFJVNVYvQ0FUcXdldDNjZlVzSTZ3YWV5alZRTXJzRVhOUTNJ?= =?utf-8?B?WFM5bU5pZVB4cG5veEhxZzJYb0xXVnhFNmRsRzVadktDNVJydkFSSW9Na0pz?= =?utf-8?B?TFNvaWVFVFhxaXpRZ0Zqc2U2QTV1WFlmS1ZCeHdYeWhrTWQyQTlTVmt3Ritz?= =?utf-8?B?TmhkWlFLTlcvRnlZQlgrRlRxdGVwVXVuYThrdEZyUzNyM1lSUnQyQ1V4V0E4?= =?utf-8?B?U2VTM0RXeWExTFUyYXo2UXl3YXNvNVIwRkhjVThFV1JBclkvakhCeVY3WVFq?= =?utf-8?B?L1F5TFR3bkIwd3lJdk15ZTJMVzRSbG9zMkhZY29Wb0hrcnpRY3hBeXNCakZI?= =?utf-8?B?dkFzQnVuVWlIZWhYV1ZoSDZpZlFLOWxqK24xd2J4TGhIWW5SQWc0d0RFTDRa?= =?utf-8?B?bWlWM050RHhlU29zdE9iS0lRZW50V2VkK2JSK3hKY1VsRmpleWRRalo0dHd2?= =?utf-8?B?Z2I1ZmR6VE00N2lOcnNwNkxBdWdORUQyaFlZTmtteWdCY1R3Zm4vMWE2bnM2?= =?utf-8?B?NkFRRGlOOG1laVQvNnJMczR2bk1qZmw0a050ZVhKbFRXQkw2RFlvRmhxekM3?= =?utf-8?B?UVl6SWZZemo2ZHdFeFhlb3Z0QmtReCs4TlVib004bnVWcUlCQUpRN2dMTkNk?= =?utf-8?B?Q2kvd3FqSUg0MklpUE5OSVYycU9MaFJ1QVlGM2NsL0ZQajlhZUZ2eG9ad2R2?= =?utf-8?B?dHF3Qks0ay9GMkdSU2g0NjJjQnhPQzVsWk5EK2huMU5BeFRuU0JQUGNlR1JS?= =?utf-8?B?MGUwNkpuY2h5K3hTSi9SWjVMK0pOVTBvbmlSQ3h6UG43bzlSV0RPZWljSWlZ?= =?utf-8?B?akk1T1p2eDZNMmlpWWVRMHFnREprVWs1a09mK0lwZGtDSEZPaGwwQitHWTll?= =?utf-8?B?YUd0cmxZL3d4N2pkQzNDZ3NzSTM2clZET1pDeVc0R2JIN1A2aktqY08wb2Qx?= =?utf-8?B?NjlENFNVK1RLQ3RkKzZtME9QNEtEbnc5bXVMZmp1ZEhlL1FCREdPZnpFQm1T?= =?utf-8?B?WXB0TTBJU1VQc2J4dStDQnppYllNdDFiV1orUzFXVlFQbGpTY1pzZzVNMDRS?= =?utf-8?B?UENjWDRuVU42OGF2WWFaZ2JsTzV4U2paeUFiOWtVZ3UyNVJLcVBpQmg5STBi?= =?utf-8?B?eGtQMXd0R1IrQ1lMWUw5WnVSaXMyTVpsYkVDWU94NkxpM2hGWkxoc2cxaWJw?= =?utf-8?B?K3pjUXFpWDliUk9zeUF2YXBoRXZOQVZtM3Y2aVhnbVg1RVdCY1ExcE12V2E4?= =?utf-8?B?eHZTd3o5Yzk4bmVlUG4yUGNTQ0RvZkZPeGtEMjV6OGRaRUNYSGI1ajBNSEhK?= =?utf-8?B?bTJTZUoydktHRkFWaENzVHQrVVFpYUFOWkZjK3ErajVjYWFKM2RNNzdxcDdS?= =?utf-8?B?dTd5YmtPWFc5K3dqSjdac0t5dldJdFhCYjlqc3g3UTN1NDFmV1FjUmxYNE9D?= =?utf-8?B?WXczTExKRTFwaDI5RURaaEp1R1Vic3JjZS9vVWVuZnFkQUVXaTdRWU8vZUFi?= =?utf-8?B?c05BSjlhUEhWS2V2d2RFQzhKRjZ0RmFJZkVaVkpIRGFuRitHNFF1dS90bmVu?= =?utf-8?B?WkoxcGE0RE5McnZyb2xvVDh3OTdJMnIvNUVpSXpkbUFsTDM4dVBicEszUCth?= =?utf-8?B?NThJUjhUSzVoUDUzQ0M3MVk5Yjl4SVJ3QkNwQmViWDk5TE1ycHFBMzhtc0FC?= =?utf-8?B?WFFUL3dVTWMydVZTOENwRjRmd1djQ1VKSWEvdjFaRFI3VXhmdWI4ZyttMWhv?= =?utf-8?B?RitEMUpsdmVic1NueThGbk1oTTlWVEdYZTZ4TFl2Z1d3RW1kcWtSazliSzNS?= =?utf-8?B?Zi84bnF5OTFSTzdCZkpKYlZCNFlNdStRUVlhYU1LbjBPMEJpcTIrbGpnN3Uw?= =?utf-8?B?NHc5MFJ6OXFHMDg3U2FJOXRHbGtzcEh0b3E2TkFmNkllM01YWm9HbVBJRUFj?= =?utf-8?B?RUFjNFNXcFN2OStGRWpuTC9LaTV2dThnN0dFYUc5YVNzUWVPV214MStFeU5Y?= =?utf-8?B?YkZ5UmNIeHlHM2R2UUtvOWIwYy91WHExR2crbUdJS2hXMVZjR0tGeGNtSUZL?= =?utf-8?B?TGEra21TWjZlVGt0ekdrWHNQTzFKakdkcjF6VVV2TzVXUitreXFPTitLdlJk?= =?utf-8?B?YUZIcnhwbCtQWDJiQURVNEttazBwZzAwM3Rtc3BwemxiWFBxNFdVcThBUUl3?= =?utf-8?Q?OtY42NnSf9qCRFM4=3D?= Content-Type: text/plain; charset="utf-8" Content-ID: <49CBA71D35CA6041BF82201DEFF07AE0@namprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA3PR03MB7419.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d8bc039-6db6-4e6c-6353-08de7de95032 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2026 14:36:55.9016 (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: rNBLnklxrPqfcYPks2ipmPtE3nSrJfk+QtPvLIOVfvAY+3eLcnHcpThdsl5+SBdsjjusKiSlHC8oQlmyxEFWtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5408 DQoNCj4gT24gOSBNYXIgMjAyNiwgYXQgMTQ6MTUsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1 QGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4gT24gTW9uLCBNYXIgMDksIDIwMjYgYXQgMTA6NDE6 MzVBTSArMDAwMCwgRWR3aW4gVMO2csO2ayB3cm90ZToNCj4+IGNsYW5nIHdvdWxkIGR1cGxpY2F0 ZSB0aGUgbG9vcCBib2R5IGFuZCBlbmQgdXAgd2l0aCBhIGRvdWJsZSBkZWZpbml0aW9uDQo+PiBv ZiB0aGUgc3ltYm9sOg0KPj4gYGBgDQo+PiAvdG1wL3Rlc3RfeDg2X2VtdWxhdG9yLTBmMzU3Ni5z OjI3ODIzOiBFcnJvcjogc3ltYm9sIGB2bW92c2hfdG9fbWVtJyBpcyBhbHJlYWR5IGRlZmluZWQN Cj4+IC90bXAvdGVzdF94ODZfZW11bGF0b3ItMGYzNTc2LnM6Mjc4MjU6IEVycm9yOiBzeW1ib2wg YC5Mdm1vdnNoX3RvX21lbV9lbmQnIGlzIGFscmVhZHkgZGVmaW5lZA0KPj4gYGBgDQo+PiANCj4+ IFVudGlsIGEgYmV0dGVyIHNvbHV0aW9uIGlzIGZvdW5kOiByZWR1Y2Ugb3B0aW1pemF0aW9ucyBp biB0aGUgdGVzdCBydW5uZXIuDQo+PiANCj4+IFVzaW5nIC1PcyBtaWdodCBhbHNvIHdvcmssIGJ1 dCB3ZSBjYW4ndCByZWx5IG9uIHRoZSBzaXplIG9wdGltaXphdGlvbg0KPj4gYWx3YXlzIGF2b2lk aW5nIHRoZSBkdXBsaWNhdGlvbiBvZiBhc20gYmxvY2tzLg0KPj4gVGhpcyBpcyB0ZXN0IGNvZGUs IG5vdCBwZXJmb3JtYW5jZSBjcml0aWNhbCBjb2RlLCBhbmQgLU8wIGlzIG1vcmUgZnV0dXJlDQo+ PiBwcm9vZi4NCj4+IEhvd2V2ZXIgZm9yIGRlYnVnZ2luZyAtT2cgaXMgcmVjb21tZW5kZWQgb3Zl ciAtTzAsIGFuZCB0aGlzIHN0aWxsDQo+PiBhdm9pZHMgdGhlIGR1cGxpY2F0ZSBsYWJlbCBwcm9i bGVtLg0KPj4gDQo+PiBTaWduZWQtb2ZmLWJ5OiBFZHdpbiBUw7Zyw7ZrIDxlZHdpbi50b3Jva0Bj aXRyaXguY29tPg0KPiANCj4gQnVpbGRpbmcgdGhlIHg4NiBlbXVsYXRvciB0ZXN0IGhhcm5lc3Mg aXMgY3VycmVudGx5IGdhdGVkIG9uOg0KPiANCj4gaWZuZXEgKCQoY2xhbmcpLHkpDQo+IFNVQkRJ UlMtJChDT05GSUdfWDg2KSArPSB4ODZfZW11bGF0b3INCj4gZW5kaWYNCg0KR29vZCBwb2ludCwg SSBoYXZlbuKAmXQgc3BvdHRlZCB0aGF0Lg0KQWx0aG91Z2ggSSBkb27igJl0IHRoaW5rIHRoYXQg ZmxhZyBpcyBzZXQgaWYgeW91IHNldCBDQz1jbGFuZy9IT1NUQ0M9Y2xhbmcgaW5zdGVhZCBvZiB1 c2luZyBjbGFuZz15Lg0KKEkgb25seSBkaXNjb3ZlcmVkIGNsYW5nPXkgYWZ0ZXIgSSBzdGFydGVk IGZpeGluZyBzb21lIGNsYW5nIGJ1aWxkIGZhaWx1cmVzKS4NCg0KPiANCj4gU28gSSB0aGluayB0 aGVyZSBzaG91bGQgYmUgYSBmdXJ0aGVyIHBhdGNoIChvciBkb25lIGhlcmUpIHRoYXQgcmVtb3Zl ZA0KPiB0aGlzIGNoZWNrLg0KPiAgQW5kIHRoZW4gd2Ugc2hvdWxkIGFsc28gcnVuIHRoZSB0ZXN0 IGhhcm5lc3MgZnJvbSBvbmUgb2YNCj4gdGhlIExMVk0gRnJlZUJTRCBidWlsZHMgaWRlYWxseS4N Cg0KDQpSdW5uaW5nIHdpdGggY2xhbmcgd291bGQgY3VycmVudGx5IGZhaWwuDQpTZWUgaHR0cHM6 Ly9sb3JlLmtlcm5lbC5vcmcveGVuLWRldmVsLzEwQjFCN0Q5LTM1MkYtNDIwMy1BQzMwLTg4RUY2 NzQxMTRGNUBjaXRyaXguY29tLw0KVW50aWwgYSAoYmV0dGVyKSBzb2x1dGlvbiBpcyBmb3VuZCBm b3IgdGhhdCwgaWYgSSByZW1vdmUgdGhlIGdhdGUgdGhlbiBJIGFzc3VtZSB0aGUgQ0kgd291bGQg ZmFpbD8NCg0KSSB0aGluayBpdOKAmWQgYmUgdXNlZnVsIHRvIGVuYWJsZSBidWlsZC10ZXN0aW5n IHdpdGggY2xhbmcgdGhvdWdoLCBzbyBJIGNvdWxkIHJlbW92ZSB0aGUgU1VCRElSUyBnYXRlLA0K YW5kIGludHJvZHVjZSBhIGdhdGUgb24gdGhlIHRlc3RzL3g4Nl9lbXVsYXRvci9NYWtlZmlsZTpy dW4gcnVsZSBpbnN0ZWFkPw0KDQo+IA0KPiBIYXZlIHlvdSB0ZXN0ZWQgd2l0aCBhIGZ1bGwgTExW TSBiYXNlZCB0b29sY2hhaW4gKHNvIGFsc28gdXNpbmcgTExWTQ0KPiBsaW5rZXI/KQ0KDQpObywg dGhlIGNsYW5nIEnigJltIHVzaW5nIGlzIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBiaW51dGlscyBs aW5rZXIgYnkgZGVmYXVsdC4NCg0KQmVzdCByZWdhcmRzLA0K4oCURWR3aW4= From xen-devel-bounces@lists.xenproject.org Mon Mar 09 14:49:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 14:49:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249544.1547018 (Exim 4.92) (envelope-from ) id 1vzbuq-0002oh-GZ; Mon, 09 Mar 2026 14:49:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249544.1547018; Mon, 09 Mar 2026 14:49:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbuq-0002oa-Dp; Mon, 09 Mar 2026 14:49:04 +0000 Received: by outflank-mailman (input) for mailman id 1249544; Mon, 09 Mar 2026 14:49:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbup-0002oS-Of for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 14:49:03 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 19846cf6-1bc7-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 15:48:57 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fV0JR4fpJz2lV for ; Mon, 9 Mar 2026 14:48:55 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 67f678a8485b4c94828b135b77d45798; Mon, 09 Mar 2026 14:48:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 19846cf6-1bc7-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773067735; x=1773337735; bh=NWg12KnlU08APrJpMjl9dwlSxHpfdbJzVp82wdhFnM0=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Qwzk+FnWJqJ3nJAA0v1B+jnHniSkZNyFWRbsQZpna/NvCTijObnuQ9mBQs+MwaXY/ jzEp3Sv1+AC2zAESeiolKZdkKbHGasPFGFNlZpm+o3EyM/8VbRdEk/6t6MabWCnA7y sxIuOPF+8FwsvFh2iOEPYAhDgrbNzwYQlpSf7ccQOG7W1doQxZ8rPMpC8yjmkciA0Z hcGx/0bsIOOSvRuE9arBgvI5eIGWXdFbDlrVpspdDfZcUyAwdjBrg3YzoIiSckULZm JPy9mGPBACv9O2N/3DmyZ4F4IayeviL+Bc7dHEHsRCUC5JQuDynzVw613+HwQltqew 62bHNYmJPFEew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773067735; x=1773328235; i=anthony.perard@vates.tech; bh=NWg12KnlU08APrJpMjl9dwlSxHpfdbJzVp82wdhFnM0=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=CECVm6uJAyQ6NaXVVuo7fMemNWA7A0z2fZc5vsFPCaHhHTbjWwM34I53qjeDu3JHm iyp5/HS40pXiQTj9nA4tS/w/cis6hw/fPGbm0KvfgDgJY/gcmFEKNOGSo83jtMmPu2 JMoBLwvxOZk6gm/FMlPYnNSb9zYVxFgBXRNACPLB6zoYTIOURIvYeWiFRty7UBbDwj 63Z8BABtAIG6YXXy6Bw/CR3jf+IOA8gqq2SLJHeVYDeixgYzt7l4R4XUyodieQv8aW 7wQjEQFeaFpOnGexMTzkIWiooS3RARFeaWD8wXfnGJPsFIYjtvDgEe4M7ZLOH+DebR +OFE8srOEIwpA== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[XEN=20PATCH]=20libxl:=20Fix=20device=5Fadd=20QMP=20calls=20with=20QEMU=209.2=20and=20newer?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773067734786 To: "Maximilian Engelhardt" Cc: xen-devel@lists.xenproject.org, "Jan Beulich" , "Juergen Gross" Message-Id: References: <20251215135124.11410-1-anthony@xenproject.org> <92e6ecac-7a5f-4831-8116-0c34856f1175@suse.com> <2692705.Lt9SDvczpP@localhost> In-Reply-To: <2692705.Lt9SDvczpP@localhost> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.67f678a8485b4c94828b135b77d45798?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260309:md Date: Mon, 09 Mar 2026 14:48:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On Thu, Feb 19, 2026 at 02:29:07PM +0100, Maximilian Engelhardt wrote: > On Monday, 15 December 2025 15:41:02 CET Anthony PERARD wrote: > > On Mon, Dec 15, 2025 at 03:11:53PM +0100, Jan Beulich wrote: > > > On 15.12.2025 14:51, Anthony PERARD wrote: > > > > From: Anthony PERARD > > > > > > > > QEMU used to ignore JSON types and do conversion string <-> integer > > > > automatically for the command "device_add", but that was removed in > > > > QEMU 9.2 (428d1789df91 ("docs/about: Belatedly document tightening of > > > > QMP device_add checking")). > > > > > > And older qemu accepts integers as well? > > > > As the QEMU document explains about the removed feature is that they > > should. We already have two users of `device_add` which use integers for > > some arguments. And just to be sure, I've just tested with QEMU 8.0, the > > patch works fine. > > > > Cheers, > > Can this patch be picked for the stable branches? I'm in particular interested > in 4.20 which is in Debian stable. Done, thanks. -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Mon Mar 09 14:53:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 14:53:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249553.1547026 (Exim 4.92) (envelope-from ) id 1vzbyp-0004Li-Vi; Mon, 09 Mar 2026 14:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249553.1547026; Mon, 09 Mar 2026 14:53:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbyp-0004Lb-T2; Mon, 09 Mar 2026 14:53:11 +0000 Received: by outflank-mailman (input) for mailman id 1249553; Mon, 09 Mar 2026 14:53:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzbyo-0004LV-Uo for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 14:53:10 +0000 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [2607:f8b0:4864:20::112d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b0104d8f-1bc7-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 15:53:09 +0100 (CET) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-7986d231b3cso146093667b3.1 for ; Mon, 09 Mar 2026 07:53:09 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0104d8f-1bc7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; t=1773067988; cv=none; d=google.com; s=arc-20240605; b=ZDmw0P2xg3rzGpam7ekL8IaqS/+qwldA779uY2fzVd+APRS9O3xcJM7topL+/PYRM4 z+dSwE784ygRur3Im1JhMZZx6qbD1tRefa+5iKai2c5h/TXLVFgxSmprVE4wfzEE9hB0 U9yO3AIs+ZOfPtl/GGzH5eF15PJ8d0joP5aY1ncbMT8eU6wrCj5VbjSbtvULTa7tDx8H INPT7bfAvbhdhhNe9U1XQupjqTAH7Sy/Vhybamx6SpXgmVNE3Z94sniiimpQXVhBVxVK FCx1iMN1HOVksOxSp6ag53aNEbfGWzn0OTuSYBZIwHKDqgxOFsmgg93zfmNtjJamHNt8 Ta4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Lmlr5xwlzExeVLyiIX4eKEZ6XfFdWyLdssC3qJF98xs=; fh=TDIhF0REsZYF3tEuaM1c9m2WWJLNBdvBT/MFEObGrQQ=; b=UO+eINfGdk2JTtI7ha4UY2LLpGBPanS+cQcV0j9RySgwDdb4fLsD1VS9vad1gug2wY uOtd/p+b5mvcajqhQAeUXaBY6pBkRt54WlBwa8o0CHr0Ravv/VFFvQqgpXW7eRwNsT2J HzEpbF/TGwHFsmlXX3kvoWKlxl87RTWl8BwdRwr9axNqjDqerwZvpJVmY9wzo0MzVyqV gRrLHPjQYl5nIygkMPryDs3IYFHe02XpiQNMRZov2NzwilSwkRlZzUN5JYA6CbH3J7rV LDxJL/H5X0lovWttPFO9mkja5vpcUiV+hiSElaSkI3sknknhIhjqkXQkOLs/6uzl8i7i G/yw==; 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=1773067988; x=1773672788; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lmlr5xwlzExeVLyiIX4eKEZ6XfFdWyLdssC3qJF98xs=; b=jYUW3H1khmbdNhXoRHSWWLw/s76ZHHi1v+fT264rqLTl1/kpIu3htF0flrEVv94duC 0/Iq7VVLLJQUcRVOW4InrsO7/YHK7n7KKHF/maCZc+THLc8Slg//z0qt4hOeC3QAxYUG qtfPldwmp5bkCNh8292TM28yxcpfjgK8pyfGZ2yuTKnPkaHnY5BYOtIq81pMFMERG2+u b++2XrTLMozzdX9KBZCtEfJ8QrUOTlPJuS/ex0XXZ1lDR3d+3nj+MpBYm94JQYCvr8nq /BzAKqw+NqSWqvD52lR5zDKZxY5wZA2Rb3o2cVAP+Gwg74/Kpc5oLGY/UuYdkkjcd+HY c0UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773067988; x=1773672788; h=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; bh=Lmlr5xwlzExeVLyiIX4eKEZ6XfFdWyLdssC3qJF98xs=; b=rQS8DGZBhNr7spXVpKBYmxTkkjrY/8Zso54aqdsx6/GGddSrs/9mWXUFnYQa8YATTi 5amIe6wK/OS260gQ2O7qKMrwg1h16YsENlh4bxnTKN9nuGTpg5NcI359KHoDraXjt2jw yaI6zGguJAvfta8+f+nDWFpUiLtQsmvoQAOa8N9Gkf8RB4lF61tKEOcIWuz8WNFBAmec 8AFcWbXKxiWSNZxcGVDZMsE08ePwiNiV1iJh6Z4CAFKSOtCkUFy6umIANrcPkTPMYhvv Zqlo3DffgQEUpnfo4EQaD0Qw3MxuzpNbVPHloAfvsSEf6478C3NUm/YR6jorNPDX5td2 BRJg== X-Forwarded-Encrypted: i=1; AJvYcCXYvlitBQ3L6rJWrTXDsGFX/AlvoIYzAV2SpWUuGWC/Y6v6V6xWn+fQljJRfHwtrG5HzjjBvfWvCnw=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHBeKBmlbGfTo0p4T0LYtWcRSv0SSKBeAbFTqiImqYmcSldwX/ 5OiqbASyXktf2WObgVdTZxxWVJO1pZIQA62SU/VWvCg/BfZrx6ngm7csN9Rhn+8Z2iAnaiWCcxk /PJw6N5BlrJn/Kn1GXx2wwW1S7pmYgnGsmJt4NFPjfg== X-Gm-Gg: ATEYQzw4Zq6DCQ7MOlKXGHgpKNq0vGT1arxBR1LPR8VT2R0JfYzj7AOjQE18sZQe20L PCQ541TEx6ILOZTCi9loGfVWupSo8Puka94NZlEjsUTsZRaO4wMvW14JcBScshiSKJ/LdoF4MJ/ KFCjL/SsWA+ozk5WDTD7TDfFhYv8u9aNe9tnAY6PwgoHBfAVlV2rIfK2chvQ1E1SWCCGrwwSlkB aAkcmyvGlwpfwwkXexQc0wWq7WfQpEor5yA7IpTd1iKQ9wThFopK5BI/N6s2z5xKv8mM4dYmy0R mhxq10Ts2QvXq5trt63qx/wluZmyy3gR2oyzDrr/VF1NIHHc0SVfkMuuv1Zy/2YjXLU= X-Received: by 2002:a05:690e:444d:b0:64a:bde9:3423 with SMTP id 956f58d0204a3-64d15477513mr6647221d50.9.1773067988458; Mon, 09 Mar 2026 07:53:08 -0700 (PDT) MIME-Version: 1.0 References: <20260309064436.51860-1-edgar.iglesias@gmail.com> In-Reply-To: <20260309064436.51860-1-edgar.iglesias@gmail.com> From: Peter Maydell Date: Mon, 9 Mar 2026 14:52:56 +0000 X-Gm-Features: AaiRm52x_MZSsoQWEpX_SVubQ81MNXoACRIsTZMqUhmaBur07rlXpMyBFnbdJgk Message-ID: Subject: Re: [PULL v1 0/5] xen: pvh: Add machine option to disable the mapcache To: "Edgar E. Iglesias" Cc: qemu-devel@nongnu.org, sstabellini@kernel.org, anthony@xenproject.org, edgar.iglesias@amd.com, xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" On Mon, 9 Mar 2026 at 06:45, Edgar E. Iglesias wrote: > > From: "Edgar E. Iglesias" > > Merge tag 'pull-11.0-virtio-gpu-updates-060326-1' of https://gitlab.com/stsquad/qemu into staging (2026-03-07 11:22:16 +0000) > > are available in the Git repository at: > > https://gitlab.com/edgar.iglesias/qemu.git tags/edgar/edgars-xen-queue-2026-02-09 > > for you to fetch changes up to 83d1d9a49e8eb970f87508ae4ce0f222084df365: > > hw/xen: xenpvh: Add prop to enable/disable the mapcache (2026-03-09 03:24:02 +0100) > > ---------------------------------------------------------------- > Edgars Xen queue > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/11.0 for any user-visible changes. -- PMM From xen-devel-bounces@lists.xenproject.org Mon Mar 09 15:35:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 15:35:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249565.1547036 (Exim 4.92) (envelope-from ) id 1vzcds-00011J-5c; Mon, 09 Mar 2026 15:35:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249565.1547036; Mon, 09 Mar 2026 15:35:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzcds-00011C-2p; Mon, 09 Mar 2026 15:35:36 +0000 Received: by outflank-mailman (input) for mailman id 1249565; Mon, 09 Mar 2026 15:35:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzcdr-000116-3Y for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 15:35:35 +0000 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [2a00:1450:4864:20::42f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9c889f56-1bcd-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 16:35:33 +0100 (CET) Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-439c4a93841so4220712f8f.1 for ; Mon, 09 Mar 2026 08:35: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-439dae36785sm25279038f8f.27.2026.03.09.08.35.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 08:35:32 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9c889f56-1bcd-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773070533; x=1773675333; darn=lists.xenproject.org; h=content-transfer-encoding:autocrypt:content-language:cc:to:subject :from:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=gN3OIK4zpzgpwDwkcYY8kl1S/ufLAnvzjD11ofjDojc=; b=bNXOTkw0jIfWDdkUoVoQkOHwEZJ/1QuAr4OyjotoVKBw875Xy2XanLaQ3DR+Um6ceA yQEg0m2CXkmqeapaCRu96DSNhLhRP4U/ivwjGwnED8GiTyiYlXQHWb5CuLK7sK3EZmUu ES+hl4CHtTPYUJrxeDpESZLTbo/S/61Pwr1DEBgrytioRGfdmftUEscadPYQlFNRuK6w BCXv7jD+u3iJuxwdolKWARInNuOUYIP+eWETOVCN8zI4QfNPmWgZpaWn7DbxRMZ9Cw34 184p5CIDTrbR+JaTmPC7K6vQZWvIZWRB36vKTZM7CI3nPnNaZbwHQW7t1o+MGBGxY4HU xbdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773070533; x=1773675333; h=content-transfer-encoding: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; bh=gN3OIK4zpzgpwDwkcYY8kl1S/ufLAnvzjD11ofjDojc=; b=Gaz0WkM73KtFolFcN0NZURTEJS/crANp2ah5cE2eEdiwGSFuPd6Tb3Wz+FQwZC4eM1 zNyMa44Uh6pRN5ACucvTeRTaCMuA+6US/X90C2mbEdDoj/07fnR8ylUqiGIIg1hdwPa1 Kk5VvM+nvUhcu+QH0IQDSWhpilo5Cg3KyQeiSlU52OqsPsjPLxA6UXJpt/AGEb1xk99L KPkwtDdMwadd9mer7JhUJGjgqV2vc9trt16GBGz99Oa2J1XCIMsP7V4av10pARz9QnHV 6NBoIkhkn9dAsDhOKVQhYB5mCmtbvlfFVjY/7pkbkOEkLjh1m8aYtqYOYzMCuFrs691p E3Ng== X-Gm-Message-State: AOJu0YyeerNzCaOuej+ieE7qk4ReW5QQu0V1v3CYjto6VO9F/IuoGkeV sNO7pULmAirwlaJmz4EgImlCKVb/7MiGzYswAYpB+9mqWG264Bq6s1L+6naDfivAASXYKkF8AGL /3Dg= X-Gm-Gg: ATEYQzwBmDPhJjGRjEJr6kp67WTxeeSEVjqESeQ/XGW34sCLB4IrMcp1FEKCrmLWvNo 9ZMsvD3B3G3fW2amqRsBVBVD49Q3+tCOPukuKG5ZOLRb5Mklds8meYrfVHv5kWUieWDfJA0VAvd O9xi3YekivWXaihrcUyUadNTsMc4B36o7q8PYR56BZgokt8QiBWL+mtvxneh3bXEYfWi1Ie49YR 39EiFuCHq4tCI6oe4OvUEZUeGn9teTrkROz7lgoZ/KG4DikqR8wsRgW0ApXuBI5T0YO9K3edXfw nkOxGmwI3/C8fCkR+K7HfjkonjfORnFTvJcc6ek+InoD370YTVnmeJ7Fw9k8Whf8jULaLatnjvJ xLvFkMCc8Hd22EMWySc7vUjcaNVBAzYyUKACHVYqay3PSNGQVtTWIIq5K0RgSi0N5R1NlKrCtrL 8eq/oLhD/aeSkU7GZ/rieqZC8FmuBWrjPqhEIdsnjDMg9Dkc2wPtLSMHdhRH0IrCXCrcqy9r7ij HPj8pE8KRGT2gXlLwSwFuci5w== X-Received: by 2002:a05:6000:1845:b0:439:b506:e430 with SMTP id ffacd0b85a97d-439da351debmr20253337f8f.17.1773070532813; Mon, 09 Mar 2026 08:35:32 -0700 (PDT) Message-ID: <29922662-8b95-4a69-9401-11480df59cdf@suse.com> Date: Mon, 9 Mar 2026 16:35:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Jan Beulich Subject: [PATCH v2] core-parking: shrink core_parking_cpunum[] To: "xen-devel@lists.xenproject.org" Cc: Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= 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 This NR_CPUS-dimensioned array is likely unused on most installations. Therefore it is especially wasteful for it to consume more space than really needed. Allocate it dynamically ahead of registering the hooks. Further the array having all fields set to -1 is actually useless. Nothing relies on it, and core_parking_remove() doesn't restore the sentinel for vacated slots. Drop the initializers altogether, rather than replacing them. Also take the opportunity and update an adjacent variable's type, where a fixed-width type was pretty clearly inappropriate to use. Finally drop the redundant initializer from core_parking_init(). Signed-off-by: Jan Beulich --- I assume there is a reason this is acting (mostly) as a LIFO. Else a simple cpumask_t would suffice. num_possible_cpus() would be the more correct thing to use as array dimension, yet we don't maintain cpu_possible_map on x86. --- v2: Use dynamic allocation. --- a/xen/common/core_parking.c +++ b/xen/common/core_parking.c @@ -20,6 +20,7 @@ #include #include #include +#include #include @@ -27,8 +28,8 @@ #define CORE_PARKING_DECREMENT 2 static DEFINE_SPINLOCK(accounting_lock); -static uint32_t cur_idle_nums; -static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1}; +static unsigned int cur_idle_nums; +static unsigned int *__ro_after_init core_parking_cpunum; struct cp_policy { char name[30]; @@ -188,7 +189,7 @@ long cf_check core_parking_helper(void * return ret; spin_lock(&accounting_lock); - BUG_ON(cur_idle_nums >= ARRAY_SIZE(core_parking_cpunum)); + BUG_ON(cur_idle_nums >= nr_cpu_ids); core_parking_cpunum[cur_idle_nums++] = cpu; spin_unlock(&accounting_lock); } @@ -263,9 +264,12 @@ static int __init register_core_parking_ static int __init cf_check core_parking_init(void) { - int ret = 0; + int ret; - if ( core_parking_controller == PERFORMANCE_FIRST ) + core_parking_cpunum = xvzalloc_array(unsigned int, nr_cpu_ids); + if ( !core_parking_cpunum ) + ret = -ENOMEM; + else if ( core_parking_controller == PERFORMANCE_FIRST ) ret = register_core_parking_policy(&performance_first); else ret = register_core_parking_policy(&power_first); From xen-devel-bounces@lists.xenproject.org Mon Mar 09 16:20:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 16:20:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249576.1547044 (Exim 4.92) (envelope-from ) id 1vzdLQ-0007li-Ac; Mon, 09 Mar 2026 16:20:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249576.1547044; Mon, 09 Mar 2026 16:20:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzdLQ-0007lb-84; Mon, 09 Mar 2026 16:20:36 +0000 Received: by outflank-mailman (input) for mailman id 1249576; Mon, 09 Mar 2026 16:20:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzdLO-0007lV-DU for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 16:20:34 +0000 Received: from mx1.somlen.de (breeze.somlen.de [2a00:1828:a019::100:0]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e4c14583-1bd3-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 17:20:32 +0100 (CET) Received: by mx1.somlen.de with ESMTPSA id 8C61850C34C; Mon, 9 Mar 2026 17:20:30 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e4c14583-1bd3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daemonizer.de; s=202303; t=1773073230; 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=ZgzjjuSkW18P1q0YDVh3ZpT1HB0jbglyqdNQdpVWgeE=; b=VpK7xzhfQoQ+vMCEEs3kO2SgpkwemEjaHmVrq/Oh865KYw3PZkz9s58OaLZjfRvfRwDm9d jR2pXo9UA6/dXR4Qf4/AM4o1s8c+eGIlGT373VwcjwE/WALMEGrD8skESvC25g+r0SdQGk B0bITgR410UOthZfQxqVVfM2M+jF/S/Ezj9FL3rYJqadhVNTga4EGrP3huJy+/oXRPjTGi nBodxwyqePQBIVUlEwF8S1yK025KKHGrWEu6Yv9S0d7c7RyGd22KeGROksRRkRliKeIYd/ ar1LhlRPnlMNifYrDg64SYHIBD55Z4Z1wlYW4BGZNtxrCK31SEVVrDkRFtKEQw== From: Maximilian Engelhardt To: Anthony PERARD Cc: xen-devel@lists.xenproject.org, Jan Beulich , Juergen Gross Subject: Re: [XEN PATCH] libxl: Fix device_add QMP calls with QEMU 9.2 and newer Date: Mon, 09 Mar 2026 17:20:30 +0100 Message-ID: <1983406.eGJsNajkDb@localhost> In-Reply-To: References: <20251215135124.11410-1-anthony@xenproject.org> <2692705.Lt9SDvczpP@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Monday, 9 March 2026 15:48:55 CET Anthony PERARD wrote: > On Thu, Feb 19, 2026 at 02:29:07PM +0100, Maximilian Engelhardt wrote: [...] > > Can this patch be picked for the stable branches? I'm in particular > > interested in 4.20 which is in Debian stable. > > Done, thanks. Thanks also. We meanwhile got two reports in Debian from people running into that issue (plus me), so it's good to see it fixed. We will pull the fix with the next xen update in Debian (but not yet the upcoming 13.4 point release), which we always base on the upstream stable branch. Maxi From xen-devel-bounces@lists.xenproject.org Mon Mar 09 16:53:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 16:53:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249589.1547053 (Exim 4.92) (envelope-from ) id 1vzdrT-0003Fj-MZ; Mon, 09 Mar 2026 16:53:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249589.1547053; Mon, 09 Mar 2026 16:53:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzdrT-0003Fc-Ji; Mon, 09 Mar 2026 16:53:43 +0000 Received: by outflank-mailman (input) for mailman id 1249589; Mon, 09 Mar 2026 16:53:42 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzdrR-0003FW-VX for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 16:53:42 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 85c5d2df-1bd8-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 17:53:40 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by BN8PR03MB5123.namprd03.prod.outlook.com (2603:10b6:408:dd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Mon, 9 Mar 2026 16:53:35 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9678.023; Mon, 9 Mar 2026 16:53:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 85c5d2df-1bd8-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PARbB9A8D3wjK8vqrWnQXsWp8l0xWpoiC/i/g7dyMed7/JTWaRYUdwwhrYiKM8HkCCul3kd7Vgx2A7B1PXmFkmChDshbSFTKyW5Tn262ruJcsx8Tq8V9sYDWWghBZRn2aDUCZpPzjAjimxpA9i+QGvxdFQy2rdafUHx4NqHo2nQA04LZpwTg2mzfOe0dn9opHw+zFD1GbgA1YThDD8EvB28Sfv6BxLjNAFkJjPtdIpNWIzjlaIDUuzAkyWy0/3K1uKtwds4+CiIIVEQx0Xe/xDtUUwwwDG+ezjHbDc6cfUeDCAmHdFIoPO6AqPU2MHc/TQmKimybDP3ACwWhtaas+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=a0Bh42TUjZTh+rzACCZYpg1BDDBu4U+CqxHDb9ejKv0=; b=Wzy00+5THPCxsawqjE1H1CqLZImIfLpxGa/ugXlNLPXHio3mtgImS67mkaDWPtJtJMCKTnb1YAmp2Qw9Hoy5zJ+1pFj1KsNg6uwBRZ6gpHqHKod0Bd5p3QVEj6IoY3bpeU4FWdTQzfYxlD8Ps3YwBT/uXxnyuHD2PHZSKPT80Pfjya0Clz5+jPeVvmLGY90lSugFEKL4wy2SqhAAnFbVO0Wnikkp/zKt16rzEY5vZ30BczLUFzDD6sSWW7+eR7E5xmjw2qjPn97XjqS2aUQesjz0ReY8X1Xw3K1NcOMVR5+vmAddTujnJLG3XX9XZHZIcK5682euaTJq3sijin0lAw== 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=a0Bh42TUjZTh+rzACCZYpg1BDDBu4U+CqxHDb9ejKv0=; b=CMvlyCVpHg1aM9ndNPib4in4LtvDqh7fNOJDTy1kengx9fPzuZvj9692Kj3/4uCtVzUgw/AA6nkM4yVOUG5JiasA/bhwP14gvW6IVLlu6ODxbobrl3hAax16EOl2Vs5FmPbZIKMRF/zeCcUNU4vE8OrLlJ6DuN6uN8vnc0Lhq0E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Mon, 9 Mar 2026 17:53:32 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH] domain: move vmtrace_alloc_buffer() invocation in vcpu_create() Message-ID: References: <528578e1-6374-4fd0-9f67-0769afd2e1c6@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <528578e1-6374-4fd0-9f67-0769afd2e1c6@suse.com> X-ClientProxiedBy: MA4P292CA0011.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2d::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|BN8PR03MB5123:EE_ X-MS-Office365-Filtering-Correlation-Id: fdd6619a-803b-4dc5-c71e-08de7dfc6775 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: /ENrw6PcIIU3IEhQxWxFZF5IB25cuHwBGPWVSiKoIpcYPqeWxFDoGaTpaMjoSyj758cSFtyT4prdVYlWWVZDemvvadfoK+Pux9gj+9ZTAcosgRraMLO+ZU59YVFpWIXT/O4KJ9TKZM8gM1rBb3qEcr35zqY7LGEA6Cxf3lRn74upxKRoUsL2bqQJohwBn6vJPwucTHoqbpA1dOkPYvImMeFulawq3yWyLeqcAQi2vJDCMGfIIMvcoyAIeF287yukhYWAcV+Sd654mz/1ZMsk4pdLXrdV3JcU1yx/6AlfIEYTrldcNOebM9Fw9ts/rUCyepLUBP4OGZ3tWJN0EV+4B+ubtPMKxCw8SDJwu7XHYa3WamoQBI7C4FsJsVB+Hbzt0B+UQ1+d1kAQGsWU/9bs5TokIrnA4iWdWGrC338F/xugD1R5qOD1Fc0fRiVBIw92Jp4tpzKwEMUvd4TPoTI+Z0p7qxugKXY+5+rRg/VSyYWCW5oIRSNTC2rvw35mxzut/HInGDNfErNgqbCiikM7jeS3XmzAwXNYJe2LaMRDxXhVFiM3Goxz9ZCXRl3Zr65oTl3kxX4ZFPxNaVtTDGN6T17VcOsagIBM1oBmpd3T1zL++5EgWjBLJ0uC+LraNv2RUWlD+w+2pxjN+9lsEa9oafGhB4femm4B5i75+yEXM4CeoA2kweTTpXvQWa5tEK+j9FVoSd1sB+K3qEGjORZtcCGJaqP1jVkvaounKzMaL7M= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bEdMWjEwTWU2ZG00aFkzWUV1WWVGWUlTYzFQTDJETjlmdFJpbEJ3MFpTT3R6?= =?utf-8?B?djBoWSswYUpZVU1jRXZqOTR5K01KajZnRTMzSUV6UmpPVzdwS3FhNm9hejhr?= =?utf-8?B?MUZLUEFhZklOb2RpbEg4U1QxQTR1NDVOcW1iTU5lNXNYSklHSXliZUJGVGVm?= =?utf-8?B?cm8zS2tweTZZTExFdzcvNlBNM0QvV1huU053cElrTStvdjFhaVhrQWhEQmpP?= =?utf-8?B?TVNGbDdOM0dIYndraldZb1g0L1BFQUczVThmU0VjdmdOQlFpd09FZXZuSmhi?= =?utf-8?B?YkFTd21OaWN6VWtsMy9aT3FydW5YeUlHb1M0V0MrclhVUnlHTkt4b1dJa0VC?= =?utf-8?B?VUFKVlVOTkhOZVRhR2NhMmJQaW45M0ZDRUdjaU5uVEJWMk1IemY0UFEwVGJC?= =?utf-8?B?VXo4bjlrMXpFOUVyeEdqRHk0Nlgybzkxcno0bkRMM2NQcUxrR0N6b0Nxblc1?= =?utf-8?B?SDNWQVV0NFFQa1BjbnkvaWFHQnNOWlEyNHNzcEgyRWd4TjF6U3hXbDNCVG1R?= =?utf-8?B?NDlhV1E3Y0VGcFcwRXgwNGJYUloyQW5heXIxaTkrWnhlQmE0ZldWZTVzMEhn?= =?utf-8?B?S2FUalM2VmZPR1RoNU1zZVlMQU5GaFpocmt1aU40b1YyTStQSzA5L0pvaFhE?= =?utf-8?B?dVdocGVnU3ZPRzllV2gwM2E2QnpJLzBDYmFDUUZBK1c0NGx2V0Y5WlRSL3FS?= =?utf-8?B?Zm5GeUw5eUVhN3lQM2JmVUF3YmhvSm9jODNoaG44RG1Dck1GS3ZiTC9Pdjdq?= =?utf-8?B?SVNjMCs5OVBGZDByWWk0UlZyR09KZ25XbmZiUUhEUlRHOXlZbndJZm1RRW9x?= =?utf-8?B?RGtHNXJ4RzBpaFo1azkrL0VQSU84dWtYNGZ2QmFuSmlHNlJjL2YydTk1UjNv?= =?utf-8?B?ajRrdDhRTlQ3Y2hxcGJaQkRoQ1NUdkY0YVFVR3JCL0J0ZGxUVUdsK2VJRkxt?= =?utf-8?B?Yy94SXYxS1pFOW9oVmxDc3VmRVBZN2hsU2FMWUtMblc0U2dLTGlURTA2dWk5?= =?utf-8?B?NDgvNkZySkY4NSs1Mk8wTWJlV1lrWENXZ2ErK21QWkxhVmpTajVTYU9XVm54?= =?utf-8?B?bHEvL0JNdjgzb2FXQ3dSY1c1ZnJxb243ZWFUTEhwekJCUVdKSnI0eXRsT3lZ?= =?utf-8?B?UTdlcDdJRllJSW1kVE1rOGgyT00wYlhDK0Fjb3V1c1ZpRWxxQ0xRR2N4bUU0?= =?utf-8?B?dDBBanpiWEtMMVFiNzI5cUxkNDVhSWFVSGFJRU81VisvVUZrdE9SZys1Z0hi?= =?utf-8?B?MjdPYlFhaElCZkNORSsyR3hiTFBuY21TdElJazk1RUVMeXBpODhva3k1SDJJ?= =?utf-8?B?OHB1bFYwaThsQ3R2RENrWjRLeUg4dDBjc0FlTlZVVGFORVRaZDJlQXhtN0Nr?= =?utf-8?B?WmR1OUVEM3lnK0pneE8vN3A1Mml3MVd3NHR3bFFrNUdVOHdoQW9nTGp6VUdZ?= =?utf-8?B?c0xORUUrVG5ISVptSlFTQmFqVElXZTJlZm5FcUtRWXZMVy91YmZuSVlpd1l0?= =?utf-8?B?ZVRkZmlHSG5URU9Jc2d4dkd1T1N6TWZuQjllRy91R1MweGliaEJCS1AzMitr?= =?utf-8?B?aG0vSTZYWUhWZjlFclZNUHMxcjc0T1JKMDJSOHRsODVtazZGcStQY241eUlq?= =?utf-8?B?WnlWdUdGd0FCWXZYeFlHMVZONkVHbnJhd0RwdFA1YjZNTW9UcmZJb2ZzaVhB?= =?utf-8?B?Qzc3emIrSnRGY1JkYm5aMm1BVzFJL1JsZkphWHJZeEREUU53ZjFyTm9MSjdZ?= =?utf-8?B?VXV1MFBPSS9kTkJNNzI2ejJmRDBKMmovamVyQUJ2QlQyNVNaZ1RzcUlEclRy?= =?utf-8?B?WjBGS0NGMzZjanlZWTgrazBDanpzbTFkdlV4WFhpUVlFclVFcy9NNURTSWpL?= =?utf-8?B?K3JWa1BsWmdsQ0EvNngzeVRsV2xBd1R6aksrbzd5TkJaR1B3bjdSQ2RhL3hi?= =?utf-8?B?QmZtcFpDNzhBQ2UvSFJDVkFIZWkrZnhNWVR6SjZsZkgwT24vL0FhaFR3YUlV?= =?utf-8?B?ZVg1SzNud1hUSmhZYWdpaVU3ejlzanBNL2hrWEprNTFiZXYrNXNGaUFPdUZi?= =?utf-8?B?MFhRMVdpQ2tOUzlOQVJ1ZVBJeUNRV2ozMThRd0NaemhvMVdIeVJUZXhTSXBK?= =?utf-8?B?QXFMUk01NS9KUkcrdFJuLzFyU0lwWEc4MkV3NFkxcGwrTzJPTkh2MXZYb1Vx?= =?utf-8?B?V25wejRZYU9MRnNFamV1UGx6OTM1UG9FVFBSWEl3WkxrUzZUSXhQRVJoM1d6?= =?utf-8?B?TGwxSjkzL002R0hpMWYrMXhSMFVnRGdBeW9YTHVtZE5XL2E5TUk0MHB1NS82?= =?utf-8?B?ZnNUUFFyblNUaVRQNmpzWklKY29BaXR3bnNFTUNkNEkyeTNwWXFRdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: fdd6619a-803b-4dc5-c71e-08de7dfc6775 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 16:53:35.6888 (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: LPA8VpYQfpACSe0Y4dPJBrZd2KLAathyhFqg6QQPl0Uv4iM3HyQJSjrt7pPc1mPoV8yEi3HNI7Xvs7vK7pEmDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR03MB5123 On Mon, Feb 16, 2026 at 04:51:53PM +0100, Jan Beulich wrote: > The label used upon the function failing is wrong. Instead of correcting > the label, move the invocation up a little, to also avoid it altogether > for the idle domain (where ->vmtrace_size would be zero, and hence the > function would bail right away anyway). > > Fixes: 217dd79ee292 ("xen/domain: Add vmtrace_size domain creation parameter") > Reported-by: Roger Pau Monné > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Mar 09 17:54:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 17:54:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249605.1547062 (Exim 4.92) (envelope-from ) id 1vzeoC-00028v-UT; Mon, 09 Mar 2026 17:54:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249605.1547062; Mon, 09 Mar 2026 17:54:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzeoC-00028o-RD; Mon, 09 Mar 2026 17:54:24 +0000 Received: by outflank-mailman (input) for mailman id 1249605; Mon, 09 Mar 2026 17:54:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzeoB-00028d-Ay for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 17:54:23 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fdda7f7b-1be0-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 18:54:17 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso97084755e9.1 for ; Mon, 09 Mar 2026 10:54:17 -0700 (PDT) Received: from [192.168.69.201] (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541a8f610sm12732545e9.7.2026.03.09.10.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 10:54:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fdda7f7b-1be0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773078856; x=1773683656; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=DQpCcbWib06GwrSrjKEgPauEB4pMQNN0BW8pnBJ7+wc=; b=AoQPx0vcvC4+N37Al/MmKLSpkhQHr0yf38PVakix4nXGwRE/USQJKX+sNKUJOUSN+2 QCDg+FSY68xsknyg1x9Eigozv2nkq2TM4p+9ZIfu+RXaJCQEBO5udbUSITPzrG0hS+MN DU9+lIX1HOq7d1k85cc4FG9npcFwd/mE/6siZfukQ33F61dZ0ejGFH2kZvJBN9FYHCbQ nkPpHIv+Ug7GquchSDwvXOqB0V5iQrxPrsWf/rljNPOQ31EFHeRlb/Uhhk1k3IsK/W5P nnqKgfcFUE82gVl1K+o+0V7GjqiXCkHpVyk2MjdXkOB5Zhh9PnSVdDkZedF0Uh93vqt9 FIBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773078857; x=1773683657; h=content-transfer-encoding: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; bh=DQpCcbWib06GwrSrjKEgPauEB4pMQNN0BW8pnBJ7+wc=; b=dSA1vSHpotk7tbaRjIOYO9owO5pZ2GLKDAqpFevtbJY6YWIqWoz4Kk6iI6JWxrpFYM OF/alj0glpvRHtpuKFHZjVv1Pgzew2EK0YBk0ARdHrsh2IVMOAYKwyRx5NeOyHObGSUI g6yfXyy9ijMpF2ETrY4S0m/js0/TKHEbiiuaJKkA7li70J+lc25Y3LNWS39LBSfqEjm7 6COfruwvd5MXEUC7dyHjD3NAxmwg9TBXERmhN7iVxQpb+2OW5U75acO1+UtrU9wyIy00 KhEQAHgSVVPYHtEmB3Q5gtDXLR6Gd8rmPAuJk8zzCsJkz42FgNWeKTvCyJvpDL2A18lP /EUA== X-Forwarded-Encrypted: i=1; AJvYcCV4x6qRmex+uYIiZRDo78UvSEOqH+6Gkj/YIzEOKqnpKcCpWlpWYNN9jNKm1HFqCl1m30MT3egdloc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyZ4s4xw2xpHpR9AC7HICQmLPNkeg+Td02e8/wzLg8bcpRN4rBR Q9yraSpWo39dqgjARtR8NY/z3UxWd5HlLRVajYH4CdZAptFrHkmdA/tWmYA5oAPGhNo= X-Gm-Gg: ATEYQzxnixMn7PyQ9y6Gbb+j0hOfLi6VyugQ8BEmKHOeZUWXCBL4sOf3/URr1hafEEk Cjj8W1Bt1S4p39WvMX0u2X/u7r+Gy+C8mC5wxcCyEr/Bi0wySmZrYvS/3pRhZ0DbEem+Cx/4a3s Fj026y8IuPjIYsGQiAn/uTrEeK18V1X0C5pFXJZOeCOHk6RSFqV9TS0AmZxW9ONPY/4ZJN/QrRm a/RhVkjqLiqj8PqWQu5HWE5H65xOLgQspkUnjeObVX50AQ3iMwSvhpwH6MqywlpO/6uZSpzRc+G M9TT9KHPTR/32o1q/JmzN4jqaiX1TCJ7z6DOK7ROzM99T5E8IlW7aTBw6jPDWGxrvdBDzpskCk+ 0umEwxykafM7XrCtIueYRX+7INQAkBEhti8u9jbikHzn7EgivKeOlb8aCRxWxr6rTJDAiC/P3as rlyYivwx3r8k+e8WsDzsYln/MeO0sKtu10ojwTNVDI/1h52O1UaJcFU/F6bGan0PiKtA== X-Received: by 2002:a05:600c:4445:b0:483:6a8d:b2f9 with SMTP id 5b1f17b1804b1-4852690febamr219281285e9.5.1773078856525; Mon, 09 Mar 2026 10:54:16 -0700 (PDT) Message-ID: <80f7ebc0-2ca9-489e-a017-29965a3fa50b@linaro.org> Date: Mon, 9 Mar 2026 18:54:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/5] accel: Try to build without target-specific knowledge Content-Language: en-US To: qemu-devel@nongnu.org Cc: kvm@vger.kernel.org, Pierrick Bouvier , Paolo Bonzini , xen-devel@lists.xenproject.org References: <20260225051303.91614-1-philmd@linaro.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= In-Reply-To: <20260225051303.91614-1-philmd@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 25/2/26 06:12, Philippe Mathieu-Daudé wrote: > Philippe Mathieu-Daudé (5): > accel/kvm: Include missing 'exec/cpu-common.h' header > accel/mshv: Forward-declare mshv_root_hvcall structure > accel/mshv: Build without target-specific knowledge > accel/hvf: Build without target-specific knowledge > accel/xen: Build without target-specific knowledge Series queued, thanks. From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:35:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:35:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249618.1547073 (Exim 4.92) (envelope-from ) id 1vzfS8-0007JT-US; Mon, 09 Mar 2026 18:35:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249618.1547073; Mon, 09 Mar 2026 18:35:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfS8-0007JM-Ql; Mon, 09 Mar 2026 18:35:40 +0000 Received: by outflank-mailman (input) for mailman id 1249618; Mon, 09 Mar 2026 18:35:40 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfS8-0007JG-2d for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:35:40 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c4ee7ce2-1be6-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 19:35:38 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-485410a0a8aso4452585e9.2 for ; Mon, 09 Mar 2026 11:35:38 -0700 (PDT) Received: from localhost.localdomain (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541a8f610sm17524365e9.7.2026.03.09.11.35.37 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Mar 2026 11:35:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c4ee7ce2-1be6-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081338; x=1773686138; 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; bh=n+n1XzLbQai9WbGm/ckfBsm2uzsateK7yt/Qy3zcLsM=; b=ltdYM5GRBPvcUWccVtgEdcxuwdM0MP21lQ2akTanFceyHcLeciBFPNM3K1wurjmAk2 vSiijYb/Uo/W6IUhltZP+oScbMeblkZpBx4VJOu1miYrZToCoyMA+x2JtrpKp6NxWVlR +3N5mtbufR+DYv12Sd0ayHjPS3O/+obuDuXpHEjXalajJStnYkQXpD46ZDwnONJhcryP X3hvs+67hw8PYaGO2ZANOGfp8eQRa937iu5+SjtzLkx4HQ9HonnTQBxscel9JCGz2yav Ea/ng0y/ZSxri/AabUtkcNSD1dilzWHin/ypOgGpaIeOThjecss2Je8S6E08KgqzbEcW u/eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081338; x=1773686138; 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; bh=n+n1XzLbQai9WbGm/ckfBsm2uzsateK7yt/Qy3zcLsM=; b=pOzVbjKufq+q1s1HzLj5mc4COA4AXXuT/RrgbC9Ajng6SOyzdKUgAkI4vZZ3J9yxUL Mbmv9M5L+f0GWwiBPoV8JiYgrrCpNkhOrKGNikH0cT/ipUuK89T1+OfVPcgsv0bvqKDD 5x+7HoE/fQFyQ363cfi0dfzthakFKiSq0oT6h+Xhccknobnh/RP421SWPK3Tvtx6KM4j UOs8y1uZnYFifrbEKVCPffB0EE3EnDOK+6uHiHfVcV4kGB7NwNI+bmf8E8XBKblfUjGz vkcu4YYrOYEAQ+fwH4GldmpoRpVpn/wDnlacI4hf/WyQ9nMt03aofs20hdtLAjHhXRg+ Qm8g== X-Forwarded-Encrypted: i=1; AJvYcCUWncaBfa1sOs8orkWo5Cl/e217jEDJCdUwed2D7qAekeaNCJgN22xnpMh6e0PZ5gW26g/r4pi6de8=@lists.xenproject.org X-Gm-Message-State: AOJu0YyneprXKjErEdEOv1y5EaCHShremDm/e5rxBdZ477dAMlOavWPz jUGM2S0XwncDgasZLgWFg3S8IQvwkmXKH8DEGKLfx9NWLq0+fck99tTMqzmmiEHIehw= X-Gm-Gg: ATEYQzyyst6rYvWwaz38Jotd5hkDYnA5itETyynBi7OZ5Fa2WXQc6/p44oR68wOfj8S hbX4gptpQjVzp/kiKgGF8heTOApHsReOZHn9TcGPD/Bw3yGULS3dBJkVuaMfyMqolx3+927RKyy GbbdHttJ/ba/ZTlXff7vOCoEmBvG0j8nCjbuGjwOWY8anx4in+eOZdNi7Jo2EnhBg9lRJClG7J4 XtfVLCxyxtejJlh2dDfEwaHgzXlFTXG31JDushAHVzOgXyfJeM6tu+czWrswvYYR35TFeg/Oozp xLpeleBGCbq8ENm7hVYxutwLTvKfGejoLTahpBG1mGeSOWsOdXMRQxxyWQCnu3Es6QgdoYTxp6L m8PPA7lWo5FBcmIxnwQ19LKs1uO9x/tcrxKWgCwKGSR01CfQV02MzmYBfSpm5BU6CpZETEXZDBV 18N+btARvt5YTh5C1JgeH9PbNgZOfUwJHsM8ETfM6pJ9UPgEU25FGknuVUdWpRyKC5xCFuBQ/+ X-Received: by 2002:a05:600c:a115:b0:485:3b5b:eb8 with SMTP id 5b1f17b1804b1-4853b5b108emr60211815e9.26.1773081338186; Mon, 09 Mar 2026 11:35:38 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefano Stabellini , Akihiko Odaki Subject: [PATCH v2 0/4] system/memory: Constify various RAMBlock/MemoryRegion arguments Date: Mon, 9 Mar 2026 19:35:31 +0100 Message-ID: <20260309183536.88976-1-philmd@linaro.org> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit v2: - Dropped "stubs: Merge physmem.c within ram-block.c" (Zoltan) - Dropped "info mtree" patches (no time to update doc for freeze) - New Xen patch Philippe Mathieu-Daudé (4): system/ramblock: Constify various RAMBlock arguments system/memory: Constify various MemoryRegion arguments system/xen: Constify various MemoryRegion arguments system/memory: Have memory_region_type() correctly describe containers include/system/memory.h | 38 ++++++++++++++++----------------- include/system/ramblock.h | 28 ++++++++++++------------ include/system/xen-mapcache.h | 2 +- include/system/xen.h | 6 +++--- hw/xen/xen-hvm-common.c | 8 +++---- hw/xen/xen-mapcache.c | 2 +- hw/xen/xen_stubs.c | 6 +++--- stubs/physmem.c | 2 +- stubs/ram-block.c | 6 +++--- system/memory.c | 40 +++++++++++++++++++---------------- system/physmem.c | 30 +++++++++++++------------- 11 files changed, 86 insertions(+), 82 deletions(-) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:35:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:35:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249619.1547081 (Exim 4.92) (envelope-from ) id 1vzfSH-0007Yj-80; Mon, 09 Mar 2026 18:35:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249619.1547081; Mon, 09 Mar 2026 18:35:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSH-0007Ya-46; Mon, 09 Mar 2026 18:35:49 +0000 Received: by outflank-mailman (input) for mailman id 1249619; Mon, 09 Mar 2026 18:35:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSF-0007JG-Hn for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:35:47 +0000 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [2a00:1450:4864:20::329]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c9a96f7e-1be6-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 19:35:46 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4853e1ce427so12503795e9.3 for ; Mon, 09 Mar 2026 11:35:46 -0700 (PDT) Received: from localhost.localdomain (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541a6bb86sm9367755e9.1.2026.03.09.11.35.44 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Mar 2026 11:35:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c9a96f7e-1be6-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081346; x=1773686146; 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; bh=xA3KiBRZDEy+tGK0VBSBg6K/vS9OJsxKrmQTjGkh/tM=; b=vHxbDQhCv7R2l0m7nn8ppI10Jd/khXsW9VNS7owUnYjELJP8p9FXXUZFAJO8qzhfi8 Ss5YV05uGA/L7PlV4CUAB2psoUGlK9x2IhRzPuxagzIVfrC67UQgsUDlC+8iew/GnQNE bw05RPSVofq6tmTCegQw+vUq1Fg+GvrGYadn5Xam/SPwklpS+ymL5iVmxC7U8bJjQkys TylXDZijOTjF7bcu7+J/fMnS/ftHFsO4sVtjMgvSJx6AvyupRW+ssDM++jXK+rBJYnfg P3myScAacVjpluoKtrkzghoiDrfHUp91ZQzwvpwH6BcFhF414pso0Wu9Wq4KT0roPcxA WULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081346; x=1773686146; 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; bh=xA3KiBRZDEy+tGK0VBSBg6K/vS9OJsxKrmQTjGkh/tM=; b=fc5+B01u0CIn1N7KIQmwd3puovGFjfOBUuG5YJYTkfnAD6X8PufBq8Msud8MoFSwm7 qLpkfWVRYrVrqEqSvJEjhRmhv5S/9kjQOOxN6hhXzrekVInFxwd2zAVKTnPOUuHrMIO0 TsGqkqmfDDppk7QimdUF2YGckvwi51Z83vPkGJS3j2frPf98O9p693cDnaA4kwHeFNpe jyARv3jmujUziYOb8LBk3bfNm+SnK8ZEt+BtDzyQVeAikM29IPH4AFdcKfGSQnCjUJ2S PMtYhYI4p+JXaF5fQOCdeJziAApCzTZTECiOmoJiW3mvnLZGu727n717wjicXs7c7xWL V+4Q== X-Forwarded-Encrypted: i=1; AJvYcCVJSHVdT5pGyK1v4+rWLQ2n3o39JqCGP+XQtU/SoC8xVscYxGxO14rZU0KoEaLvCY6w8npw3AwwAbs=@lists.xenproject.org X-Gm-Message-State: AOJu0YyH3eJiNbf7xywiJhRY80DwjRlEHNs/feEPrU/9ZTo6R5eqE1Iw DzyMkF94SpE5WTjZO9q3ClBDX05a5QDycXVrnGNnrcTq0NJVICjcZtkYVnLtUO8/lKPRxpzSURs MaUV6wOI= X-Gm-Gg: ATEYQzw7oDthjzhXcXUX5xR263W9mMENckvqHJg69G/a1IfYs/JsesJiZbujWVYb597 O78NbSSAa7NNsJdHji9zNtUa5NEo5fEPvTijGN5vosPG3H/Gl3F4z/Bz3TayXfTkmqpjY4hr8yU eOKAOAGksfnn4COHSQkVPlCfcvyN6BKU6wUn6JmJjFiPn/YAdjeK9JXgDY//LWJh5PSB8NQTFuc mRaLN4dGOor9DC2syZ6+5pDhGFMasMke3Q8o82iIwY+QV9yAY/EUscaSlfA6wV6rzuaJeAX2OfI aw6QBqIMBqBHYm/LN8ngs3GDVDl971r8u0wr+Zh147ZyvHvKwWoIzvNdtEuVmaOUNLK1ha+SunB kYV61aHopIH69RbtBwpPv3lQ4OWfwuZCMAqX+XeWDkNFSutcv2vibdiUYhETD1bJSdvKPKGMXLj tULYJO5CVwr/KLC+sAEwvMTAFrBcdMezivCkEurt4iZdeC+6wllBgVYVdGXVCnNmbEwmcum0j/ X-Received: by 2002:a05:600c:3b8e:b0:485:35a4:939c with SMTP id 5b1f17b1804b1-48535a4a188mr113829175e9.29.1773081346102; Mon, 09 Mar 2026 11:35:46 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefano Stabellini , Akihiko Odaki Subject: [PATCH v2 1/4] system/ramblock: Constify various RAMBlock arguments Date: Mon, 9 Mar 2026 19:35:32 +0100 Message-ID: <20260309183536.88976-2-philmd@linaro.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309183536.88976-1-philmd@linaro.org> References: <20260309183536.88976-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark the RAMBlock structure const when is only accessed read-only. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Pierrick Bouvier Reviewed-by: Peter Xu --- include/system/ramblock.h | 28 ++++++++++++++-------------- stubs/physmem.c | 2 +- stubs/ram-block.c | 6 +++--- system/physmem.c | 28 ++++++++++++++-------------- 4 files changed, 32 insertions(+), 32 deletions(-) diff --git a/include/system/ramblock.h b/include/system/ramblock.h index e9f58ac0457..4435f8d55fe 100644 --- a/include/system/ramblock.h +++ b/include/system/ramblock.h @@ -154,26 +154,26 @@ RAMBlock *qemu_ram_block_by_name(const char *name); */ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, ram_addr_t *offset); -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host); +ram_addr_t qemu_ram_block_host_offset(const RAMBlock *rb, void *host); void qemu_ram_set_idstr(RAMBlock *block, const char *name, DeviceState *dev); void qemu_ram_unset_idstr(RAMBlock *block); -const char *qemu_ram_get_idstr(RAMBlock *rb); -void *qemu_ram_get_host_addr(RAMBlock *rb); -ram_addr_t qemu_ram_get_offset(RAMBlock *rb); -ram_addr_t qemu_ram_get_fd_offset(RAMBlock *rb); -ram_addr_t qemu_ram_get_used_length(RAMBlock *rb); -ram_addr_t qemu_ram_get_max_length(RAMBlock *rb); -bool qemu_ram_is_shared(RAMBlock *rb); -bool qemu_ram_is_noreserve(RAMBlock *rb); -bool qemu_ram_is_uf_zeroable(RAMBlock *rb); +const char *qemu_ram_get_idstr(const RAMBlock *rb); +void *qemu_ram_get_host_addr(const RAMBlock *rb); +ram_addr_t qemu_ram_get_offset(const RAMBlock *rb); +ram_addr_t qemu_ram_get_fd_offset(const RAMBlock *rb); +ram_addr_t qemu_ram_get_used_length(const RAMBlock *rb); +ram_addr_t qemu_ram_get_max_length(const RAMBlock *rb); +bool qemu_ram_is_shared(const RAMBlock *rb); +bool qemu_ram_is_noreserve(const RAMBlock *rb); +bool qemu_ram_is_uf_zeroable(const RAMBlock *rb); void qemu_ram_set_uf_zeroable(RAMBlock *rb); -bool qemu_ram_is_migratable(RAMBlock *rb); +bool qemu_ram_is_migratable(const RAMBlock *rb); void qemu_ram_set_migratable(RAMBlock *rb); void qemu_ram_unset_migratable(RAMBlock *rb); -bool qemu_ram_is_named_file(RAMBlock *rb); -int qemu_ram_get_fd(RAMBlock *rb); +bool qemu_ram_is_named_file(const RAMBlock *rb); +int qemu_ram_get_fd(const RAMBlock *rb); -size_t qemu_ram_pagesize(RAMBlock *block); +size_t qemu_ram_pagesize(const RAMBlock *block); size_t qemu_ram_pagesize_largest(void); #include "exec/target_page.h" #include "exec/hwaddr.h" diff --git a/stubs/physmem.c b/stubs/physmem.c index 14667f2bd8f..2eca06ab6d6 100644 --- a/stubs/physmem.c +++ b/stubs/physmem.c @@ -7,7 +7,7 @@ RAMBlock *qemu_ram_block_from_host(void *ptr, bool round_offset, return NULL; } -int qemu_ram_get_fd(RAMBlock *rb) +int qemu_ram_get_fd(const RAMBlock *rb) { return -1; } diff --git a/stubs/ram-block.c b/stubs/ram-block.c index 8790a59593e..1c79e447ff0 100644 --- a/stubs/ram-block.c +++ b/stubs/ram-block.c @@ -3,17 +3,17 @@ #include "system/ramblock.h" #include "system/memory.h" -void *qemu_ram_get_host_addr(RAMBlock *rb) +void *qemu_ram_get_host_addr(const RAMBlock *rb) { return 0; } -ram_addr_t qemu_ram_get_offset(RAMBlock *rb) +ram_addr_t qemu_ram_get_offset(const RAMBlock *rb) { return 0; } -ram_addr_t qemu_ram_get_used_length(RAMBlock *rb) +ram_addr_t qemu_ram_get_used_length(const RAMBlock *rb) { return 0; } diff --git a/system/physmem.c b/system/physmem.c index 7eecd818770..e5390d09bef 100644 --- a/system/physmem.c +++ b/system/physmem.c @@ -1859,48 +1859,48 @@ static void qemu_ram_setup_dump(void *addr, ram_addr_t size) } } -const char *qemu_ram_get_idstr(RAMBlock *rb) +const char *qemu_ram_get_idstr(const RAMBlock *rb) { return rb->idstr; } -void *qemu_ram_get_host_addr(RAMBlock *rb) +void *qemu_ram_get_host_addr(const RAMBlock *rb) { return rb->host; } -ram_addr_t qemu_ram_get_offset(RAMBlock *rb) +ram_addr_t qemu_ram_get_offset(const RAMBlock *rb) { return rb->offset; } -ram_addr_t qemu_ram_get_fd_offset(RAMBlock *rb) +ram_addr_t qemu_ram_get_fd_offset(const RAMBlock *rb) { return rb->fd_offset; } -ram_addr_t qemu_ram_get_used_length(RAMBlock *rb) +ram_addr_t qemu_ram_get_used_length(const RAMBlock *rb) { return rb->used_length; } -ram_addr_t qemu_ram_get_max_length(RAMBlock *rb) +ram_addr_t qemu_ram_get_max_length(const RAMBlock *rb) { return rb->max_length; } -bool qemu_ram_is_shared(RAMBlock *rb) +bool qemu_ram_is_shared(const RAMBlock *rb) { return rb->flags & RAM_SHARED; } -bool qemu_ram_is_noreserve(RAMBlock *rb) +bool qemu_ram_is_noreserve(const RAMBlock *rb) { return rb->flags & RAM_NORESERVE; } /* Note: Only set at the start of postcopy */ -bool qemu_ram_is_uf_zeroable(RAMBlock *rb) +bool qemu_ram_is_uf_zeroable(const RAMBlock *rb) { return rb->flags & RAM_UF_ZEROPAGE; } @@ -1910,7 +1910,7 @@ void qemu_ram_set_uf_zeroable(RAMBlock *rb) rb->flags |= RAM_UF_ZEROPAGE; } -bool qemu_ram_is_migratable(RAMBlock *rb) +bool qemu_ram_is_migratable(const RAMBlock *rb) { return rb->flags & RAM_MIGRATABLE; } @@ -1925,12 +1925,12 @@ void qemu_ram_unset_migratable(RAMBlock *rb) rb->flags &= ~RAM_MIGRATABLE; } -bool qemu_ram_is_named_file(RAMBlock *rb) +bool qemu_ram_is_named_file(const RAMBlock *rb) { return rb->flags & RAM_NAMED_FILE; } -int qemu_ram_get_fd(RAMBlock *rb) +int qemu_ram_get_fd(const RAMBlock *rb) { return rb->fd; } @@ -1987,7 +1987,7 @@ static char *cpr_name(MemoryRegion *mr) } } -size_t qemu_ram_pagesize(RAMBlock *rb) +size_t qemu_ram_pagesize(const RAMBlock *rb) { return rb->page_size; } @@ -2772,7 +2772,7 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t addr) } /* Return the offset of a hostpointer within a ramblock */ -ram_addr_t qemu_ram_block_host_offset(RAMBlock *rb, void *host) +ram_addr_t qemu_ram_block_host_offset(const RAMBlock *rb, void *host) { ram_addr_t res = (uint8_t *)host - (uint8_t *)rb->host; assert((uintptr_t)host >= (uintptr_t)rb->host); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:35:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:35:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249622.1547090 (Exim 4.92) (envelope-from ) id 1vzfSR-0007rv-DL; Mon, 09 Mar 2026 18:35:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249622.1547090; Mon, 09 Mar 2026 18: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 ) id 1vzfSR-0007ro-AY; Mon, 09 Mar 2026 18:35:59 +0000 Received: by outflank-mailman (input) for mailman id 1249622; Mon, 09 Mar 2026 18:35:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSP-0007ml-KH for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:35:57 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ce1be43b-1be6-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 19:35:54 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-439a89b6fd0so8685701f8f.2 for ; Mon, 09 Mar 2026 11:35:54 -0700 (PDT) Received: from localhost.localdomain (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae3a20fsm28028805f8f.28.2026.03.09.11.35.52 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Mar 2026 11:35:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ce1be43b-1be6-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081353; x=1773686153; 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; bh=UNqLEUifsz1cpFVFbx5viMkbYuuKYfbDoeHlGj5zHNY=; b=bV+nNqVTnq6M8SC1jLgNDzkojYaMysQ4LhdKodcI3jGmCi+c1v+xGzpHsTNxzSX6sJ X9E+WDgLrY5biFmthQJsJ+mDr66MuEgaM5XSiri/PEfE3lznNfTds2eB0Z9JW2CoWjUl l9b0vFCT8Lzg0EmhCBM/y+mrTgiOEXN4gR3w7ZgRk0aUAYitvkGlkr+d9rJwGW9BDvgx wau7rlAMb5drBh/OmUkLgzEfdoMt44Hxc4M2huGWyAt/aARewi65adJ7gq/ymx8H7v4J Yrboh6izOg1MhJe3oM5VNDrwSFItgJmWzBffEEPkYgI8NtbXxK4eFCrmGnXpQTP7gjnG X+5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081353; x=1773686153; 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; bh=UNqLEUifsz1cpFVFbx5viMkbYuuKYfbDoeHlGj5zHNY=; b=h/urbMSXlmG9Z9dreHHPm/yWGEZP0o5bK/Ba2jAInOzFHDqRgLTkeV0zhZ8zJvVgXz qnQyl3AdudrhiTxRnbgVbWJDgL9obn7fbH5m1tTWFZESMj9J4z/5xfGlfss5PQAmWJ+a pGxjHhh7PTLhWNgoVWDcGGVhQZVbctv+M6WdIgmoTmeFiac1v4AWTXIT9B/vFIwZZXg6 uQICshlFWbQ4se6/kHw1+8gvyXpBptCNs8uNmiI7yWZA531rPOL1BlblEOhx9okbazC/ mlZV7LZvNdb+sMg9ThEL8BLKbS01rEqWufxpd3udsCaC5N7Spt4yQIld84qzN7Fc7B3z QN1Q== X-Forwarded-Encrypted: i=1; AJvYcCXvrz+u8zXQ3XUW1yJUuWI6D4dz+0g1WpGlg/ckVRvneEz9pRX/jThOiPHO6B2EsDA2lRYJUCUq8/M=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy2kn0/z/pH0OPSzL5EFFztLsg8amCFUZ+Rxgs1m8fENpK1z4k6 /rpgrxQRk3sZttyl14o1hw3NUJW1DbG3tJb7wwS1Gr0R8cta9IDUojZcFG/v/dWR85M= X-Gm-Gg: ATEYQzxa+TtGequ+onEjjhywkVnTEpC2wJxwoUBjNr8DdUiZXc2zmvI2djaklTRx699 k/l2MtNriQ9/a9NPsjthGNXkoEHHbpWfmU238APbKpLopUa/B77QDsiBSRZEiUlsxfQ4NXtelHB /aBMHwaBxVD2HAvjhR0Z5MwMDmxRMuREK+AGAQYh/FjNQ2s21rApcgobpp/wdObrjMMmkOrKkue 9wreQPw3No6BXh14StgfRap5gGduMh8vZ79W3keIKdcZrY3ID3DoEzRjFsBzc5jJadZVKl5wC51 +794N1+J/Dah4wgIJfWT/qSnUv78qIeOCUYr4k2vHW3lyZa4kTf1b83nC+7TRHgy6YoXFJ2AeHu 0wypLVvBSflKBkyet70joI5MxAaidOuOL5XXJgG6K8xsz6cmvqK0003Dzi//4R3UHU96N1i5Lhb s8iIaXBs0dB7mrfLAEi83zIHVVuh/HMG8+l3G8xjx8DIG5c/YGxdz5trZcdtT/acfubLXXnj2X X-Received: by 2002:a05:6000:704:b0:439:df5f:4220 with SMTP id ffacd0b85a97d-439df5f42f8mr17289075f8f.18.1773081353315; Mon, 09 Mar 2026 11:35:53 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefano Stabellini , Akihiko Odaki Subject: [PATCH v2 2/4] system/memory: Constify various MemoryRegion arguments Date: Mon, 9 Mar 2026 19:35:33 +0100 Message-ID: <20260309183536.88976-3-philmd@linaro.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309183536.88976-1-philmd@linaro.org> References: <20260309183536.88976-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark the MemoryRegion structure const when is only accessed read-only. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Pierrick Bouvier Reviewed-by: Peter Xu --- include/system/memory.h | 38 +++++++++++++++++++------------------- system/memory.c | 38 ++++++++++++++++++++------------------ system/physmem.c | 2 +- 3 files changed, 40 insertions(+), 38 deletions(-) diff --git a/include/system/memory.h b/include/system/memory.h index 0562af31361..6a04c46db37 100644 --- a/include/system/memory.h +++ b/include/system/memory.h @@ -1749,14 +1749,14 @@ bool memory_region_init_rom_device(MemoryRegion *mr, * * @mr: the memory region being queried. */ -Object *memory_region_owner(MemoryRegion *mr); +Object *memory_region_owner(const MemoryRegion *mr); /** * memory_region_size: get a memory region's size. * * @mr: the memory region being queried. */ -uint64_t memory_region_size(MemoryRegion *mr); +uint64_t memory_region_size(const MemoryRegion *mr); /** * memory_region_is_ram: check whether a memory region is random access @@ -1765,7 +1765,7 @@ uint64_t memory_region_size(MemoryRegion *mr); * * @mr: the memory region being queried */ -static inline bool memory_region_is_ram(MemoryRegion *mr) +static inline bool memory_region_is_ram(const MemoryRegion *mr) { return mr->ram; } @@ -1777,7 +1777,7 @@ static inline bool memory_region_is_ram(MemoryRegion *mr) * * @mr: the memory region being queried */ -bool memory_region_is_ram_device(MemoryRegion *mr); +bool memory_region_is_ram_device(const MemoryRegion *mr); /** * memory_region_is_romd: check whether a memory region is in ROMD mode @@ -1787,7 +1787,7 @@ bool memory_region_is_ram_device(MemoryRegion *mr); * * @mr: the memory region being queried */ -static inline bool memory_region_is_romd(MemoryRegion *mr) +static inline bool memory_region_is_romd(const MemoryRegion *mr) { return mr->rom_device && mr->romd_mode; } @@ -1800,7 +1800,7 @@ static inline bool memory_region_is_romd(MemoryRegion *mr) * * @mr: the memory region being queried */ -bool memory_region_is_protected(MemoryRegion *mr); +bool memory_region_is_protected(const MemoryRegion *mr); /** * memory_region_has_guest_memfd: check whether a memory region has guest_memfd @@ -1810,7 +1810,7 @@ bool memory_region_is_protected(MemoryRegion *mr); * * @mr: the memory region being queried */ -bool memory_region_has_guest_memfd(MemoryRegion *mr); +bool memory_region_has_guest_memfd(const MemoryRegion *mr); /** * memory_region_get_iommu: check whether a memory region is an iommu @@ -1820,7 +1820,7 @@ bool memory_region_has_guest_memfd(MemoryRegion *mr); * * @mr: the memory region being queried */ -static inline IOMMUMemoryRegion *memory_region_get_iommu(MemoryRegion *mr) +static inline IOMMUMemoryRegion *memory_region_get_iommu(const MemoryRegion *mr) { if (mr->alias) { return memory_region_get_iommu(mr->alias); @@ -1991,7 +1991,7 @@ const char *memory_region_name(const MemoryRegion *mr); * @mr: the memory region being queried * @client: the client being queried */ -bool memory_region_is_logging(MemoryRegion *mr, uint8_t client); +bool memory_region_is_logging(const MemoryRegion *mr, uint8_t client); /** * memory_region_get_dirty_log_mask: return the clients for which a @@ -2002,7 +2002,7 @@ bool memory_region_is_logging(MemoryRegion *mr, uint8_t client); * * @mr: the memory region being queried */ -uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr); +uint8_t memory_region_get_dirty_log_mask(const MemoryRegion *mr); /** * memory_region_is_rom: check whether a memory region is ROM @@ -2011,7 +2011,7 @@ uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr); * * @mr: the memory region being queried */ -static inline bool memory_region_is_rom(MemoryRegion *mr) +static inline bool memory_region_is_rom(const MemoryRegion *mr) { return mr->ram && mr->readonly; } @@ -2023,7 +2023,7 @@ static inline bool memory_region_is_rom(MemoryRegion *mr) * * @mr: the memory region being queried */ -static inline bool memory_region_is_nonvolatile(MemoryRegion *mr) +static inline bool memory_region_is_nonvolatile(const MemoryRegion *mr) { return mr->nonvolatile; } @@ -2036,7 +2036,7 @@ static inline bool memory_region_is_nonvolatile(MemoryRegion *mr) * * @mr: the RAM or alias memory region being queried. */ -int memory_region_get_fd(MemoryRegion *mr); +int memory_region_get_fd(const MemoryRegion *mr); /** * memory_region_from_host: Convert a pointer into a RAM memory region @@ -2071,7 +2071,7 @@ MemoryRegion *memory_region_from_host(void *ptr, ram_addr_t *offset); * * @mr: the memory region being queried. */ -void *memory_region_get_ram_ptr(MemoryRegion *mr); +void *memory_region_get_ram_ptr(const MemoryRegion *mr); /* memory_region_ram_resize: Resize a RAM region. * @@ -2421,7 +2421,7 @@ void memory_region_add_subregion_overlap(MemoryRegion *mr, * * @mr: the region to be queried */ -ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr); +ram_addr_t memory_region_get_ram_addr(const MemoryRegion *mr); uint64_t memory_region_get_alignment(const MemoryRegion *mr); /** @@ -2521,7 +2521,7 @@ bool memory_region_present(MemoryRegion *container, hwaddr addr); * * @mr: a #MemoryRegion which should be checked if it's mapped */ -bool memory_region_is_mapped(MemoryRegion *mr); +bool memory_region_is_mapped(const MemoryRegion *mr); /** * memory_region_get_ram_discard_manager: get the #RamDiscardManager for a @@ -2967,7 +2967,7 @@ void *qemu_map_ram_ptr(RAMBlock *ram_block, ram_addr_t addr); int memory_access_size(MemoryRegion *mr, unsigned l, hwaddr addr); bool prepare_mmio_access(MemoryRegion *mr); -static inline bool memory_region_supports_direct_access(MemoryRegion *mr) +static inline bool memory_region_supports_direct_access(const MemoryRegion *mr) { /* ROM DEVICE regions only allow direct access if in ROMD mode. */ if (memory_region_is_romd(mr)) { @@ -2984,8 +2984,8 @@ static inline bool memory_region_supports_direct_access(MemoryRegion *mr) return !memory_region_is_ram_device(mr); } -static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write, - MemTxAttrs attrs) +static inline bool memory_access_is_direct(const MemoryRegion *mr, + bool is_write, MemTxAttrs attrs) { if (!memory_region_supports_direct_access(mr)) { return false; diff --git a/system/memory.c b/system/memory.c index c51d0798a84..b130d956d4e 100644 --- a/system/memory.c +++ b/system/memory.c @@ -1819,9 +1819,9 @@ static void memory_region_finalize(Object *obj) g_free(mr->ioeventfds); } -Object *memory_region_owner(MemoryRegion *mr) +Object *memory_region_owner(const MemoryRegion *mr) { - Object *obj = OBJECT(mr); + const Object *obj = OBJECT(mr); return obj->parent; } @@ -1849,7 +1849,7 @@ void memory_region_unref(MemoryRegion *mr) } } -uint64_t memory_region_size(MemoryRegion *mr) +uint64_t memory_region_size(const MemoryRegion *mr) { if (int128_eq(mr->size, int128_2_64())) { return UINT64_MAX; @@ -1866,25 +1866,25 @@ const char *memory_region_name(const MemoryRegion *mr) return mr->name; } -bool memory_region_is_ram_device(MemoryRegion *mr) +bool memory_region_is_ram_device(const MemoryRegion *mr) { return mr->ram_device; } -bool memory_region_is_protected(MemoryRegion *mr) +bool memory_region_is_protected(const MemoryRegion *mr) { return mr->ram && (mr->ram_block->flags & RAM_PROTECTED); } -bool memory_region_has_guest_memfd(MemoryRegion *mr) +bool memory_region_has_guest_memfd(const MemoryRegion *mr) { return mr->ram_block && mr->ram_block->guest_memfd >= 0; } -uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr) +uint8_t memory_region_get_dirty_log_mask(const MemoryRegion *mr) { uint8_t mask = mr->dirty_log_mask; - RAMBlock *rb = mr->ram_block; + const RAMBlock *rb = mr->ram_block; if (global_dirty_tracking && ((rb && qemu_ram_is_migratable(rb)) || memory_region_is_iommu(mr))) { @@ -1898,7 +1898,7 @@ uint8_t memory_region_get_dirty_log_mask(MemoryRegion *mr) return mask; } -bool memory_region_is_logging(MemoryRegion *mr, uint8_t client) +bool memory_region_is_logging(const MemoryRegion *mr, uint8_t client) { return memory_region_get_dirty_log_mask(mr) & (1 << client); } @@ -2406,7 +2406,7 @@ void memory_region_reset_dirty(MemoryRegion *mr, hwaddr addr, memory_region_get_ram_addr(mr) + addr, size, client, NULL); } -int memory_region_get_fd(MemoryRegion *mr) +int memory_region_get_fd(const MemoryRegion *mr) { RCU_READ_LOCK_GUARD(); while (mr->alias) { @@ -2415,7 +2415,7 @@ int memory_region_get_fd(MemoryRegion *mr) return mr->ram_block->fd; } -void *memory_region_get_ram_ptr(MemoryRegion *mr) +void *memory_region_get_ram_ptr(const MemoryRegion *mr) { uint64_t offset = 0; @@ -2440,7 +2440,7 @@ MemoryRegion *memory_region_from_host(void *ptr, ram_addr_t *offset) return block->mr; } -ram_addr_t memory_region_get_ram_addr(MemoryRegion *mr) +ram_addr_t memory_region_get_ram_addr(const MemoryRegion *mr) { return mr->ram_block ? mr->ram_block->offset : RAM_ADDR_INVALID; } @@ -2806,7 +2806,7 @@ static FlatRange *flatview_lookup(FlatView *view, AddrRange addr) sizeof(FlatRange), cmp_flatrange_addr); } -bool memory_region_is_mapped(MemoryRegion *mr) +bool memory_region_is_mapped(const MemoryRegion *mr) { return !!mr->container || mr->mapped_via_alias; } @@ -3290,7 +3290,7 @@ void address_space_destroy_free(AddressSpace *as) call_rcu(as, do_address_space_destroy_free, rcu); } -static const char *memory_region_type(MemoryRegion *mr) +static const char *memory_region_type(const MemoryRegion *mr) { if (mr->alias) { return memory_region_type(mr->alias); @@ -3483,7 +3483,6 @@ static void mtree_print_flatview(gpointer key, gpointer value, GArray *fv_address_spaces = value; struct FlatViewInfo *fvi = user_data; FlatRange *range = &view->ranges[0]; - MemoryRegion *mr; int n = view->nr; int i; AddressSpace *as; @@ -3510,7 +3509,8 @@ static void mtree_print_flatview(gpointer key, gpointer value, } while (n--) { - mr = range->mr; + const MemoryRegion *mr = range->mr; + if (range->offset_in_region) { qemu_printf(MTREE_INDENT HWADDR_FMT_plx "-" HWADDR_FMT_plx " (prio %d, %s%s): %s @" HWADDR_FMT_plx, @@ -3683,8 +3683,10 @@ static void mtree_info_as(bool dispatch_tree, bool owner, bool disabled) /* print aliased regions */ QTAILQ_FOREACH(ml, &ml_head, mrqueue) { - qemu_printf("memory-region: %s\n", memory_region_name(ml->mr)); - mtree_print_mr(ml->mr, 1, 0, &ml_head, owner, disabled); + const MemoryRegion *mr = ml->mr; + + qemu_printf("memory-region: %s\n", memory_region_name(mr)); + mtree_print_mr(mr, 1, 0, &ml_head, owner, disabled); qemu_printf("\n"); } diff --git a/system/physmem.c b/system/physmem.c index e5390d09bef..4a9e0760045 100644 --- a/system/physmem.c +++ b/system/physmem.c @@ -1975,7 +1975,7 @@ void qemu_ram_unset_idstr(RAMBlock *block) } } -static char *cpr_name(MemoryRegion *mr) +static char *cpr_name(const MemoryRegion *mr) { const char *mr_name = memory_region_name(mr); g_autofree char *id = mr->dev ? qdev_get_dev_path(mr->dev) : NULL; -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:36:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:36:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249626.1547098 (Exim 4.92) (envelope-from ) id 1vzfSU-0008BU-Jz; Mon, 09 Mar 2026 18:36:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249626.1547098; Mon, 09 Mar 2026 18:36:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSU-0008BK-H2; Mon, 09 Mar 2026 18:36:02 +0000 Received: by outflank-mailman (input) for mailman id 1249626; Mon, 09 Mar 2026 18:36:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfST-0007JG-SA for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:36:01 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d23a8f3a-1be6-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 19:36:01 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4852afd42ceso28017405e9.2 for ; Mon, 09 Mar 2026 11:36:01 -0700 (PDT) Received: from localhost.localdomain (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dad977f8sm28487057f8f.9.2026.03.09.11.35.59 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Mar 2026 11:35:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d23a8f3a-1be6-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081360; x=1773686160; 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; bh=frENE9FJEJIJp1aKXCLyQE1na5fHvR5E0RLXQsidK/I=; b=os2dCYM2iWuRmBmvtuR6wM13CdxyRW3KIePfht+f1sk+yiLI56doQBPzj4ypfiDw64 WPcYrFF6zb8b8aGH3dvw17K0Acu/JV0oBdhiWpDkslu9FS7NmyD40wdhme3M1Y3qgq3j 2g08aNgFkuW5W/47CiDKxSwaHy9gCSQSmH6W3xbJpPaovvFLzlX4MxsuZf6d9cgefu3f QcL9pzdOVxHTZdN3wvdUBBHbNZ14kolnEzDsPSkjwWdGkBN2/oTmZJdv7YOkxtZHIFL8 fVYQ3tEcYxhRrwxlg+UsD7N4frQ1KtFPv9pj3IciXXkz/yseuNulVNnpXBQPwko1PAQF Rf2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081360; x=1773686160; 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; bh=frENE9FJEJIJp1aKXCLyQE1na5fHvR5E0RLXQsidK/I=; b=hDgi6V2WqLex5z+mCq2HIC4UqaoMEbBTSQGPgFqirdQ2iL06r+yDpsmhwVJlPXSsxD nldTNBxYQKzNZWjtryd99PjYA7rd/JBnD85rkfDHoomnGygHjw88mm4NSv0NNp8ACM4T J+axL2A1IodAj2roe8CnoCUYNWUyuq/O22COsPxInvDaF8qo3/7iFfl3p25/iiyYHY+8 tb4CaiAr/1A1N7z6JLR8r6wQM4doYSYKd41EoorzVKT8lv1oMXF5UoTerWJkI+oh2nWa AQ9vcc+9Zs/W5bREA7/xDDE38IgQ/dM24lkR8n/yt9IG+sQAg+C6hhNu+GJVtK8Llxet zBHQ== X-Forwarded-Encrypted: i=1; AJvYcCWPZ1CdnEN7/jcPMY71qqDgwjQfEpRLJ2t3AZgIuHOzQboRLT292qHLbKn3//3ezjLnOJFxomkxcsk=@lists.xenproject.org X-Gm-Message-State: AOJu0YxIqN84mLl532odponTioOswoDGM9dpz1D/gdFBcUC6wa9Mlxpr +w9iBFf73L4RHjSfDqIBIuxwty3NZ9CzkBTlRMtAy34WyMKA0IuqhxY1UeWC4qgBJZ8= X-Gm-Gg: ATEYQzxrVAS7jPaNI7KyP8iKbxfbxXY8ckqudVHh4HU/grU28WaXHeuJGpDDMImrNGy Pez1PHz4TRGrg4ZF0EIwGDXqrWlybew1ykjKOabgvWg16NjyhoSQmq0M6tp98RU26PPosMLbp5s Zl8uvJRRTilXuHMilQOgCUzyZTQEBpu3dYX9zcHvuJ01HP092MxvYcs6QwCvTNnaUwCG54uLLja DFO99wAuc1s9xYAjkUwE5OkwcghagyRk/LFfF1mqksvIZUTiFk0iRNMgG65sghDByx/+iaX6tfY vUIQ5xGiY8Q/zOmpHWz1kq6aEtE79HZeZtivyd9VHLpzWeoYYUS/UBW3GJOLMpzW1QvagvAgoU2 GrCcMbWpdP35G4EhqySPIsGiDeM4jk+LWzAbYCzXYC1+7kdrUQHR0H2T7PQQPX6lg0j4znAPn0W fRE046Zk0Q6qhsgumo8TnBk87PenROxv/rHdLMwP4z/oIBr2lLjY5oyHouLVloSROI9OU/eMbE X-Received: by 2002:a05:6000:2681:b0:439:be4e:6e58 with SMTP id ffacd0b85a97d-439da891d17mr20945001f8f.47.1773081360467; Mon, 09 Mar 2026 11:36:00 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefano Stabellini , Akihiko Odaki Subject: [PATCH v2 3/4] system/xen: Constify various MemoryRegion arguments Date: Mon, 9 Mar 2026 19:35:34 +0100 Message-ID: <20260309183536.88976-4-philmd@linaro.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309183536.88976-1-philmd@linaro.org> References: <20260309183536.88976-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mark the MemoryRegion structure const when is only accessed read-only. Signed-off-by: Philippe Mathieu-Daudé --- include/system/xen-mapcache.h | 2 +- include/system/xen.h | 6 +++--- hw/xen/xen-hvm-common.c | 8 ++++---- hw/xen/xen-mapcache.c | 2 +- hw/xen/xen_stubs.c | 6 +++--- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/include/system/xen-mapcache.h b/include/system/xen-mapcache.h index c46190dd0ce..114d1929c80 100644 --- a/include/system/xen-mapcache.h +++ b/include/system/xen-mapcache.h @@ -16,7 +16,7 @@ typedef hwaddr (*phys_offset_to_gaddr_t)(hwaddr phys_offset, bool xen_map_cache_enabled(void); void xen_map_cache_init(phys_offset_to_gaddr_t f, void *opaque); -uint8_t *xen_map_cache(MemoryRegion *mr, hwaddr phys_addr, hwaddr size, +uint8_t *xen_map_cache(const MemoryRegion *mr, hwaddr phys_addr, hwaddr size, ram_addr_t ram_addr_offset, uint8_t lock, bool dma, bool is_write); diff --git a/include/system/xen.h b/include/system/xen.h index 9a7c53f2838..43b857e4d15 100644 --- a/include/system/xen.h +++ b/include/system/xen.h @@ -30,7 +30,7 @@ extern bool xen_allowed; void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length); void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, - struct MemoryRegion *mr, Error **errp); -bool xen_mr_is_memory(MemoryRegion *mr); -bool xen_mr_is_grants(MemoryRegion *mr); + const MemoryRegion *mr, Error **errp); +bool xen_mr_is_memory(const MemoryRegion *mr); +bool xen_mr_is_grants(const MemoryRegion *mr); #endif diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c index eb7f6270a0d..62d88804c43 100644 --- a/hw/xen/xen-hvm-common.c +++ b/hw/xen/xen-hvm-common.c @@ -23,19 +23,19 @@ MemoryRegion xen_memory, xen_grants; /* Check for any kind of xen memory, foreign mappings or grants. */ -bool xen_mr_is_memory(MemoryRegion *mr) +bool xen_mr_is_memory(const MemoryRegion *mr) { return mr == &xen_memory || mr == &xen_grants; } /* Check specifically for grants. */ -bool xen_mr_is_grants(MemoryRegion *mr) +bool xen_mr_is_grants(const MemoryRegion *mr) { return mr == &xen_grants; } -void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr, - Error **errp) +void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, + const MemoryRegion *mr, Error **errp) { unsigned target_page_bits = qemu_target_page_bits(); unsigned long nr_pfn; diff --git a/hw/xen/xen-mapcache.c b/hw/xen/xen-mapcache.c index a3c162cd4c6..85cf0cf359c 100644 --- a/hw/xen/xen-mapcache.c +++ b/hw/xen/xen-mapcache.c @@ -460,7 +460,7 @@ tryagain: return mc->last_entry->vaddr_base + address_offset; } -uint8_t *xen_map_cache(MemoryRegion *mr, +uint8_t *xen_map_cache(const MemoryRegion *mr, hwaddr phys_addr, hwaddr size, ram_addr_t ram_addr_offset, uint8_t lock, bool dma, diff --git a/hw/xen/xen_stubs.c b/hw/xen/xen_stubs.c index a39efb5062d..f830768d998 100644 --- a/hw/xen/xen_stubs.c +++ b/hw/xen/xen_stubs.c @@ -19,12 +19,12 @@ void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length) } void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, - struct MemoryRegion *mr, Error **errp) + const MemoryRegion *mr, Error **errp) { g_assert_not_reached(); } -bool xen_mr_is_memory(MemoryRegion *mr) +bool xen_mr_is_memory(const MemoryRegion *mr) { g_assert_not_reached(); } @@ -44,7 +44,7 @@ ram_addr_t xen_ram_addr_from_mapcache(void *ptr) g_assert_not_reached(); } -uint8_t *xen_map_cache(MemoryRegion *mr, +uint8_t *xen_map_cache(const MemoryRegion *mr, hwaddr phys_addr, hwaddr size, ram_addr_t ram_addr_offset, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:36:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:36:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249634.1547108 (Exim 4.92) (envelope-from ) id 1vzfSc-0000FY-Uk; Mon, 09 Mar 2026 18:36:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249634.1547108; Mon, 09 Mar 2026 18:36:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSc-0000FL-RM; Mon, 09 Mar 2026 18:36:10 +0000 Received: by outflank-mailman (input) for mailman id 1249634; Mon, 09 Mar 2026 18:36:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfSc-0007ml-09 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:36:10 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d6836500-1be6-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 19:36:08 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so13527755e9.2 for ; Mon, 09 Mar 2026 11:36:08 -0700 (PDT) Received: from localhost.localdomain (88-187-86-199.subs.proxad.net. [88.187.86.199]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dad8dbb3sm25412105f8f.4.2026.03.09.11.36.06 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Mar 2026 11:36:07 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d6836500-1be6-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081368; x=1773686168; 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; bh=bIEbHx6YI4gBPOp+3pEqRYyaYkjjh/Mj9wYvLwhU6C8=; b=aPaJeDnuDxPPuL19l9GAwpuXdgxNkYHXJtb3gKMJ3RWbVJCmv4aRLhvJ+UBKwvLowv N3LaBNI7o5TDhpQiIog8ZQAPzkiWZLLIiVEUf1fwJMNHEP+16Hu8M9SchebZto+DV7KI f1m8b7m45Pg3eDpxdR2ZhqzPGYo1QOWo5SaGf+w7h2EXMRswKarQK3wSbT0swMzEbAuY 1ark1aw1B0Wh/nPw6yGAuvnCNdkuK38spmbEeaSKvza+mN+sKDN3T4WymUvLsiQ8AOGJ jdv8SP8NAz1vZ6wftmJfWyJXDLA8J71/5SVVzFRkmjxfrxrnVXzsvWTmaKOvWR9DtwPa N0eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081368; x=1773686168; 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; bh=bIEbHx6YI4gBPOp+3pEqRYyaYkjjh/Mj9wYvLwhU6C8=; b=gWioS4uBy8bCZaZW1FjQxH2iay7OWwS57pmUJ2jGAK4NhWon+q7VeI8Ti0xXBX7BPD 8bmMSOZ+FpivwoddLqC3palPxrsOAwY1QFEX02dSXqBN5+oJBq5H/KS/Ux9RUcOmw5Nu v6pPTKeMXyb29CVCQL8lMtV3hLP13Z/9D1tcHe6Basl0cmhcVn6CFbUfXS8c5f0kcaYF rlsVYpedvxV2wX/hQx2wlD3o0XAVE+qv8vdPOLqd/38AA6MpXU/PSuixv6p21hdKYzQx PwARTmtTgORj7PLLw+5P2mkT508Ke9xY1fmpCRaa5Ya0BAMSQ9sTiE/g4aep7rzBmyef QwNA== X-Forwarded-Encrypted: i=1; AJvYcCXXzAdKu2zvWqNjPjrcrt4Vwso+2TxueXSbPfKNqfYRoPfXM1keKIVSWyV4ek74UG68sNwM/ffMHRY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx9EwmoAPFaDy/5XOhB2yf/WrABGerxWzuVn06PSxXM6zNbdpQ/ hK0iNfrcOJz6qvXSW5VONCNMDH3zpnGkB1npVJoRI3OEVKhn/IEF0/KLtYVNNO4Ewxk8X6LTmdt jxU4o8jE= X-Gm-Gg: ATEYQzwAFYQRIyd+QE4WNKdc31vohrKlWRspmrOLQUIzYwy/lWxH5Rz331kLKlx7yUf Ig1uzFbZMyzStuXkonSEg2qriqJppteI91nabeIl/kxvrU6F+DLJNX0nzpD5ezGUhSuUhb6dyGS ZXsWjwqlUag2qbKNJNn2wDjkDojcSBedQEaUbJSDJ9qLOJpw+xt4WuzKL0KTeiHz+Ype4+iI9Ed /iHUdQTJ2kLAvIbavZa6mWiXyugQNnK5YXPLymZ++QGc1wrtaA06VZUMYusU8lOMn7pf4UlKNN0 FYv3e+f1ckkVO44o1LArWpBgbrqihJhzpmG/WYDjes3RM0e54Po3F1kBd91EgnMNphk7k23FC2n h1xoyAoxOYyh/h2SDFdaksY7T3czKR3njK5JWvgXwzb24aK+G1XmKDXALjWKRXllkrCjIcjGNLg CAY8PzFVCTFsIzPfYBpeNkGl5Qlk6SD17Hks7V0e7VgjT2b7sxHp3p5sH8IBlS8v1HIaDocWM3 X-Received: by 2002:a05:6000:604:b0:439:b715:6f4b with SMTP id ffacd0b85a97d-439da8a78d1mr22493963f8f.57.1773081367549; Mon, 09 Mar 2026 11:36:07 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefano Stabellini , Akihiko Odaki Subject: [PATCH v2 4/4] system/memory: Have memory_region_type() correctly describe containers Date: Mon, 9 Mar 2026 19:35:35 +0100 Message-ID: <20260309183536.88976-5-philmd@linaro.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309183536.88976-1-philmd@linaro.org> References: <20260309183536.88976-1-philmd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit MemoryRegion containers are not I/O regions, describe them as 'container'. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Pierrick Bouvier Reviewed-by: Peter Xu --- system/memory.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/system/memory.c b/system/memory.c index b130d956d4e..2f2f96ab046 100644 --- a/system/memory.c +++ b/system/memory.c @@ -3303,6 +3303,8 @@ static const char *memory_region_type(const MemoryRegion *mr) return "rom"; } else if (memory_region_is_ram(mr)) { return "ram"; + } else if (!mr->container) { + return "container"; } else { return "i/o"; } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Mon Mar 09 18:37:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 18:37:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249660.1547117 (Exim 4.92) (envelope-from ) id 1vzfTp-0001Rc-97; Mon, 09 Mar 2026 18:37:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249660.1547117; Mon, 09 Mar 2026 18:37:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfTp-0001RV-5a; Mon, 09 Mar 2026 18:37:25 +0000 Received: by outflank-mailman (input) for mailman id 1249660; Mon, 09 Mar 2026 18:37:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzfTo-0001RL-7k for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 18:37:24 +0000 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [2607:f8b0:4864:20::633]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 029ceeb6-1be7-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 19:37:23 +0100 (CET) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-2ae5423b02aso55624355ad.1 for ; Mon, 09 Mar 2026 11:37:23 -0700 (PDT) Received: from [192.168.1.87] (216-71-219-44.dyn.novuscom.net. [216.71.219.44]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae840ad9b7sm206390295ad.79.2026.03.09.11.37.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Mar 2026 11:37:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 029ceeb6-1be7-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1773081441; x=1773686241; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=CB0c8DocWs9nC0mRqWJrFur/DeD1o0K/iABvpYV8rYI=; b=i5y0ybtdX1y23IwGXWB7o4dQ2/JoVqs2xwGqiLhc3N2mutFkTnmi9bhpLv60Iqii8i e+3HuWFCuVAycSoEb2dQxcfDJ5LjZn6n6dBQYelwugKZYbOVjwjftJhslAxQFHINgus9 z6n+Q2RDRuE5y7fJmEVw16gTq9ESViCv2jGt7kovJoOz02MbmXXMzUOHmdxj9e6EZCuH b0MKe3TvDBKtoIqKIwbn0GpilpzOvgQHQQcYAAFlSkX04nL7AkB0p0pltyZFD5s/UsLJ G/qt2UO+SAyfXyxPMarMC2s4hod11FRDAZdTHI0LqTBCZr9ahHdPfhdm8JA5oBWiu60D 6rOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773081441; x=1773686241; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CB0c8DocWs9nC0mRqWJrFur/DeD1o0K/iABvpYV8rYI=; b=X5hDMNXiWjQs9hUlEb+I7cSkDev6+ouC3kN+VYPYfkRMxkAR1fr8ZnVsxd95GQyEAR ZbUIMTh9Df5Arl3bFyih+H7y8t77aqyEzCV/44EgO4DPGrJiIOd6KQWzrJi05Raouehs MHAP3x+MSshy8O7/SkZA29m/5rWydVuq/rQcjLzlFgKhX9V+tjJ06lokECGRYSZ7umLZ TrDPq74GXiJGdqpvCMOigf9mTn2n9bUMMpjppyb+Hl0eGvBNRfu2dfY7wAAK11IwQKt8 qW8/NLEe8YXfJUj4HV7AWDdvVmGr/f6m5lN0ZkIUtH0K7tsi3V/2roeKeNVc0FbnMY4H tNHg== X-Forwarded-Encrypted: i=1; AJvYcCWR56dx8mKYvgiJvZ7rNk74RLHINNeaSY6htA2R5UnlBWi+TlcULWnVlzgRbcPPQxbzLYyOlw5NkXg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzRZYPe1msjtfdMDX6kz73uzuDRUpRWnyjyMVvo/3gco7TXupLW d4YX1nFXpPpTmQazPqwkkfgq+SGCxbharIPqOezHYb+Nw+gOHlwWxXhUksgr0k6yTu0= X-Gm-Gg: ATEYQzymjHqtAnKSBtYU0Y/aMVqmqFxgEgvPncDGdJu2BNrq6Kno6uGzj3TPyuHgGaS BWmYbyY2DQjkrZggs63KODxFc+VQV/NtwSH9f7lJ8rGqhmeljPm1cCLJQENJsWmufjkmDRfWBxd KdvlRWHF2MzeBsJrRy/RVhGnBMZy5kRzQh4fUJCkSlox9ZKi6em0j7rWCdsuFubdkckDGwPpwtD ozD7gzwJ7qg0xJtAtCWKm1h/T6ryYh0FHzqi5Y0a3kAcNPPzzY0kZkibZkfa0XTnv5RGuxOxYbp yIpkQb6/i363Bm1LNth8EYChmIxA+29ixz7VeGIKutigZ6uSeGWXTUsVj0vmLIZV0kN2HFWsxTW zMsQsJVSQ2rRvB8wWJMfdvdpjpl9ede1NkjGT5pBOPWcH1RrrYYX/Ku9hqRtBoXIAHauxyaoCFv 93MR/hSZt+ay0Coiy1/C1bARnv6GnC3HOxcspRbkMxgOdjfacWOK/Ncey2jq4leve5jE1F0Lz06 Fh+AeA= X-Received: by 2002:a17:903:ac4:b0:2ae:69d3:5b9f with SMTP id d9443c01a7336-2ae824ac5abmr118864835ad.52.1773081441272; Mon, 09 Mar 2026 11:37:21 -0700 (PDT) Message-ID: <5483ce28-65d2-4726-b7f2-1003113ff58c@linaro.org> Date: Mon, 9 Mar 2026 11:37:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/4] system/xen: Constify various MemoryRegion arguments To: =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , qemu-devel@nongnu.org Cc: Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Peter Xu , Richard Henderson , Paolo Bonzini , "Edgar E. Iglesias" , Stefano Stabellini , Akihiko Odaki References: <20260309183536.88976-1-philmd@linaro.org> <20260309183536.88976-4-philmd@linaro.org> From: Pierrick Bouvier Content-Language: en-US Autocrypt: addr=pierrick.bouvier@linaro.org; keydata= xsDNBGK9dgwBDACYuRpR31LD+BnJ0M4b5YnPZKbj+gyu82IDN0MeMf2PGf1sux+1O2ryzmnA eOiRCUY9l7IbtPYPHN5YVx+7W3vo6v89I7mL940oYAW8loPZRSMbyCiUeSoiN4gWPXetoNBg CJmXbVYQgL5e6rsXoMlwFWuGrBY3Ig8YhEqpuYDkRXj2idO11CiDBT/b8A2aGixnpWV/s+AD gUyEVjHU6Z8UervvuNKlRUNE0rUfc502Sa8Azdyda8a7MAyrbA/OI0UnSL1m+pXXCxOxCvtU qOlipoCOycBjpLlzjj1xxRci+ssiZeOhxdejILf5LO1gXf6pP+ROdW4ySp9L3dAWnNDcnj6U 2voYk7/RpRUTpecvkxnwiOoiIQ7BatjkssFy+0sZOYNbOmoqU/Gq+LeFqFYKDV8gNmAoxBvk L6EtXUNfTBjiMHyjA/HMMq27Ja3/Y73xlFpTVp7byQoTwF4p1uZOOXjFzqIyW25GvEekDRF8 IpYd6/BomxHzvMZ2sQ/VXaMAEQEAAc0uUGllcnJpY2sgQm91dmllciA8cGllcnJpY2suYm91 dmllckBsaW5hcm8ub3JnPsLBDgQTAQoAOBYhBGa5lOyhT38uWroIH3+QVA0KHNAPBQJivXYM AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEH+QVA0KHNAPX58L/1DYzrEO4TU9ZhJE tKcw/+mCZrzHxPNlQtENJ5NULAJWVaJ/8kRQ3Et5hQYhYDKK+3I+0Tl/tYuUeKNV74dFE7mv PmikCXBGN5hv5povhinZ9T14S2xkMgym2T3DbkeaYFSmu8Z89jm/AQVt3ZDRjV6vrVfvVW0L F6wPJSOLIvKjOc8/+NXrKLrV/YTEi2R1ovIPXcK7NP6tvzAEgh76kW34AHtroC7GFQKu/aAn HnL7XrvNvByjpa636jIM9ij43LpLXjIQk3bwHeoHebkmgzFef+lZafzD+oSNNLoYkuWfoL2l CR1mifjh7eybmVx7hfhj3GCmRu9o1x59nct06E3ri8/eY52l/XaWGGuKz1bbCd3xa6NxuzDM UZU+b0PxHyg9tvASaVWKZ5SsQ5Lf9Gw6WKEhnyTR8Msnh8kMkE7+QWNDmjr0xqB+k/xMlVLE uI9Pmq/RApQkW0Q96lTa1Z/UKPm69BMVnUvHv6u3n0tRCDOHTUKHXp/9h5CH3xawms7AzQRi vXYMAQwAwXUyTS/Vgq3M9F+9r6XGwbak6D7sJB3ZSG/ZQe5ByCnH9ZSIFqjMnxr4GZUzgBAj FWMSVlseSninYe7MoH15T4QXi0gMmKsU40ckXLG/EW/mXRlLd8NOTZj8lULPwg/lQNAnc7GN I4uZoaXmYSc4eI7+gUWTqAHmESHYFjilweyuxcvXhIKez7EXnwaakHMAOzNHIdcGGs8NFh44 oPh93uIr65EUDNxf0fDjnvu92ujf0rUKGxXJx9BrcYJzr7FliQvprlHaRKjahuwLYfZK6Ma6 TCU40GsDxbGjR5w/UeOgjpb4SVU99Nol/W9C2aZ7e//2f9APVuzY8USAGWnu3eBJcJB+o9ck y2bSJ5gmGT96r88RtH/E1460QxF0GGWZcDzZ6SEKkvGSCYueUMzAAqJz9JSirc76E/JoHXYI /FWKgFcC4HRQpZ5ThvyAoj9nTIPI4DwqoaFOdulyYAxcbNmcGAFAsl0jJYJ5Mcm2qfQwNiiW YnqdwQzVfhwaAcPVABEBAAHCwPYEGAEKACAWIQRmuZTsoU9/Llq6CB9/kFQNChzQDwUCYr12 DAIbDAAKCRB/kFQNChzQD/XaC/9MnvmPi8keFJggOg28v+r42P7UQtQ9D3LJMgj3OTzBN2as v20Ju09/rj+gx3u7XofHBUj6BsOLVCWjIX52hcEEg+Bzo3uPZ3apYtIgqfjrn/fPB0bCVIbi 0hAw6W7Ygt+T1Wuak/EV0KS/If309W4b/DiI+fkQpZhCiLUK7DrA97xA1OT1bJJYkC3y4seo 0VHOnZTpnOyZ+8Ejs6gcMiEboFHEEt9P+3mrlVJL/cHpGRtg0ZKJ4QC8UmCE3arzv7KCAc+2 dRDWiCoRovqXGE2PdAW8788qH5DEXnwfzDhnCQ9Eot0Eyi41d4PWI8TWZFi9KzGXJO82O9gW 5SYuJaKzCAgNeAy3gUVUUPrUsul1oe2PeWMFUhWKrqko0/Qo4HkwTZY6S16drTMncoUahSAl X4Z3BbSPXPq0v1JJBYNBL9qmjULEX+NbtRd3v0OfB5L49sSAC2zIO8S9Cufiibqx3mxZTaJ1 ZtfdHNZotF092MIH0IQC3poExQpV/WBYFAI= In-Reply-To: <20260309183536.88976-4-philmd@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/9/26 11:35 AM, Philippe Mathieu-Daudé wrote: > Mark the MemoryRegion structure const when is only accessed read-only. > > Signed-off-by: Philippe Mathieu-Daudé > --- > include/system/xen-mapcache.h | 2 +- > include/system/xen.h | 6 +++--- > hw/xen/xen-hvm-common.c | 8 ++++---- > hw/xen/xen-mapcache.c | 2 +- > hw/xen/xen_stubs.c | 6 +++--- > 5 files changed, 12 insertions(+), 12 deletions(-) > Reviewed-by: Pierrick Bouvier From xen-devel-bounces@lists.xenproject.org Mon Mar 09 19:28:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 19:28:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249687.1547129 (Exim 4.92) (envelope-from ) id 1vzgH7-00004z-WB; Mon, 09 Mar 2026 19:28:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249687.1547129; Mon, 09 Mar 2026 19:28:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzgH7-00004s-SG; Mon, 09 Mar 2026 19:28:21 +0000 Received: by outflank-mailman (input) for mailman id 1249687; Mon, 09 Mar 2026 19:28:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzgH6-0008WS-HU for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 19:28:20 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1ef7f47d-1bee-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 20:28:17 +0100 (CET) Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-377-giO3XCGYORep7-RwVSzZzA-1; Mon, 09 Mar 2026 15:28:14 -0400 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-89a17ec1eecso385620426d6.3 for ; Mon, 09 Mar 2026 12:28:13 -0700 (PDT) Received: from x1.local ([174.91.117.149]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89a57c21650sm3965026d6.39.2026.03.09.12.28.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 12:28:11 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1ef7f47d-1bee-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773084495; 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=rbgWYjkthYIOSTddrLM7TxbryCIauGeCCATpvk8Vcjo=; b=OTbtKYNx9U1VSvr/q62NqwK7FMPTsE6CvsDNi5S+iSABv8gqXhhdui29gq63rhcMwgYQmr js8YOA0a3oDzDOs+vxlljPka3w7ljabdxDTQtZ2O6CVG5H3WsRHeo+G+nklz6IoYTGQA9T NCMs60r3qGpKp+n/+Zine4bMrEftPT8= X-MC-Unique: giO3XCGYORep7-RwVSzZzA-1 X-Mimecast-MFC-AGG-ID: giO3XCGYORep7-RwVSzZzA_1773084493 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773084493; x=1773689293; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rbgWYjkthYIOSTddrLM7TxbryCIauGeCCATpvk8Vcjo=; b=I+HOOdZ4CcSwK0vbuFPPj7igZt1VDfWTGGX+AQcULAlMhPEWT3OXqYflmFMxFOT8U9 VivaCfAeRLFrjfcdl8KTc6sWYz9xicYSAGT0veftY4slANf5RaLFpYJ7B7ig3E8QIvtR ByWfBiOJYkPmQrT/F1yyK/30y/wMatYjUVEPKAEep9bdOpSr1ohKnwRLjKkPRWivekpi HzdcsT1fyBIMZs9MMu/ObjvWV/twvW9Vmg9hI58JepVaogWv/4OTaiC48U8tAwwFzIhc rY26FW3HDM6BqxHPeUB6sPdUpGl3y7S04O28YePpF8jujNg2TVdxfzfGSD4oeqkd4lSh kVXQ== X-Forwarded-Encrypted: i=1; AJvYcCVRnkpE5Nbtp7VkjYeZGivrez14syg+q4yGC1bTL14yL8Q/C0jJEKlYHHo7dkwCZ1uIp1dbl9SkFTk=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz5N46SVB87E0NfGCLw6IIbWlET9tmDlvPPVTnezEq5q3UY0+GC VNGOsU1llS3EQWYdHKC43c2dvgBPkx5o7pFrnCyYKFZAyfUIxtE1mZUBhc0ah4ji9nKpydWrNuH rihcbz8qXVnuJvGkS5X4ycGP8D+oUztnmpMJv/HnhFgDulaVvpZkCV/t/PEBde76i/3SI X-Gm-Gg: ATEYQzzCXfLxZvwwq4cD3n8lCmu4a2FBeCRj7y9lO+bWKCCPLP7HPS3K7yG29jEklpL KpWka3g5MBnskSHG+cNQzCz3uUvaydMbP9sx3uoCbD2Av6ttA6Vhsw8Nuawn1BQfHxiVIPwC8vg 6DRtMgVVpwbAS3AROYpk4m8Dzs9S7/MeezFZ18BtvT8I51JCmy50Yo/5JYU5agedyKbsVpHWAh1 1j/PL0xKOrYwt0NvGacWzxhfI+sNMcFrQcotAWzpaTUC1kJ8rAhwgT41pg9O0GUR2QoqLFlJYGO 7I7j9zAN/C4RrH7NiGud+gXOe33N5Aah6Vz8kqX08yxGnrpjGTx/qszMGy7g/lKTCgYL8kI1wFJ q5X0CUkH8WQHXLg== X-Received: by 2002:a05:6214:cc4:b0:89a:865:75d7 with SMTP id 6a1803df08f44-89a30a5c913mr195502306d6.27.1773084493136; Mon, 09 Mar 2026 12:28:13 -0700 (PDT) X-Received: by 2002:a05:6214:cc4:b0:89a:865:75d7 with SMTP id 6a1803df08f44-89a30a5c913mr195501746d6.27.1773084492577; Mon, 09 Mar 2026 12:28:12 -0700 (PDT) Date: Mon, 9 Mar 2026 15:28:00 -0400 From: Peter Xu To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= Cc: qemu-devel@nongnu.org, Mohamed Mediouni , Anthony PERARD , xen-devel@lists.xenproject.org, Mark Cave-Ayland , Richard Henderson , Pierrick Bouvier , Paolo Bonzini , "Edgar E. Iglesias" , Stefano Stabellini , Akihiko Odaki Subject: Re: [PATCH v2 0/4] system/memory: Constify various RAMBlock/MemoryRegion arguments Message-ID: References: <20260309183536.88976-1-philmd@linaro.org> MIME-Version: 1.0 In-Reply-To: <20260309183536.88976-1-philmd@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: mkQdIm1VSr7gb2jADLY9uz5gmDZdWzhCynGKUdVAxgo_1773084493 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Mar 09, 2026 at 07:35:31PM +0100, Philippe Mathieu-Daudé wrote: > v2: > - Dropped "stubs: Merge physmem.c within ram-block.c" (Zoltan) > - Dropped "info mtree" patches (no time to update doc for freeze) > - New Xen patch > > Philippe Mathieu-Daudé (4): > system/ramblock: Constify various RAMBlock arguments > system/memory: Constify various MemoryRegion arguments > system/xen: Constify various MemoryRegion arguments > system/memory: Have memory_region_type() correctly describe containers queued -- Peter Xu From xen-devel-bounces@lists.xenproject.org Mon Mar 09 21:05:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 21:05:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249722.1547138 (Exim 4.92) (envelope-from ) id 1vzhmq-0003RG-Km; Mon, 09 Mar 2026 21:05:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249722.1547138; Mon, 09 Mar 2026 21:05:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhmq-0003R9-Hk; Mon, 09 Mar 2026 21:05:12 +0000 Received: by outflank-mailman (input) for mailman id 1249722; Mon, 09 Mar 2026 21:05:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhmp-0003R3-QT for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 21:05:11 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a7ba343a-1bfb-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 22:05:09 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0FF3560054; Mon, 9 Mar 2026 21:05:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FD26C4CEF7; Mon, 9 Mar 2026 21:05:07 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a7ba343a-1bfb-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773090307; bh=Nq8FH4TTfSWeK3IqSHQXr18jc5JUXALz41xxYhKgNgA=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=kdf6A65npBGYj/ybcEJCHuWvMf/VZj0Jj8ZaOAFs96ROtJKN3tNO6HP1MgrC1B6oy EPz1UZwrSSC9JS6jVh8OFGGbTheePHMFWRYLgBv6QYovtZxwfOJIBlVIiFiT1GlRLD gIb3m8jY9XsN+5f9e3VF1vUYbRS23+wDBhf1FUzktXUHwBjHU/K01iV5QYd4lJUqwT Juq+UXeh/FdpGWKyQnG8gefrB2Wu+pXvMbGgRB3sIPoxuUO6Q4ct39W+i2TnSz6lEb 4iJj4AIMUzMPKu8qsjNoIlfsyAQcX/cq7D4MiOj4h7VwqN29Fg5h87eIkiuTTVEPZg 88YY2nPe8WVWw== Date: Mon, 9 Mar 2026 16:05:06 -0500 From: Bjorn Helgaas To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v10 0/3] of: parsing of multi #{iommu,msi}-cells in maps Message-ID: <20260309210506.GA589665@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> On Mon, Mar 09, 2026 at 01:03:36AM +0530, Vijayanand Jitta wrote: > ... > Charan Teja Kalla (1): > of: factor arguments passed to of_map_id() into a struct Please make this subject line match the capitalization of those below, i.e., "of: Factor arguments ..." > Robin Murphy (2): > of: Add convenience wrappers for of_map_id() > of: Respect #{iommu,msi}-cells in maps From xen-devel-bounces@lists.xenproject.org Mon Mar 09 21:08:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 21:08:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249730.1547146 (Exim 4.92) (envelope-from ) id 1vzhqR-0003xG-2n; Mon, 09 Mar 2026 21:08:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249730.1547146; Mon, 09 Mar 2026 21:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhqR-0003x9-0H; Mon, 09 Mar 2026 21:08:55 +0000 Received: by outflank-mailman (input) for mailman id 1249730; Mon, 09 Mar 2026 21:08:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhqQ-0003x3-Dw for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 21:08:54 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2c21054e-1bfc-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 22:08:51 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id E215760054; Mon, 9 Mar 2026 21:08:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6AE8BC4CEF7; Mon, 9 Mar 2026 21:08:50 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2c21054e-1bfc-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773090530; bh=U7I3bh69J3B4cMe2WWPQdGTO1zM2gflc1SsDGP9ZT0I=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=A0L3JiuPR1xjYzTSESZft46f57l2sFUINbyiBwaa6vFAi1NfK83JHNon+cdjeHKbn 7dtI21fEV5QD8ro2YvLh2Si8Xpmb/17KnuNGo/q5fBhZ11PkzUawLhZoFdFNhVyGZM h/UhGimNDd/Bac8cHifHRIEZ0rQmMlZ0lNoOeU0rl8G4gzJtuuk805FkZ6Mu2QWd+Z 3MmBuE34eHGaY4YmNqZFA/7GR/Hc/hOENwdlrhexbxhowZ156iiF3wnKTE7av1xp4N wTipYJkof56uIJTznJYFJZWnhgT23MKaop5kLLZPDuod/62QnQMcD8mDWMFBsMhO4/ d13soJV6gfW+A== Date: Mon, 9 Mar 2026 16:08:49 -0500 From: Bjorn Helgaas To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v10 3/3] of: Respect #{iommu,msi}-cells in maps Message-ID: <20260309210849.GA591344@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260309-parse_iommu_cells-v10-3-c62fcaa5a1d8@oss.qualcomm.com> On Mon, Mar 09, 2026 at 01:03:39AM +0530, Vijayanand Jitta wrote: > From: Robin Murphy > > So far our parsing of {iommu,msi}-map properites has always blindly s/properites/properties/ From xen-devel-bounces@lists.xenproject.org Mon Mar 09 21:17:03 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 21:17:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249741.1547155 (Exim 4.92) (envelope-from ) id 1vzhyE-0005WG-Oi; Mon, 09 Mar 2026 21:16:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249741.1547155; Mon, 09 Mar 2026 21:16:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhyE-0005W9-Lx; Mon, 09 Mar 2026 21:16:58 +0000 Received: by outflank-mailman (input) for mailman id 1249741; Mon, 09 Mar 2026 21:16:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzhyD-0005W3-55 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 21:16:57 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4bdf1f80-1bfd-11f1-b164-2bf370ae4941; Mon, 09 Mar 2026 22:16:54 +0100 (CET) Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 629HBqeH3148233 for ; Mon, 9 Mar 2026 21:16:53 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 4csv5ua53a-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 09 Mar 2026 21:16:53 +0000 (GMT) Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-50900e9803aso189295131cf.2 for ; Mon, 09 Mar 2026 14:16:53 -0700 (PDT) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a13d01cbfasm2323612e87.14.2026.03.09.14.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 14:16:50 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4bdf1f80-1bfd-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=KLgWRaioXqeIrwHgYBcxPqE/ kg4Fe+2f2o7A+PfgTZw=; b=eYrTi12bsFRg+Ep63Gvyrpkz6qz+XZZnxJnhHzZ8 Afqkljn6AGFqwUNG6Hi9uCb6ZzQda58iRJHt3K5YZu6fE5lb/rlDs3LPJDnuIy9X R2Y9ER606cwX+ZHgCY8VFLE+xAxUWo2O4Thd+KKh+iYlFQhrYQ0g6GO+JQptJ4KE 6f0gsKaivSPOXL1lrK/xqQc3elp326ygArdomugL7e78pyCIveo8V0I+Gp/yH752 qn3L1fJOi+1y8gGG02UGdrOgFKCLS1JmoihvFsIZX4/Br1ShuSsjy4BmL2Iv75+1 0Iz/BPpRhzYykPy9UUlKCrzFisiTC2PnI1DfQMHXc4YBKg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773091012; x=1773695812; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=KLgWRaioXqeIrwHgYBcxPqE/kg4Fe+2f2o7A+PfgTZw=; b=YBvG900VLbelKbArd2GrhU0/17rMOvtDrX/WHXT+YfYcMkAZW+XhglRT5ktWEhWYwY JMjJ+Mb1dbwkXOhqoPBshKs0PnkG52diMl8JjkxfitfU9Hr43mOI2dvwlZRkkM+aFu9B rIDOJssm+n0+aHq92wlA0+t5aSH4zoXYPrmOtsRb8lM5HG+PQPvgrucWhs4NeCVCIpgU x/XLuXAapoXqci92TZSnaYLNz6fSoA2/BnHG20IbjYQ0IGWW1YwM+/piVD6NTA82nE6x mKQgq6Yeazysl5VEA6YmopTX6kW+OTM60SV3IwnS2AHmTNLZsV8UrvYfkdjmZgfcUDGi RgKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773091012; x=1773695812; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KLgWRaioXqeIrwHgYBcxPqE/kg4Fe+2f2o7A+PfgTZw=; b=dPL4bAG/xRBEtC/h0NUmBR6+Q7l9IqP31M5bjcez0Dy2IWAatn+GvgbFt+C7EYUKsC g/kzTXA2pol3M7VfAiiKqYJjpNWR+ZysdIniktnf27XoJq5SMcgVaFv/AIxBGtAFUBuX r1lV8cqcLupLRPxnHgNAZOyOduWezB3j6pLhpmRJO9ADbpouUY0dbQNpY5gzAVJbTDWn pZY4azpg5yXk6u0yzsEK6oO5svxnYgwu2/JB6KQwLBXW99r1/upooYqOjajckoi1pBHg dRJwb3Le1ZICfth/G0kf7zTib+oqnaWXBV/cS78i6HII/OmAPXNp9/csAuZ8zsetcMHm ghxw== X-Forwarded-Encrypted: i=1; AJvYcCVq1TQ6LHT8G9i5mVvOFxqmLNwD46LzfViKyT4F0R0+GS5gtoDKdB3DCi7VLOqFnWww3XcsojgjhFE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz5aSug+lK9v9QBZM4zuHIQBhcqcYSzdyDzOXq6GAmYL8b/CLXL ghE7b/dX5Nb5GRvKdVjB0p0eKP873qWzE1YSZKp1+/ZSijO3usRL0pleKE/XkGnzPMDzzOUfYLg BeQsF5PHbw+mm8XG+A0iQ0V9RHWDEhCtK/DHHGBzY55YyKBbQRTa9pmRFVJPr+THFaKwRmA== X-Gm-Gg: ATEYQzw27STEevhm7AmigV3VEMplRitjyQ4Sp4fcwPXkMu62CuIgPatQ6Ljn7/uhXM/ /grkk/kyhg4+A+haZQFeJptVg3+eDyRDIGAGUfC90NH6NB26uQ3Nmg36pG0nm+/+fKJVsClvQDs iRHScba/MTxPpKYLxlzJ1MhkVr9KoBf8RRZy/yVx2waep4IUi2YLoo3dGCId7DYNZzKRHjAfQdy GgtViDSyoI6H0llnwaT8LddR9N3FOZKsUIwKMS6FeRLpodYPX4nRYDpQLRcQaJuZFSPZGID2rmb VOqgHu8hyQz3NeWpCHSvZqBzV2oGRJuBidRMYYetKpBj+S5zp4ok/mV/8dfCzfkVnmZG3RHz+wj Zx+9JJ0GsPOf6oML4II+VF53m6bv9Ekfz6KeZ6HASI4yrI9rx5kMyTLoyHhKHJAJIQZBj2W2PeV SDzim1P+vlC1qx1hfBY/EjTMewtDyFvnf9O5c= X-Received: by 2002:a05:620a:2946:b0:8cb:3d7a:c009 with SMTP id af79cd13be357-8cd6d4b5029mr1566977985a.78.1773091012403; Mon, 09 Mar 2026 14:16:52 -0700 (PDT) X-Received: by 2002:a05:620a:2946:b0:8cb:3d7a:c009 with SMTP id af79cd13be357-8cd6d4b5029mr1566971885a.78.1773091011890; Mon, 09 Mar 2026 14:16:51 -0700 (PDT) Date: Mon, 9 Mar 2026 23:16:47 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v10 1/3] of: Add convenience wrappers for of_map_id() Message-ID: <3plcdobbd6teiluzijzk33yepbpsur24tnmjr32sco7a4loptm@xmzmsaurvmvj> References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> <20260309-parse_iommu_cells-v10-1-c62fcaa5a1d8@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260309-parse_iommu_cells-v10-1-c62fcaa5a1d8@oss.qualcomm.com> X-Proofpoint-GUID: 6_yulVzokgJlJ8zTfldfI44zalv2-rYd X-Proofpoint-ORIG-GUID: 6_yulVzokgJlJ8zTfldfI44zalv2-rYd X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA5MDE4OCBTYWx0ZWRfX3SHK2/4Bi9kJ 4bwyS2EYRgSOUVzpxGYs8exPK3Af9EvVolSyAH1Cs8dKATw1Gtc0TVPqwLIMrBMGTMnoMtAUloI hHb63vl2cj76QeEYeoZ6E7pGssO0xFdrsBhktFtFI0HCkKZBi7A1bGhZaVyNo0tEuivxPXnt+Gd tJiclvW2M9kHP3aO2X8kEiVVVJjgmnihUcFv0N4r/EatkL/saB5kH2a93ww6vnxpNh5Qs1Txqvk buRKZTyyR/l65Skv7BUfSCBhaDDCuCna2pfKgu62sDTgdgyaMGxbZam6ysHzglM4smUlW+qqANW 2jq9xGOjkilsOl16Y1euSJfsX7rVOERXCZk4DloZ8J0z99LGwz0kwMobkTZM8FxCXXQHrMc0QCZ 74xeEPu2unMUqPHMCIZoVRv8Uq0gE11O6nA8oy+xA3iMecWEnukCiqqjEeSNDCmk4aUnIZcu5g3 IO5xJFO6aNAPx2KIntg== X-Authority-Analysis: v=2.4 cv=Xr/3+FF9 c=1 sm=1 tr=0 ts=69af38c5 cx=c_pps a=EVbN6Ke/fEF3bsl7X48z0g==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=EUspDBNiAAAA:8 a=5ndfpk7zZlG9lj9R3R4A:9 a=CjuIK1q_8ugA:10 a=a_PwQJl-kcHnX1M80qC6:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-09_06,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 spamscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 priorityscore=1501 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603090188 On Mon, Mar 09, 2026 at 01:03:37AM +0530, Vijayanand Jitta wrote: > From: Robin Murphy > > Since we now have quite a few users parsing "iommu-map" and "msi-map" > properties, give them some wrappers to conveniently encapsulate the > appropriate sets of property names. This will also make it easier to > then change of_map_id() to correctly account for specifier cells. > > Reviewed-by: Rob Herring (Arm) > Reviewed-by: Frank Li > Signed-off-by: Robin Murphy > Signed-off-by: Vijayanand Jitta > --- > drivers/cdx/cdx_msi.c | 3 +-- > drivers/iommu/of_iommu.c | 4 +--- > drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- > drivers/of/base.c | 36 ++++++++++++++++++++++++++++++++ > drivers/of/irq.c | 3 +-- > drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- > drivers/pci/controller/pcie-apple.c | 3 +-- > drivers/xen/grant-dma-ops.c | 3 +-- > include/linux/of.h | 18 ++++++++++++++++ > 9 files changed, 62 insertions(+), 16 deletions(-) > > + > +/** > + * of_map_msi_id - Translate an ID using "msi-map" bindings. Which ID are we talking about wrt. MSI interrupts? > + * @np: root complex device node. > + * @id: device ID to map. > + * @target: optional pointer to a target device node. > + * @id_out: optional pointer to receive the translated ID. > + * > + * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask". > + * > + * Return: 0 on success or a standard error code on failure. > + */ > +int of_map_msi_id(const struct device_node *np, u32 id, > + struct device_node **target, u32 *id_out) > +{ > + return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out); > +} > +EXPORT_SYMBOL_GPL(of_map_msi_id); -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Mon Mar 09 21:23:32 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 21:23:32 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249755.1547164 (Exim 4.92) (envelope-from ) id 1vzi4T-0007Ac-GU; Mon, 09 Mar 2026 21:23:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249755.1547164; Mon, 09 Mar 2026 21:23:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzi4T-0007AV-Dp; Mon, 09 Mar 2026 21:23:25 +0000 Received: by outflank-mailman (input) for mailman id 1249755; Mon, 09 Mar 2026 21:23:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzi4R-0007AH-JZ for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 21:23:23 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3198570e-1bfe-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 22:23:20 +0100 (CET) Received: from pps.filterd (m0279862.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 629HC5OW3280630 for ; Mon, 9 Mar 2026 21:23:18 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 4csqcyb93u-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 09 Mar 2026 21:23:18 +0000 (GMT) Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8cd8b37d4b2so809163385a.3 for ; Mon, 09 Mar 2026 14:23:18 -0700 (PDT) Received: from umbar.lan (2001-14ba-a073-af00-264b-feff-fe8b-be8a.rev.dnainternet.fi. [2001:14ba:a073:af00:264b:feff:fe8b:be8a]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a13d02b7e5sm2278544e87.32.2026.03.09.14.23.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 14:23:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3198570e-1bfe-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=TtfIg1OCm36qvkMhTOZUWOO1 bZpr9t+AjKAbArsxNiE=; b=eyJPpq3Ig7NxG3aU7DJtqhc3PsNXLt5yKHOlINSp 78iEyJkx1Kv9HVu6lMkbquLLkhFVRe5VDgVx9MdIMWcWpERBlViQyHeWKFr7V/43 lAexD7de/jtwjnixjFWElOdRtTAIZNMzoznOULVcEij4or/w85O0w5pOTYqfMFzD wgLOlGhGMmOrikUaOuSMbrHYIzoWhjJeHlO1Qrx5j6m2GqcbpZQ1RTGMGok0jfFB XGjD8yimz+eA29vgC3DWQ7BPQBxPpoNpuMsj+8cgHe4x9pLY4Yzr1buVqa0zukzA m+HUjpVrpT5ki3Gp8XA+FcQIiEHg+NxuCR1N3G0DZTdEOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773091397; x=1773696197; darn=lists.xenproject.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=TtfIg1OCm36qvkMhTOZUWOO1bZpr9t+AjKAbArsxNiE=; b=Fu5t+K5rE51VQhevNF/pDl+e1b245p9mYtwOOKDg4pDjMchNhxs/mGXlzzDQdYd/u4 qVYBXFiPB7G6NNdCJeyh6h6S2teopPTX1qZJG6SzhVugiuAVho12GaZTIVjbYdjycHZt G1sDe8o1+UnAUojGRM9dxUc2wKHDRWavA/yfOfZQU/gNN8q9s7VqW8p0KSqITh7EsDjt pysolNK4Vlw+r69ydW7hQCsTg0V4GMftawVmx0PB9TDRSEAJhGxPKOl3kral/vxXDXNM iznBtX2hZo3NlltzhR3sF177oht9WEIFvU7i+w7WJYGEUf5Veefh94CzwnSAwbeCw1hM ecTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773091397; x=1773696197; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TtfIg1OCm36qvkMhTOZUWOO1bZpr9t+AjKAbArsxNiE=; b=bypc/3kpl3kCwpgILOWfvJNlZovkDoA+6J1webwavcZwnR5e2LSSK/dG+HdXOkzHEB GewCs4uQyc+wt6zPZAcsXsVjbi0Lvcd1gbaBJTn/E9VExAtuwPXZrDlM582FFxmDwz+I 7fsGuqIK7r3V3tY2C/54oj5dXKs2KjBH4BtFSQIeG1opGDvQ5Pqn+vj31n4Q3U3bZ+Qc g25MQB9x6BhO3lByczRiFpu73H7POoZkRlaR2SxirR/phI1wqVZQKSnf4MSu7X8k64t4 xQC9qjUnOv8BWgI67nYEZV+HxOVaN/1X7EKbpw2K/fHHabtlukvKHCLsI2606fKoj4tb 8LfQ== X-Forwarded-Encrypted: i=1; AJvYcCWHsLXux6jrkSVpGcXzFpsLOEhUtHCHDmsyxK67UWgXFAE12dEcZWPaVnu2UZ2rZEp4LFUneYMHThg=@lists.xenproject.org X-Gm-Message-State: AOJu0YzX/wxFLfwD1H0Q/AoxjWw8o046mOPUZ9i90p31bAY84HG75/FX OTzVXqwxONFdZr5sugYSFPDiUFzLn7KCGFfP9BT8Cpu78SLHDDAYYWPjl4jnqWwVH9c8t0KDD5K 4SS/nG1r8rqMd3fz1wPDxfoQ7v0fnAukN/CDZNJF5N8nq0NxVchv118QOw5a++KiZQIPTng== X-Gm-Gg: ATEYQzxznwoTKAtSvFmXDXcNJss4JcRA16mdjn/3Q+0YWiM3xo2+oZ4Kv+ZpkB6gclu jANZT/HJl20kPhb/rztZWomYAlduQBDeAjEPm17/VkM1bxJIgxvUVod81I32NDJ4v0vtS+eu0eP T9wMvOwNf2JN+sKVa91cMWzoTazQDI1iIfLU1zV41rysTr1DGSXNMq+mV12SCyh9hoxOOkumEd/ Dzi3ipio9cjFNXG3hn+ZE2eq3iCvKf0u8muiOboNphN0RTIiKHyK65RDVZSI5dJu/63k1rqyc+W PeFcfFjaYpM4keDKTYNLnrTtndFjpxWKNBpQxVGtuZDwk/KH8Fbne05DnBxoIX6PpziS9ENSJz6 Cxbow15sew8QBYh/Ay6JKzTYKW97qwWryjHFEMvC0NeF9PRxVk35BaFyZJI4o1Wb082l+OlExlO RS5PHwLYCZD4gd3l2iRvx0qiHJD/VJjF1jv48= X-Received: by 2002:a05:620a:40c3:b0:8cd:8f18:d1d3 with SMTP id af79cd13be357-8cd8f18d5demr363277185a.58.1773091397432; Mon, 09 Mar 2026 14:23:17 -0700 (PDT) X-Received: by 2002:a05:620a:40c3:b0:8cd:8f18:d1d3 with SMTP id af79cd13be357-8cd8f18d5demr363272685a.58.1773091396812; Mon, 09 Mar 2026 14:23:16 -0700 (PDT) Date: Mon, 9 Mar 2026 23:23:14 +0200 From: Dmitry Baryshkov To: Vijayanand Jitta Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla Subject: Re: [PATCH v10 2/3] of: factor arguments passed to of_map_id() into a struct Message-ID: References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> <20260309-parse_iommu_cells-v10-2-c62fcaa5a1d8@oss.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260309-parse_iommu_cells-v10-2-c62fcaa5a1d8@oss.qualcomm.com> X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA5MDE5MCBTYWx0ZWRfXzGxDle9W+Rrv GhlTY6w5b6yjK6Ym/IAYZdOsdUJPUguMTirY5OzNhUH1+4ilklILotAlzjbtKkd762bLXcuwhS0 80QgOwcJ5gLmNyp7Lp7ZlViiA5qRRuoHXdFjsj8JDFYbYKtgZLbzugkPz3onXoh5mzxdYVQLTNe dbFwzQiHFgaUUsNKIIrKGDl+6EGuFzulWfRi4V1HHK6ZUpZ5axM57uO7SgyJoxYJfQLsoVjkMj5 1dmJaM9g60xh2Dfe2q2lYt4CFy9NKhhPyx9caSETaQvPTm4JbLNKqJ73pdi3miXivwd7b1TS7b9 46iN/4VU1yyi1gjS71m4r0L6RVmlMpbNOr8KMmE9dvu0Moh/6QWk90rqIXl3bGDyVJsA/7gf6Ow JtRhhkoQMaMe8WacRdcxcBX6AtWCU4sQv/E9fnmkuXxc1IwbTGU+pL0I1vc/+yKsXn3Q1sYUMcT yCNGjNOOsf021Lo9ZIA== X-Authority-Analysis: v=2.4 cv=QJtlhwLL c=1 sm=1 tr=0 ts=69af3a46 cx=c_pps a=qKBjSQ1v91RyAK45QCPf5w==:117 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_K5XuSEh1TEqbUxoQ0s3:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=eKfNa9SdMFmDU-kgw3kA:9 a=CjuIK1q_8ugA:10 a=NFOGd7dJGGMPyQGDc5-O:22 X-Proofpoint-ORIG-GUID: lBcBBpm6i9hwRRbqvFlToXI4ABktjZdN X-Proofpoint-GUID: lBcBBpm6i9hwRRbqvFlToXI4ABktjZdN X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-09_06,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 adultscore=0 spamscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 bulkscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603090190 On Mon, Mar 09, 2026 at 01:03:38AM +0530, Vijayanand Jitta wrote: > From: Charan Teja Kalla > > Change of_map_id() to take a pointer to struct of_phandle_args > instead of passing target device node and translated IDs separately. > Update all callers accordingly. > > Subsequent patch will make use of the args_count field in > struct of_phandle_args. > > Suggested-by: Rob Herring (Arm) > Signed-off-by: Charan Teja Kalla > Signed-off-by: Vijayanand Jitta > --- > drivers/cdx/cdx_msi.c | 5 ++- > drivers/iommu/of_iommu.c | 2 +- > drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++-- > drivers/of/base.c | 63 ++++++++++++++++---------------- > drivers/of/irq.c | 8 +++- > drivers/pci/controller/dwc/pci-imx6.c | 16 ++++++-- > drivers/pci/controller/pcie-apple.c | 5 ++- > drivers/xen/grant-dma-ops.c | 4 +- > include/linux/of.h | 12 +++--- > 9 files changed, 76 insertions(+), 50 deletions(-) > > diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c > index 63b3544ec997..03232b5ffbca 100644 > --- a/drivers/cdx/cdx_msi.c > +++ b/drivers/cdx/cdx_msi.c > @@ -121,6 +121,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > struct device *dev, > int nvec, msi_alloc_info_t *info) > { > + struct of_phandle_args msi_spec = { .np = NULL }; Why do you need to set it? Parse functions ignore passed args, don't they? > struct cdx_device *cdx_dev = to_cdx_device(dev); > struct device *parent = cdx_dev->cdx->dev; > struct msi_domain_info *msi_info; > @@ -128,11 +129,13 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, > int ret; > > /* Retrieve device ID from requestor ID using parent device */ > - ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); > + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, &msi_spec); > if (ret) { > dev_err(dev, "of_map_id failed for MSI: %d\n", ret); > return ret; > } > + of_node_put(msi_spec.np); > + dev_id = msi_spec.args[0]; > > #ifdef GENERIC_MSI_DOMAIN_OPS > /* Set the device Id to be passed to the GIC-ITS */ > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c > index a511ecf21fcd..d255d0f58e8c 100644 > --- a/drivers/iommu/of_iommu.c > +++ b/drivers/iommu/of_iommu.c > @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, > struct of_phandle_args iommu_spec = { .args_count = 1 }; .args_count = 1 should be set by of_map_iommu_id now (and dropped here). > int err; > > - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); > + err = of_map_iommu_id(master_np, *id, &iommu_spec); > if (err) > return err; > > diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c > index b63343a227a9..729fa2f9f758 100644 > --- a/drivers/irqchip/irq-gic-its-msi-parent.c > +++ b/drivers/irqchip/irq-gic-its-msi-parent.c > @@ -152,6 +152,8 @@ static int its_v5_pci_msi_prepare(struct irq_domain *domain, struct device *dev, > static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u32 *dev_id, > phys_addr_t *pa) > { > + struct device_node *msi_ctrl __free(device_node) = NULL; > + struct of_phandle_args msi_spec = { .np = NULL }; > struct of_phandle_iterator it; > int ret; > > @@ -178,9 +180,12 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u > } > } > > - struct device_node *msi_ctrl __free(device_node) = NULL; > - > - return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); > + ret = of_map_msi_id(dev->of_node, dev->id, &msi_spec); > + if (!ret) { > + msi_ctrl = msi_spec.np; > + *dev_id = msi_spec.args[0]; > + } > + return ret; > } > > static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, > diff --git a/drivers/of/base.c b/drivers/of/base.c > index 959305a84748..b6e07c5fe715 100644 > --- a/drivers/of/base.c > +++ b/drivers/of/base.c > @@ -2102,36 +2102,37 @@ int of_find_last_cache_level(unsigned int cpu) > * @id: device ID to map. > * @map_name: property name of the map to use. > * @map_mask_name: optional property name of the mask to use. > - * @target: optional pointer to a target device node. > - * @id_out: optional pointer to receive the translated ID. > + * @arg: pointer to a &struct of_phandle_args. On input, @arg->np may be > + * set to a target device node to match, or NULL to match any. On > + * success, @arg->np will be set to the matched target node (with a > + * reference held) and @arg->args[0] will contain the translated ID. Is this part being actually used (and useful)? > * > * Given a device ID, look up the appropriate implementation-defined > * platform ID and/or the target device which receives transactions on that > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or > - * @id_out may be NULL if only the other is required. If @target points to > - * a non-NULL device node pointer, only entries targeting that node will be > - * matched; if it points to a NULL value, it will receive the device node of > - * the first matching target phandle, with a reference held. > + * ID, as per the "iommu-map" and "msi-map" bindings. If @arg->np points to > + * a non-NULL device node, only entries targeting that node will be matched; > + * if it is NULL, it will receive the device node of the first matching > + * target phandle, with a reference held. > * > * Return: 0 on success or a standard error code on failure. > */ > int of_map_id(const struct device_node *np, u32 id, > const char *map_name, const char *map_mask_name, > - struct device_node **target, u32 *id_out) > + struct of_phandle_args *arg) > { > u32 map_mask, masked_id; > int map_len; > const __be32 *map = NULL; > > - if (!np || !map_name || (!target && !id_out)) > + if (!np || !map_name || !arg) > return -EINVAL; > > map = of_get_property(np, map_name, &map_len); > if (!map) { > - if (target) > + if (arg->np) > return -ENODEV; > /* Otherwise, no map implies no translation */ > - *id_out = id; > + arg->args[0] = id; > return 0; > } > > @@ -2173,18 +2174,15 @@ int of_map_id(const struct device_node *np, u32 id, > if (!phandle_node) > return -ENODEV; > > - if (target) { > - if (*target) > - of_node_put(phandle_node); > - else > - *target = phandle_node; > + if (arg->np) > + of_node_put(phandle_node); > + else > + arg->np = phandle_node; > > - if (*target != phandle_node) > - continue; > - } > + if (arg->np != phandle_node) > + continue; > > - if (id_out) > - *id_out = masked_id - id_base + out_base; > + arg->args[0] = masked_id - id_base + out_base; > > pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", > np, map_name, map_mask, id_base, out_base, -- With best wishes Dmitry From xen-devel-bounces@lists.xenproject.org Mon Mar 09 22:26:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 09 Mar 2026 22:26:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249770.1547174 (Exim 4.92) (envelope-from ) id 1vzj3C-0006bi-Qd; Mon, 09 Mar 2026 22:26:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249770.1547174; Mon, 09 Mar 2026 22:26:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzj3C-0006bb-O1; Mon, 09 Mar 2026 22:26:10 +0000 Received: by outflank-mailman (input) for mailman id 1249770; Mon, 09 Mar 2026 22:26:08 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzj3A-0006bF-L3 for xen-devel@lists.xenproject.org; Mon, 09 Mar 2026 22:26:08 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f48d48d4-1c06-11f1-9ccf-f158ae23cfc8; Mon, 09 Mar 2026 23:26:04 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by DM6PR03MB5258.namprd03.prod.outlook.com (2603:10b6:5:241::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.24; Mon, 9 Mar 2026 22:25: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%6]) with mapi id 15.20.9678.024; Mon, 9 Mar 2026 22:25:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f48d48d4-1c06-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HripiaxAwLMthSRqJbYXa0IGTEMawW2n4IxtfA7Zn8ZwPbQZBycTp1l53abEdmSsY1OnBiYMrW53UpJvZdXGLyEHzl4Ht3z/1Lv8T+OL66flnqacBfBVANZbg4LCjs8UtnQXeN86sdjv3eI5NjJwp523Evjkc0vqZDFm4RncdZsfZW2hVs/+NiItAyx/VzQQ8FIPmRXf1wzJDRH4LbMXaIUw4TB7MFHEfVoIoiDmViqL2iW75N8QmFdWPJSfFad3syyPA2JI2zZXLjiYKTPxvQ6qxH/5Jt+nna/ZEBZHIgBMl7r9a6a13J7i3Q4NNT6Rm4foCk8XPEKLj8zm3zS/jg== 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=UDFVJUJF3kmz2I1pqipMVwW1Sn8k47w6+4QxW3w4UAY=; b=FJ9w92Dg8KAYz4dzFBs2g0m81VZKj+SAVbyOih96gaBsmB2JvFyruS2CzOQMoooe4+YVpkKxC3YbxSfBeohUIMCGwX1FxQoBrNQO5/+86IyAH1QoK/uxgzu58w8YCEFqXN21jiojUf3L+civ2WJ7ZdD+2BKJ+MSD9+7kE3C20Vh1gC/TFhR2so5PliRq8kYsY9B7FuJ28BxcHNrJh50YL/WlPdzucj1m2IvQJHsDx6bS9plGSiWoV35lLrcCSpWvw9cbLMiLC7ujFrUjRjEqEvpqrlnAT42J5uZGxO6lt3mEhQ79u3pwtiXDEs4N8YrF/7//Hgx9qPTTfj0sP/tqrQ== 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=UDFVJUJF3kmz2I1pqipMVwW1Sn8k47w6+4QxW3w4UAY=; b=ma9bnogCWaP1YXuqoXul4tY1U4sRXTO6lsEer4AvJRkW1nL+7f8s0CW+72yDk/lRA/sgp3Vao7ZTVV+wi6Fo10HGFhHJt4txt0NHqEYtaH8vQQfTtlfhCruRe3s+13OVgJ8bCl7HTYVCj1/eXWegI9hwNfiSRn5T5JoewfzmMNw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <1fc7bde0-dbaa-4daf-b23f-a46b84219278@citrix.com> Date: Mon, 9 Mar 2026 22:25:55 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: [PATCH v4 12/14] x86/pv: System call handling in FRED mode To: Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-13-andrew.cooper3@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260227231636.3955109-13-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0663.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:316::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_|DM6PR03MB5258:EE_ X-MS-Office365-Filtering-Correlation-Id: e9127bd3-b7d4-4c26-9bf5-08de7e2ad6c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014; X-Microsoft-Antispam-Message-Info: 2ZtbtkEVCLQy11XllNguwevcCkKaqtdu9+4SH6vYKrJqOZDS30tvSiXcCmGNqVoiSZ4G6t/q6ZKgHfiE2kzdCi/RtWA8U+oj3mizMKlnOJvbNB0ILSL0AJbXuy5uTWPAgU68bB5/Vevy0WJ062DdZzsID6N3Y/psPLluek+3FislRqtLxBilbVg1Y84pS7hUyjVePd5friReVqV37WmUUi62izbeDk2SKNQYOUzJ91hC3ElehHRzFDQu4fRWnXzudhNK+wyjPig1+PFS2Rf7l/M51qJ2rjoEmIAzbe3sXoNOmSQNmcLqhcxft5bSGa2MeB31MgIfeE/T6nIHd/rMD2c0UtqLXfvENswUFpt2Wzs1H2EVMjssUtsZWpLceH/eL+wI5jx7EPNdVvk5DcaZCFh7SFefD6jE5DizyG4O6on61qpHVNpPS6USKoZsZUsdEbIypE7URJdZ94cCWLL6ISybc9dAhv5SZAeI6sRZnUidR28X/qwARe+sUxzPcSaefO5zYB7TL0ayvjeV0o+9oMrZgFI0CfcQpcDdyfvWAQ6pJJgLSuaEutCdnX+WxZJPOKZCbmT3tozNYhCoXvtCbJ+7KSjmkh8uW5eiGDnGbBH0lPKxfJiP/RAsnqjAEHnjDcGp7dOra6doR5j7qLDAQLsnZAIDDD+bgLrEo1dPf1DkvjZXlbu5Fg6nKjQV6Bzv5qK1aYWZ6nkD4yyQyonXw44gyhAKjQg+DO+O7PlJyp4= 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);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cm0wUjlVU3EydytnZGJOcWFTc1NYZHhqQXpOUmRpRlFIS3QwczhoWjBlSnNq?= =?utf-8?B?ZzRMdDZTNGdEQ0IrTmdXcVFLUDRGUHhUM3NpZXRxUkQ5aGVlSEl5eHNDWUwv?= =?utf-8?B?L0hCK1IrcFVrYzlBOWpEZmI5VWVteExTQ3BXbmptaS9INFFOZHMwRDY1LzdO?= =?utf-8?B?amNRSS9BbmFGbjFYTUpWQVdUdzFuSjV0ZTNYbkx4TTQwT3d1TlVGaTVna3I2?= =?utf-8?B?QXFrZXRHdTQydnBhSWkyMUN5eEtUN2NHR21WZzdaeWd5blBUemE5MWsyaGg4?= =?utf-8?B?N2oyVFNZQlU0OU1HOUI1OFI5a2VRUzVUK3QrUTFjcysrVXloMkxlVW9uMVpW?= =?utf-8?B?bzJzOVZmRFMyWHVmZ2VVRlBiV0VLV0drR0VSZzR5V2VQTkNncDF2TllGR3JT?= =?utf-8?B?UzdDMUVXT1RRMnBxTFIzNXpBWXphUzE4MVQ0Nm45MnJGemlkV3hVeXFkQ1ky?= =?utf-8?B?dVNEb1grSnBjSGlHMzNlWU9DZm5lSjB0dEM1ZlAyMjh3ak9ZeDJnQVlBVFk0?= =?utf-8?B?eUNwTXkwNm5TOHF6bWI3T1A3aGFWSFBrTWU2Wm5ZTHFPQ1lZZHJtVnV4SnMw?= =?utf-8?B?cGFrZXZ6SW9TSzI4cVk3dDBxUXIzUWN3RGg1L0d4V2VjZmtXUllDcGNaSTNX?= =?utf-8?B?NFl1aURFaTBWZzVlZE9HbWtjdjU2aUVGVmo5Y1psdkpKLzZOb2JrKzZSU2dy?= =?utf-8?B?VVlkVi9UMUdYQVNVUEdoRll1Wk9LNkNLK2RGU3lLV2l4RG0xUjNhOENVY0k4?= =?utf-8?B?VzRXQ09RNGc1Z0ZIZE96Wm5HbHVWRGxqeHFINm1iSGdUeTVsa3hrbE85Rkpx?= =?utf-8?B?bDM3Q2tDd2hVVlIrelJLeVRjaVZSSGZ6RGpDQkpiK3FSR1k0NVlTeVFtVzdp?= =?utf-8?B?MzhmenVJZEJCZllQY3dTaTVJQmYyNlI4R3RPeVNRenJ2NkNPdkpWZkk2TDBs?= =?utf-8?B?TVJuMGY1YytKTVoyc0pyaklabEV1NEUySlREN0haOURyT2JrRWR2eHgva1N3?= =?utf-8?B?em5wUVlFKytteTNxUzB6dm9SK3pXNG00YWNrVzRQOFpSL3ozRDNwTGJzakdx?= =?utf-8?B?YXk4NTVnOGlhSDcrKzhVa0JscGlkZk1rTThHR2NEZnh2TGw0SEorZGNJaGVm?= =?utf-8?B?ZVBkSmFHcnozcFU2MnliRzZLZGVhelAwSGJUaFRVMnFCNXJBK1FNWW4vaU1x?= =?utf-8?B?ckJCcXE3cUNXSjNUU05wOVMyZ040TFp3bnVRZ1l3eWk1UVRiUFFiZmxyWGVn?= =?utf-8?B?d05DclBxRFlLRHVXQ0FVSG9YSTZxL1MvYlJIeFJCSGh4Y1NtUDRhUnYvYy9q?= =?utf-8?B?a2xjb0J2WGx0ZDFRUG1GU2dHb1l3WEZlUUNUaVRhdUtaVTMwSFdkT2IyaUFm?= =?utf-8?B?UHYvbUNzZld2MFhLT2h0a2U0eHNzSjFwZWU4SndYYS9QbHYrTU5WZ3pTek51?= =?utf-8?B?dDk0QkpvYTlHUWNSZDUvTWZFUExBYlVGTTlFQjBoQ20yOWZRL0c0Y2ZzS3cr?= =?utf-8?B?UXd6L0ZLY2k0MlB4L1FEUXVTeWZpZGM4RzJsVDB1RkEvenA3bjNzT2g1YldO?= =?utf-8?B?SmtDcXA5VDRTbEZWWTVCVFFXZGd2dENtNFA0YXgyb3N4OW5BRFFRcTNuZSti?= =?utf-8?B?M3NOK2M2UU5CZzJ6QmtkOFdrNVd0SllGV2dUOEE3eVJPNzNUWm42U0tWNDRT?= =?utf-8?B?SjYzMnpXNnJmSjNBMDl4cjE4aG1MSm91c2RaSTl6QjZDblZ5MnRtSU5CSVJN?= =?utf-8?B?MzdTZU9FRG1KUG1wTTg3R3E0QkFyR2ZmcXFWMVM0MUZIcXJOM0FEQ0NqUkxk?= =?utf-8?B?ckM5N1pMN3Nud3JBWmVkMEJQZHlrNEtPSHdTWmtIMk5XSFh3L1RvTWhPenpu?= =?utf-8?B?eGF4QnJobHp3NnM1VGZlUFBEM3U2OUVlWUlqMVU1TjdIOU1rU0VRUG40RE5x?= =?utf-8?B?NnVxcHR2M0lMNTU3eW41MlFYaUh1VzRWQzh6QWdZVm9BZEs3WVhtSVh0UzUw?= =?utf-8?B?R1l5eWtObE54VHNqdGx3bHcvTit5WFBQWVdwOVN3NFpKdjhaY3JaeDFwQjB4?= =?utf-8?B?QUw5b3o3WmJVR1M4RzM4V2dhTUtFZ2Zmc3JMMmpkYzdyeVZHL2UwR0Z1cTRh?= =?utf-8?B?Z3JjUENyc2pOaW9RM0grK1JleFZva1FwdVlRTTdmMjZaQ2IzN1hxYUlDN2E1?= =?utf-8?B?YlN3dVg5WXUrWnpwWVFSRE1adTJOWFlyNkxpcnpjZWFpZ1Y2U2JBamdBcU5w?= =?utf-8?B?TEV4WGtZZnFKdyt6ZGVzNmtYUDQ2Ky9iQTRsUTdjcWRhNDloSTA2STc5TDVR?= =?utf-8?B?d05QZHdSaXRGTzFiZENocm1EM2hUcnZGQkc5eEpTbStGTk9Ua0J2dz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9127bd3-b7d4-4c26-9bf5-08de7e2ad6c7 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2026 22:25:59.1916 (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: hkWrz+GGiWo6b2+GlP6uVhRNytB9I3pM64wIMAD3wviMXMc60wewFItIMnEYpZ5SGKRV2jT5WBps1g4nmc27YkFD+iLJRYQ7K3SLdf/kSW0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB5258 On 27/02/2026 11:16 pm, Andrew Cooper wrote: > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c > index 2f40f628cbff..e2c35a046e6b 100644 > --- a/xen/arch/x86/traps.c > +++ b/xen/arch/x86/traps.c > ... > + case 2: /* SYSENTER */ > + { > + /* > + * FRED delivery preserves the interrupted state, but previously > + * SYSENTER discarded almost everything. > + * > + * The guest isn't aware of FRED, so recreate the legacy > + * behaviour. > + * > + * When setting the selectors, clear all upper metadata. In > + * particular fred_ss.swint becomes pend_DB on ERETx. > + * > + * When converting to a fault, hardware finally gives us enough > + * information to account for prefixes, so provide the more > + * correct behaviour rather than assuming the instruction was two > + * bytes long. > + */ > + unsigned int len = regs->fred_ss.insnlen; > + > + regs->ssx = FLAT_USER_SS; > + regs->rsp = 0; > + regs->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF); > + regs->csx = 3; > + regs->rip = 0; > + > + if ( !curr->arch.pv.sysenter_callback_eip ) > + { > + regs->rip -= len; > + pv_inject_hw_exception(X86_EXC_GP, 0); > + } > + else > + pv_inject_callback(CALLBACKTYPE_sysenter); > + break; This isn't actually a correct transformation of the IDT code.  When the SYENTER entrypoint isn't registered, this delivers a #GP at 0003:fffffffffffffffe The simple fix to get back to IDT behaviour is to simply drop the subtraction of len. In FRED mode, we can finally point the #GP at the SYSENTER instruction, rather than delivering at 0.  We could even provide the success case pointing sensibly too. The question is should we?  Until now, the differences between FRED and IDT mode are minimal.  This would be major difference, and it's for SYSENTER which all but unused.  I'm erring on the side of "match IDT". ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 10 05:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 05:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249789.1547200 (Exim 4.92) (envelope-from ) id 1vzq4C-0007EE-Kb; Tue, 10 Mar 2026 05:55:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249789.1547200; Tue, 10 Mar 2026 05:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzq4C-0007E7-Hp; Tue, 10 Mar 2026 05:55:40 +0000 Received: by outflank-mailman (input) for mailman id 1249789; Tue, 10 Mar 2026 03:21:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vznem-0006gN-Us for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 03:21:16 +0000 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2aab0753-1c30-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 04:21:07 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4fVJtY2xXbzmV8y; Tue, 10 Mar 2026 11:16:05 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id E197640565; Tue, 10 Mar 2026 11:21:00 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 10 Mar 2026 11:20:59 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2aab0753-1c30-11f1-9ccf-f158ae23cfc8 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=TT+M/HNYlJSQX27HOtuYm2otltrl3F+s0X9BiZbUIzc=; b=ixI1woUGB7ctC3EgDtiIAVXDQtMwKnAm6gqjEcu7Ioth6mixa7zzjeYU4cmcrR0mR18bNy8h5 5nViuN/Xfbli6I4fMQTda7HIJzjMdDsiCUSXnOVb/xk+/dR+/rXDufXhWuvtusN+MT0rkLw8hMj lKjtF9p/nZ4Uip8uiGMHUyY= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Chengwen Feng , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , Subject: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Date: Tue, 10 Mar 2026 11:20:49 +0800 Message-ID: <20260310032049.25387-3-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260310032049.25387-1-fengchengwen@huawei.com> References: <20260310032049.25387-1-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemk500009.china.huawei.com (7.202.194.94) pcie_tph_get_cpu_st() is broken on ARM64: 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. cpu_uid should be the ACPI Processor UID [1]. 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, generated and managed by kernel (e.g., [0,255] for a system with 256 logical CPU cores). 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the MADT table, and this UID may not match the kernel's logical CPU ID. When this occurs, the mismatch results in the wrong CPU steer-tag. 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID so the mismatch is not seen. Resolution: 1. Implement acpi_get_cpu_acpi_id() for x86, which replaces cpu_acpi_id(). All ACPI platforms now have an implementation. 2. Use acpi_get_cpu_acpi_id() in pcie_tph_get_cpu_st() to translate from logical CPU ID to ACPI Processor UID needed for the DSM call. 3. Rename pcie_tpu_get_cpu_st() parameter from cpu_uid to cpu to reflect that it is a logical CPU_ID. [1] According to ECN_TPH-ST_Revision_20200924 (https://members.pcisig.com/wg/PCI-SIG/document/15470), the input is defined as: "If the target is a processor, then this field represents the ACPI Processor UID of the processor as specified in the MADT. If the target is a processor container, then this field represents the ACPI Processor UID of the processor container as specified in the PPTT." Fixes: d2e8a34876ce ("PCI/TPH: Add Steering Tag support") Cc: stable@vger.kernel.org Signed-off-by: Chengwen Feng Reviewed-by: Jonathan Cameron --- Documentation/PCI/tph.rst | 4 ++-- arch/x86/include/asm/acpi.h | 2 ++ arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 1 - arch/x86/kernel/cpu/common.c | 12 ++++++++++++ arch/x86/xen/enlighten_hvm.c | 4 ++-- drivers/pci/tph.c | 11 ++++++----- include/linux/pci-tph.h | 4 ++-- 8 files changed, 26 insertions(+), 13 deletions(-) diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst index e8993be64fd6..b6cf22b9bd90 100644 --- a/Documentation/PCI/tph.rst +++ b/Documentation/PCI/tph.rst @@ -79,10 +79,10 @@ To retrieve a Steering Tag for a target memory associated with a specific CPU, use the following function:: int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type, - unsigned int cpu_uid, u16 *tag); + unsigned int cpu, u16 *tag); The `type` argument is used to specify the memory type, either volatile -or persistent, of the target memory. The `cpu_uid` argument specifies the +or persistent, of the target memory. The `cpu` argument specifies the CPU where the memory is associated to. After the ST value is retrieved, the device driver can use the following diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h index a03aa6f999d1..b968369715c1 100644 --- a/arch/x86/include/asm/acpi.h +++ b/arch/x86/include/asm/acpi.h @@ -157,6 +157,8 @@ static inline bool acpi_has_cpu_in_madt(void) return !!acpi_lapic; } +u32 acpi_get_cpu_acpi_id(unsigned int cpu); + #define ACPI_HAVE_ARCH_SET_ROOT_POINTER static __always_inline void acpi_arch_set_root_pointer(u64 addr) { diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h index ad235dda1ded..57a0786dfd75 100644 --- a/arch/x86/include/asm/cpu.h +++ b/arch/x86/include/asm/cpu.h @@ -11,7 +11,6 @@ #ifndef CONFIG_SMP #define cpu_physical_id(cpu) boot_cpu_physical_apicid -#define cpu_acpi_id(cpu) 0 #endif /* CONFIG_SMP */ #ifdef CONFIG_HOTPLUG_CPU diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 84951572ab81..05d1d479b4cf 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -130,7 +130,6 @@ __visible void smp_call_function_interrupt(struct pt_regs *regs); __visible void smp_call_function_single_interrupt(struct pt_regs *r); #define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu) -#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu) /* * This function is needed by all SMP systems. It must _always_ be valid diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 1c3261cae40c..93f4f3283c81 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -29,6 +29,7 @@ #include #include +#include #include #include #include @@ -57,6 +58,7 @@ #include #include #include +#include #include #include #include @@ -2643,3 +2645,13 @@ void __init arch_cpu_finalize_init(void) */ mem_encrypt_init(); } + +u32 acpi_get_cpu_acpi_id(unsigned int cpu) +{ +#ifndef CONFIG_SMP + return 0; +#else + return per_cpu(x86_cpu_to_acpiid, cpu); +#endif +} +EXPORT_SYMBOL_GPL(acpi_get_cpu_acpi_id); diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c index fe57ff85d004..0a5cde7865b2 100644 --- a/arch/x86/xen/enlighten_hvm.c +++ b/arch/x86/xen/enlighten_hvm.c @@ -161,8 +161,8 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu) */ xen_uninit_lock_cpu(cpu); - if (cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) - per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu); + if (acpi_get_cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) + per_cpu(xen_vcpu_id, cpu) = acpi_get_cpu_acpi_id(cpu); else per_cpu(xen_vcpu_id, cpu) = cpu; xen_vcpu_setup(cpu); diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c index ca4f97be7538..c1bd60637b5a 100644 --- a/drivers/pci/tph.c +++ b/drivers/pci/tph.c @@ -236,18 +236,19 @@ static int write_tag_to_st_table(struct pci_dev *pdev, int index, u16 tag) * with a specific CPU * @pdev: PCI device * @mem_type: target memory type (volatile or persistent RAM) - * @cpu_uid: associated CPU id + * @cpu: associated CPU id * @tag: Steering Tag to be returned * * Return the Steering Tag for a target memory that is associated with a - * specific CPU as indicated by cpu_uid. + * specific CPU as indicated by cpu. * * Return: 0 if success, otherwise negative value (-errno) */ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag) + unsigned int cpu, u16 *tag) { #ifdef CONFIG_ACPI + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); struct pci_dev *rp; acpi_handle rp_acpi_handle; union st_info info; @@ -265,9 +266,9 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, *tag = tph_extract_tag(mem_type, pdev->tph_req_type, &info); - pci_dbg(pdev, "get steering tag: mem_type=%s, cpu_uid=%d, tag=%#04x\n", + pci_dbg(pdev, "get steering tag: mem_type=%s, cpu=%d, tag=%#04x\n", (mem_type == TPH_MEM_TYPE_VM) ? "volatile" : "persistent", - cpu_uid, *tag); + cpu, *tag); return 0; #else diff --git a/include/linux/pci-tph.h b/include/linux/pci-tph.h index ba28140ce670..be68cd17f2f8 100644 --- a/include/linux/pci-tph.h +++ b/include/linux/pci-tph.h @@ -25,7 +25,7 @@ int pcie_tph_set_st_entry(struct pci_dev *pdev, unsigned int index, u16 tag); int pcie_tph_get_cpu_st(struct pci_dev *dev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag); + unsigned int cpu, u16 *tag); void pcie_disable_tph(struct pci_dev *pdev); int pcie_enable_tph(struct pci_dev *pdev, int mode); u16 pcie_tph_get_st_table_size(struct pci_dev *pdev); @@ -36,7 +36,7 @@ static inline int pcie_tph_set_st_entry(struct pci_dev *pdev, { return -EINVAL; } static inline int pcie_tph_get_cpu_st(struct pci_dev *dev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag) + unsigned int cpu, u16 *tag) { return -EINVAL; } static inline void pcie_disable_tph(struct pci_dev *pdev) { } static inline int pcie_enable_tph(struct pci_dev *pdev, int mode) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 05:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 05:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249785.1547183 (Exim 4.92) (envelope-from ) id 1vzq4B-0006o5-61; Tue, 10 Mar 2026 05:55:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249785.1547183; Tue, 10 Mar 2026 05:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzq4B-0006nw-1I; Tue, 10 Mar 2026 05:55:39 +0000 Received: by outflank-mailman (input) for mailman id 1249785; Tue, 10 Mar 2026 03:21:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzned-0006fN-4Z for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 03:21:07 +0000 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 29ab9a57-1c30-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 04:21:03 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4fVJsl23JTz12LCw; Tue, 10 Mar 2026 11:15:23 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 6E06320104; Tue, 10 Mar 2026 11:20:59 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 10 Mar 2026 11:20:57 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 29ab9a57-1c30-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=A0FMIWNr2Dx+OlfZSA1sGW6DfHKLq8qTyrKRNs7QJ7U=; b=Wcm0KY75ufjFNPJyc4zSdiHPUv18HrWLJez1cr9p/yPEHO6W6HDMoMpkYk8j28awyuVeBv3xd Jy3fYOyOLPQ1eo5HCwj2w3Z/yn9Vx8hUTFCorNL3HFqAMJeEV7VRD5qvGecAhYJA/D9L4lA0g07 Dk0fwR1m0uotQ11p7R5z7Yo= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Chengwen Feng , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , Subject: [PATCH v5 1/2] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 Date: Tue, 10 Mar 2026 11:20:48 +0800 Message-ID: <20260310032049.25387-2-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260310032049.25387-1-fengchengwen@huawei.com> References: <20260310032049.25387-1-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemk500009.china.huawei.com (7.202.194.94) To unify the CPU ACPI ID retrieval interface across architectures, rename the existing get_acpi_id_for_cpu() function to acpi_get_cpu_acpi_id() on arm64/riscv/loongarch platforms. This is a pure rename with no functional change, preparing for a consistent ACPI Processor UID retrieval interface across all ACPI-enabled platforms. Cc: stable@vger.kernel.org Signed-off-by: Chengwen Feng Reviewed-by: Jonathan Cameron --- arch/arm64/include/asm/acpi.h | 4 ++-- arch/loongarch/include/asm/acpi.h | 2 +- arch/riscv/include/asm/acpi.h | 2 +- arch/riscv/kernel/acpi_numa.c | 2 +- drivers/acpi/pptt.c | 16 ++++++++-------- drivers/acpi/riscv/rhct.c | 2 +- drivers/perf/arm_cspmu/arm_cspmu.c | 2 +- 7 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index c07a58b96329..202107aeb05b 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -114,7 +114,7 @@ static inline bool acpi_has_cpu_in_madt(void) } struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu); -static inline u32 get_acpi_id_for_cpu(unsigned int cpu) +static inline u32 acpi_get_cpu_acpi_id(unsigned int cpu) { return acpi_cpu_get_madt_gicc(cpu)->uid; } @@ -125,7 +125,7 @@ static inline int get_cpu_for_acpi_id(u32 uid) for (cpu = 0; cpu < nr_cpu_ids; cpu++) if (acpi_cpu_get_madt_gicc(cpu) && - uid == get_acpi_id_for_cpu(cpu)) + uid == acpi_get_cpu_acpi_id(cpu)) return cpu; return -EINVAL; diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h index 7376840fa9f7..89c6c8f52cc3 100644 --- a/arch/loongarch/include/asm/acpi.h +++ b/arch/loongarch/include/asm/acpi.h @@ -40,7 +40,7 @@ extern struct acpi_madt_core_pic acpi_core_pic[MAX_CORE_PIC]; extern int __init parse_acpi_topology(void); -static inline u32 get_acpi_id_for_cpu(unsigned int cpu) +static inline u32 acpi_get_cpu_acpi_id(unsigned int cpu) { return acpi_core_pic[cpu_logical_map(cpu)].processor_id; } diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h index 6e13695120bc..1d23681b61b5 100644 --- a/arch/riscv/include/asm/acpi.h +++ b/arch/riscv/include/asm/acpi.h @@ -61,7 +61,7 @@ static inline void arch_fix_phys_package_id(int num, u32 slot) { } void acpi_init_rintc_map(void); struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu); -static inline u32 get_acpi_id_for_cpu(int cpu) +static inline u32 acpi_get_cpu_acpi_id(int cpu) { return acpi_cpu_get_madt_rintc(cpu)->uid; } diff --git a/arch/riscv/kernel/acpi_numa.c b/arch/riscv/kernel/acpi_numa.c index 130769e3a99c..c2eb4824d0f7 100644 --- a/arch/riscv/kernel/acpi_numa.c +++ b/arch/riscv/kernel/acpi_numa.c @@ -40,7 +40,7 @@ static inline int get_cpu_for_acpi_id(u32 uid) int cpu; for (cpu = 0; cpu < nr_cpu_ids; cpu++) - if (uid == get_acpi_id_for_cpu(cpu)) + if (uid == acpi_get_cpu_acpi_id(cpu)) return cpu; return -EINVAL; diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index de5f8c018333..c1a8fba4c2b2 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -459,7 +459,7 @@ static void cache_setup_acpi_cpu(struct acpi_table_header *table, { struct acpi_pptt_cache *found_cache; struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu); - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); struct cacheinfo *this_leaf; unsigned int index = 0; struct acpi_pptt_processor *cpu_node = NULL; @@ -546,7 +546,7 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table, unsigned int cpu, int level, int flag) { struct acpi_pptt_processor *cpu_node; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (cpu_node) { @@ -622,7 +622,7 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag) { struct acpi_table_header *table; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); struct acpi_pptt_processor *cpu_node = NULL; int ret = -ENOENT; @@ -671,7 +671,7 @@ int acpi_get_cache_info(unsigned int cpu, unsigned int *levels, pr_debug("Cache Setup: find cache levels for CPU=%d\n", cpu); - acpi_cpu_id = get_acpi_id_for_cpu(cpu); + acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node) return -ENOENT; @@ -797,7 +797,7 @@ int find_acpi_cpu_topology_cluster(unsigned int cpu) if (!table) return -ENOENT; - acpi_cpu_id = get_acpi_id_for_cpu(cpu); + acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node || !cpu_node->parent) return -ENOENT; @@ -872,7 +872,7 @@ static void acpi_pptt_get_child_cpus(struct acpi_table_header *table_hdr, cpumask_clear(cpus); for_each_possible_cpu(cpu) { - acpi_id = get_acpi_id_for_cpu(cpu); + acpi_id = acpi_get_cpu_acpi_id(cpu); cpu_node = acpi_find_processor_node(table_hdr, acpi_id); while (cpu_node) { @@ -966,7 +966,7 @@ int find_acpi_cache_level_from_id(u32 cache_id) for_each_possible_cpu(cpu) { bool empty; int level = 1; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); struct acpi_pptt_cache *cache; struct acpi_pptt_processor *cpu_node; @@ -1030,7 +1030,7 @@ int acpi_pptt_get_cpumask_from_cache_id(u32 cache_id, cpumask_t *cpus) for_each_possible_cpu(cpu) { bool empty; int level = 1; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); struct acpi_pptt_cache *cache; struct acpi_pptt_processor *cpu_node; diff --git a/drivers/acpi/riscv/rhct.c b/drivers/acpi/riscv/rhct.c index caa2c16e1697..c15ce8c13136 100644 --- a/drivers/acpi/riscv/rhct.c +++ b/drivers/acpi/riscv/rhct.c @@ -44,7 +44,7 @@ int acpi_get_riscv_isa(struct acpi_table_header *table, unsigned int cpu, const struct acpi_rhct_isa_string *isa_node; struct acpi_table_rhct *rhct; u32 *hart_info_node_offset; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id = acpi_get_cpu_acpi_id(cpu); BUG_ON(acpi_disabled); diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index 34430b68f602..506b661c60fd 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1115,7 +1115,7 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu) if (affinity_flag == ACPI_APMT_FLAGS_AFFINITY_PROC) { for_each_possible_cpu(cpu) { if (apmt_node->proc_affinity == - get_acpi_id_for_cpu(cpu)) { + acpi_get_cpu_acpi_id(cpu)) { cpumask_set_cpu(cpu, &cspmu->associated_cpus); break; } -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 05:55:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 05:55:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249787.1547186 (Exim 4.92) (envelope-from ) id 1vzq4B-0006qB-CH; Tue, 10 Mar 2026 05:55:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249787.1547186; Tue, 10 Mar 2026 05:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzq4B-0006op-7f; Tue, 10 Mar 2026 05:55:39 +0000 Received: by outflank-mailman (input) for mailman id 1249787; Tue, 10 Mar 2026 03:21:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vznei-0006fN-5q for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 03:21:12 +0000 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 295cd73b-1c30-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 04:21:03 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4fVJtT143zz1prR7; Tue, 10 Mar 2026 11:16:01 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 00BA9404AD; Tue, 10 Mar 2026 11:20:58 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 10 Mar 2026 11:20:56 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 295cd73b-1c30-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=CoRpNTmhms6uOa5K4ZBNB1qadS4KRwgybZKo09j4UpA=; b=fxjB361v9DDU1Vc+vLq2UHX6kf3YaHF64h4a8BYjj4aAMs12yChq1Z0Yq6LWSEtvySPL+BtAo SmhO/UwvL3+krDUwG6Ey2Y4dTPD6DcU6QbkOWDYEtWJMfpBjNaajoNIgGcRf4UfrVM1Nvz67TAV 1UXfCWkUyhSSX4AnepSv81U= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Chengwen Feng , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , Subject: [PATCH v5 0/2] Fix get cpu steer-tag fail on ARM64 platform Date: Tue, 10 Mar 2026 11:20:47 +0800 Message-ID: <20260310032049.25387-1-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemk500009.china.huawei.com (7.202.194.94) This patchset addresses the issue where retrieving the CPU steer-tag fails on ARM64 platforms. The first commit is a pure renaming of the ACPI CPU ID retrieval interface (no functional changes), which serves as preparation for the second commit that implements the core fix for the steer-tag retrieval logic. --- Changes in v5: - Refine commit-log of commit 2/2 - Replace cpu_acpi_id() by acpi_get_cpu_acpi_id() on x86 Changes in v4: - Split the rename into a separate commit. Changes in v3: - Rename existing get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() other than add one new API. Changes in v2: - Add ECN _DSM reference doc name and its URL. - Separate implement acpi_get_cpu_acpi_id() in each arch which supports ACPI. - Refine commit-log. Chengwen Feng (2): ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Documentation/PCI/tph.rst | 4 ++-- arch/arm64/include/asm/acpi.h | 4 ++-- arch/loongarch/include/asm/acpi.h | 2 +- arch/riscv/include/asm/acpi.h | 2 +- arch/riscv/kernel/acpi_numa.c | 2 +- arch/x86/include/asm/acpi.h | 2 ++ arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 1 - arch/x86/kernel/cpu/common.c | 12 ++++++++++++ arch/x86/xen/enlighten_hvm.c | 4 ++-- drivers/acpi/pptt.c | 16 ++++++++-------- drivers/acpi/riscv/rhct.c | 2 +- drivers/pci/tph.c | 11 ++++++----- drivers/perf/arm_cspmu/arm_cspmu.c | 2 +- include/linux/pci-tph.h | 4 ++-- 15 files changed, 41 insertions(+), 28 deletions(-) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 07:16:45 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 07:16:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249820.1547209 (Exim 4.92) (envelope-from ) id 1vzrKM-0000uc-8y; Tue, 10 Mar 2026 07:16:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249820.1547209; Tue, 10 Mar 2026 07:16:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzrKM-0000uV-63; Tue, 10 Mar 2026 07:16:26 +0000 Received: by outflank-mailman (input) for mailman id 1249820; Tue, 10 Mar 2026 07:16:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzrKK-0000uP-Ck for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 07:16:24 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0a6e16b8-1c51-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 08:16:22 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4852ff06541so27869155e9.2 for ; Tue, 10 Mar 2026 00:16: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-485245dbcffsm112559375e9.18.2026.03.10.00.16.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 00:16:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a6e16b8-1c51-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773126981; x=1773731781; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=uV76+llFq4AaGCDzTuZZ/2XFlOJWtZBta/pWcVVXHBc=; b=Y0DIMsAKBXX2he6xnQvQhqxcYgZjBN7352cCGyLH1GnNEUsHRhZoyuUM41k/5NGCnN GM2N5vnMOhkHnsqNcmwKoV39IaAsJGfaErlcL5GBf7IpT0DQNp2lSpVyCVSFkrLyQ9+Z KrIs1GkIUa2GLMQPl3qQ08tFgPC1xExd1HsVlbAmP16Ae6sL8IiF4iZ+51GOj7kbK+L7 zo1EAZycffNwRMOAXshelSJqqEjD33hB1l/LJkXJWQtPmGuiCYwxS2bUbNKHWrYdsq7i 1TNXdUW3tDd6V+/NiNDFxUKE+bOov2YrTWYk/7GcEo1qoxUrlFdMI0yevv1ibNYsQeN5 Z61A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773126981; x=1773731781; h=content-transfer-encoding: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; bh=uV76+llFq4AaGCDzTuZZ/2XFlOJWtZBta/pWcVVXHBc=; b=UBsxIPb0u2mva6DTwu5vSawuo1aSuxx+yPytuRu1i8+pClu2gqGsjMnrPvQiAeItLu EVsug2yL7LZb3zb3brMdqtTo35xmAjN0NwXtdM85D1JVTuEY//kaCTOtZ/r1F1N2oev/ BjlM6hrRqRhGIimv7EFTt3Fm679gfKcVlracST1oKl7EyLVtk5poslCzDINMZBLBxoUE QxUUgKnGQCUw0lYIdNVHlA+cF6p/r3IbxkjofdhPqnXZKSNHfDTQO84IVGj5kiHQ9KIW kC39rydQgg8CkUFXFi0YwzilSyCUA0uMJA+aY36+U2x9D5Qke7RgSjatfPQxTusvtYWD F/OQ== X-Forwarded-Encrypted: i=1; AJvYcCVU02Xy1iCIbaoI6g8dKjepJQKJPI+rUDY1Duwri/EkLIZGk5xhnOjd/4rv0Hkx53EHld8t6E9s7fQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHDztYrWEAgpeISVzxMGfrEydL8alz9Hgw6pmZO47rxNPDed08 zHprSPCQUp6yDag/UfEgtAhaPu4vC/Nv1uVUJLOztLID8xKaOr4XX0ZQxVb+QyYYig== X-Gm-Gg: ATEYQzzSSoSWPFF03DOmlC+NXwS82V41St39vw61ZK+Lu2K0sdIX1mYsHSazaWdds5a 9Q2puMHZCjVuN+uSIRAbDETrkopfBGlX6MfxnG7mylxQatF1rbZ9fIjiZNrkUYYLEWUJ9gucs4z VAo5iLcJ9IDBH7CBxikFCQ6g22a94CFyg/ctarVpGpmEPR+7bwfzy1+sHaXeg5WKFi3igBTqzlE fSlENoO8Mowoq95HSIuElihryv75tLi6UeGdrb44sduElrB2QXl3B7hCZ7JCTZC7I7tFvrI2EwF 13rlAkB0qaUwzN6h89j8JaFH7AiZrDOSMSJjtXZnmhQ47xKPBq/R+oqCD6UllKUug4O5HDq//yX U3/P+yaUowyEAnb+Oo/GomPgOjMatZv8v5GWB7OVChdyZT+FckrA7XQ+8gFTfm+XFhMrglbOmU4 4DcU8vUejjp4IZGnIXvMEA03a7N/TeyfQLQp7G8emGWghO9rvm44tXk3m4hgCG4hDGAuT3K7h6v Ge02MH0HNI+9iI= X-Received: by 2002:a05:600c:a41:b0:483:c35d:367f with SMTP id 5b1f17b1804b1-48526957c15mr223332805e9.21.1773126981243; Tue, 10 Mar 2026 00:16:21 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 08:16:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 12/14] x86/pv: System call handling in FRED mode To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-1-andrew.cooper3@citrix.com> <20260227231636.3955109-13-andrew.cooper3@citrix.com> <1fc7bde0-dbaa-4daf-b23f-a46b84219278@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <1fc7bde0-dbaa-4daf-b23f-a46b84219278@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.03.2026 23:25, Andrew Cooper wrote: > On 27/02/2026 11:16 pm, Andrew Cooper wrote: >> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c >> index 2f40f628cbff..e2c35a046e6b 100644 >> --- a/xen/arch/x86/traps.c >> +++ b/xen/arch/x86/traps.c >> ... >> + case 2: /* SYSENTER */ >> + { >> + /* >> + * FRED delivery preserves the interrupted state, but previously >> + * SYSENTER discarded almost everything. >> + * >> + * The guest isn't aware of FRED, so recreate the legacy >> + * behaviour. >> + * >> + * When setting the selectors, clear all upper metadata. In >> + * particular fred_ss.swint becomes pend_DB on ERETx. >> + * >> + * When converting to a fault, hardware finally gives us enough >> + * information to account for prefixes, so provide the more >> + * correct behaviour rather than assuming the instruction was two >> + * bytes long. >> + */ >> + unsigned int len = regs->fred_ss.insnlen; >> + >> + regs->ssx = FLAT_USER_SS; >> + regs->rsp = 0; >> + regs->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF); >> + regs->csx = 3; >> + regs->rip = 0; >> + >> + if ( !curr->arch.pv.sysenter_callback_eip ) >> + { >> + regs->rip -= len; >> + pv_inject_hw_exception(X86_EXC_GP, 0); >> + } >> + else >> + pv_inject_callback(CALLBACKTYPE_sysenter); >> + break; > > This isn't actually a correct transformation of the IDT code.  When the > SYENTER entrypoint isn't registered, this delivers a #GP at > 0003:fffffffffffffffe > > The simple fix to get back to IDT behaviour is to simply drop the > subtraction of len. > > In FRED mode, we can finally point the #GP at the SYSENTER instruction, > rather than delivering at 0.  We could even provide the success case > pointing sensibly too. > > The question is should we?  Until now, the differences between FRED and > IDT mode are minimal.  This would be major difference, and it's for > SYSENTER which all but unused.  I'm erring on the side of "match IDT". I agree. Down the road we could introduce an opt-in "better behavior" mode when running under FRED (also covering other aspects previously discussed). Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 08:08:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 08:08:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249837.1547218 (Exim 4.92) (envelope-from ) id 1vzs8e-0007X3-2l; Tue, 10 Mar 2026 08:08:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249837.1547218; Tue, 10 Mar 2026 08: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 ) id 1vzs8d-0007Ww-Vy; Tue, 10 Mar 2026 08:08:23 +0000 Received: by outflank-mailman (input) for mailman id 1249837; Tue, 10 Mar 2026 08:08:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzs8c-0007Wo-VS for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 08:08:22 +0000 Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 48d4b70a-1c58-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 09:08:17 +0100 (CET) Received: from localhost.localdomain (unknown [210.73.43.101]) by APP-03 (Coremail) with SMTP id rQCowAD3E9to0a9pDDQ7Cg--.45464S2; Tue, 10 Mar 2026 16:08:09 +0800 (CST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 48d4b70a-1c58-11f1-b164-2bf370ae4941 From: Pengpeng Hou To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Pengpeng Hou Subject: [PATCH v2] xen/grant-table: guard gnttab_suspend/resume with CONFIG_HIBERNATE_CALLBACKS Date: Tue, 10 Mar 2026 08:08:00 +0000 Message-Id: <20260310080800.742223-1-pengpeng.hou@isrc.iscas.ac.cn> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:rQCowAD3E9to0a9pDDQ7Cg--.45464S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr15ZFWDtrW5uFyfXw4Utwb_yoW8tF4xpF Z8JrWqyr95Ja4SyFWaya9YkFy5ua93J3yxGr4Y9rZxZan7Gr17ArWSqFyjvr1kWrW8Jr4v vF4qgrW3Cr4UuaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvv14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r 4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCY1x0262kKe7AKxVWU AVWUtwCY02Avz4vE14v_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr 1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE 14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7 IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E 87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73Uj IFyTuYvjfUjkucDUUUU X-Originating-IP: [210.73.43.101] X-CM-SenderInfo: pshqw1hhqjhx1rx6x21ufox2xfdvhtffof0/ In current linux.git, gnttab_suspend() and gnttab_resume() are defined and declared unconditionally. However, their only in-tree callers reside in drivers/xen/manage.c, which are guarded by CONFIG_HIBERNATE_CALLBACKS. Match the helper scope to their callers by wrapping the definitions in CONFIG_HIBERNATE_CALLBACKS and providing no-op stubs in the header. This fixes the config-scope mismatch and reduces the code footprint when hibernation callbacks are disabled. Signed-off-by: Pengpeng Hou --- Hi Juergen, Thank you for the feedback. I apologize for the non-standard patch format in the previous version. As requested, I have regenerated this patch using `git format-patch` to ensure proper hunk headers and context line numbers are included. Changes in v2: - Re-generated with proper git formatting (line numbers and context). - No functional changes from v1. drivers/xen/grant-table.c | 3 ++- include/xen/grant_table.h | 12 ++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 97e27f754d396..a6abf1ccd54ce 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -1579,7 +1579,7 @@ static int gnttab_setup(void) } return gnttab_map(0, nr_grant_frames - 1); } - +#ifdef CONFIG_HIBERNATE_CALLBACKS int gnttab_resume(void) { gnttab_request_version(); @@ -1592,6 +1592,7 @@ int gnttab_suspend(void) gnttab_interface->unmap_frames(); return 0; } +#endif static int gnttab_expand(unsigned int req_entries) { diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index 69ac6d80a006b..a33a60a2ea72d 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -84,8 +84,20 @@ struct gntab_unmap_queue_data }; int gnttab_init(void); +#ifdef CONFIG_HIBERNATE_CALLBACKS int gnttab_suspend(void); int gnttab_resume(void); +#else +static inline int gnttab_suspend(void) +{ + return 0; +} + +static inline int gnttab_resume(void) +{ + return 0; +} +#endif int gnttab_grant_foreign_access(domid_t domid, unsigned long frame, int readonly); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 08:11:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 08:11:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249850.1547229 (Exim 4.92) (envelope-from ) id 1vzsBx-0000gJ-J4; Tue, 10 Mar 2026 08:11:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249850.1547229; Tue, 10 Mar 2026 08:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzsBx-0000gC-FI; Tue, 10 Mar 2026 08:11:49 +0000 Received: by outflank-mailman (input) for mailman id 1249850; Tue, 10 Mar 2026 08:11:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzsBw-0000fn-Rr for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 08:11:48 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c84a2640-1c58-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 09:11:47 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-482f454be5bso126083895e9.0 for ; Tue, 10 Mar 2026 01:11: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-48541b6f708sm74400015e9.11.2026.03.10.01.11.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 01:11:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c84a2640-1c58-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773130306; x=1773735106; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=bYPN/tGDDB2gNXEumQ56ibMZof+RWYgUy2Nmn53+I3Y=; b=JY3zyUpPT/i6XUnjvkKfp4VbzxnW+lJdJX3sDPEcxOo4KlaGQzqN2GIlkihyO8bGXo SyLgUmPCGA0JQGnGOKkemUfZVNNBNdu3aMj5kVPzzPG6DzW12yzgdwhTuOVZUMggeFeS Biw0Xlgkc6sSvqhylVC93t8gYp9BtKLRnr4jFA1UHPC10c/YdPuEuEQ1P6QJ9FGm7Lzb G6hbfOlyEuc8QvY8YjmlF7QYj3Ek4j6LDQp2BCsgjgH49mlba7O6darV7R+AfgWlLQqy jjqtZMZOwDtJfTBey/Iic7dyqTDddFN7NlOPg6BWFh6e3TgT/ipHacF26sVQn5mbMd10 n+sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773130306; x=1773735106; h=content-transfer-encoding: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; bh=bYPN/tGDDB2gNXEumQ56ibMZof+RWYgUy2Nmn53+I3Y=; b=HfcyesLBKJEizqCebhjNM0SXddv9QZjrfCZDE9LKdYVGeTZFjPvYYxURskBgQ8e1bZ VbOw994RzmsdvrkBq6LWXtdKO4omoSmXoDVFwf+kha8hE2MDm5zYI3wmRC25f53P+Qfc BRJM29vvRfuHmIfqKw7q0RkongABAbD393CL5oujkU/9sXv5Hry5SnCowm0JxKKjTTLu tYJY/9OkZTxBz8JZoZcIXmf9hOwfFH8lp0+Xbbhf9zDJulsoXMGYadHtIdEIECKxFndb 5urqF/CX3OAaj47TLMVSin6TGj9S6r3/LmRioGC+TLI9iAONSbr64ApyOKmynxbKYgF1 umyg== X-Forwarded-Encrypted: i=1; AJvYcCUc7ebjQOVUMlmbijtaC6buuipJD+12EqjN38CahVS4I4R2swDBv86feg1iJ83zSLF6NxfGq+3b1yU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxZUxtIh9bR1DqsRws0z3H0efKSFzyifHRCwUYXz+KtQzEEnmwt oR1BZXOi6/kXyYxSx/GItMWb4EfBUYLWAfYK20U2mPqyxMaLlJ2OqPf9xMcOZE343w== X-Gm-Gg: ATEYQzxC3/sezy1HONkoAfj4ntJ4S/QQJgxAOt16ePSBoFuvAqNVfpPJ/SIG4az7U2U KJuIkNPTpDyMhRmXCxSNaeYEqtWaDyAf6qzDSqb1OXCNaEcu4p5wpc9DTJyUUdr2LtGMZLUrccE GQeQwe/PeyduaocRY1eGIB0/jk4lqE7t+0uS+7fcmlGDOFDjfDP0trRFWMJUNGeI/wUXQfX0ip/ 60ps2q1mds/In8AsYX9d5SvQOYsWpTmsgBEedi2lbSC0REygrZROKpefQZyE3E7JKC/7nZKRw+l Yt+yLhhh3py0b2zw9/oDArajtvGD1Tl2kDpTgUJAh8ki0MYL5HPt9B+ptJ9BbMBLr/iG3qVZEVe lzLO7O6FPxQJRbieTRacPd5WtQIuBZhAfePWtADfEkruMN/NQWwvPTztrabQAznulx4Q8MeXAA7 Mr/SyKmEbnwXWowfZsSNFvdF4Bj+77hG01UpZ7TcM97OVEZ+Vas+YhmI0+zw/2C4NzoMr45Y3UG J2KygwSWtKCL2M= X-Received: by 2002:a05:600c:1d89:b0:485:3c2e:60d5 with SMTP id 5b1f17b1804b1-485419a2774mr35770765e9.2.1773130306204; Tue, 10 Mar 2026 01:11:46 -0700 (PDT) Message-ID: <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@suse.com> Date: Tue, 10 Mar 2026 09:11:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2026 17:33, Oleksii Kurochko wrote: > Some hypervisor CSRs expose optional functionality and may not implement > all architectural bits. Writing unsupported bits can either be ignored > or raise an exception depending on the platform. > > Detect the set of writable bits for selected hypervisor CSRs at boot and > store the resulting masks for later use. This allows safely programming > these CSRs during vCPU context switching and avoids relying on hardcoded > architectural assumptions. > > Use csr_read()&csr_write() instead of csr_swap()+all ones mask as some > CSR registers have WPRI fields which should be preserved during write > operation. > > Also, ro_one struct is introduced to cover the cases when a bit in CSR > register (at the momemnt, it is only hstateen0) may be r/o-one to have > hypervisor view of register seen by guest correct. > > Masks are calculated at the moment only for hedeleg, henvcfg, hideleg, > hstateen0 registers as only them are going to be used in the follow up > patch. > > If the Smstateen extension is not implemented, hstateen0 cannot be read > because the register is considered non-existent. Instructions that attempt > to access a CSR that is not implemented or not visible in the current mode > are reserved and will raise an illegal-instruction exception. > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich I'll commit as-is, yet still a couple of remarks: > --- > Changes in V7: > - Use csr_read_set() in INIT_CSR_MASK() instead of csr_read()+csr_write(). > - Add undef of INIT_CSR_MASK(). > - Move local variable old above INIT_CSR_MASK(). This contradicts ... > - Introduce INIT_RO_ONE_MASK() to init csr_masks.ro_one.* fields. > - Introduce defines for masks intead of constants. > - Move old variable inside macros INIT_CSR_MASK() and INIT_RO_ONE_MASK(). ... this. You may want to prune revlog entries when making incremental changes within one revision. > --- a/xen/arch/riscv/domain.c > +++ b/xen/arch/riscv/domain.c > @@ -2,9 +2,66 @@ > > #include > #include > +#include > #include > #include > > +#include > +#include > + > +struct csr_masks { > + register_t hedeleg; > + register_t henvcfg; > + register_t hideleg; > + register_t hstateen0; > + > + struct { > + register_t hstateen0; > + } ro_one; > +}; > + > +static struct csr_masks __ro_after_init csr_masks; > + > +#define HEDELEG_AVAIL_MASK ULONG_MAX > +#define HIDELEG_AVAIL_MASK ULONG_MAX > +#define HENVCFG_AVAIL_MASK _UL(0xE0000003000000FF) > +#define HSTATEEN0_AVAIL_MASK _UL(0xDE00000000000007) It's not quite clear to me what AVAIL in here is to signal. It's also not quite clear to me why you would use _UL() in #define-s sitting in a C file (and hence not possibly being used in assembly code; even for asm() I'd expect constants to be properly passed in as C operands). > +void __init init_csr_masks(void) > +{ > + /* > + * The mask specifies the bits that may be safely modified without > + * causing side effects. > + * > + * For example, registers such as henvcfg or hstateen0 contain WPRI > + * fields that must be preserved. Any write to the full register must > + * therefore retain the original values of those fields. > + */ > +#define INIT_CSR_MASK(csr, field, mask) do { \ > + register_t old = csr_read_set(CSR_##csr, mask); \ > + csr_masks.field = csr_swap(CSR_##csr, old); \ > + } while (0) > + > +#define INIT_RO_ONE_MASK(csr, field, mask) do { \ > + register_t old = csr_read_clear(CSR_HSTATEEN0, mask); \ > + csr_masks.ro_one.field = csr_swap(CSR_##csr, old) & mask; \ > + } while (0) > + > + INIT_CSR_MASK(HEDELEG, hedeleg, HEDELEG_AVAIL_MASK); > + INIT_CSR_MASK(HIDELEG, hideleg, HIDELEG_AVAIL_MASK); > + > + INIT_CSR_MASK(HENVCFG, henvcfg, HENVCFG_AVAIL_MASK); > + > + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) > + { > + INIT_CSR_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); > + INIT_RO_ONE_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); > + } The 3rd macro parameters are now redundant. At the example of INIT_CSR_MASK(), you could now have #define INIT_CSR_MASK(csr, field) do { \ register_t old = csr_read_set(CSR_ ## csr, csr ## _AVAIL_MASK); \ csr_masks.field = csr_swap(CSR_ ## csr, old); \ } while (0) This would reduce the risk of incomplete editing after copy-and-paste, or other typo-ing. Note also that ## being a binary operator, ./CODING_STYLE wants us to put blanks around it just like for non-pre-processor binary operators. I'll try to remember to make that adjustment when committing. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 08:13:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 08:13:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249858.1547236 (Exim 4.92) (envelope-from ) id 1vzsDL-0001AO-Rd; Tue, 10 Mar 2026 08:13:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249858.1547236; Tue, 10 Mar 2026 08: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 ) id 1vzsDL-0001AH-Oo; Tue, 10 Mar 2026 08:13:15 +0000 Received: by outflank-mailman (input) for mailman id 1249858; Tue, 10 Mar 2026 08:13:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzsDK-0001AB-52 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 08:13:14 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fb19602a-1c58-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 09:13:12 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so18509495e9.2 for ; Tue, 10 Mar 2026 01:13: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 5b1f17b1804b1-48536b5b3absm59710785e9.32.2026.03.10.01.13.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 01:13:11 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fb19602a-1c58-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773130391; x=1773735191; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=6b7G87Vo157IaGbJCatI+989xIlbUVkO1fK/stTSOIA=; b=BNL7HLb2TGQS3fWjfvZq3/XttHJGyo+FIjjAxsP4kRL02NKDWV0mDMDBh5hvXn4UYx alXJ/44X2HVTvUGK6JxukECSKSE8xXwTVjYNi8y6qiJzzFqWgQzqiWJr7UMF+njbLfLa mqtTTz+Qg4iebkn6MYPoasc8qqcozIu+G0+2qlFdLlhHCy7mtNU9bzoieSHXRuzEh31O nYHdhUxaybumuuEEH2wSbLDJl/pdoEtkl7oR8iOhBFATMzn/Pw/XJnW5jeOwsNDpZOWs H1Y+VvVsHzoztFtkK7dMD9ilM4mTBjxExSPNSyjvDCHQqiMNY2BGJtckELocwPUoQjx1 eJfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773130391; x=1773735191; h=content-transfer-encoding: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; bh=6b7G87Vo157IaGbJCatI+989xIlbUVkO1fK/stTSOIA=; b=pUSI+Ud45RlsXLfxDQPGQ6fYSLSz6IH7o2HIBSbb/KXkRdbL1qV7ynUnNzKAtqCEBE bp/p68SDi2BQ8zj+6Ki11hVu+NO41X007lpOM8TctVMNLfOJ1NxID8WA1bLf/bUu6fWD oGATCzvbYjwUxxeXtlJmrDL0nziDtatRXGb7+UlzZTAjtKINH8TtPg+b9d6LNWkji/rk DZ3kp8djD8YaxDd9pP9RLUdvl01WYJ1lBttyjzlOarjkN60PrA1bMzRjBiMjxjR8McDi QAgpM6c/sKvJqYFAPqAE1bdur8NQBIGctZnN5DiCFhpkx4FospbJBeM5MPAUwI6YCR95 ubtw== X-Forwarded-Encrypted: i=1; AJvYcCUYsnXhbra5PgQhdj+lE3f0564L1Ik18n3fh/Ykm4j2MxB86UoQobchOHA+j68j1j55IW19I+2BqJ0=@lists.xenproject.org X-Gm-Message-State: AOJu0YxIESGy4pEHVtmOZFOo4lboJ0T/SuiXFe6DcaYyZHLYgJ5TETXa QBQo5JpIxOLbrNyvqyydatzNxGd2MUt1VsSlJZ8KMYs45vorAasuf7MgYZ67WsFBWw== X-Gm-Gg: ATEYQzxyNsS9b9kM4OO+E3Gaa3T8dUrfDocJZAsLrOWBYWGUnisXwtFAv+XprJ1TFyX iRS05GheGfEmX+AiEh0DS9Lr8+USaHFNyGUnSFUSPDF2xpeA2vmzPp0cN73rTzwvrq8YuJK82E8 YF+Ox9qV2mrlsuS71L3nVzgZVo/OkJAt/eX6RKDGK/1zU4oHPYFC3a3+N0AQJOgbnRnEqNRDSxc 5fpnDoeGcP/uU/5cmK9mIH9mADRIgLofRSqanBJrBae2j0bJYuL22fQ756cKz8+kyWc9uKfYU0Z NcPUS41DCt/18x1EGIPZATgayMdQcHzqOfFXhckptNeyYLPjMAU6tbQoZYqIuWbP0MKV7JUMR5n mINdesFn+SkfXsxfddc28Jo3D5pou17ve1fIKLNBH1IbX0NvX0y53LHBgZnHYDpNguVmWao/Sj0 IUGqgLUuIe0Eg8JSWZTdDQBveErd1Y0UEhttABDBCHs1ah3wKvdlUZd9DGRo1LLG/jb/t6btlL0 bF6GRRvNDqyZ/oASKSq7wULag== X-Received: by 2002:a05:600c:811a:b0:485:4535:73d with SMTP id 5b1f17b1804b1-4854535091fmr11150265e9.2.1773130391408; Tue, 10 Mar 2026 01:13:11 -0700 (PDT) Message-ID: <794ecd76-29f3-464e-889b-b3800fda9cd9@suse.com> Date: Tue, 10 Mar 2026 09:13:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 03/14] xen/riscv: introduce tracking of pending vCPU interrupts, part 1 To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <949104bf183688fa0416845fe7e3c19c2c5b2a2d.1772814110.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <949104bf183688fa0416845fe7e3c19c2c5b2a2d.1772814110.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06.03.2026 17:33, Oleksii Kurochko wrote: > Based on Linux kernel v6.16.0. > Note that smp_wmb() is used instead of smp_mb__before_atomic() as what > we want to guarantee that if a bit in irqs_pending_mask is obversable > that the correspondent bit in irqs_pending is observable too. > > Add lockless tracking of pending vCPU interrupts using atomic bitops. > Two bitmaps are introduced: > - irqs_pending — interrupts currently pending for the vCPU > - irqs_pending_mask — bits that have changed in irqs_pending > > The design follows a multi-producer, single-consumer model, where the > consumer is the vCPU itself. Producers may set bits in > irqs_pending_mask without a lock. Clearing bits in irqs_pending_mask is > performed only by the consumer via xchg(). The consumer must not write > to irqs_pending and must not act on bits that are not set in the mask. > Otherwise, extra synchronization should be provided. > > On RISC-V interrupts are not injected via guest registers, so pending > interrupts must be recorded in irqs_pending (using the new > vcpu_{un}set_interrupt() helpers) and flushed to the guest by updating > HVIP before returning control to the guest. The consumer side is > implemented in a follow-up patch. > > A barrier between updating irqs_pending and setting the corresponding > mask bit in vcpu_set_interrupt()/vcpu_unset_interrupt() guarantees > that if the consumer observes a mask bit set, the corresponding pending > bit is also visible. This prevents missed interrupts during the flush. > > It is possible that a guest could have pending bit in the hardware > register without being marked pending in irq_pending bitmap as: > According to the RISC-V ISA specification: > Bits hip.VSSIP and hie.VSSIE are the interrupt-pending and > interrupt-enable bits for VS-level software interrupts. VSSIP in hip > is an alias (writable) of the same bit in hvip. > Additionally: > When bit 2 of hideleg is zero, vsip.SSIP and vsie.SSIE are read-only > zeros. Else, vsip.SSIP and vsie.SSIE are aliases of hip.VSSIP and > hie.VSSIE. > This means the guest may modify vsip.SSIP, which implicitly updates > hip.VSSIP and the bit being written with 1 would also trigger an interrupt > as according to the RISC-V spec: > These conditions for an interrupt trap to occur must be evaluated in a > bounded amount of time from when an interrupt becomes, or ceases to be, > pending in sip, and must also be evaluated immediately following the > execution of an SRET instruction or an explicit write to a CSR on which > these interrupt trap conditions expressly depend (including sip, sie and > sstatus). > What means that IRQ_VS_SOFT must be synchronized separately, what is done > in vcpu_sync_interrupts(). Note, also, that IRQ_PMU_OVF would want to be > synced for the similar reason as IRQ_VS_SOFT, but isn't sync-ed now as > PMU isn't supported now. > > For the remaining VS-level interrupt types (IRQ_VS_TIMER and > IRQ_VS_EXT), the specification states they cannot be modified by the guest > and are read-only because of: > Bits hip.VSEIP and hie.VSEIE are the interrupt-pending and interrupt-enable > bits for VS-level external interrupts. VSEIP is read-only in hip, and is > the logical-OR of these interrupt sources: > • bit VSEIP of hvip; > • the bit of hgeip selected by hstatus.VGEIN; and > • any other platform-specific external interrupt signal directed to > VS-level. > Bits hip.VSTIP and hie.VSTIE are the interrupt-pending and interrupt-enable > bits for VS-level timer interrupts. VSTIP is read-only in hip, and is the > logical-OR of hvip.VSTIP and any other platform-specific timer interrupt > signal directed to VS-level. > and > When bit 10 of hideleg is zero, vsip.SEIP and vsie.SEIE are read-only zeros. > Else, vsip.SEIP and vsie.SEIE are aliases of hip.VSEIP and hie.VSEIE. > > When bit 6 of hideleg is zero, vsip.STIP and vsie.STIE are read-only zeros. > Else, vsip.STIP and vsie.STIE are aliases of hip.VSTIP and hie.VSTIE. > and also, > Bits sip.SEIP and sie.SEIE are the interrupt-pending and interrupt-enable > bits for supervisor-level external interrupts. If implemented, SEIP is > read-only in sip, and is set and cleared by the execution environment, > typically through a platform-specific interrupt controller. > > Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable > bits for supervisor-level timer interrupts. If implemented, STIP is > read-only in sip, and is set and cleared by the execution environment > Thus, for these interrupt types, it is sufficient to use vcpu_set_interrupt() > and vcpu_unset_interrupt(), and flush them during the call of > vcpu_flush_interrupts() (which is introduced in follow up patch). > > vcpu_sync_interrupts(), which is called just before entering the VM, > slightly bends the rule that the irqs_pending bit must be written > first, followed by updating the corresponding bit in irqs_pending_mask. > However, it still respects the core guarantee that the producer never > clears the mask and only writes to irqs_pending if it is the one that > flipped the corresponding mask bit from 0 to 1. > Moreover, since the consumer won't run concurrently because > vcpu_sync_interrupts() and the consumer path are going to be invoked > sequentially immediately before VM entry, it is safe to slightly relax > this ordering rule in vcpu_sync_interrupts(). > > Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Mar 10 08:17:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 08:17:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249866.1547246 (Exim 4.92) (envelope-from ) id 1vzsH7-0001jw-AU; Tue, 10 Mar 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 1249866.1547246; Tue, 10 Mar 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 ) id 1vzsH7-0001jp-7v; Tue, 10 Mar 2026 08:17:09 +0000 Received: by outflank-mailman (input) for mailman id 1249866; Tue, 10 Mar 2026 08:17:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzsH5-0001jj-UG for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 08:17:07 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8683dd29-1c59-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 09:17:06 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4852afd42ceso32667265e9.2 for ; Tue, 10 Mar 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-48541a6bc3bsm60097875e9.2.2026.03.10.01.17.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 01:17:05 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8683dd29-1c59-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773130625; x=1773735425; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=fRACD4x7N8wd8Fy91xzLuO2yKCsx3uFmszHJJ8SyNGg=; b=g9xoQwi5jmkPEpoWKnL9DPj3AxCaZzUTRCbJ99d3j3j5h4at9wPJR91iuCz/um3fPh xYClO+X7xNcBJvGnMuMo+PirmTsmpV7eNT9HDZuZqSoQGdEpXwq5qZK+pIE/NMBr2dKZ 4w4UvXpE1a1e8beNrv/7N5vpU2gHVIuvmQ0y1vmX66OUrPpuqkGraa8wc6mD6ZDixDg+ XMYnjI44NmJbAHTYqpu7cLV971aKD+pX1liC63oWGUjvoCxxJ/stAuq0iMFIfE9zcR/r FG6bspRsUYM1oC+Mg6p27Nua9dgGzJgPw6kKnP1yAhvj2UuT/P7AgKvOJbEDTe9TQzbF pWTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773130625; x=1773735425; h=content-transfer-encoding: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; bh=fRACD4x7N8wd8Fy91xzLuO2yKCsx3uFmszHJJ8SyNGg=; b=xB7sVPzw+Pw98iJtCDAzOrXvzrwJWuepwN5X7cm4vK101Egnfnrx+4ZD9KeOr1lD1C wNpsBm34qWyCtFw3wh7EogPgBmjjhBDvUJiVxHruEHEK7iDpnIRNATNxbrnBV9ObHLES fGo3VEd4AyfrQXuehRFIiqqS2TVNVcVc6DJ1lp8sm0uFr+5P+ErZyOc6bizfelbJZcFe h4WAL9LPUpPXyDnrTczRXLWznhbosxQ/B3JFAZkJ9WMdji9c81kkpeZhQtnov40HCIgT 7ZS7J28X9slrmZ28rQa9fevfyOMlM9FenOloi5hgqUxUpMRdzdX+y2qZmeGHO7yY4o+M /liQ== X-Forwarded-Encrypted: i=1; AJvYcCWHUojwm4RZoI1Vgxf/Q3Oxw4SQTQrsbI2D8241iyFa/LKZ/L7F6NfJYntj2/W4IblKKWq+Sh5fhV0=@lists.xenproject.org X-Gm-Message-State: AOJu0Yzn7ZIqG+/H57VSUwKrsiLuiZ7aqAv6lYxxRA1hO6ahA9NltMUP nO0ZHy9rh9BL1MPmXvF5M/c4sEVvV0prqDbthmjC6w02AIie0tEXACzQx+4stwk0oQ== X-Gm-Gg: ATEYQzxYxS+YlZSAHAjXJ0xkK4QVtBurqLAi96V/O0hgZT4c+c7i+lO2dPI1iCZeDbx atHI0uvsuCXkXFYYM0+rVWwM6oTPikTocP5i1zFoEd4FYJnBN0eSP63JbGcwPUJo2K8DihZKmYs r5rEND1ixWnSKpx7BzhRukzjNQh6p2r5CKp/nnfLkzs43uwE8DbuuFSghromvAj/53nEBLzYtVm /ysnOA+HAx3cuyx5hsbyxsZu/cHcWGtO6fPW8jv51/nDX7Ky9JkUxLuE5fvwHInRAQgkWF+oDO6 CpZGwZHfcxvGAua9F45otW4a21cZDMAhl570LrwQmUpnvB8CwOFC1AjiFQ/3LV57Sb+iAaXJQGP xgf8cu3AMvI/FmWHwh3mbN4OCiuSwCEwwKuC7rCQyxY/1KSTnjPOLTLNpVlKe7WmpgS5bRwEnus A9xUWvIw86d5bPFj+o9IQahv6bDiyB+d5uXY9FOBOcRAa/wyT47Cn5GALO89ZXmR+9MCUyexjrP 5MN3DWZ//LtxjY= X-Received: by 2002:a05:600c:5250:b0:485:2fe9:3375 with SMTP id 5b1f17b1804b1-4852fe93587mr185229035e9.15.1773130625377; Tue, 10 Mar 2026 01:17:05 -0700 (PDT) Message-ID: <6a4d68e3-e640-4f74-be74-132f094db752@suse.com> Date: Tue, 10 Mar 2026 09:17:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot From: Jan Beulich To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@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: <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.03.2026 09:11, Jan Beulich wrote: > On 06.03.2026 17:33, Oleksii Kurochko wrote: >> +void __init init_csr_masks(void) >> +{ >> + /* >> + * The mask specifies the bits that may be safely modified without >> + * causing side effects. >> + * >> + * For example, registers such as henvcfg or hstateen0 contain WPRI >> + * fields that must be preserved. Any write to the full register must >> + * therefore retain the original values of those fields. >> + */ >> +#define INIT_CSR_MASK(csr, field, mask) do { \ >> + register_t old = csr_read_set(CSR_##csr, mask); \ >> + csr_masks.field = csr_swap(CSR_##csr, old); \ >> + } while (0) >> + >> +#define INIT_RO_ONE_MASK(csr, field, mask) do { \ >> + register_t old = csr_read_clear(CSR_HSTATEEN0, mask); \ >> + csr_masks.ro_one.field = csr_swap(CSR_##csr, old) & mask; \ >> + } while (0) >> + >> + INIT_CSR_MASK(HEDELEG, hedeleg, HEDELEG_AVAIL_MASK); >> + INIT_CSR_MASK(HIDELEG, hideleg, HIDELEG_AVAIL_MASK); >> + >> + INIT_CSR_MASK(HENVCFG, henvcfg, HENVCFG_AVAIL_MASK); >> + >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + { >> + INIT_CSR_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); >> + INIT_RO_ONE_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); >> + } > > The 3rd macro parameters are now redundant. At the example of INIT_CSR_MASK(), > you could now have > > #define INIT_CSR_MASK(csr, field) do { \ > register_t old = csr_read_set(CSR_ ## csr, csr ## _AVAIL_MASK); \ > csr_masks.field = csr_swap(CSR_ ## csr, old); \ > } while (0) > > This would reduce the risk of incomplete editing after copy-and-paste, or > other typo-ing. > > Note also that ## being a binary operator, ./CODING_STYLE wants us to put > blanks around it just like for non-pre-processor binary operators. I'll > try to remember to make that adjustment when committing. Oh, I'm also going to replace the bogus CSR_HSTATEEN0 inside the INIT_RO_ONE_MASK() macro definition. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:07:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:07:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249884.1547256 (Exim 4.92) (envelope-from ) id 1vzt46-00084U-29; Tue, 10 Mar 2026 09:07:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249884.1547256; Tue, 10 Mar 2026 09: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 ) id 1vzt45-00084N-UR; Tue, 10 Mar 2026 09:07:45 +0000 Received: by outflank-mailman (input) for mailman id 1249884; Tue, 10 Mar 2026 09:07:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzt43-00084H-Ve for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:07:44 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 970c0dc9-1c60-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 10:07:41 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by PH0PR03MB5861.namprd03.prod.outlook.com (2603:10b6:510:3a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Tue, 10 Mar 2026 09:07:37 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c%4]) with mapi id 15.20.9678.024; Tue, 10 Mar 2026 09:07:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 970c0dc9-1c60-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ul/bd23rdLsXEPxmituoioCMijPWUsQGYsWTsEPplNmsvbCieEo4IVjXgyuNRKV/Agf+V6o5HEa0OFf3cb9N7jlFk6McypwD6+Z6qz1Ym5RD8vo1UWP5RkLzipJbWvJbPHtxQplfIr9JFaY11mhP4zVfuaoQaD1P/r3lK/+6Kw1/aUXZ0QgnUhWwJQ0BQBDBxg2RqcaJhfKIPwiOJTWeiBN/728n67+Py3jG4qyrfQejmEyWXmhdGe5FmiuqCcodiQ0yy6OXEqIWdJuRmjdQZ03uAMw/LLrsAmZlEwCalxXnLWwizIxudmTj/jKzHVjLltcyDTF2F9jA6VWhRfE1Zg== 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=V59VMzch7YVpTMT8Le0sHR09r5yilpvHjOVWb5ku7Nk=; b=sd05CIU17Q8D3Z4uVVMpJPKrDaooQV4dihoKkk2DfHGiCz+D27BCNfDQPtf0QMWe3dzYCCnlXrukKtX1fgxkvwuALpuodYYB+mL1wEVxqY1LsZ1JYaMnfbl1SFB1Zr8CYrXs0EQgD3uGcnX5UUsX9UUM/tFsnBohyMeSHvKkPEiLp95G9VEarb7gGlTIwbIcR1ianSECLOshM4R6pKmFGw6UHBsuimomX36Q656XBLyuxF3MGDBusZuOmKDj+6G2RPR2eHX02YdrmjtHgsfmFv8Ns6fWTCEps3iyxUBVB/QwXFUhZEPrJrDcnXCgTU38MA16n88JjHDIBzLMXDcZ8w== 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=V59VMzch7YVpTMT8Le0sHR09r5yilpvHjOVWb5ku7Nk=; b=SPyqERMjle39aKk4DiP/GV1q7L5tmJLZ5a40BKaa+PIFLr9H281J4kN26OAz+Z1Cnt+MVs0eszscd1XncUPc4jpJnMIFcO5hl3woXlQ+kkrtcDtmdqalaAJo0cAttVJ5XHMFEC0elZD2CYHz7mMlgcUjJUyCLG/jDRQfyFw0Vzg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 10 Mar 2026 10:07:30 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2] core-parking: shrink core_parking_cpunum[] Message-ID: References: <29922662-8b95-4a69-9401-11480df59cdf@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <29922662-8b95-4a69-9401-11480df59cdf@suse.com> X-ClientProxiedBy: MA2P292CA0001.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:1::17) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|PH0PR03MB5861:EE_ X-MS-Office365-Filtering-Correlation-Id: 5dbb1d06-c6e1-45a0-8605-08de7e847750 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|366016|7053199007; X-Microsoft-Antispam-Message-Info: N1t31VkKIZm4gmyv4USPAWMUQTL4CAzhp8yH4C59R3FHAJ6Ee6zHKPRVroseeFuhCxMQuv2AmduKjlz2uNObOqB3wcPMczBru3KE8u7XfvO2gIU1ZrM+ls3/0Hn4t0G0StISIua/eETp1COS2olyuGSbTWgamFA369gNXWj3NIEzETZ95bsK+MQCCvhCQYf/eAgxk+e11Atg2yUXhiEJRwTlKWImy+fSy9n4M/SiEIrOVbxpqturbwOszmXRdMEWcsCnTLWlf94GSXIbe8vQDYEOgy9yN0XjM0WaDc9pmTcNUXISilcSCZ4hPTv1rvq7Uov1057Rg8XZGYdnohQ99SzaR6cIpBxGQTsnYW8syyvitfW8/AD00fUJ4gUN0UBpufkZYwEYPNPRVMB0w8NhdUU6dlD41mWf+yN4TlZNLE+fsU7IFYncxKEoY34iPz0VkMx4I7RDJm46G7psl6cWoGe2kITc/yGeKTXOiOxUyJCA2GyszlSBMHdrYf5E7GV0q7VMLkyWg6bOXS7UE/hEn3OwOQBLka6NOAJVi2uMuMp/5qZWDSrzQNLpbQyBdi2rxMhf5Ea9VyH1wu8vNzDMIMLtEVgsVgF1Wb9KvtaU6ld2vHAOBdskR8HnRVsVXSXUvmQKuukSJmYgFu0u1+BcvCjxAaQnZKNOC9kwgVjxim0/w+CzSzy0R1a7xmgSNGYIWUhIkrfmWg5YJe68Uc4JM1U/VdXkxqBOwMFvYxJO9iw= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(366016)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dmFpTUxGUWw3eHpqWXh2Vk1EanEzR3ZrTGRzYjVPRm1WRHkxLzlxZlRSVUsv?= =?utf-8?B?bU81dk95QjhFWkpaYmIrUWdRODF1RGVjcUFhNkFndjVhcjczZjhncUlBQkdn?= =?utf-8?B?S3BBRmMzWmZIa053WkNpZ01oR0ZUM0JZRy95c29ldXZGdjZFTnpyazkyRmxX?= =?utf-8?B?VEVOdUlQQ3l2OEhXYnk2RGxwZGlFSld6RkNjWDNOTWJmTEdXNFBaU2tuMWts?= =?utf-8?B?UDdNZ3I0d1g4L0tHdUJlMTUwbFo1T2hnNVpUSU1TSHdwR0l0a3ZlRjR3d2F0?= =?utf-8?B?bWtxQVZxa3VMVk0rOWhjRHFYaW5qVHdwZXdSUEN6V3Rtb2lVT0EvSVQ4V3Fi?= =?utf-8?B?bm9pK3pnaXRCMzBaOVdodGR0TnFFRzY4b0xsbUJLV2VvRkg0SHo1VEFyTUNo?= =?utf-8?B?eGQzUTl1Z1Juc1VRaWs0T01OaGpFQnVGNUMxc3VTcE9VYURqZ1NlZGhjMFJu?= =?utf-8?B?bEpCdXpZYzZxdGIwZElJcFVWWUxCcmdoakFVa1JVcVlXWE5HT0ppSUVxS2Y5?= =?utf-8?B?RUIyckp6Ym4vOXM0KzNCMmJiYzNLWGpGaG10bkFmaFk0ckg3T2lvS1J0NG5N?= =?utf-8?B?aHBGbkJORTJNQUZZV2ZVbEZ4TFdDb0NtTzVWVEViNHY3L2taaHlVOU1zWG9W?= =?utf-8?B?V2psVlZmRmpqeWlxU21BUFQ0TGpNQVRJMTBJbzFpOHp1VmQ2QU5jM1JTUThM?= =?utf-8?B?RkNSdDRwMzZrbkxSb2VrQ1QzbGpVVXRXZEo3WFJwVEpJa3VBeTJSZGt3QlR0?= =?utf-8?B?VWVaYUNPaGJPdFZYWm5ZeGhhMXV4OURJb1hDNy9vc1ROOTUrcHE0Ym9MZUk2?= =?utf-8?B?Nzl1OUZscC9GMEZLbmlNdWRMVkltUnFsMkdvZU12a1hGK2dQM3V5dC9idmQv?= =?utf-8?B?Y1cxYWViMHFQWGNGK0o4TjFyUERmUnM4dFJWZENaa0tmYnI4UGsvbnVTMUcz?= =?utf-8?B?NFdWa3FiZTYxcXoyQXl2bzYvOFlEcVhQaWpBMWpGVklHUWpkNTJXcThudVk1?= =?utf-8?B?NkNwWk50U3dtOTVwRENXTlhBd0x3MHhQYUs2NlVhOUw5K2ZDWmZUbGszTUlz?= =?utf-8?B?TWkvcklRblFMVjZad2drbHhCZ2pWNUJSTyt0R0Y4QXhCWWhpTFh4WFdmdmhX?= =?utf-8?B?WEZxbnMxckxVaW0yRGV4K094NXJHbVE3cjFjb0pEM2htWGhGOHppRUpVZ2xM?= =?utf-8?B?MjZWeDZTRWVSaUNwalpWZTU3VmNTZW44RmtNZjF2UExIS2JEQ1lNVGFGNkVM?= =?utf-8?B?c09jNm4xKytTa0hGY2JkekNKa1hEYk9nVVZ2UHZFM1AvdTd5T3NIQnRGblpZ?= =?utf-8?B?eTNheFJVZmVQMlA1U0s5MFFSV0xaMkk0N3JkSk5PV0xoWmp3bDZsUk5nc29S?= =?utf-8?B?WG9kdnMyL3pWZXF1dzlWZkU0ZjJiV21KejB0MGNHeHlLZWlLUjAxZTJvc0NV?= =?utf-8?B?KzBmVFBHNFNhYUZxdmYrbEYzSHBlWWFNTXRwYzlFSXdMOXhUVGtkcENEUm1r?= =?utf-8?B?QS9MMXR3ZmxTMVJRbUt1d3BLK25WRm80MDd1c2tORUxINGtwK2xZZ3NQM0VG?= =?utf-8?B?NUEwZkFFQ2ZWQ1lUQ3M5aUx0UzVMZ1lJY2Z5QmtRWjZLSmdxTUN4YkN3L05h?= =?utf-8?B?dWFrb3FNZGQxNURUSmdsNXJsUWJvenNKcUJYdmZXVC8wTTV1V1RPS3dpY25s?= =?utf-8?B?NDEzOVRFd1FuRXZJdm9TSXNmbkJ0b1k0VjlVajd5ZEd6cDduSjZENzh3Z3Fn?= =?utf-8?B?c3Y0Y1M4SWV1L3Vlald0aFdlNlVhRWU0R0xob0Q0LzN6UVFWVVZPTUtkL1kz?= =?utf-8?B?UEMxR29DcmpxMjE5UjFCWDZUdFZvVFhlTE15TXJMc1p1K2VFdHdIK3pjdnVs?= =?utf-8?B?YUljUUJNR3VHTU9iczgrME5OTUxNa1pHMkVnTTlzaHVlYWNScnZackpJQ084?= =?utf-8?B?SGF0YmJwUXRZbVRSNkJmMDZVSkRWeEQ1NjMyWmhZVFZoU3FlanlHbHhzNTdi?= =?utf-8?B?emsyTkFRKy8zR1BsTUloRm51dlJXK0hDWHFKNUhUNlE1NS9qU2ZhSHJJSHM3?= =?utf-8?B?eUdWWTFMbVpDNGV5b3hSZnZBTmlzc3FjbHprbVJOa2dwZlU0N2UxZ3JrWXp1?= =?utf-8?B?cjNJOGlIOFRwcGZMdGdCU2hYMTVOcWxBZGp1UGRzeWJFQVVEZ1dvaGVBY3Fr?= =?utf-8?B?Um1xNWNxT3FVNlhOMWd1OGhWRUhGVWVKTkU1ZEd6YmpSSUMrdGNFRE4xbEVn?= =?utf-8?B?V1FQN1ZlVGdjdWZ4bUswdmdwR0w0N1FPSy9sbXd6bTVKOWNHZTlEc0MxNmFv?= =?utf-8?B?QmhhOG5BNXBkSUI4S2VYNlFCbXVodktPNS9PYjhPdjd1SE9jVkNvUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5dbb1d06-c6e1-45a0-8605-08de7e847750 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 09:07:37.0292 (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: zitMzcQBGw/fAYrvSJSMn+Fei6beppJADGH4CK2ESbhWSJK82Znuow2osjZ9rmHIeHUkJ7gDzZfALqnrwUFIoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR03MB5861 You possibly want to adjust the subject, instead of shrink I would use "dynamically allocate" or similar. On Mon, Mar 09, 2026 at 04:35:34PM +0100, Jan Beulich wrote: > This NR_CPUS-dimensioned array is likely unused on most installations. > Therefore it is especially wasteful for it to consume more space than > really needed. Allocate it dynamically ahead of registering the hooks. > > Further the array having all fields set to -1 is actually useless. Nothing > relies on it, and core_parking_remove() doesn't restore the sentinel for > vacated slots. Drop the initializers altogether, rather than replacing > them. > > Also take the opportunity and update an adjacent variable's type, where > a fixed-width type was pretty clearly inappropriate to use. > > Finally drop the redundant initializer from core_parking_init(). > > Signed-off-by: Jan Beulich > --- > I assume there is a reason this is acting (mostly) as a LIFO. Else a > simple cpumask_t would suffice. > > num_possible_cpus() would be the more correct thing to use as array > dimension, yet we don't maintain cpu_possible_map on x86. > --- > v2: Use dynamic allocation. > > --- a/xen/common/core_parking.c > +++ b/xen/common/core_parking.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > > #include > > @@ -27,8 +28,8 @@ > #define CORE_PARKING_DECREMENT 2 > > static DEFINE_SPINLOCK(accounting_lock); > -static uint32_t cur_idle_nums; > -static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1}; > +static unsigned int cur_idle_nums; > +static unsigned int *__ro_after_init core_parking_cpunum; Don't you need some kind of check in core_parking_remove() to prevent a NULL pointer dereference if core_parking_cpunum hasn't been allocated? Callers of XEN_SYSCTL_cpu_hotplug can set fn = smt_up_down_helper, and that would call core_parking_remove(). core_parking_helper() already contains a check that prevents accessing core_parking_cpunum if no policy has been registered. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:15:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:15:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249895.1547264 (Exim 4.92) (envelope-from ) id 1vztBP-0001DZ-Ny; Tue, 10 Mar 2026 09:15:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249895.1547264; Tue, 10 Mar 2026 09:15:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztBP-0001DS-L7; Tue, 10 Mar 2026 09:15:19 +0000 Received: by outflank-mailman (input) for mailman id 1249895; Tue, 10 Mar 2026 09:15:18 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztBO-0001D3-Bd for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:15:18 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a620e150-1c61-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 10:15:15 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-439bcec8613so6761487f8f.3 for ; Tue, 10 Mar 2026 02:15: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-439dadac2a7sm35114095f8f.15.2026.03.10.02.15.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 02:15:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a620e150-1c61-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773134114; x=1773738914; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=chx2YjW890Ou0wPw7znAMHOGpEa1l+u9HuoEt9x/NDE=; b=DK1FoGX8bEnfrOQiSV3jiDfocaWw8MlOWst0dT3i/TpL+Bkybytaw4hAmaFF218XqQ sEEGt+FZYSpMRgLyeT7DwprCUWPmAL8bm7WyrDcjevSriXQtkOS6cEuIclBXZu5XQ7dV lheB3AwvF+a9EbdUi6RiZTUTDKP35BrBTUhzJrLt0v93kpmHPo6zE2bUWqVhH5D3v9VW Ej6sZFRZUGMPbgT9jIDQgRKiBTOZNYdxKADBcs7dunPHYzybESFFI5VNxhTDi0DducGu 0OxIKZb5ZJ4AIrpMw9XR894F4Nos1ZJ4Sqr7KYpA1OwRD5EHiVI3xcAAbgqCdsQWNElZ 86sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773134114; x=1773738914; h=content-transfer-encoding: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; bh=chx2YjW890Ou0wPw7znAMHOGpEa1l+u9HuoEt9x/NDE=; b=PBNVWnNL6vTSXd1ZXVAgzsVq2fgXJBq3BGWixXMExzgSvJGRWQ+iLmuBNL/m7L3cKG wrRMMmHNfYNypqUjy15e62Xilhd6jp9jrteTTcCHUQijJembY6kgHRoUoDwqWu/I4dJS 8przSVXRc+yYzVh2vMUeOyzVgxFG2yc47TsovK7Za/irxSRqsuYAQyonfaofxfUeNefJ vrRNOgxml4LqXgA59n6ojceWZwBIlF98Aqxpv+GLXxLaTQYr/frsbG26DeDgmKISTPx2 Id74LUqtMnyUZSK/+N/f9R0nsBPftoYRYQcrlINYNsewodSwF9PAMoVarSeWAn3rL+UI Xjhg== X-Forwarded-Encrypted: i=1; AJvYcCUInaujjVaSFv3oVgHuzffFHpWrQm3arvuftq+HgcUbTkV0NjFrMksdwcx9hNeMnGkmsUHZPhQWkCY=@lists.xenproject.org X-Gm-Message-State: AOJu0YzYTsST8f9+FqXrRuHk6RoA/Bk8rbknOrX92QQMM7UDRYaDjncU NV6iL0n7y3laxk6d0BJE40MIUUHNya0vMlW6wwJdDNAMEQiv0iX5AcgKJpJuL0K8sw== X-Gm-Gg: ATEYQzwybGZaoly226exfHUbAR3FlqVn27gt+SWO18FE3IeznvOTWHyemMFJRTFjWRu 6i/J7XRVhexFlJH2xEQePjTFn7I2zEXKYR3OvBfuZunVgHUBwa+fdhc/zHplVeL+DZBuA/rmDar l/d7oGamrodeVdtiB1EanJuUt/dDCfqd8tA90VbnOftSbAI/u2cwVQnfShIxnr65wllXopyuLH/ HzVw4/HiTUJlLhxybO639fTG5LNCWtKWc8y6RWrOZea21KIrM9uhWJw00IOJpDpAyw+oYXbyAWO UWCGMPp+coJChvroyf/NkBu36P5DsVa0csy9OPLfoRVhow1ylzB0CjMCttCCIHRFTB4djVKySaY ZLwHfP7mFN0CZKbZ5QC+Kj6lKaxK7nEdhyy0oJFNLhg6U51sgNESlKQncgta9uVYg5lViDyX8Jy j8CCyBRSiA4DZHc5ByDtJYs3Bv5LlTqOL/lzGZwEMjy24vdJn51UvXAnKPGG+PuKKveDvarI022 HPOMtHrLIzI8ok= X-Received: by 2002:a05:6000:2888:b0:439:af96:29e4 with SMTP id ffacd0b85a97d-439da86f748mr24365056f8f.54.1773134114169; Tue, 10 Mar 2026 02:15:14 -0700 (PDT) Message-ID: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> Date: Tue, 10 Mar 2026 10:15:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing To: Oleksii Kurochko Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2026 17:33, Oleksii Kurochko wrote: > Some RISC-V platforms expose the SSTC extension, but its CSRs are not > properly saved and restored by Xen. Using SSTC in Xen could therefore > lead to unexpected behaviour. And what's wrong with (or what gets in the way of) adding proper saving/restoring? Also, wouldn't a guest use vstimecmp anyway? I.e. what saving/restoring are you talking about here? > To avoid this in QEMU, disable SSTC by passing "sstc=off". On real > hardware, OpenSBI does not provide a mechanism to disable SSTC via the > DTS (riscv,isa or similar property), as it does not rely on that > property to determine extension availability. Instead, it directly > probes the CSR_STIMECMP register. > > Introduce struct trap_info together with the do_expected_trap() handler > to safely probe CSRs. The helper csr_read_allowed() attempts to read a > CSR while catching traps, allowing Xen to detect whether the register > is accessible. This mechanism is used at boot to verify SSTC support and > panic if the CSR is not available. > > The trap handling infrastructure may also be reused for other cases > where controlled trap handling is required (e.g. probing instructions > such as HLV*). Hmm, won't you need a more generic way of dealing with traps anyway? See Linux'es _ASM_EXTABLE(). See also comments further down. > --- a/automation/scripts/qemu-smoke-riscv64.sh > +++ b/automation/scripts/qemu-smoke-riscv64.sh > @@ -7,7 +7,7 @@ rm -f smoke.serial > > export TEST_CMD="qemu-system-riscv64 \ > -M virt,aia=aplic-imsic \ > - -cpu rv64,svpbmt=on \ > + -cpu rv64,svpbmt=on,sstc=off \ > -smp 1 \ > -nographic \ > -m 2g \ How does this fit with you panic()ing when SSTC isn't available (i.e. the register cannot be read)? I must be missing something, likely a result of me not being able to really understand the description. > --- a/xen/arch/riscv/cpufeature.c > +++ b/xen/arch/riscv/cpufeature.c > @@ -17,6 +17,8 @@ > #include > > #include > +#include > +#include > > #ifdef CONFIG_ACPI > # error "cpufeature.c functions should be updated to support ACPI" > @@ -483,6 +485,7 @@ void __init riscv_fill_hwcap(void) > unsigned int i; > const size_t req_extns_amount = ARRAY_SIZE(required_extensions); > bool all_extns_available = true; > + struct trap_info trap; > > riscv_fill_hwcap_from_isa_string(); > > @@ -509,4 +512,9 @@ 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"); > + > + csr_read_allowed(CSR_STIMECMP, (unsigned long)&trap); Please avoid such casts; see also below. > --- a/xen/arch/riscv/entry.S > +++ b/xen/arch/riscv/entry.S > @@ -99,3 +99,27 @@ restore_registers: > > sret > END(handle_trap) > + > + /* > + * We assume that the faulting instruction is 4 bytes long and blindly > + * increment SEPC by 4. > + * > + * This should be safe because all places that may trigger this handler > + * use ".option norvc" around the instruction that could cause the trap, > + * or the instruction is not available in the RVC instruction set. > + * > + * do_expected_trap(a3, a4): > + * a3 <- pointer to struct trap_info > + * a4 <- temporary register > + */ > +FUNC(do_expected_trap) > + csrr a4, CSR_SEPC > + REG_S a4, RISCV_TRAP_SEPC(a3) > + csrr a4, CSR_SCAUSE > + REG_S a4, RISCV_TRAP_SCAUSE(a3) > + > + csrr a4, CSR_SEPC Why read sepc a 2nd time? Yet further, what's the point of storing the value in the first place? The sole present user doesn't care. > --- a/xen/arch/riscv/include/asm/csr.h > +++ b/xen/arch/riscv/include/asm/csr.h > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > #ifndef __ASSEMBLER__ > > @@ -78,6 +79,37 @@ > : "memory" ); \ > }) > > +/* > + * Some functions inside asm/system.h requires some of the macros above, > + * so this header should be included after the macros above are introduced. > + */ > +#include > + > +#define csr_read_allowed(csr_num, trap) \ > +({ \ > + register unsigned long tinfo asm("a3") = (unsigned long)trap; \ Why can't this variable be of the correct (pointer) type? This would then at the same time serve as a compile-time check for the caller to have passed an argument of the correct type. > + register unsigned long ttmp asm("a4"); \ > + register unsigned long stvec = (unsigned long)&do_expected_trap; \ Fiddling with stvec may be okay-ish very early during boot. NMIs, for example, do exist in principle on RISC-V, aiui. There must be a way for them to be dealt with by other than just M-mode. > + register unsigned long ret = 0; \ > + unsigned long flags; \ > + ((struct trap_info *)(trap))->scause = 0; \ "trap" would better be of the correct type. Don't use casts like this, please. Further, wouldn't you better set the field to a guaranteed invalid value? 0 is CAUSE_MISALIGNED_FETCH, after all. > + local_irq_save(flags); \ > + asm volatile ( \ > + ".option push\n" \ > + ".option norvc\n" \ Shouldn't this come later? > + "add %[ttmp], %[tinfo], zero\n" \ Why "add", when you really mean "mv"? And why set ttmp in the first place, when that's what do_expected_trap() writes to? Don't you really mean to specify "a4" as a clobber? > + "csrrw %[stvec], " STR(CSR_STVEC) ", %[stvec]\n" \ The assembler does understand "stvec" as an operand, doesn't it? > + "csrr %[ret], %[csr]\n" \ > + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ > + ".option pop" \ > + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ tinfo isn't modified, is it? > + [ttmp] "+&r" (ttmp), [ret] "=&r" (ret) \ ttmp isn't initialized (in C), so the compiler could legitimately complain about the use of an uninitialized variable here (due to the use of + where = is meant). Whereas for ret the situation is the other way around - you initialize the variable, just to then tell the compiler that it can drop this initialization, as - supposedly - the asm() always sets it (which it doesn't when the csrr faults). > + : [csr] "i" (csr_num) \ > + : "memory" ); \ > + local_irq_restore(flags); \ > + ret; \ > +}) A macro of this name would better return an indicator of what it is checking, rather than the CSR value (which the sole user of this macro doesn't even care about). Ideally such would also be an inline function. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:21:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:21:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249904.1547274 (Exim 4.92) (envelope-from ) id 1vztGt-0002qX-Br; Tue, 10 Mar 2026 09:20:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249904.1547274; Tue, 10 Mar 2026 09:20:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztGt-0002qQ-85; Tue, 10 Mar 2026 09:20:59 +0000 Received: by outflank-mailman (input) for mailman id 1249904; Tue, 10 Mar 2026 09:20:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztGr-0002qK-Tr for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:20:57 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 70ee2cbd-1c62-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 10:20:55 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4852c9b4158so24060755e9.0 for ; Tue, 10 Mar 2026 02:20: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-48541ad1e4esm62024235e9.8.2026.03.10.02.20.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 02:20:54 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 70ee2cbd-1c62-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773134455; x=1773739255; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=8TONH6FjQzT6zZXhEPqa6FRGF1U7MKYWtnc3/hCLotE=; b=XzP2fCD9UemDx0011MOf8Z0KCdWmtKDDLyeHw7Th3GPIez1hK4OJoVCLagr4Y21QAM IjdNeQD3HO1TETjpwgmp8cse9klLyHEScRzDNsL3tsENMc1MpmrJYtb9e83Vj4HV1ul2 Fmhd0UE/saAAk+xDudIEUIeCKIjos4zcN5FrP1Kzh1JIf8jOyO4SeUTZc7F6PYZgwu4W Xm25GNDyBeUewXNi1Cz2hSdyVkKbQGEOIjS9os+hFLztDoMbru2oSfQYzo9myAYKCxFI pWLitvTh/rPIPXuyaAtiaT9Fng9Z8KH3sqcl/HLgaV/r8JcsyU6GuOJIliBgrryH0dH/ Cl/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773134455; x=1773739255; h=content-transfer-encoding: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; bh=8TONH6FjQzT6zZXhEPqa6FRGF1U7MKYWtnc3/hCLotE=; b=Nw0cqTHmB1a5SY2FkLZoc+RtW0H1qkzBv333u/fslTZLG6Kp98+CtEaPWgyIytiO4j Zw5q3bJtK3/hiciw9WBbOTDziX1Y+NIugrh1BRlbne985vVVQYfOvvxPNSwezGYDXge7 VlBquBIge7t6c0dfqDUeVlFA8CvhL6MiiEzGbJ6w5kGbvb5qj+MRnMVAZohAr/GjZmFG c30tD1lBgOBAVSi3JZ2ckfXLrR3u1hlBEfr1fowc9/7/F9XFFrwM/qwhSXX3nYxz/81A QJdlgdA0xLLLttaebCbr9674tBuwXNaCrmq1av8LcGom5Sj4fEyHwl1nSX0UKydoiZCM yKtA== X-Gm-Message-State: AOJu0Yw3MpgfEo1th9q3k9Dv2YtrrEiKMzKSo8lAUkraBcv13sUXxuuZ Qxozi2GGIVlcy4DRxiXiBhA0VvjYbykvsXk0axi7sU9v2uO5o08qJfIiWpdjglVDTw== X-Gm-Gg: ATEYQzx3Vo39BXG+sAs7SZumPsMgo2JprMwEmjTjZkOflqqcmx27HjEhEiBmZPYx9Pe swP7Xem0fBh3S8yqmJr150a+dCyvxiUXjffcy+2oRcNDVz7r9trLBc+96nZ7L9/QJo4qouUc+aG dH3reviy2oXdV2d16xpSccIhNm6cLtjr6WHT2fvQmp5rOASgXLTqMZo8lIt2tQOvXOwwzeVKbZY rqVUirGs4qk1UNojVBfAlfZQ+qW5ITD5nBN2erSnnA39Q2MZSPO/m4mQVodkh4MT999cjG2ANb7 BDPV3N679RbYgzZxYfZyvNJsCn6ytAoKbCNrh0EZjaE17Mhd45OQBDLLPiklvyM80E6MQVoHqI8 nfmlMLkC41NAfp8/LER2isP6Kuhu4311+6Y+ppk0QwHtTCLs+zLO3qMz7Ds2VI51qaRHqKVwFOW caKeltxJLn+FupQgcJ786ViReTSGmYdFlnsVoqjcmo4xgBUw2WmDFjKlNXyCPSTD2zUff3Q/c3Q FuwKuqKjIBvVT4= X-Received: by 2002:a05:600c:3595:b0:485:3f58:d84 with SMTP id 5b1f17b1804b1-4853f580f40mr71824205e9.32.1773134454777; Tue, 10 Mar 2026 02:20:54 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 10:20:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] core-parking: shrink core_parking_cpunum[] To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <29922662-8b95-4a69-9401-11480df59cdf@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10.03.2026 10:07, Roger Pau Monné wrote: > You possibly want to adjust the subject, instead of shrink I would use > "dynamically allocate" or similar. I've changed it, albeit the goal really is the shrinking. > On Mon, Mar 09, 2026 at 04:35:34PM +0100, Jan Beulich wrote: >> --- a/xen/common/core_parking.c >> +++ b/xen/common/core_parking.c >> @@ -20,6 +20,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> >> @@ -27,8 +28,8 @@ >> #define CORE_PARKING_DECREMENT 2 >> >> static DEFINE_SPINLOCK(accounting_lock); >> -static uint32_t cur_idle_nums; >> -static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1}; >> +static unsigned int cur_idle_nums; >> +static unsigned int *__ro_after_init core_parking_cpunum; > > Don't you need some kind of check in core_parking_remove() to prevent a > NULL pointer dereference if core_parking_cpunum hasn't been allocated? > > Callers of XEN_SYSCTL_cpu_hotplug can set fn = smt_up_down_helper, and > that would call core_parking_remove(). core_parking_helper() already > contains a check that prevents accessing core_parking_cpunum if no > policy has been registered. Because of this check, cur_idle_nums can never become non-zero when the array couldn't be allocated. Hence core_parking_remove() will be a somewhat expensive no-op in that case, with no deref of core_parking_cpunum. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:53:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:53:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249919.1547282 (Exim 4.92) (envelope-from ) id 1vztlm-0006u5-Qe; Tue, 10 Mar 2026 09:52:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249919.1547282; Tue, 10 Mar 2026 09:52:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztlm-0006ty-Nm; Tue, 10 Mar 2026 09:52:54 +0000 Received: by outflank-mailman (input) for mailman id 1249919; Tue, 10 Mar 2026 09:52:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztll-0006tq-DV for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:52:53 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e76e3e7e-1c66-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 10:52:52 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439cd6b09f8so4298063f8f.3 for ; Tue, 10 Mar 2026 02:52: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-439dae2b9ccsm34080319f8f.19.2026.03.10.02.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 02:52:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e76e3e7e-1c66-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773136371; x=1773741171; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=cQhj+ZqfJMzx6WmErb/09tHVtJEKFVNJ++SvDsmyi1s=; b=Do7c1ws/oVvNMslfXgjMg57ML1F3lJIPhTjZSjJRtWwHgWO98Tqdnu0ywgj5F1pGrP PSZCJL+sjAzt4LaNDjz0x9Kee+o7nTvrG6ezihL7r17sSF9j8KWfleRuw72+Gh3PRBuc FzMP+5NNAKvt5NIOMx2ubXaK2AGiMZ7fXdWIuu3+l2agzUPTwu3FYXrXUUXpWqHY63Gx 8qmds77n6Kjd91XamE3nQ2fTaFHJq2bT0jtjlSL/PGFyx/91EuO79C1q27i+RmhEM3fS xdPKNFqFUMK+uqMaXmFU4YeQBXRQX2Ci+a2WVuZTDEN1zwljlED4Kdzae1cb4OfLwPe9 CAfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773136371; x=1773741171; h=content-transfer-encoding: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; bh=cQhj+ZqfJMzx6WmErb/09tHVtJEKFVNJ++SvDsmyi1s=; b=oMdCQ5tvukWnyyTBPMtN7qCdW4ItmR+NnTHyEJ+wwaXFsA+0cSZJuLEszERo0O+xOz 1FZozH0nHYMI+bGl7/TgB9DGI2RiQ05kI2Zqv+ow50Jfb3IuCCck4T+vPKQ4DrrL6+Z1 lhGXnWTgyTZD0NeZ1DiKt52k20kc4R1suHOnbQ++llTdJTUAhTsGdapv+FR2cz95C02t a36wANodNKvvEfGFcIoT09Oyq2dTbOk4TxoVfiMf97ft3tjPDPSqw4yd5WejobjtsGgk lSMf9bd+1CCWQHCbQLt9SHr0NkNsgqXFIMQtMMcLAqKUClYjXaHJJ/y2tC9uQT5qEVkN tO+w== X-Forwarded-Encrypted: i=1; AJvYcCWCpGQiwPeYHEI8vC/46NNZW8l5/Co3VcsVrBh/W1fzRwnj+dXpOeF1Ip8t2xPBoGO8ke12XkOl8lc=@lists.xenproject.org X-Gm-Message-State: AOJu0YzKG4rFvooBmtPiLF4guJj7+EH5zyv6+a/s2o7dvJvbi0ux7r+7 CKhrXr/Cp5hiwehhXDacc80s+Gh8H/Aqk464KKSFbH6yKuqqpAylOgSXzxCaAJEfxQ== X-Gm-Gg: ATEYQzzL4Iqm6rjfrKc85VGBtlJ7vMSp9W2ZGXoneYC/pWF21jmbydVMefii2rmDCqn 89cWiaC5NtDGNNXmSJ6Hk9BWMHwup+plXSDkq3LKCETn2mK/DoBTuuXv6PWQLgkgArfQW4tMLoH /un6Az/XWKMu2LsC20Pn6QA1JhW5Md11QRNN7YDTSEfToWWFa9Ocd4so5E3/VIiPxULPPbJ700O +kXQdr7D/SNVjQ67fSuXY+n1hHXFqAftzjS/+gKLUiF8Yn9Zefn266saoGD8ozg8FWFnqa6X7mK ePa5tD7uAYGr1uLuYv0l+4CYuDgHTfv+bR0+oZ2O3AePVwcWRuOIEu/uU4A2fnJ8NqP6Juib2rQ tIoGNu+vpV/gPtg7bbe5kDMZNeVWGCbeL7IjUp6viXmjm1hxSkLSQ7OoZBzA8BqE6uajOibA6mG 6lPmeoxdyYUgZjIBiYMyJBPsjt9Hs6Rt2YDHIVOJZY/6NxtwWXrPnpM1zfXNLFof4TIUA9P6h48 EGfarKqpIcvsqc= X-Received: by 2002:a05:600c:c107:b0:485:3eba:ab96 with SMTP id 5b1f17b1804b1-4853ebab021mr64815165e9.3.1773136371546; Tue, 10 Mar 2026 02:52:51 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 10:52:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/6] x86: Remove x86 prefixed names from mcheck code To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-2-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-2-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > struct cpuinfo_x86 > .x86 => .family > .x86_vendor => .vendor > .x86_model => .model > .x86_mask => .stepping > > No functional change. > > This work is part of making Xen safe for Intel family 18/19. > > Signed-off-by: Kevin Lampis > --- > Changes since v1: > - mcheck_init() check for family != 5 instead of 6 and 15 Imo this wants splitting off, to have its own description. In particular, there's no 64-bit CPU with family 5, afaia. > @@ -564,8 +565,7 @@ bool mce_available(const struct cpuinfo_x86 *c) > */ > unsigned int mce_firstbank(struct cpuinfo_x86 *c) > { > - return c->x86 == 6 && > - c->x86_vendor == X86_VENDOR_INTEL && c->x86_model < 0x1a; > + return c->vfm >= INTEL_PENTIUM_PRO && c->vfm < INTEL_NEHALEM_EP; > } Wouldn't this better be return c->vendor == X86_VENDOR_INTEL && c->vfm < INTEL_NEHALEM_EP; similar to how you have it in mce_is_broadcast()? Independently there's the question whether this is correct, seeing that INTEL_CORE2_DUNNINGTON > INTEL_NEHALEM_EP. But if a change was needed for this, it would want to be a separate patch anyway. > --- a/xen/arch/x86/cpu/mcheck/mce_intel.c > +++ b/xen/arch/x86/cpu/mcheck/mce_intel.c > @@ -711,10 +711,7 @@ static bool mce_is_broadcast(struct cpuinfo_x86 *c) > * DisplayFamily_DisplayModel encoding of 06H_EH and above, > * a MCA signal is broadcast to all logical processors in the system > */ > - if ( c->x86_vendor == X86_VENDOR_INTEL && c->x86 == 6 && > - c->x86_model >= 0xe ) > - return true; > - return false; > + return c->vendor == X86_VENDOR_INTEL && c->vfm >= INTEL_CORE_YONAH; > } Is anything below Yonah 64-bit capable? Even Yonah itself isn't 64-bit capable afaics, so perhaps again this check can be simplified in a preferably separate change (possibly folded with the P5 related adjustment above)? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:56:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:56:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249928.1547291 (Exim 4.92) (envelope-from ) id 1vztpB-0007SF-8v; Tue, 10 Mar 2026 09:56:25 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249928.1547291; Tue, 10 Mar 2026 09:56:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztpB-0007S8-5R; Tue, 10 Mar 2026 09:56:25 +0000 Received: by outflank-mailman (input) for mailman id 1249928; Tue, 10 Mar 2026 09:56:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztp9-0007S2-Qr for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:56:23 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 61c549e5-1c67-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 10:56:18 +0100 (CET) Received: from BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) by SJ0PR03MB5533.namprd03.prod.outlook.com (2603:10b6:a03:28e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.18; Tue, 10 Mar 2026 09:56:14 +0000 Received: from BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c]) by BY1PR03MB7875.namprd03.prod.outlook.com ([fe80::20d8:6571:d4aa:166c%4]) with mapi id 15.20.9678.024; Tue, 10 Mar 2026 09:56:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 61c549e5-1c67-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ASc4FhDSWb36YGyDh8oet+7fcVfQQvpDA4JoAbPzTnwSJJgAAMBAheiM7beMvjPlHERnzOWkefgxk0w9ZhcsNUKdzl+URzJY+4OgPlz//j20NjQp4fixFl/30vCFh8TFTK26HXwXl3XRc6ZYloulZDdHPOK6WnFHKUcEUGACEu8Ru1ZTeJB0cCKtNANAb3UgKBykwaqVWzyI76Ml0qrYsdaS0AcFFWFH8ej93xsCw7DfFt82ntHaU738hPSqa6bNove0iIKNAZ9A0PE9++lGfyAiP69yBdP6FWt550X80mi5lCpe43g7RLWnQH1uEYHbxlvlI52IIHj8jP4vgUeqow== 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=lEbQUuU1SGwprGIKvAjqcdRp4avOR0fy/79RpehbaYk=; b=xDBx3du19HL1q1jq4MpDv570OJK6+iDT3nS4tbGLxQkqhhfGnWIV4ao3nH7wHoPFwKW49SRgcQWSfmbmQ9g6lpEuTgpZenI78UpUSirCGKwrv4X7Cje/5ou0raYY1/TrCeHoFXk3Xup0zBQW4QgeMwoWDSce8j2+4cQVpGQKvo/+0xJWPiamFabkesdHzz7UZ2QaLKXZemS2bGhBHF6a9UV/vTKcf3mp957wRaKHowO8rrWfJJY8f5YUhnNPcX6Ss6KDseE/5OS0RGlYTzvRqzt7EKV6/9ohTmrp1+QrW8fiBZbMsqzn4x4EHlY18Ha24HsueLBij6R2yQCfExB5KA== 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=lEbQUuU1SGwprGIKvAjqcdRp4avOR0fy/79RpehbaYk=; b=l/Wck4KrtG8teaLBZdYB3PhMp5NBrzSRfs+cKJ6cI8hRa1AdiY8ytOqotZxBQVUWoh/nOl9oQk020Y2mECXWPm6lrpm6dTVTvRdTPVG7ZiA1+0bkPStTkxewdK30y2AxEhTHpzddj3yMpaWeAiZwGBrYxMljDATM0Sh0WodWtmc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Tue, 10 Mar 2026 10:56:10 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel Subject: Re: [PATCH v2] core-parking: shrink core_parking_cpunum[] Message-ID: References: <29922662-8b95-4a69-9401-11480df59cdf@suse.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MA3P292CA0013.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:2c::6) To BY1PR03MB7875.namprd03.prod.outlook.com (2603:10b6:a03:5b1::10) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY1PR03MB7875:EE_|SJ0PR03MB5533:EE_ X-MS-Office365-Filtering-Correlation-Id: 6be3b59d-df4e-4095-81b5-08de7e8b4423 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014; X-Microsoft-Antispam-Message-Info: s/yFDkKabxeewcx9yi69GEQFgVQI6Tdn6/KwIHpm8K7jrhpeStPBfRTe9DldwvNi1NEgFTcqJ+w+tBEMkNodrsEqt+vr4lhSJ1edQrmfNR2ZMIkLdhr/E7vphe+j5qSW3k3CoE9KE92I5Jkx1txoMEoUQ4O17uYtg2rS5QFZPKu9DqnHtl631BCcigqyxTHFYnxdwGbffEXBzipKhNjwKCC7Cfyg7pFy78SANQ3nzAhzeeHuf1zEhzJrh5bcss/ynkBFqIeznEEnGJGpr639GPMxkAdUbOlc/Hv/XE3Cn8AjJBXAFGwkpg9GtbBPGZ+PO6Pq7dO52XJHkx8Nv1HhKceBfyzzWdvwjUYSfL7m0phosPjCrFJ6Yx88/4AkKkyzZupgF2CliDzMZFVoZAEABoUOr8cg1a9/j35pvOcz1GtouQ+XZ+mk0IbAJScbRT+PjFLEvPBb1huEZAjHa9TfRQAGC7+kX2L9xEuVnRxoQGNcqaDQ9wOfQlVj5358Tewfz3TUvz26/bd4by6SMYw4vs8wEyZ/ma3K0hbGJW1p1tOWMl6k420vQ1H5oFadI3HRricVSLD4zKcLXeEKRci9I5ns7BwK+H+TsGhCkmvd3z2ZYsE1ogtkZ8aE1x02MrYwizpYstjhRX/KMrHlu07pgLcBeS4AqVrI1fEC8w/cAqlFFYYTyYUw1m6kuBAfZ/k57oG+5Zx03a+wrhNgPJQ2eQ0+RhoRkVFR7SZLC5uhb9g= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY1PR03MB7875.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ckxxampnRlJoSnNyTzF0SnpyNSszNVhwNWd6YjJ4WFlySWZ5UFI1T2ZsSEdt?= =?utf-8?B?QzZLZlVua1N0NzN0SG9rS1k5Z2l0UlVKd1RmUlVrMk0rUFNSNnJrSWhoeVhZ?= =?utf-8?B?enFQTHpQWk0rNXI4dE8wTzhWQkdDcTJ4R0hTYTRUSENGVUQvYzNyT1pWU2Uy?= =?utf-8?B?TE8wMXlDYWpCK1hhVVBQZ2RoWmZDQms5TWIwRG5RTnV1SFlkSFZ1V0xnT3BN?= =?utf-8?B?c21DWlk3NWh3b0FCcmxvbU05d3pJbFhZZzdzUDVGcEF1MllSSUVHaGdrUGty?= =?utf-8?B?cGhYdWVwa2NWcHZKc0U3NGFsbG9FVGZpQ1VuaVF0LzB6TTU3djZUT3Z6Smx0?= =?utf-8?B?YzhRSFFDdHQyNUFET2drdEdrMWUzRFRvSzN0MWlIVEhwRjRvOVMrcncrMGNV?= =?utf-8?B?UmluZjBiMVA5RmdNTUlwWG1XcUZidUtvOFB3Q0NrMmZEZDBYZ0cxNHFPT3RS?= =?utf-8?B?Q3M3UkxJUEVJUUlmQmlxZXdyV3ZRaTFWK2VKcHdyT0x0d1JmaVZtcEd6dlBv?= =?utf-8?B?Zm9LN1A4Y0cvT1oraitKUEw1MXVldW43bFdFTVJSR2szdjNqbXk1Z25tUXZJ?= =?utf-8?B?MkZsVlJWMmozSFhxaUswWDk0ZWpGNG1iV0JwN21ObnJSYjU4M0VDYXh0MWdz?= =?utf-8?B?QWFyczNlRDhaK28ydE1iRFRabzZaNmhSUmUwcTZlWCtXeUlGY1doSGxhZ2tP?= =?utf-8?B?TmM5ZlRvM3o3dHFLa0hpSjhuS0ZaajhIUmxVbmVWVjRqVUl1VkUyVkxlMXF0?= =?utf-8?B?WlMzdjMwekxza09HUlpKTzBHdktTUFB3MlpKRytSSjRacnZBQTFXY2RmekZr?= =?utf-8?B?dzl2ckdHMjRITG5nV3NxQlR4YzRIVlBEUFE4M091TjIvNzlhUW5FOXRnY3Aw?= =?utf-8?B?Q0JqYjlMZUZ3NjRnRDFwaWhoSXhkZjdlTmtIQVNCdlptVmVGUW9oTjdqMCtL?= =?utf-8?B?YXN0cGVRWGQwWngyOWlmOWhXVkVUbHRqWGRwU3FXOVN2TUt3NHFEQWxvanNF?= =?utf-8?B?amdXRGMyTUVrN1g3L0h3TkM1bHhSMUx0MldQaUhOSyt0V0Y3cnRZbkQrS1pp?= =?utf-8?B?TGw4Tmo2L1NUWCtqc1o4bHljR01ra0RBMlNBS0pZQWFlQUllZWFMS2NuaTRB?= =?utf-8?B?UTRLSHdESzhNZ2hPc2Vpb09xaGd3MlVlQUtaOExhdlROcCswSlh5djlZSjA1?= =?utf-8?B?MHVEMTVVbm5iZ1BSaDB6RUZvUml4SVJiaUFEZVRCOGdsbjRNYTI2b0R4b1FD?= =?utf-8?B?bm16WmtTT1FxNWJxMk1hSTlvMUtZNU53V2pBajlRZGxpUzl6dU10S0FBSE5T?= =?utf-8?B?R0lDYi81a2NueVdVUHhhaUtnWWwwWmJYYkdVS2tRUENxeTJYWi93WHlleEJS?= =?utf-8?B?bGk1YnpKY0JhS0V5QWFBU0I0aDJ6YWJNREFyZ0Jhd1E1S3JMQi9vQVljc3pD?= =?utf-8?B?ekNhRDhSNXgwcWF0MlhORCtOS0htZjdORjN3RTdKbTlRMWdiaENWYkVlMkJS?= =?utf-8?B?d2crVWNNalM1MjJYUDVteHN2ekJXWjMzWFJJb1kyOVVJbWNrZ2REVm1xS1NX?= =?utf-8?B?Y05yWENLd29MMmlMRVdwZ1AzTllXQkRuUERMUDl6aU0yWjJJNVJ1bVFXMlZs?= =?utf-8?B?TEVydHhHWDJ4MW81RlJSYURabzhocTZ4ekV1R0tSSnhVaCt2akVpTEwwZEFz?= =?utf-8?B?MkcvS2k1dWhGRzhmTForMzJmUlFtSzVKRFk4OXVIYmtITFkxNi8rL0dSOEdt?= =?utf-8?B?SFhqamVEVzdWWFo5RGxtZ3dQTUxnLy84ZWl6bEZjb0tneGZacW5qVW1NNVpD?= =?utf-8?B?YTNVVlgyOUxnRjRZZnl3Q3NhdU9OUXhMdGFQcXNBRGkySk9nUW4wRjVXYnFI?= =?utf-8?B?NDdCV2xjL0cwc1hJa3V4STV6bmxOVE9Sd24vMWhKeCt5ZTlVNlJkRHNjY1Vy?= =?utf-8?B?bGxBYTUralcwV0ovaHRkTFZ2aTFZVG54L2xDcDZJeVY5K2dsUExZeTUyZlZq?= =?utf-8?B?cHpWOTdmemNVelJ1SHVFVGZwSldVMzB1TXZGaS9MenBFa2ljVW1jR1ZCS3BL?= =?utf-8?B?cWk1dkx4Q3dPMG5wbUFmdFVJbTAvNEcxVWloVTRubWNzQ3F0alV4dnNobzd2?= =?utf-8?B?cmFtYy9PTENpRUFmQTI5b1lkaCtKTFc2NFdmdWtDcnF5Q0FvREQxOGs1dVpk?= =?utf-8?B?WlkzUW9TSE42TlZ6V2xlbFJTWHZ0UDRDM21NZFpkd2l5RU9iTWppNXlwYWJm?= =?utf-8?B?V0pOcVJjNFJ6ZVNYSHBNbHUyRDBzMnBQb1pjSFdOdEljLzM4eGMrcjd1YklY?= =?utf-8?B?bUpjU3ZncUk4Y3NIeWJTZXRLMUFHalVGbHNWdFFiVVZSRjVuWlFhQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6be3b59d-df4e-4095-81b5-08de7e8b4423 X-MS-Exchange-CrossTenant-AuthSource: BY1PR03MB7875.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 09:56:14.3733 (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: tMrFqNpV3PZP+yHQx+I1/wmxvpebgszODQElbJuQ+1ey0DTZwtwyL3siVu90yDs77zHj3+FHhcsry+ObsuVoOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5533 On Tue, Mar 10, 2026 at 10:20:53AM +0100, Jan Beulich wrote: > On 10.03.2026 10:07, Roger Pau Monné wrote: > > You possibly want to adjust the subject, instead of shrink I would use > > "dynamically allocate" or similar. > > I've changed it, albeit the goal really is the shrinking. > > > On Mon, Mar 09, 2026 at 04:35:34PM +0100, Jan Beulich wrote: > >> --- a/xen/common/core_parking.c > >> +++ b/xen/common/core_parking.c > >> @@ -20,6 +20,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #include > >> > >> @@ -27,8 +28,8 @@ > >> #define CORE_PARKING_DECREMENT 2 > >> > >> static DEFINE_SPINLOCK(accounting_lock); > >> -static uint32_t cur_idle_nums; > >> -static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ... NR_CPUS-1] = -1}; > >> +static unsigned int cur_idle_nums; > >> +static unsigned int *__ro_after_init core_parking_cpunum; > > > > Don't you need some kind of check in core_parking_remove() to prevent a > > NULL pointer dereference if core_parking_cpunum hasn't been allocated? > > > > Callers of XEN_SYSCTL_cpu_hotplug can set fn = smt_up_down_helper, and > > that would call core_parking_remove(). core_parking_helper() already > > contains a check that prevents accessing core_parking_cpunum if no > > policy has been registered. > > Because of this check, cur_idle_nums can never become non-zero when the > array couldn't be allocated. Hence core_parking_remove() will be a > somewhat expensive no-op in that case, with no deref of core_parking_cpunum. Oh, I see, both loops in core_parking_remove() are bounded to cur_idle_nums. Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Mar 10 09:59:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 09:59:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249937.1547299 (Exim 4.92) (envelope-from ) id 1vztrt-00086G-LC; Tue, 10 Mar 2026 09:59:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249937.1547299; Tue, 10 Mar 2026 09:59:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztrt-000869-I0; Tue, 10 Mar 2026 09:59:13 +0000 Received: by outflank-mailman (input) for mailman id 1249937; Tue, 10 Mar 2026 09:59:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vztrs-000863-4U for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 09:59:12 +0000 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [2a00:1450:4864:20::436]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c92d1449-1c67-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 10:59:10 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-439b2965d4bso7424736f8f.2 for ; Tue, 10 Mar 2026 02:59: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 ffacd0b85a97d-439dad977f8sm34419385f8f.9.2026.03.10.02.59.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 02:59:09 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c92d1449-1c67-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773136750; x=1773741550; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=qTdWkCNeBclAJHTd440+WKj08O236iton84b7CEgDhg=; b=GTAVKkZTRMFi9tYJvgoigzjFI+U9g2cgXLdYUOiDzsM94/+9K7CRHt5Uo904YapJ0u pY6c1cvTkxXq5FuYKatjQVni0KkSzj1wom2ih6jhw9pGp16hD5zFQVTaG+rYGApjTw6+ mRkHUSNe/SaWe+Zg4hpfUhm0x7md73KEsv2NBMRub9uMwHJrdBM/NHAl1Wk18nwSm1C0 QvBbNpP40nlHxs5FNaS63xkKKw7l2cNXxV1WaqCPjxS9NCanEIU+eLnMl9sTYPu/Swzt w7okz8JcwXb8OE4c0hv3M6ZjLmuNGvirzTzCFPJ16JNec2WPstbAaVmHy9S/DnD9hC+v 0TmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773136750; x=1773741550; h=content-transfer-encoding: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; bh=qTdWkCNeBclAJHTd440+WKj08O236iton84b7CEgDhg=; b=GClrN/B//LQRrJVpFVEOB8byRXNMKoMwPzW6PK4vgIcX4gu4ejY4i/4g6MOEysO14Q LYrc2HE8731Rwi+O6pqceCDhv6AAKq6TPm4+yBHc5KpkEz3MID2Kt/ORnE7DbD+py2EY g6tTxkvwQn4kh8i6aLEi8dAsqGHL6wTmimCPA7EXna9JZ7AOZ5lnxzIv0TjIqwBj7mpS hY3nonFinXu9hbBbdqKl/Rv5Osf+x+gB+o/YgAUR50K5T5hYKIfYzpXTVHWfQQLQAALu qK0Yvl7Mahdr+7FzHAmjkvEoHNrFCPsbriVnzMlSDfgJOiTjmrJ9X3VzE4aIIt0hmmYB cZlw== X-Forwarded-Encrypted: i=1; AJvYcCVa+WefBrHLkB2iYKKY1GKIwdcJV3JGhhMO6cz/TLGMvwFUzePY0G5bvmGUD4eAARg1DR7rwWxenlY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxg+xwxdW4lR6GaWOhGI6h42oLvGz72cxS5r2OS9E3oa7YYxQok e8+cEpgcj7i8t2aR0LePTmghAy3z9iXdj6ZNImH6zUvbEGfPo31vf7M9aTLW+kZAAQ== X-Gm-Gg: ATEYQzzFbxGDIL/984jeN61AoyXaHzbUt8E0u2g81Jc+ZRFucUItbwNrs2XibDMPluX PNogLnfnhsEF0wLCZfe6+GVBgwQPIgXhAvJrSdmgO/sK6VF264WWJXH2jOxEsbFDdatzD2HzJJ1 L5U8uKeMOApRh5nM0dKiwFHmahDv3W8BWO+eGP2/uZ4k2BQJfZPbTOWqk+cMGIyO6VXP7baCql4 2JRi03PCRDDZcZz+wV/NAo9SsUopwoQH8yY6IFfRZv05d+BhWQ9pjWcclfZ/wjNBo4vw9uuL+vL OPi4UnR5a8siV0I4NUNiUa1U8cf84n9ewfTJe+F4iMgafaFd7k+V/8JIq79nWPrYWyPKHhtasOd uWl5gUf9lE9l9LxBvFba7tHGjvGheg4VT/HMkCyZtdG/VOC9dZpbYm6UjHwJvrod8Zju7sKT7uz 5LtSo8LNXJp3c08KCIWIZG/RVPeGwiu1Qe4Q/U3mf0YBvxDEWILrcVIP4zI4+ll2p+qsxQ+eSwV OzjDPMefBcmhbs= X-Received: by 2002:a05:600c:a115:b0:485:3b5b:eb8 with SMTP id 5b1f17b1804b1-4853b5b108emr88886155e9.26.1773136750263; Tue, 10 Mar 2026 02:59:10 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 10:59:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] x86: Remove x86 prefixed names from acpi code To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-3-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-3-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > struct cpuinfo_x86 > .x86 => .family > .x86_vendor => .vendor > .x86_model => .model > .x86_mask => .stepping > > No functional change. > > This work is part of making Xen safe for Intel family 18/19. > > Signed-off-by: Kevin Lampis > --- > Inside do_get_hw_residencies() > there is an explicit check for `c->family != 6` > Do we need to add family 18/19 support here? I think there is more stuff to add there, as the last addition looks to have been quite a while back. But "yes" to the question. However, ... > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c > @@ -178,10 +178,11 @@ static void cf_check do_get_hw_residencies(void *arg) > struct cpuinfo_x86 *c = ¤t_cpu_data; > struct hw_residencies *hw_res = arg; > > - if ( c->x86_vendor != X86_VENDOR_INTEL || c->x86 != 6 ) > + /* XXX Does this need to be extented to include fam 18/19? */ > + if ( c->vendor != X86_VENDOR_INTEL || c->family != 6 ) > return; ... I'd prefer if such a comment could be avoided, ideally by covering the case (in a separate change). > @@ -1059,8 +1060,7 @@ static void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flag > * is not required while entering C3 type state on > * P4, Core and beyond CPUs > */ > - if ( c->x86_vendor == X86_VENDOR_INTEL && > - (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 14)) ) > + if ( c->vendor == X86_VENDOR_INTEL && c->vfm >= INTEL_CORE_YONAH ) > flags->bm_control = 0; > } Again a check that likely can simply be dropped (in a separate change, possibly together with those other droppings suggested in reply to patch 1)? With the adjustments: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 10:27:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 10:27:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249946.1547308 (Exim 4.92) (envelope-from ) id 1vzuId-0003ia-N4; Tue, 10 Mar 2026 10:26:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249946.1547308; Tue, 10 Mar 2026 10: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 ) id 1vzuId-0003iT-K6; Tue, 10 Mar 2026 10:26:51 +0000 Received: by outflank-mailman (input) for mailman id 1249946; Tue, 10 Mar 2026 10:26:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzuIc-0003iN-CY for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 10:26:50 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a4df623b-1c6b-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 11:26:48 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-485445e80bdso3817825e9.0 for ; Tue, 10 Mar 2026 03:26: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-439dad97abasm31852455f8f.10.2026.03.10.03.26.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 03:26:46 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a4df623b-1c6b-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773138407; x=1773743207; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=sXZ/Do0x+4Oc8KRITWR6W9eSNAsHpSr+C2VoN330X78=; b=eIcm9j5YuIEo+nWYD+2OgurBX/GFT7mZOsqMY+orZ+5YKzwom7aBHXAng1uU+wdjn9 DiZIvCis/kj57j686tEteD6dll3eAeujkHcz+aX6zJ7qec30pWBASNLT6sgwbo51KFsI 2oYpjA31FLVNWqGAcTMIXsZXOFZlT6JSmHtnZP7HqOCSkQjOR3gFNpLAEGO8AMxG/OWr oKjY0Hy5RJ7EusoiCpR5zdAoHwE9/Cch6h5OOrHkBw7ZR0r7umZjgU1EK6+JDh9o+DQX F8rSudZU6muSbDD+5s5ygXy3KooJtbVGWDymM6X8dx1VAfbvzfZBmhghARUoGQJO5QFH l4MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773138407; x=1773743207; h=content-transfer-encoding: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; bh=sXZ/Do0x+4Oc8KRITWR6W9eSNAsHpSr+C2VoN330X78=; b=N5ABbzUsJrlOlEBDCNpQ9IzTR6AtezQDHjFroe3scOQpmOC6G8/7Rlw3E/qrVG/+J2 995ZqRTbk9eJBaPJXQn1yJTL296hNPm+8bsS4DnUNZPjUFEuf4qDAUTT+/U/M7DY/SMb mgjEx367vSbZLkQ4vyYVQw0otS7eTMkANYDQ7zU9u/WRudS4+zx8EyhsZpLy9QyPLriF J9UvUVzhg/WC+BfUyXttbkTJ1D61Zs1w/C2Y3sS6VcRWXpy3UlBxs9PnMmVqb6uzSNyk mWPnhehG43ec+GjfPgEKuX03DqOqAYwEDRoCzkfSu4yCW1MFqdACP+1iLQCUidmTp9zH 6Muw== X-Forwarded-Encrypted: i=1; AJvYcCUsqQA/vZ2/Swoy089yTLKcPidj/D4U3R4hSFNM2qmXRsxBRBUGK1riHixIQI6zslCsO7T+xO1Z+1s=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw1x7Zu5Yo9den8CNZwNiDGWuu8VgIJi3kI0CVEmJiMTTE+Oadp +DIXiy+kfBcc/BW69i6JbD20b3yhZJfdSw9PopDbaYvPyLZOy20b6Gn8HQofGL5OsA== X-Gm-Gg: ATEYQzyOm+WDP2cQgI32Y/1GABUO7ZO3OzOKDRQF+vlJwKyyMk+ZZoziZEuhGdPIRw1 9ERLEa6dIr+6/Tg+2FU9Or+Mxgi8Rq8f+w+9IWM31s7xm9baANKj5tUvYTTx7YwMRn2Ec1uZrXh o4apIBQRpTin0/PvKg/Ep6U+qgeyHm9Girgtg7JnXdhe0tmlCKNlOfFMBfkrVFIpTBWpsmHUWJW utmLtLHEvyg785OBShXgUQ0omNJJFWtyK+cG26pXrgH4Hss+HaZA1t+czSLYXbXVtgoZrjeWtuL EeARew2kdz6lUF3iP9cSggPYFxUK3r1/zmX0OMTOjM/t6msgkevOHKqFKDhYU5mLVweglk4XgtQ RKu06LH3l6CHiiqoKVn6xDzqH3E5CFEMBv/uuipNYkZBUvri40SmhSXnCBDcsPR0TdHE7bmyk4s wdWwRUa3YRn204pDaQ+cRqvXc40ik4SLms2YvQdvAzSAsszmGtGqcX+Zn5+/bNFT6Mx4s9CQP8j siJmsFTisDHOoA= X-Received: by 2002:a05:6000:2008:b0:439:d73d:95e with SMTP id ffacd0b85a97d-439da66a476mr25320352f8f.27.1773138407218; Tue, 10 Mar 2026 03:26:47 -0700 (PDT) Message-ID: <4a5018a2-9867-432b-9464-874532241316@suse.com> Date: Tue, 10 Mar 2026 11:26:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] x86: Remove x86 prefixed names from hvm code To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-4-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-4-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > struct cpuinfo_x86 > .x86 => .family > .x86_vendor => .vendor > .x86_model => .model > .x86_mask => .stepping > > No functional change. > > This work is part of making Xen safe for Intel family 18/19. > > Signed-off-by: Kevin Lampis > --- > I couldn't find any information about these Intel family 6 processors: > model 0x5d: /* SoFIA 3G Granite/ES2.1 */ > model 0x65: /* SoFIA LTE AOSP */ > model 0x6e: /* Cougar Mountain */ > Should I add them to intel-family.h? We should keep that in sync with Linux, I think, so "no" unless you mean to first have respective entries added there. 0x5d is listed in the SDM, so I'd recommend keeping the entries (using IFM() directly for the time being). 0x65 and 0x6e aren't listed in the SDM, so may never really have hit the public. Respective cases can perhaps be dropped, but such dropping would again likely better be done in a separate change. > @@ -3073,71 +3077,71 @@ static bool __init has_if_pschange_mc(void) > * IF_PSCHANGE_MC is only known to affect Intel Family 6 processors at > * this time. > */ > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - boot_cpu_data.x86 != 6 ) > + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || > + boot_cpu_data.family != 6 ) > return false; > > - switch ( boot_cpu_data.x86_model ) > + switch ( boot_cpu_data.vfm ) > { > /* > * Core processors since at least Nehalem are vulnerable. > */ > - case 0x1f: /* Auburndale / Havendale */ > - case 0x1e: /* Nehalem */ > - case 0x1a: /* Nehalem EP */ > - case 0x2e: /* Nehalem EX */ > - case 0x25: /* Westmere */ > - case 0x2c: /* Westmere EP */ > - case 0x2f: /* Westmere EX */ > - case 0x2a: /* SandyBridge */ > - case 0x2d: /* SandyBridge EP/EX */ > - case 0x3a: /* IvyBridge */ > - case 0x3e: /* IvyBridge EP/EX */ > - case 0x3c: /* Haswell */ > - case 0x3f: /* Haswell EX/EP */ > - case 0x45: /* Haswell D */ > - case 0x46: /* Haswell H */ > - case 0x3d: /* Broadwell */ > - case 0x47: /* Broadwell H */ > - case 0x4f: /* Broadwell EP/EX */ > - case 0x56: /* Broadwell D */ > - case 0x4e: /* Skylake M */ > - case 0x5e: /* Skylake D */ > - case 0x55: /* Skylake-X / Cascade Lake */ > - case 0x7d: /* Ice Lake */ > - case 0x7e: /* Ice Lake */ > - case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ > - case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ > - case 0xa5: /* Comet Lake H/S */ > - case 0xa6: /* Comet Lake U */ > + case INTEL_NEHALEM_G: > + case INTEL_NEHALEM: > + case INTEL_NEHALEM_EP: > + case INTEL_NEHALEM_EX: > + case INTEL_WESTMERE: > + case INTEL_WESTMERE_EP: > + case INTEL_WESTMERE_EX: > + case INTEL_SANDYBRIDGE: > + case INTEL_SANDYBRIDGE_X: > + case INTEL_IVYBRIDGE: > + case INTEL_IVYBRIDGE_X: > + case INTEL_HASWELL: > + case INTEL_HASWELL_X: > + case INTEL_HASWELL_L: > + case INTEL_HASWELL_G: > + case INTEL_BROADWELL: > + case INTEL_BROADWELL_G: > + case INTEL_BROADWELL_X: > + case INTEL_BROADWELL_D: > + case INTEL_SKYLAKE_L: > + case INTEL_SKYLAKE: > + case INTEL_SKYLAKE_X: > + case INTEL_ICELAKE: > + case INTEL_ICELAKE_L: > + case INTEL_KABYLAKE_L: > + case INTEL_KABYLAKE: > + case INTEL_COMETLAKE: > + case INTEL_COMETLAKE_L: > return true; > > /* > * Atom processors are not vulnerable. > */ > - case 0x1c: /* Pineview */ > - case 0x26: /* Lincroft */ > - case 0x27: /* Penwell */ > - case 0x35: /* Cloverview */ > - case 0x36: /* Cedarview */ > - case 0x37: /* Baytrail / Valleyview (Silvermont) */ > - case 0x4d: /* Avaton / Rangely (Silvermont) */ > - case 0x4c: /* Cherrytrail / Brasswell */ > - case 0x4a: /* Merrifield */ > - case 0x5a: /* Moorefield */ > - case 0x5c: /* Goldmont */ > - case 0x5d: /* SoFIA 3G Granite/ES2.1 */ > - case 0x65: /* SoFIA LTE AOSP */ > - case 0x5f: /* Denverton */ > - case 0x6e: /* Cougar Mountain */ > - case 0x75: /* Lightning Mountain */ > - case 0x7a: /* Gemini Lake */ > - case 0x86: /* Jacobsville */ > + case INTEL_ATOM_BONNELL: > + case INTEL_ATOM_BONNELL_MID: > + case INTEL_ATOM_SALTWELL_MID: > + case INTEL_ATOM_SALTWELL_TABLET: > + case INTEL_ATOM_SALTWELL: > + case INTEL_ATOM_SILVERMONT: > + case INTEL_ATOM_SILVERMONT_D: > + case INTEL_ATOM_AIRMONT: > + case INTEL_ATOM_SILVERMONT_MID: > + case INTEL_ATOM_SILVERMONT_MID2: Can the Silvermonts please be grouped together? > + case INTEL_ATOM_GOLDMONT: > + //case 0x5d: /* SoFIA 3G Granite/ES2.1 */ // XXX ??? > + //case 0x65: /* SoFIA LTE AOSP */ // XXX ??? > + case INTEL_ATOM_GOLDMONT_D: > + //case 0x6e: /* Cougar Mountain */ // XXX ??? > + case INTEL_ATOM_AIRMONT_NP: Same for the Airmonts and ... > + case INTEL_ATOM_GOLDMONT_PLUS: ... the Goldmonts. > @@ -3431,23 +3435,20 @@ static void __init lbr_tsx_fixup_check(void) > * fixed up as well. > */ > if ( cpu_has_hle || cpu_has_rtm || > - boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - boot_cpu_data.x86 != 6 ) > + boot_cpu_data.vendor != X86_VENDOR_INTEL || > + boot_cpu_data.family != 6 ) > return; > > - switch ( boot_cpu_data.x86_model ) > + switch ( boot_cpu_data.vfm ) > { > - case 0x3c: /* HSM182, HSD172 - 4th gen Core */ > - case 0x3f: /* HSE117 - Xeon E5 v3 */ > - case 0x45: /* HSM182 - 4th gen Core */ > - case 0x46: /* HSM182, HSD172 - 4th gen Core (GT3) */ > - case 0x3d: /* BDM127 - 5th gen Core */ > - case 0x47: /* BDD117 - 5th gen Core (GT3) > - BDW117 - Xeon E3-1200 v4 */ > - case 0x4f: /* BDF85 - Xeon E5-2600 v4 > - BDH75 - Core-i7 for LGA2011-v3 Socket > - BDX88 - Xeon E7-x800 v4 */ > - case 0x56: /* BDE105 - Xeon D-1500 */ > + case INTEL_HASWELL: > + case INTEL_HASWELL_X: > + case INTEL_HASWELL_L: > + case INTEL_HASWELL_G: > + case INTEL_BROADWELL: > + case INTEL_BROADWELL_G: > + case INTEL_BROADWELL_X: > + case INTEL_BROADWELL_D: > break; I think it would be nice for the errata numbers to not be lost. > @@ -3476,19 +3477,16 @@ static void __init ler_to_fixup_check(void) > * that are not equal to bit[47]. Attempting to context switch this value > * may cause a #GP. Software should sign extend the MSR. > */ > - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || > - boot_cpu_data.x86 != 6 ) > + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || > + boot_cpu_data.family != 6 ) > return; > > - switch ( boot_cpu_data.x86_model ) > + switch ( boot_cpu_data.vfm ) > { > - case 0x3d: /* BDM131 - 5th gen Core */ > - case 0x47: /* BDD??? - 5th gen Core (H-Processor line) > - BDW120 - Xeon E3-1200 v4 */ > - case 0x4f: /* BDF93 - Xeon E5-2600 v4 > - BDH80 - Core-i7 for LGA2011-v3 Socket > - BDX93 - Xeon E7-x800 v4 */ > - case 0x56: /* BDE??? - Xeon D-1500 */ > + case INTEL_BROADWELL: > + case INTEL_BROADWELL_G: > + case INTEL_BROADWELL_X: > + case INTEL_BROADWELL_D: > ler_to_fixup_needed = true; > break; > } Same here then. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 10:48:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 10:48:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249978.1547384 (Exim 4.92) (envelope-from ) id 1vzudD-0007BI-69; Tue, 10 Mar 2026 10:48:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249978.1547384; Tue, 10 Mar 2026 10: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 ) id 1vzudD-0007BB-3S; Tue, 10 Mar 2026 10:48:07 +0000 Received: by outflank-mailman (input) for mailman id 1249978; Tue, 10 Mar 2026 10:48:06 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzudC-0007B5-L4 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 10:48:06 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9d99aa20-1c6e-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 11:48:04 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-439c4a93841so4842212f8f.1 for ; Tue, 10 Mar 2026 03:48: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 ffacd0b85a97d-439dadb29fdsm34852930f8f.16.2026.03.10.03.48.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 03:48:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d99aa20-1c6e-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773139683; x=1773744483; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=OU0Gcrr3SCErOq/JAQhv2N/NVZPEAl9WbVDQK1P+2t8=; b=bff/Zt1EChfkqtR7LiGd6fqk3oq+Y0jwRkQ8wkbLqYbUZ/2SKiEhdODFvyJQ4G77xw 8fV1eevgBWmGsaTuDQSAiA6Djp6xFja5DML/Q5ShaN2hqsWjFfu/dN8SOknBL3QHWC/V vodnOHl7+7YsP1+MLZFHA/CpzEwjuHD8AVfO/PLqb3B0/Bgdltlq6OrMky32vRsmreHc at1VmbLDIJdxvMSrBYt6IEK5h2FLP7Pi8dPgtDX3Q+AKKiFLnZ1QGoybap98gVyxEKt/ HH/7jvTs32/Dkhd8UNsBFAfjqgffGBthbce6pUIpxUlqOLpif1Z71zF49B+6DDq83wAL T+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773139683; x=1773744483; h=content-transfer-encoding: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; bh=OU0Gcrr3SCErOq/JAQhv2N/NVZPEAl9WbVDQK1P+2t8=; b=eJjKgBs8j6/lU08EuYhyLnVthreQCIPc0CkbDqDih5FrWq3VphcslqlVPqHd1emLqU 11MQiIr2Gu2i9qXneeA1pEXoP9STNCM9n5l6i8e/wccxD/F8AJ1wxqZsh+SEFCLvwsV0 Pgk1gdX3KXIqnMzlkNiPYNSuMN++97AMgyjoQRPELSdaKMnV5PpMLnLivRQGbqE1fQZi ptpCWbg9Ek5uvU/nKtKQejjsK+JO/Uw4CneTzeaYHqAeOlYsTYJMm8R2CViIok96bhz9 4PI9QBCEi88c1dm4vM8JaYfby7I6X+OQ7xcE5sVi2Q504mhvCQFemM7sR5sA2p4kPdD6 9L3Q== X-Forwarded-Encrypted: i=1; AJvYcCV4/818VRWOVmwzoeBngDp3Qzg18pA+KHTFe00Ikp6QJMDygz0zto1Pa2ySHW2V91wdlj/u35iGYR8=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy928sCo3uREMy+d/1vCMW8dqdpcaoacKXIzw1goWNI1I7v102w GJNPTa1s05cyW0VMNBbViWOmMOoaQWIxphfHysBa0XxyGij+VUbu2Pm/olCjqKL5Pg== X-Gm-Gg: ATEYQzxoFzfDpvToT1Ntq7pdbyJCIfRjFjX9Y0HcyU4AbdMNqQl0e/TNm/+9UezAXGO 4BTWrQLZMdAxlGDs1zzBHPahAAFzhWXJwsVGOHo7v8mRwJNK1P3pIGSuo66r+OmkidaBIn0j807 VgPQiYI7E+zgcS5zxtRolM8xC3fo+bhEBPIBeHSmTH+opiPhz2mtLoeGa9sW3d45zmvz5Xw4M6O OXAhdW3RtCUbHrH+fa7Hmg20NoEdB67K0W8j/0i8v75EuzRj7qNS6AXRncAHnNIKZpQCBdtkLzD QyLvUzE+XETHbtATlJHVP0u1Ga3kWGRdUUbhtlyEyeVC4WEaks+bOt0ONL3HEaVuLxyeO/lWxR1 NYTwHo8y/JB0b93QrJY7k+KZTcmJEsAsPtfvEgHYRqvGTWpITbZ8Wj/B/F5RW31JXwkI6kHGIa4 XlsEg7krpGZKd9Ew0NmNcNzDXd8opbka/YKnyXt+z6QWnV7UDPSzf+5dV5wJKOqDTaOM+uT/ta0 aQt9rja8u+76U1ANoQPxbWmOA== X-Received: by 2002:a5d:5c84:0:b0:439:b3ff:9ab9 with SMTP id ffacd0b85a97d-439da67c418mr26178050f8f.48.1773139683511; Tue, 10 Mar 2026 03:48:03 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 11:48:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/6] x86: Remove x86 prefixed names from x86/cpu/ files To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-5-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-5-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > struct cpuinfo_x86 > .x86 => .family > .x86_vendor => .vendor > .x86_model => .model > .x86_mask => .stepping > > No functional change. > > This work is part of making Xen safe for Intel family 18/19. > > Signed-off-by: Kevin Lampis > --- > Inside core2_vpmu_init() there is a check for family == 6. > Should this be extended to family 18/19? Likely, but again in a separate change. > --- a/xen/arch/x86/cpu/mtrr/generic.c > +++ b/xen/arch/x86/cpu/mtrr/generic.c > @@ -218,9 +218,9 @@ static void __init print_mtrr_state(const char *level) > printk("%s %u disabled\n", level, i); > } > > - if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD && > - boot_cpu_data.x86 >= 0xf) || > - boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) { > + if ((boot_cpu_data.vendor == X86_VENDOR_AMD && > + boot_cpu_data.family >= 0xf) || > + boot_cpu_data.vendor == X86_VENDOR_HYGON) { > uint64_t syscfg, tom2; Just to mention (not insisting on a change), the >= 0xf could be dropped, as older CPUs aren't 64-bit capable. > --- a/xen/arch/x86/cpu/vpmu.c > +++ b/xen/arch/x86/cpu/vpmu.c > @@ -398,7 +398,7 @@ int vpmu_load(struct vcpu *v, bool from_guest) > static int vpmu_arch_initialise(struct vcpu *v) > { > struct vpmu_struct *vpmu = vcpu_vpmu(v); > - uint8_t vendor = current_cpu_data.x86_vendor; > + uint8_t vendor = current_cpu_data.vendor; Imo we should take the opportunity to change this variable to unsigned int. > @@ -815,7 +815,7 @@ static struct notifier_block cpu_nfb = { > > static int __init cf_check vpmu_init(void) > { > - int vendor = current_cpu_data.x86_vendor; > + int vendor = current_cpu_data.vendor; Perhaps this one as well then. > --- a/xen/arch/x86/cpu/vpmu_intel.c > +++ b/xen/arch/x86/cpu/vpmu_intel.c > @@ -917,7 +917,9 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) > return ERR_PTR(-EINVAL); > } > > - if ( current_cpu_data.x86 != 6 ) > + /* XXX Does this need to be changed to include family 18/19? > + * Is the core2_ function name misleading? */ > + if ( current_cpu_data.family != 6 ) > { As indicated before, such comments better wouldn't be added here, imo. With it dropped and preferably with the type adjustments above (happy to carry out while committing, as long as you agree): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 10:50:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 10:50:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249986.1547394 (Exim 4.92) (envelope-from ) id 1vzufd-0000F8-J9; Tue, 10 Mar 2026 10:50:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249986.1547394; Tue, 10 Mar 2026 10: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 ) id 1vzufd-0000F1-Fv; Tue, 10 Mar 2026 10:50:37 +0000 Received: by outflank-mailman (input) for mailman id 1249986; Tue, 10 Mar 2026 10:50:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzufc-0000Et-AM for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 10:50:36 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f7004f13-1c6e-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 11:50:34 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439b9b190easo6265259f8f.2 for ; Tue, 10 Mar 2026 03:50: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 ffacd0b85a97d-439dae57401sm29081393f8f.38.2026.03.10.03.50.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 03:50:33 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f7004f13-1c6e-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773139833; x=1773744633; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=G6fvKaTpBbw6vpDPHysRCUkc3qx/GI/I0SvhAXdQ1Qg=; b=Qj5xkEs7aslGIFwuSD+H07MtDx2MDL6HiQNi7pergEsYI/Vc2JZDd6T+5ULknhr23N 8mejO+5aSPxO8t0oQzXXmXdVv3FoYujwFVb6DSFqIqVJBet7AD9csYwWW0+NEEfS2vTp 9Hoeldi9Ffcqg64akXeAmjedC+Ck8Bu6xGXQmKwldxdVMSfZb8j9g8zhTvd+NHjGFKWc abejTeNJp/qUep0anAYEp9DWkVpp+0/vUXrJnyU44l6val/uZLPjt9qfPtQoW6dMMnCr HMGfNSDC+dSCdZ4iVrxtPfxwpvbkJX7XDeM/cjymZrlMTliya66SOpwmPFgtv+Tf1u2M NRIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773139833; x=1773744633; h=content-transfer-encoding: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; bh=G6fvKaTpBbw6vpDPHysRCUkc3qx/GI/I0SvhAXdQ1Qg=; b=UnSbXDWjt89wgTkjbC/reVZP/lcqwfEWTFarrXdt3SMv2NRed5OwoLiVgIo0rvwvpW PGXYAp3hb1+fdYuNrJ1TSQ6lkASzSS/e/hlvnu/L81Nf1mia5GYqKx9qtif1HUQWVxlk 0Srkh/sKOGavjAspfKW3seD/uQfz2DR1TsdSlMfRNJux7GKyKfE9CEDTcT4kX+XBoc9R eHEpMnLmO0ewoqKRLMtjw5W2P63wZ/qbO7uxOy1hKjflXcQq1mRM0k2ZEVbA2sLiv/JG /pKRTB/OTUTAJf0NUNS7zkfgvVGZ26C2fwNZ19OvCOnsK2h9OOZzrXRzAMfS1WJeCIar CVgg== X-Forwarded-Encrypted: i=1; AJvYcCXZebBfMqmAKOm/ufxdByY3RqviUc2TwAij/8MhlPRY+7AJsQ3h5FRopoNGXz+6o6NAa9Wi+R/CJps=@lists.xenproject.org X-Gm-Message-State: AOJu0YwzCgQ1CXGxUBRZKtZYRrTByIx5uev29FyxishrE7ZlZaDWZ4uY He+6A5Fmvyur1pScjazD/3W6TZ0nAKOhOdoA5y/Eefhdoku1ugAscLCyXNnoAkE5rPr7a2uze4s 7PV4= X-Gm-Gg: ATEYQzw8O6B7I2+ENffi/muAsoVKbVktM1Xl108H93ANJr0Jkv/rgzzMOY7S/Cjs+Hh VuAVNjlkAt3nA4qNlsh8BUqQYEP8/Ii/vE1CkUcyfIVnKmd6GczM5qKQks4R9zlraysq+lp8MjL 4FHlWllsNZGAm6We+uVTQVcHVdDvH9BiAPCXurcDtOUIIZKltVqL5Ut+y3FybPcfVwA3hs6cbZC 9mz1csGP54/GMQLjCkR+6FRsGV7MPifZGNaIP705bXLFJfCeQLwgV/TRjDa/l6r6LAKR4+44wIa JUKVvrxw3f+qdu+0d98XJRughLv3kPtGTYAMomZa64uKaEAM2iBQIKzygHRG+nld3T3UUmkON/i 1+vkoN427ccl/Ll+l0XE7sNfOWtiS//VjLTwgHy56zteTdSt/1/Ias0rUm4vL8hJLRY2AhTmyl5 5Uv03p7Xv7rbj+NyCbg+KJYHkx+539/GFGhEcYaPAiMn0PA/Yo1kuYyh/1f9fLdPWXE+ba01yL4 j1JqjqUXm5XGBg= X-Received: by 2002:a05:6000:310b:b0:439:bc2b:cb50 with SMTP id ffacd0b85a97d-439da348173mr27037766f8f.4.1773139833489; Tue, 10 Mar 2026 03:50:33 -0700 (PDT) Message-ID: <0f184667-6b62-466c-bb07-393f2b3ca759@suse.com> Date: Tue, 10 Mar 2026 11:50:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6/6] x86: Remove x86 prefixed names from cpuinfo To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-7-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-7-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > --- a/xen/arch/x86/include/asm/cpufeature.h > +++ b/xen/arch/x86/include/asm/cpufeature.h > @@ -43,19 +43,15 @@ > #ifndef __ASSEMBLER__ > > struct cpuinfo_x86 { > - /* TODO: Phase out the x86 prefixed names. */ > union { > struct { > union { > - uint8_t x86_model; > uint8_t model; > }; > union { > - uint8_t x86; > uint8_t family; > }; > union { > - uint8_t x86_vendor; > uint8_t vendor; > }; > uint8_t _rsvd; /* Use of this needs coordinating with VFM_MAKE() */ > @@ -63,7 +59,6 @@ struct cpuinfo_x86 { > uint32_t vfm; /* Vendor Family Model */ > }; > union { > - uint8_t x86_mask; > uint8_t stepping; > }; > But then all the now unnecessary unions also want to go away? Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 10:58:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 10:58:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1249996.1547403 (Exim 4.92) (envelope-from ) id 1vzumi-0000wR-9B; Tue, 10 Mar 2026 10:57:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1249996.1547403; Tue, 10 Mar 2026 10:57:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzumi-0000wK-6G; Tue, 10 Mar 2026 10:57:56 +0000 Received: by outflank-mailman (input) for mailman id 1249996; Tue, 10 Mar 2026 10:57:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzumh-0000wE-47 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 10:57:55 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fc8fcf2f-1c6f-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 11:57:53 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4852ff06541so30154225e9.2 for ; Tue, 10 Mar 2026 03:57: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-485244b6e9esm202889655e9.5.2026.03.10.03.57.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 03:57:51 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fc8fcf2f-1c6f-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773140272; x=1773745072; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=GDrKToaCfFiwyWhaD+7oB4TG1h69l9pLvYTca8ZWrOY=; b=Is9tX7uQZ8+u4WKo8vGGV76aaOpN+OVvnetrxGn0cXVbj7vou7UUVGDK3m4L5M4hGE MGxrkU8dqioYaPRdzFNVP9iySWp4tWBM8gMWQoyaXLRH9AZeicY6zLDwYoawIUSuFSnp Wvd5pW+DnMsmItEfJq1Nr3lY/KIdeclVINdKNU0zgptzbk6g+3ICtR4Rwh1XdVRUkwed lRgjq1JOne54RO/VrDf3no2MpxCi+CHThvHMEfkFl0MoIKAQg5l/lHBZaF/xf6dTq0LD LRO8v2+490TqUyeyREov/rdown7N1z7q1aKZ4LmY1giaw9niZHAHc4CQg5PG8+365pKg JwCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773140272; x=1773745072; h=content-transfer-encoding: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; bh=GDrKToaCfFiwyWhaD+7oB4TG1h69l9pLvYTca8ZWrOY=; b=X1E9bcMhN9g7f3sgviA8Wiuj4kWiSdAPEtPa8Kwhc8Rnfkjc10yvMJQngB7WJgwE7i Y/Q1lVaqS5Uk6nZFJHkqSHZj3D5f94oVWbsJNYuWlcqX2itW6u0K2HT71/YIiIpD+OW8 OSkeIJh4JjQMV0wkla0IucNHZWmeZXl4LwC5QTBNzSQNFj9blpsLt/v3Csdy+XJ/f7D+ nXGb1UHwIY0JnY90uPakxbkkUJRwZKJfd9liV2QEUvFWNQGTjA+NkQkJyB/2n4jqagCq KU+1uTr6Dd0WWrsp2Q2Pd1fvYKfgtOgqE2EjL2U6opfWb9hwbYpP9wW5bXj/vT4O2uez REFA== X-Forwarded-Encrypted: i=1; AJvYcCW6OQoHTvdR7gzEo2rd9yuM8+PPETv+8LK9V/u41Tmbs5adRNvPAZcSRyXDk05LOKCYY+Rn1WYF3XI=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxa6/+PEueg3johBPRyB5uCI08QLSeG/QKiPDRE2sXDyMHO3sCO zOj2w3U3PxkU5Douw/J3yD+NRwQDqRykWwV1XVDaqIIRuXNQvXwCZ255BsRJ2WgJMw== X-Gm-Gg: ATEYQzz1rt4pcEEZo9ZJM9d5z6ykWIvFN8hnwBo7uS/A0Z76+9CZzz2LUbdwCiHKUBx 5TXMrXO8McpbFS+CIprSf2h2wCnXAlSzN9d++VH9HkyF/ovgDQBX9Yr2zGo/37tH7x0jPVZWPqq Yqx46tVOD0xJ+wZ6wjth/3r/Gjd1FdQphGONeMwDflKJ5xLrsTr3ILuOU6M70hAEBVvNLwuLP1w h9Aq/mOsri5Cq206v6nQksqCl9nabCz77QZOrN7FbUdEr+0vjQgzte+RMzr37sTrW10e2VvAXUO wXkhT0UirkD3e2tDG1f6UjFwpnHCPub88VVBUQOwksX/seBduKyx9CPy9OB0NEc/27PMe50qbhV QUs0AblR+K9DoAg7g2ljnmjEg3F/2Y7AvSXn5c4R8n7WNHH9zWswgKq53OsiQ2DFQT2lBjlNYvx cJnve643C9LhzJe8X47+XIaorfZ/oAgv3D38brhNsxBLm/ey21a2Z7emwRpPDHXbJ41VGCm4Sd2 FO7K7n/8QXSdOQ= X-Received: by 2002:a05:600c:1e88:b0:477:6d96:b3e5 with SMTP id 5b1f17b1804b1-48526916beamr265027065e9.7.1773140272233; Tue, 10 Mar 2026 03:57:52 -0700 (PDT) Message-ID: <785c0042-55c6-4738-aad3-fd88bee3f047@suse.com> Date: Tue, 10 Mar 2026 11:57:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/6] x86: Remove x86 prefixed names misc To: Kevin Lampis Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, xen-devel@lists.xenproject.org References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-6-kevin.lampis@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260304195350.837593-6-kevin.lampis@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 04.03.2026 20:53, Kevin Lampis wrote: > --- a/xen/arch/x86/nmi.c > +++ b/xen/arch/x86/nmi.c > @@ -216,12 +216,12 @@ void disable_lapic_nmi_watchdog(void) > { > if (nmi_active <= 0) > return; > - switch (boot_cpu_data.x86_vendor) { > + switch (boot_cpu_data.vendor) { > case X86_VENDOR_AMD: > wrmsrns(MSR_K7_EVNTSEL0, 0); > break; > case X86_VENDOR_INTEL: > - switch (boot_cpu_data.x86) { > + switch (boot_cpu_data.family) { > case 6: > wrmsrns(MSR_P6_EVNTSEL(0), 0); > break; I think here we would benefit from switching to Xen style at this occasion. Fair parts of the file are already Xen style, and this function would then end up almost correct. > @@ -362,7 +362,7 @@ 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.x86_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); This may want leaving as is, to match the rest of the function, but ... > @@ -387,16 +387,16 @@ void setup_apic_nmi_watchdog(void) > if ( nmi_watchdog == NMI_NONE ) > return; > > - switch ( boot_cpu_data.x86_vendor ) > + switch ( boot_cpu_data.vendor ) > { > case X86_VENDOR_AMD: > setup_k7_watchdog(); > break; > > case X86_VENDOR_INTEL: > - switch (boot_cpu_data.x86) { > + switch (boot_cpu_data.family) { ... this (again to match the rest of the function) would want adjusting again. With that (again, happy to make the adjustments while committing): Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 11:32:05 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 11:32:05 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250010.1547413 (Exim 4.92) (envelope-from ) id 1vzvJV-0005zp-Qc; Tue, 10 Mar 2026 11:31:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250010.1547413; Tue, 10 Mar 2026 11:31:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvJV-0005zi-M9; Tue, 10 Mar 2026 11:31:49 +0000 Received: by outflank-mailman (input) for mailman id 1250010; Tue, 10 Mar 2026 11:31:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvJU-0005za-8T for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 11:31:48 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b7b7a833-1c74-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 12:31:45 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48538c5956bso23029415e9.0 for ; Tue, 10 Mar 2026 04:31: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 5b1f17b1804b1-4852378de92sm176118465e9.0.2026.03.10.04.31.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 04:31:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b7b7a833-1c74-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773142304; x=1773747104; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=m/m5As2KkE3vFRnY7bzO3q+1AL0PAuceDrUlhe1039g=; b=OaxJmuvRVVNZAS9VFTLyKEM9lWNzZDfGlq0j7TC5gjuEaqrm/c/bmoO8ZR+rJOarOF xHhm5GgY90u8G8ItxCSS1amNgQuQtgcO+CZA1t1KVmWe5FOw7+P9D24mOLCvt1Cd41BV 4MajdWf5UWiBFogIRCqA0+isy6aJNIOvh/px3zvgR11WS8crnlRtprdvH8leljYAmUlv m88EqijI/lw3jXdcvMfgvn/uzpmO+NXkNpdT9ZOZeV76w0Re1UqotZ+uZSfh9w0eHMTW sWJaYGq78gD4DF7mB3FKiD1SI50nF9Dfk2smUzZU29C3V2brsjmfgJAb/puWyuHPHsQc 3GkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773142304; x=1773747104; h=content-transfer-encoding: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; bh=m/m5As2KkE3vFRnY7bzO3q+1AL0PAuceDrUlhe1039g=; b=jS9CM3vcaxu6ourpjC1u5KqeTlPqvgangztiYZw2O/u7cExRt6PxjoQmQ49xtURvZh yvGWOXz/HOBZiA9GHH2v2v0g8ptswrG+/altEjqEB6E1603I+yeVA51bC19jveWZunQO t5viBTvaUi4seAVeKO5vLcLAKUktzPevGGJBpKoDDxnEHhuLwV6LYqWTKDX523OOM3pr +l6aFzd14/mTHr8kb5QkH90iSukcgMo+4fKKvvpX1SY8aWDj0NsObIqk/OH6dfv4C76E OIF4UK8sAhyiFTKOLcK7tOjR42scF5C2svI1BFiJq+Gl6y2c2+W2vSD/SkrwIQwfksyv FCTQ== X-Forwarded-Encrypted: i=1; AJvYcCW+jQIM7eX8SPRXB93Mch1p5iThY8+DGUB3U+odMAEZ4+kJnTIqfW/euzmXeROde9+qNZAae5i4ha8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzxKMMoaOfvt/j71Z5dA8l3rJgAc3qL7cQy916j1ElB+xpQvk37 X40zI2Ts3/J4DJszbFcy1mVHL2BH/T7q87kyvF8cP4Yfvv6EkU3/9uSifO29jPXoDQ== X-Gm-Gg: ATEYQzzawb2LItQWbUa/x631/WGMkCAVojI396VkbyXFKnkm06cgHy2fGzQhd9uH5KV N6LWC8I2ck7RmGr3ceskw41aPaYLUegvU+sDXvFvTs0UlJJUp44It5ggQJy8bt4diqLs5VTZT1e JQ6EkP4af0xUeK37UB0m5CazmVFjDBvWTLglh9vEFcgS/9zTFPhc/rt6e0NV2ekBSDj9HL0h4yZ tl40DbqiG8ODCYRE/3eY7KqjEYppRv+LHqXXf6xHebljVhou8fnY4VqROxfw2qxuwHORpmrniix B2ElF9wMNF9JMiPRAQh7Ce0JhILrJeE+xLr2W2k2i/4HtioYTJCa65S8QjkODOQ4K+u4DofV+Qr F3tVziX9JkZ8pq5lyhyKUPYMo6EZ8FNPn7dTDA7dz+35bVyPli0bN9f2VNFzRK+w18acQUfl/pm 3OzI1pvPAXm57vcYOoylxXyOWxElM/+kXAibxPUyE4eXsgyWGAEOiqNk6fJhL1SxvSwLpHdqkVj dYf0zPzbfIbmks= X-Received: by 2002:a05:600c:138e:b0:485:3e00:944a with SMTP id 5b1f17b1804b1-485419d759amr50541695e9.9.1773142304057; Tue, 10 Mar 2026 04:31:44 -0700 (PDT) Message-ID: <7fe8339f-5bec-46d2-88d3-ca7d2d45006b@suse.com> Date: Tue, 10 Mar 2026 12:31:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] x86/efi: Add BGRT image preservation during boot To: Soumyajyotii Ssarkar Cc: "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Andrew Cooper , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> <20260306132935.13727-2-soumyajyotisarkar23@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260306132935.13727-2-soumyajyotisarkar23@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2026 14:29, Soumyajyotii Ssarkar wrote: > @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) > efi_bs->FreePool(memory_map); > } > > +struct bmp_header { > + uint16_t signature; > + uint32_t file_size; > + uint16_t reserved_1; > + uint16_t reserved_2; > + uint32_t data_offset; > +} __attribute__((packed)); > + > +/* > + * ACPI Structures - defined locally, > + * since we cannot include acpi headers > + * in EFI Context. > + */ > + > +struct acpi_rsdp { > + char signature[8]; > + uint8_t checksum; > + char oem_id[6]; > + uint8_t revision; > + uint32_t rsdt_physical_address; > + uint32_t length; > + uint64_t xsdt_physical_address; > + uint8_t extended_checksum; > + uint8_t reserved[3]; > +} __attribute__((packed)); > + > +struct acpi_table_header { > + char signature[4]; > + uint32_t length; > + uint8_t revision; > + uint8_t checksum; > + char oem_id[6]; > + char oem_table_id[8]; > + uint32_t oem_revision; > + uint32_t asl_compiler_id; > + uint32_t asl_compiler_revision; > +} __attribute__((packed)); > + > +struct acpi_xsdt { > + struct acpi_table_header header; > + uint64_t table_offset_entry[1]; /* Variable array length */ > +} __attribute__((packed)); > + > +struct acpi_bgrt { > + struct acpi_table_header header; > + uint16_t version; > + uint8_t status; > + uint8_t image_type; > + uint64_t image_address; > + uint32_t image_offset_x; > + uint32_t image_offset_y; > +} __attribute__((packed)); > + > +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE *SystemTable) > +{ > + EFI_GUID acpi2_guid = ACPI_20_TABLE_GUID; > + struct acpi_rsdp *rsdp = NULL; > + struct acpi_xsdt *xsdt; > + struct acpi_bgrt *bgrt; > + uint32_t entry_count, actual_size; No need for fixed-width types here, I expect (see ./CODING_STYLE). > + unsigned int i; > + > + for ( i = 0; i < SystemTable->NumberOfTableEntries; i++ ) > + { > + if ( match_guid(&acpi2_guid, &SystemTable->ConfigurationTable[i].VendorGuid) ) > + { > + rsdp = SystemTable->ConfigurationTable[i].VendorTable; > + break; > + } > + } Why would this be needed, when efi_tables() has already run? > + if ( !rsdp || !rsdp->xsdt_physical_address ) > + return NULL; > + > + xsdt = (struct acpi_xsdt *)rsdp->xsdt_physical_address; > + if ( !xsdt ) > + return NULL; > + > + actual_size = (xsdt->header.length - sizeof(struct acpi_table_header)); > + entry_count = (actual_size / sizeof(uint64_t)); Pleas prefer sizeof() over sizeof(), such that as a reader one can know what is actually meant. > + for ( i = 0; i < entry_count; i++ ) > + { > + struct acpi_table_header *header = (struct acpi_table_header *)xsdt->table_offset_entry[i]; > + > + if ( header->signature[0] == 'B' > + && header->signature[1] == 'G' > + && header->signature[2] == 'R' > + && header->signature[3] == 'T' ) Nit (style): If this was to not be replaced by a suitable function call, the operators belong at the end of the earlier line (again see ./CODING_STYLE). > + { > + bgrt = (struct acpi_bgrt *)header; > + return bgrt; > + } > + } > + return NULL; > +} Nit (style): Blank line please ahead of the main return statement of a function. > +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject if bigger */ > + > +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTable) > +{ > + struct acpi_bgrt *bgrt; > + struct bmp_header *bmp; > + void *old_image, *new_image; > + uint32_t image_size; > + EFI_STATUS status; > + uint8_t checksum; > + unsigned int i; > + > + bgrt_debug_info.preserved = false; > + bgrt_debug_info.failure_reason = NULL; > + > + bgrt = find_bgrt_table(SystemTable); > + if ( !bgrt ) > + { > + bgrt_debug_info.failure_reason = "BGRT table not found in XSDT"; > + return; > + } > + > + if ( !bgrt->image_address ) > + { > + bgrt_debug_info.failure_reason = "BGRT image_address is NULL"; > + return; > + } > + > + old_image = (void *)bgrt->image_address; > + bmp = (struct bmp_header *)old_image; > + > + if ( bmp->signature != 0x4D42 ) > + { > + bgrt_debug_info.failure_reason = "Invalid BMP signature"; > + return; > + } > + > + image_size = bmp->file_size; > + if ( !image_size || image_size > MAX_IMAGE_SIZE ) > + { > + bgrt_debug_info.failure_reason = "Invalid image size"; Why "invalid"? The cap is arbitrary, isn't it? > + return; > + } > + > + status = efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &new_image); > + if ( status != EFI_SUCCESS || !new_image ) > + { > + bgrt_debug_info.failure_reason = "Memory allocation failed"; > + return; > + } > + > + memcpy(new_image, old_image, image_size); > + > + bgrt->image_address = (uint64_t)new_image; > + bgrt->status |= 0x01; > + > + bgrt->header.checksum = 0; > + checksum = 0; > + for ( i = 0; i < bgrt->header.length; i++ ) > + checksum += ((uint8_t *)bgrt)[i]; > + bgrt->header.checksum = (uint8_t)(0 - checksum); > + > + bgrt_debug_info.preserved = true; > + bgrt_debug_info.old_addr = (uint64_t)old_image; > + bgrt_debug_info.new_addr = (uint64_t)new_image; Seeing how you need to cast here, imo using pointer type fields and ... > + bgrt_debug_info.size = image_size; > +} > + > /* > * Include architecture specific implementation here, which references the > * static globals defined above. > @@ -1794,6 +1968,19 @@ void __init efi_init_memory(void) > if ( !efi_enabled(EFI_BOOT) ) > return; > > + if ( bgrt_debug_info.preserved ) > + { > + printk(XENLOG_INFO "EFI: BGRT image preserved: %u KB\n", > + bgrt_debug_info.size / 1024); > + printk(XENLOG_INFO "EFI: BGRT relocated from %#" PRIx64 " to %#" PRIx64 "\n", ... %p here would be preferable. With any casts between uint64_t / UINT64 and pointer types you need to be aware that these will cause issues the moment we gain a 32-bit use of this EFI interfacing code. Hence the fewer such casts, the better. > + bgrt_debug_info.old_addr, bgrt_debug_info.new_addr); > + } > + else if ( bgrt_debug_info.failure_reason ) > + { > + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n", > + bgrt_debug_info.failure_reason); Did you verify this actually works? efi_preserve_bgrt_img() runs when we're still in physical mode, and hence the pointers stored will be physical addresses. Whereas here you need virtual ones. A trick to use may be to initialize the field with a pointer to a string literal (perhaps simply an empty string). That'll cause a relocation to be emitted for the field, and hence the pointer will then be relocated together with the rest of the Xen image. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 11:34:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 11:34:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250020.1547421 (Exim 4.92) (envelope-from ) id 1vzvLc-0006XM-8O; Tue, 10 Mar 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 1250020.1547421; Tue, 10 Mar 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 ) id 1vzvLc-0006XF-4i; Tue, 10 Mar 2026 11:34:00 +0000 Received: by outflank-mailman (input) for mailman id 1250020; Tue, 10 Mar 2026 11:33:58 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvLa-0006X8-Db for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 11:33:58 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 05d3dd45-1c75-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 12:33:56 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-485345e1013so18732085e9.1 for ; Tue, 10 Mar 2026 04:33: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-48541a7f1f5sm123068205e9.4.2026.03.10.04.33.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 04:33:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 05d3dd45-1c75-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773142435; x=1773747235; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=6nXiOBgpVqJzWlI7izeUdI7naL+DVopaSDZJu+av888=; b=CgLsRoJipRV+qyYfPsT4bH9qKFyGlg+yPPXlWEfCPHRVVtBhUWrZiaYbGGIkzzZquZ UiwAdQ2xLQ2WEsbQK4RHYDBqmcoW8gcaGn2XkYzBCHvjGItblGVQcc1arLSHWT98FecV y7WiDmMuPVzd8ps6waMvfZzcKzfNEfz47ncU1BQc5TqNO9qZQhC5nT6cP/h88BWt63S8 2WzwuM8+OEE9ghC+hhCcYKy8SHkPpAXkTBYE6jTjg+Hngh4bwIUa6omPyVYk+AflPBzN MYfoOUYJz4bNqkfyUyXvSJEGBF1JU/ksgR+t+iQrY8IFV+LAlf3y0bh3yQVaOL3gwmLb 5MYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773142435; x=1773747235; h=content-transfer-encoding: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; bh=6nXiOBgpVqJzWlI7izeUdI7naL+DVopaSDZJu+av888=; b=nX3xEKiHVWqWwgwVP/Z1/qkIjADNm+/3x/Z7gMapC/3iz5qxzuhFqrxzeozVIt2t32 dVdHkMUyRG75v+fUP7IarAf1E4dom8BqVfdeatL2k4ExLKjln/DCE6AHi/r/JGEkY10F ZmstLDhgFaDnGxshyMoJt1bOQoqh1LC3Zbe8E6yh/QGxKAeDIlE4psEzfEwrNhHMHrd+ XmqjVOmfENOUMpwdNgDH4YSqO4A4wmd2y8vQ9a1doX7S2/oTQ4GWA4o9dIikle+joWEo 8mHjE3iqv26m3OQTTsGaefedWyWwerhw+lu91eVKZcUSLUoT0bw3hjxY8Ls+ryS8XE3r IsFw== X-Forwarded-Encrypted: i=1; AJvYcCWNd+4IuBYmDq5EGN3i6lfcgtO/C9UEYctgE0//ZCsPh0QQhbzSWW54WINfQXq4e5r72nGdb6WWbX4=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywn/s1z2UlzyZnBFkhQltkhYQnT5VYTm1yJIdaa32UsHWnEQq3D PGFknpHBJgDpKtBBHDAgWDhPHBYzYyFCtJ3IFYEg39E7PVbYDVgoKiXAL8EBxipJ9A== X-Gm-Gg: ATEYQzxvQC05t+AXcj+5ldb8hiVg31EUb4sIQUmqmYgCOXGp+P4eqGyDj+Y4lOcKVsq Qf0Mn30kpoD9tznLSOkaDHyKGQQfe2o1ZMCcQcHLlcu6nFdzPpMH2/OmO9Mx8LRApt2Nx7F3reH NstNYZ9TBzikU/tSR7j30vs5GPAaZJG/SBXoKUVTVE+mmf6JVv8GdJUtSLXs0xV36m5ONdYzbGP jVodIH180JpPjBSKJcSQLjyfzNIP5nW45WpcLa+kqf7rycTSqj1Ki+RakrXZCOPFyXx/NNcVZdB DEDg+o/4YaCF0LacdTrD82cmbaqNrp165gyrdHcjgNbRGY29+xsTJ3zIG2B724VEV46+lXLq6Re aSdkwaTlZCnQ2f65JanHJhgk222At1Ev8oVxvlmd90C/hRE7Cc0aHacS7M+8ZfZVP29XYBDMQ9U wyzf36K14MJ4XSKEi55nfp5aAUExFFzLnbn0hX6Qso59kWcJ3haVnwigsDuSNyQXFtC08XJYH8Q SCjJW685xD6rhA= X-Received: by 2002:a05:600c:8488:b0:485:3989:b3e4 with SMTP id 5b1f17b1804b1-485419b61a2mr45900475e9.6.1773142435531; Tue, 10 Mar 2026 04:33:55 -0700 (PDT) Message-ID: <6df95cb0-3f01-43a6-abc5-0e464c3c98e9@suse.com> Date: Tue, 10 Mar 2026 12:33:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] x86/acpi: Clarify BGRT invalidation behavior with preservation To: Soumyajyotii Ssarkar Cc: "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Andrew Cooper , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> <20260306132935.13727-3-soumyajyotisarkar23@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260306132935.13727-3-soumyajyotisarkar23@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2026 14:29, Soumyajyotii Ssarkar wrote: > Now that BGRT images are preserved during EFI boot (via > EfiACPIReclaimMemory allocation), the invalidation code in > acpi_parse_bgrt() is no longer needed. > However, The original invalidation code acts as a safety net for when > preservation fails or is disabled via "efi=no-bgrt". > > Thus, Add comments to clarify this behavior for future reference. > > Signed-off-by: Soumyajyotii Ssarkar Acked-by: Jan Beulich I wonder though if this wasn't better folded into the earlier patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 11:41:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 11:41:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250031.1547430 (Exim 4.92) (envelope-from ) id 1vzvT6-0008Ha-VW; Tue, 10 Mar 2026 11:41:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250031.1547430; Tue, 10 Mar 2026 11: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 ) id 1vzvT6-0008HT-SV; Tue, 10 Mar 2026 11:41:44 +0000 Received: by outflank-mailman (input) for mailman id 1250031; Tue, 10 Mar 2026 11:41:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvT6-0008HN-FR for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 11:41:44 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1bbdaf51-1c76-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 12:41:42 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-439b9b190easo6310984f8f.2 for ; Tue, 10 Mar 2026 04:41: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-439dae2ba5bsm33679643f8f.22.2026.03.10.04.41.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 04:41:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1bbdaf51-1c76-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773142902; x=1773747702; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=0r05h2blS+gYEN1+6JRpyqm3ySQPHfmFxeqRQ6IxccM=; b=dJWHuGX7uATfmk07gjjZyTfhGPcdQlGCN7OaoG3nl/qf1gfhvNKeGFNbfyjulv38si Edj9KNPHBNabGcBUiEg9J6dglGKAr+lVA5ZiyYwj/FSpOTc+S9in/cvIpQqiK3BESYOs 3tr3/HJ67ElW8tRLqk25cfVOTooNeaHwqV2rj7OswC9O7lHRYf5Cjwm4GihibsHWuOKR +E5d5Gk9c7RPQc/keZMqzobn4PRNfdftjJ9GtepyVYNBOstwLxR1LSQyNZgDe4Urfimf pyQuwOzKgffTy4SaxkOUGPuLpKALCLK//dUbdAYtu9f1G8ITh+eMJKuYJRinNZeQx+2J ReIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773142902; x=1773747702; h=content-transfer-encoding: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; bh=0r05h2blS+gYEN1+6JRpyqm3ySQPHfmFxeqRQ6IxccM=; b=YcysgiWu42EsPQI2ZkpDfAOcd4zGyUVHxF5Cg8LpZ+URTF9xdj4L+A7du4XMxgDrht BJqXu3sGMASbAQmwMFuS7F8TVubT1A/iJEbKfMuQzxDO/cH4E7PeX3HHui036pmx1+p+ XqtYBCtpu4VeI9dycjtc20+a3xpoH3auYVuaVyVzhRdAbo//T8eiNWW6BMx2YdN0FJdG w0AATnFYg3TM8VAed+9Sjk3HiwdalMP/XMy+vJCeJOCHbTsRyujdusC0FRDGO5enWrMv d8QdT8Ft8OIAvF0dqC3M57utDvKwWTom1JzYvSMuQD5mbr2E7Q0RjaTuQunk42qEqUOH 17zQ== X-Forwarded-Encrypted: i=1; AJvYcCUKVBtSX/w6snpbvTFuTFHEHO9AKzOByE/gZ4MTLoPAckHh9pjsV05aVkUVShZrnKDuHYovNb7bF+k=@lists.xenproject.org X-Gm-Message-State: AOJu0YxJ1tAnU+luJJ2qlySGBuEmATOw21dFL9MUM86jgK3K9/SGV77x XiNEUqJ+QeWBjUBtPZQnKdq50mU24yyHhpC2HCHyCAY3tTnvYlJwwdi8w375sD/S+A== X-Gm-Gg: ATEYQzwQ8+8Di9YzFnS1EJx+ImVwtcxFQG0+lqRxLFZW3diNJM4dZextBFVlK722Hs4 BCCac54bpblh1dgBP8hsQNOseZdalJweqgppdrNXEx99+aZdmmx82YdNlAIJfYUt+kLZXmLNd6p X7G4WYCerC5KzhRCR+Zsct7AwtBJ5SKxn28VIk1Kgpnz7T1FBOPZvFF1tQMqESpv9WqPS6Epogl 34YtZecAyLx7U/YeM3JdmPDql70DF7rNa4goTrOHiIayQk5pogNF1R7ymjLEhQbEh8Nw1eI96jm 5fWZ/RMrQaF2BIMZXyTFYmZEPa6jIp+QIko+0iK+Dqxw3o8eEeU2rSgUdBAFxtyh67b9fYPmHCJ k8y0BRmIuEqNuVSjhgCRkVWoVN7cORR2mLFqNHKpZkh/cT/ejRsuYAOxIcr/glXCrzZK2KFJKU5 Pjm0JEOTBEGy1/XsXIU9/N/AuIHTulU9r4l7gZWrOPUcmnF/agNGdabsUoHv4l6TycNekT1/1aN wBQWrPaZdvScfDcMbWjETzMCQ== X-Received: by 2002:a05:6000:400e:b0:439:b0ed:2afe with SMTP id ffacd0b85a97d-439da348192mr23599490f8f.11.1773142901645; Tue, 10 Mar 2026 04:41:41 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 12:41:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] x86/efi: Add opt-out mechanism for BGRT preservation To: Soumyajyotii Ssarkar Cc: "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Andrew Cooper , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> <20260306132935.13727-4-soumyajyotisarkar23@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260306132935.13727-4-soumyajyotisarkar23@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 06.03.2026 14:29, Soumyajyotii Ssarkar wrote: > As described in the task, BGRT preservation is now enabled by default to fix ACPI corruption > for desktop/workstation systems (similar to ESRT). What's "the task"? > Add an opt-out parameter 'efi=no-bgrt' to allow disabling BGRT > preservation on systems where the ~1MB memory overhead is not > desired. This looks to contradict ... > The parameter is parsed during normal Xen boot (not during EFI > phase), so it only affects diagnostic logging. ... this. For xen.efi you want to add code to the command line parsing near the top of efi_start(). What to do for the MB2 boot path perhaps the only thing there is to peek into the command line (see arch/x86/boot/cmdline.c). > @@ -1873,6 +1877,10 @@ static int __init cf_check parse_efi_param(const char *s) > else > __clear_bit(EFI_RS, &efi_flags); > } > + else if ( (ss - s) == 7 && !memcmp(s, "no-bgrt", 7) ) No "no-" prefixes please; you want to use parse_boolean(). > @@ -1968,7 +1976,11 @@ void __init efi_init_memory(void) > if ( !efi_enabled(EFI_BOOT) ) > return; > > - if ( bgrt_debug_info.preserved ) > + if ( opt_bgrt_disabled ) > + { > + printk(XENLOG_INFO "EFI: BGRT preservation disabled\n"); > + } No need for figure braces here. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 12:05:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 12:05:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250064.1547503 (Exim 4.92) (envelope-from ) id 1vzvqR-0003Qb-JA; Tue, 10 Mar 2026 12:05:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250064.1547503; Tue, 10 Mar 2026 12:05:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvqR-0003QU-G1; Tue, 10 Mar 2026 12:05:51 +0000 Received: by outflank-mailman (input) for mailman id 1250064; Tue, 10 Mar 2026 12:05:49 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvqP-0003QN-Kp for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 12:05:49 +0000 Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 78343de1-1c79-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 13:05:46 +0100 (CET) Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id E1CEC1D0011E; Tue, 10 Mar 2026 08:05:44 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Tue, 10 Mar 2026 08:05:45 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 10 Mar 2026 08:05:43 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 78343de1-1c79-11f1-9ccf-f158ae23cfc8 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=fm1; t=1773144344; x=1773230744; bh=2WGFbOnRDU6ryJkj7VOMsza798aVYRtJwrdjku8elyQ=; b= q5xJNLi6odveOzVOviX1D+WumgvUmW4vrv/F/gUfiAsT5H1DkPHYeWjxdTq48nu3 RvLEgSycTkvNQIwXnEX8wQ5Pl5E0G/mcvh0ZMk1ll8mNxUyk1Am0MDkLv4A967Cu GdrMxcyTITeiVaImGLEVrg8b349YIS4/rcF+ZrWP64pdlcmCzz2FmV62Yq4lzQWY N4hg+i2rO1qc+sb0sbKZ/6y/dkYhM3MW9OasTyRAXgJ0ZaSdbcySfn/X4HVNoXc6 15h7VlNt93q7xeu1E+5P0PVFM6E7jkpf2BGdBSp9TVWQKmmDDxcnZZDdJYVM9mjq RXJwNFly8lrDxUqujsHNXQ== 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=fm1; t= 1773144344; x=1773230744; bh=2WGFbOnRDU6ryJkj7VOMsza798aVYRtJwrd jku8elyQ=; b=V+034gMWEvotCy4gpTFt5X3MELf7/MOazqJ4LhA+QIt4MFcw5US vSi4TCjrIVGR7BZa36UHEJasLYU8AzpOPqXyZ4Dgp4+dZ7Vq7sRUBAgA9WNq8E4j yoa3f/uScB2RpovRdZmTXe5cAzj9BYmJiZNnqM1LaejDQWGuQC3k6z5AfrCilHVf nsNdDSVyG8TGRmHtFXU0y4lFNCyWiQT1C+sStHkB0oW1ZMmliqN07IyQ16ezoJ/J R5Cca4Kslt6MAgoNE1VidS/MZoYkf0k3DP1aMtysngU/C9FvjfF6Z+tHoMGWMh3p eU0jZj70p5KKBeUBczahsyb2Uo8FS1lMl3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkedtleejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtroertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnheptdetvdfh kedutedvleffgeeutdektefhtefhfffhfeetgefhieegledvtddtkedtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepjhgsvghulhhitghhsehsuhhsvgdrtgho mhdprhgtphhtthhopehsohhumhihrghjhihothhishgrrhhkrghrvdefsehgmhgrihhlrd gtohhmpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhs rdgtohhmpdhrtghpthhtoheprhhoghgvrhdrphgruhestghithhrihigrdgtohhmpdhrtg hpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtghomhdprhgtphht thhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrghdprh gtphhtthhopehsrghrkhgrrhhsohhumhihrghjhihothhivdefsehgmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 10 Mar 2026 13:05:41 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Soumyajyotii Ssarkar , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Subject: Re: [PATCH v2 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Message-ID: References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> <20260306132935.13727-4-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H3L8xXMJr0AcoNuY" Content-Disposition: inline In-Reply-To: --H3L8xXMJr0AcoNuY Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2026 13:05:41 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Cc: Soumyajyotii Ssarkar , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Subject: Re: [PATCH v2 3/3] x86/efi: Add opt-out mechanism for BGRT preservation On Tue, Mar 10, 2026 at 12:41:40PM +0100, Jan Beulich wrote: > On 06.03.2026 14:29, Soumyajyotii Ssarkar wrote: > > As described in the task, BGRT preservation is now enabled by default t= o fix ACPI corruption > > for desktop/workstation systems (similar to ESRT). >=20 > What's "the task"? I asked him to work on this, but I don't think there is a gitlab issue created, so reference to "the task" is not relevant here. > > Add an opt-out parameter 'efi=3Dno-bgrt' to allow disabling BGRT > > preservation on systems where the ~1MB memory overhead is not > > desired. >=20 > This looks to contradict ... >=20 > > The parameter is parsed during normal Xen boot (not during EFI > > phase), so it only affects diagnostic logging. >=20 > ... this. For xen.efi you want to add code to the command line parsing > near the top of efi_start(). What to do for the MB2 boot path perhaps > the only thing there is to peek into the command line (see > arch/x86/boot/cmdline.c). See also my response on v1 - for MB2 path, look at efi_multiboot2(). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --H3L8xXMJr0AcoNuY Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmwCRUACgkQ24/THMrX 1yxA5ggAiLMgeHCgw354QZxy5Nz4/ZL+zy+dagaWLjfWgg8hixKmsiIJE2jmnIC9 qdCvZEueyTdXXesW+ojfHOHWBmVxVKdnbO50lMWIpccmjDIGhfyHxSB3qalACeTJ hmFMbp1eAnBNaqwouZFLgMI8TKSkg3m1xiegDMSIYIdIgUVYF3r4cZWAZ9XoLoIm 2oVnDhLs/k1KCyd2t4Ah3uIBWyt8N40dRCYdFfyISVpfuiF6iKrl5Y+D0DwRdcKI bpSMEi0o2rGK6Cm77XSrCrgCCbnWoUAafH8xz5JgE8y0hc5Tc5D3SlGwsKSd8b47 Nj5mkEpbPJzM7eCOEY8NyfmdvsYVmA== =FjQ8 -----END PGP SIGNATURE----- --H3L8xXMJr0AcoNuY-- From xen-devel-bounces@lists.xenproject.org Tue Mar 10 12:07:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 12:07:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250070.1547512 (Exim 4.92) (envelope-from ) id 1vzvrs-0003tJ-TY; Tue, 10 Mar 2026 12:07:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250070.1547512; Tue, 10 Mar 2026 12:07:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvrs-0003tC-QA; Tue, 10 Mar 2026 12:07:20 +0000 Received: by outflank-mailman (input) for mailman id 1250070; Tue, 10 Mar 2026 12:07:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzvrr-0003sl-KI for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 12:07:19 +0000 Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ae4fbfdf-1c79-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 13:07:17 +0100 (CET) Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 21B4B7A0208; Tue, 10 Mar 2026 08:07:16 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Tue, 10 Mar 2026 08:07:16 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 10 Mar 2026 08:07:14 -0400 (EDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ae4fbfdf-1c79-11f1-b164-2bf370ae4941 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=fm1; t=1773144435; x=1773230835; bh=rJNy2V1r18eUkt+FDuWvUZnnrRhtKNBTvcoO1cA8wGY=; b= DtprdXdK47iH0UKWxVfFYMLu0GnDVyAk6B55KQGr8VtNreseOebu8GzwWedR1Apj PrS4ZyM3w5RUWBu8S6SHnCfJeTdq7Qilrgnojks4O4kAkkFbOEcRdNrBWguXZZez ROMsI4M7bHKfe3Uu/t1v+0cGtgX5VgvVmCZb9+vCtXXWNpQBcefEeouXotAS5uW/ FPejGNmjiGIV+g5X68jH+1fkTs2WhNtPXHBFebZ0PSCAm6IaiuOevTedLaZ8Pw2y lgAFJr8C+0vfr4Ang5fp1kwnDcmZFs2gz40XyuHMnMZTEhNpklFEOv/9oyYcc+ea XOg9HXMefb3xDGPFmJLDdA== 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=fm1; t= 1773144435; x=1773230835; bh=rJNy2V1r18eUkt+FDuWvUZnnrRhtKNBTvco O1cA8wGY=; b=jdSxJPL1JWV9W5hoG/3GRukqxd8+feRmcjh6UEb+NeOBTV46HlX 5TxsAf0cPhaU8JhXiYeVrRHHIocsxRcjx3f8zrfX+WhB1IH2jpAefXy224aqnbMN CwItqe7OTYL2oFKTVj2z41/2XVcB9OpPcpq5yXuy4e4LSjueTU1OcFr63g9qSijs VgwGPE1JMjqiYy3ovkuSFN/hAyEQvk63sGHKDbwlJOh5QKTEpgncRi6jKqTvPYlq AbprotWDbzfY9/7mWBskPCQAm7kcsqfWEw/zWyftNhVrKN85whZvIrjpR3zFh1k+ TP7UDikRbjyLaOTnF28aUBPyGb5J22CarQQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkedtleekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrrhgvkhcu ofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhiuceomhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhepgfduleet feevhfefheeiteeliefhjefhleduveetteekveettddvgeeuteefjedunecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehi nhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhdpnhgspghrtghpthhtohepjedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtohepshhouhhmhigrjhihohhtihhsrghrkhgr rhdvfeesghhmrghilhdrtghomhdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsth hsrdigvghnphhrohhjvggtthdrohhrghdprhgtphhtthhopehsrghrkhgrrhhsohhumhih rghjhihothhivdefsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjhgsvghulhhitghhse hsuhhsvgdrtghomhdprhgtphhtthhopeguphhsmhhithhhsegrphgvrhhtuhhsshholhhu thhiohhnshdrtghomhdprhgtphhtthhopehrohhgvghrrdhprghusegtihhtrhhigidrtg homhdprhgtphhtthhopegrnhgurhgvfidrtghoohhpvghrfeestghithhrihigrdgtohhm X-ME-Proxy: Feedback-ID: i1568416f:Fastmail Date: Tue, 10 Mar 2026 13:07:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH v2 1/3] x86/efi: Add BGRT image preservation during boot Message-ID: References: <20260306132935.13727-1-soumyajyotisarkar23@gmail.com> <20260306132935.13727-2-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p0lgbi4TdJfZJK01" Content-Disposition: inline In-Reply-To: <20260306132935.13727-2-soumyajyotisarkar23@gmail.com> --p0lgbi4TdJfZJK01 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Mar 2026 13:07:12 +0100 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Soumyajyotii Ssarkar Cc: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, Jan Beulich , "Daniel P . Smith" , Roger Pau =?utf-8?B?TW9ubsOp?= , Andrew Cooper Subject: Re: [PATCH v2 1/3] x86/efi: Add BGRT image preservation during boot On Fri, Mar 06, 2026 at 06:59:33PM +0530, Soumyajyotii Ssarkar wrote: > The ACPI BGRT (Boot Graphics Resource Table) contains a pointer to a > boot logo image stored in BootServicesData memory. When Xen reclaims > this memory during boot, the image is lost and the BGRT table becomes > invalid, causing Linux dom0 to report ACPI checksum errors. >=20 > Add preservation logic similar to ESRT table handling: > - Locate BGRT table via XSDT during EFI boot services phase > - Validate BMP image signature and size (max 16 MB) > - Copy image to EfiACPIReclaimMemory (safe from reclamation) > - Update BGRT table with new image address > - Recalculate ACPI table checksum >=20 > The preservation runs automatically during efi_exit_boot() before > Boot Services are terminated. This ensures the image remains > accessible to dom0. >=20 > Open-coded ACPI parsing is used because Xen's ACPI subsystem is not > available during the EFI boot phase. The RSDP is obtained from the > EFI System Table, and the XSDT is walked manually to find BGRT. >=20 > Signed-off-by: Soumyajyotii Ssarkar > --- > xen/arch/x86/efi/efi-boot.h | 2 + > xen/common/efi/boot.c | 187 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 189 insertions(+) >=20 > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h > index 42a2c46b5e..27792a56ff 100644 > --- a/xen/arch/x86/efi/efi-boot.h > +++ b/xen/arch/x86/efi/efi-boot.h > @@ -910,6 +910,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, >=20 > efi_relocate_esrt(SystemTable); >=20 > + efi_preserve_bgrt_img(SystemTable); > + See my remark on v1 - efi_start() wants this change too. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab --p0lgbi4TdJfZJK01 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmwCXAACgkQ24/THMrX 1yxuFQf9F1Sk9gsZiIayNgHTQJ41+Gdxf+DCn91KFOV3PKS0xjWCP162pvYMgU1o RCTk+Zp1ycBVH2YgJSSKyq3//Iq8kH4drkso2aVGIdnoFHxwnUnvhPazwd+pQ0yT tRGTsfJB2pbOxQUzxaqQYHjBf9D9yjxLpnhD0pXwL0fEZl6cS1x2r6OrxHuZ9EQ8 34u2ZK4gQ4iT34ll1xC3hJXevXLsjwvceGLOCB7Gf9MuoBvMs+cJmVps4SuYqti9 lfsIFyoOVcA30WjKLI1k5rBtgup/6EJi0m6NkhGYuEgaDd/nOuVAH0o+soR1aamU pEMOT0EzcOqAb68z5+x8mwSTPtXtoA== =MFMh -----END PGP SIGNATURE----- --p0lgbi4TdJfZJK01-- From xen-devel-bounces@lists.xenproject.org Tue Mar 10 13:05:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 13:05:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250104.1547541 (Exim 4.92) (envelope-from ) id 1vzwmL-00038F-51; Tue, 10 Mar 2026 13:05:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250104.1547541; Tue, 10 Mar 2026 13:05:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzwmL-000388-2K; Tue, 10 Mar 2026 13:05:41 +0000 Received: by outflank-mailman (input) for mailman id 1250104; Tue, 10 Mar 2026 13:05:40 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzwmJ-000381-Nn for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 13:05:40 +0000 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [2a00:1450:4864:20::644]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d4daaa6a-1c81-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 14:05:37 +0100 (CET) Received: by mail-ej1-x644.google.com with SMTP id a640c23a62f3a-b9382e59c0eso1079331266b.0 for ; Tue, 10 Mar 2026 06:05:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d4daaa6a-1c81-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; t=1773147937; cv=none; d=google.com; s=arc-20240605; b=McI1cfhYTRN/FLgAKf/qPb0TkMJVTgzJG+agBjLZXGyP5Qdq/CIpTvFfKlQvVJfj7q PYb1v/rLyau3xYIMBmCgwG1+fyFy04ZUYR08JJ8aQ1QlIFbrHSYia9oOtgqzFKDE4gW9 MnJ9TYEKDvnBQhXK1bu85UBeN/syQh6Gqfe73ai/gzbSPtVElh597aSD31B9LZgK4taw dvcmy4/ax2kqA/nLc5EUym2xbNwsPQ2Kc5PutjwZE4l1/ACDcdwyEI3/Y1fZb8GnVQBS a+zRfJxNYkCg9DOc+p+04J1EsyrH6oIcg0R5BatdQ4zlD6ZRZ+ukxYEaoEnCqRexE8s8 hisw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=ga8jCZ7CqbuFk4UhyLtYz4TN6QQ9AKKQ+o8iEh3ZVkU=; fh=kR8e0jgh9J8Sozt4pR++eFa4KCzOPti8Z95iha/9tDE=; b=Ybbz7lCZYHiiqbnojj92tPi39tQmaBzcx8BoNprEbSDKRSrRbjoXrnTCRp4cwICtqJ qLnY/dG6FkvKNM5cpfV8EEL0UG/LUz5s1hvgsbqOS2ilh+ZnkF9bUfxpLe3oYOiNk/qx X+cwA08Pz4d+DlMOhik7qpc+zgJP/1vKlH7AQCQNb1G5PUN758cCujo2LuA6Ta+Tserv VEYxeP3ehwgPgWjuXf8n1BGFtMkWadSWfllO+eu0otNeGP+Im180qm0SZpWvo0v6I0oZ CI5/mejqYCo5kiETKYE0wDxFA5GNNSKCg6FIMWf+KcTyDtUlANLDVmrjdlxrZE9ZNYpH OBjA==; 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=20230601; t=1773147937; x=1773752737; darn=lists.xenproject.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ga8jCZ7CqbuFk4UhyLtYz4TN6QQ9AKKQ+o8iEh3ZVkU=; b=MV7iu4Bwlg0uZTDOS16uSnxGZ3hVUCRi4lkUj2vj6EcYnZy31i9ExiQIoYxMUQHsLj YlUgGtLQ6d/zOYNNWTHtkviOhCKSawdgPK7wi5RQnYfYaWnamZ2C7pQnLeBuvvBecGGJ h/IsHKoxGUwHFHuaacWBF08NvH4vaL9MTdQoHcDJo7cF8uQEN3P3q5kMywQ/AZ7ekw6N ltCTd7PUirXgIHKLzX/EjrhI0kO7k4RS1uQDJ09++CqlJuiZI3oQVy37kdZr+eBeOSnc icomaHfRdbV2xvNfIiFjg9mb9vMk9DMBK3nBul3xZYcccwuc5ebMnXh8N3LDVzD+DUEp 3/lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773147937; x=1773752737; h=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; bh=ga8jCZ7CqbuFk4UhyLtYz4TN6QQ9AKKQ+o8iEh3ZVkU=; b=t2kMYzXENDZDy2ksLSO5ly9xWlEtZ7RqgApBUSwJOkYJXBzyuv0wjKbzufoA4woKAl 6ULqdjWRH2LX0xmbahBrJ2iqc4/3qteDA94Z/A7nYRjXLakf8XHLCsmGBi03n+b7auEf oVSNncMCtN1nBLfrNX14YlH61moZTspXbrxOn/QFCiBMoK6j66C/dgjuYEwHEOEjmXzf WYwYOWwJUi3eyujJoeJBW/MxCVVZ8T34kyRvsl75J9f/F8VO6BpE7FYsDkMSli6aUNVV vSD/URDoPKfHCf4885pxR68is/kPMTXB1T1sRZ/U2wsQjYFBGKyG634lxvJ77snniGu9 ya9A== X-Forwarded-Encrypted: i=1; AJvYcCV2kBqqpZ/5UKbBEUj+0L/UF5Gtz9c/NBI4BgwM28sp5g1AcMs7dcdbJ7ei9KHs44llPSDMJGrnNvw=@lists.xenproject.org X-Gm-Message-State: AOJu0YxLA4OBgUZocNzEnlwghcUmFw9qNskWc/tWBgwR9PxnoDrexpm9 euIm3PBFo8dlj2C9ydGqRL9h6BkiS1Bfs6MUJbGUlpwlDD+P1n3D95Oj+IQbXXyDzbGuCmhf9Uz IZcdLN/7tQRmEHjS6TT9UGcDmhxpab1s= X-Gm-Gg: ATEYQzyb7lVtgiiOz7g/cVyiZejcQDuyCUj3SP/zEp/xZXXEyeAlE9RMwTSf01JmrgE RBH7nz7TDlYCydz4WCJXqP+YBeNOqRI9kqVXWLw+4BSDr94mhtdXgV7R0LV6HdkJRdR9Y8pXQ5g 7QYE7buX5/MvZNUa/OMXYfrYICJrUZJu9mnvD9lCLSLcwQqx7KTFewjAsLFGuR4H9FRnULpGXLN pWAq+wVvdz8TFliMV03hwtNdTPXBiq6Igs6GMfYDsKccKU7NaypomsHI3VVQsRX7Il2KcCxnARE PAnone0XwWgcvo5sLulK050WC4BBnQvlaQRdmDHsdkIx+0FAYzJeQAirVOnAvy3JwMK9Y5JMSXO 86z0knqbKDGRJ5kMYMXDovzbKaE1Fc47XcW5111vEjYloQEUM X-Received: by 2002:a17:907:d91:b0:b96:dac1:60b with SMTP id a640c23a62f3a-b96dac10e1fmr594792266b.49.1773147936272; Tue, 10 Mar 2026 06:05:36 -0700 (PDT) MIME-Version: 1.0 References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> <609060f4-d94b-4b65-a10b-5126f10307db@suse.com> In-Reply-To: <609060f4-d94b-4b65-a10b-5126f10307db@suse.com> From: Soumyajyotii Ssarkar Date: Tue, 10 Mar 2026 18:35:24 +0530 X-Gm-Features: AaiRm52DwxILmcUMzvBlmOS6wDYYa4zXQH9UHyXqq5qdsqK9MySdegCo4yT6kFc Message-ID: Subject: Re: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot To: Jan Beulich Cc: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper Content-Type: multipart/alternative; boundary="000000000000e035cd064cab2cd5" --000000000000e035cd064cab2cd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2026 at 1:01=E2=80=AFPM Jan Beulich wrot= e: > On 08.03.2026 19:30, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Mar 06, 2026 at 12:48:08AM +0530, Soumyajyotii Ssarkar wrote: > >> --- a/xen/common/efi/boot.c > >> +++ b/xen/common/efi/boot.c > >> @@ -7,6 +7,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> #include > >> @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; > >> static struct file __initdata xsm; > >> static const CHAR16 __initconst newline[] =3D L"\r\n"; > >> > >> +static __initdata struct { > >> + bool preserved; > >> + uint64_t old_addr; > >> + uint64_t new_addr; > >> + uint32_t size; > >> + const char *failure_reason; > >> +} bgrt_debug_info; > >> + > >> static void __init PrintStr(const CHAR16 *s) > >> { > >> StdOut->OutputString(StdOut, (CHAR16 *)s ); > >> @@ -747,6 +756,171 @@ static void __init > efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) > >> efi_bs->FreePool(memory_map); > >> } > >> > >> +struct bmp_header { > >> + uint16_t signature; > >> + uint32_t file_size; > >> + uint16_t reserved_1; > >> + uint16_t reserved_2; > >> + uint32_t data_offset; > >> +} __attribute__((packed)); > >> + > >> +/* > >> + * ACPI Structures - defined locally, > >> + * since we cannot include acpi headers > >> + * in EFI Context. > >> + */ > >> + > >> +struct acpi_rsdp { > >> + char signature[8]; > >> + uint8_t checksum; > >> + char oem_id[6]; > >> + uint8_t revision; > >> + uint32_t rsdt_physical_address; > >> + uint32_t length; > >> + uint64_t xsdt_physical_address; > >> + uint8_t extended_checksum; > >> + uint8_t reserved[3]; > >> +} __attribute__((packed)); > >> + > >> +struct acpi_table_header { > >> + char signature[4]; > >> + uint32_t length; > >> + uint8_t revision; > >> + uint8_t checksum; > >> + char oem_id[6]; > >> + char oem_table_id[8]; > >> + uint32_t oem_revision; > >> + uint32_t asl_compiler_id; > >> + uint32_t asl_compiler_revision; > >> +} __attribute__((packed)); > >> + > >> +struct acpi_xsdt { > >> + struct acpi_table_header header; > >> + uint64_t table_offset_entry[1]; /* Variable array length */ > > > > uint64_t table_offset_entry[]; > > > > BTW, do we have some canonical place with list of files imported (and > > kept in sync) with other projects? xen/include/acpi/actbl.h doesn't > > exactly follow Xen coding style, but it's unclear to me if it needs to > > stay this way. > > I don't really understand why the headers we've got can't be used. Even > some of the library-like code under xen/acpi/ may be usable here. > > While we don't exactly keep xen/include/acpi/ in sync with Linux, when > things are added we preferably add them in the way Linux has them. > > I was trying to avoid including the headers from the xen/include/acpi/ since it was specified in the comment. to not include them. Specific comment specified below this paragraph. Also since acpi was using datatypes like "u32" while boot.c had types of "uint32", so it felt a bit non-standardized. I checked the rest of the boot.c which followed the same manner. So I went with this choice. /* * Keep this arch-specific modified include in the common file, as moving * it to the arch specific include file would obscure that special care is * taken to include it with __ASSEMBLER__ defined. */ #define __ASSEMBLER__ /* avoid pulling in ACPI stuff (conflicts with EFI) */ #include #undef __ASSEMBLER__ #endif The ACPI headers in /xen/include/acpi uses defines such as ACPI_NAME_SIZE, ACPI_OEM_ID_SIZE and ACPI_OEM_TABLE_ID_SIZE these require adding additional header. Also since their is no acpi headers included in the boot.c file, so i thought to I avoid it. Thus to get it fully working with ACPI headers from the xen/include/acpi I would require these three headers. #include #include #include I thought this would lead to cross contamination, and confusing to further modifications in future so weighing my options I thought best to redefine them, for code clarity. Can you suggest me best option to move forward, should I redefine them as is or include the headers? >> +} __attribute__((packed)); > >> + > >> +struct acpi_bgrt { > >> + struct acpi_table_header header; > >> + uint16_t version; > >> + uint8_t status; > >> + uint8_t image_type; > >> + uint64_t image_address; > >> + uint32_t image_offset_x; > >> + uint32_t image_offset_y; > >> +} __attribute__((packed)); > >> + > >> +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE > *SystemTable) > > Nit (style): The first * is misplaced. > > >> +{ > >> + EFI_GUID acpi2_guid =3D ACPI_20_TABLE_GUID; > >> + struct acpi_rsdp *rsdp =3D NULL; > >> + struct acpi_xsdt *xsdt; > >> + struct acpi_bgrt *bgrt; > > Here and ... > > >> + uint32_t entry_count, actual_size; > >> + unsigned int i; > >> + > >> + for ( i =3D 0; i < SystemTable->NumberOfTableEntries; i++ ) > >> + { > >> + if ( match_guid(&acpi2_guid, > &SystemTable->ConfigurationTable[i].VendorGuid) ) > >> + { > >> + rsdp =3D SystemTable->ConfigurationTable[i].VendorTable; > >> + break; > >> + } > >> + } > >> + > >> + if ( !rsdp || !rsdp->xsdt_physical_address ) > >> + return NULL; > >> + > >> + xsdt =3D (struct acpi_xsdt *)rsdp->xsdt_physical_address; > >> + if ( !xsdt ) > >> + return NULL; > >> + > >> + actual_size =3D (xsdt->header.length - sizeof(struct > acpi_table_header)); > >> + entry_count =3D (actual_size / sizeof(uint64_t)); > >> + > >> + for ( i =3D 0; i < entry_count; i++ ) > >> + { > >> + struct acpi_table_header *header =3D (struct acpi_table_heade= r > *)xsdt->table_offset_entry[i]; > > ... here and elsewhere - please use pointer-to-const wherever possible. > > >> + if ( header->signature[0] =3D=3D 'B' > >> + && header->signature[1] =3D=3D 'G' > >> + && header->signature[2] =3D=3D 'R' > >> + && header->signature[3] =3D=3D 'T' ) > > > > strncmp? > > Or even memcmp() in this case. Plus there is ACPI_SIG_BGRT. Yeah, my apologies. Since I was going with the whole not including acpi headers idea, I thought this would be better stylistic choice. New patch version with strncmp upcoming. The headers are in xen/include/acpi, so was trying to work around without including them. Perhaps including the headers would be the move forward? What is your opinion Marek? > >> + { > >> + bgrt =3D (struct acpi_bgrt *)header; > > > > You can just return it here, avoiding the extra variable. > > > >> + return bgrt; > >> + } > >> + } > >> + return NULL; > >> +} > >> + > >> +#define MAX_IMAGE_SIZE (16 * 1024 * 1024) /* Sanity check: reject > if bigger */ > >> + > >> +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *SystemTabl= e) > >> +{ > >> + struct acpi_bgrt *bgrt; > >> + struct bmp_header *bmp; > >> + void *old_image, *new_image; > >> + uint32_t image_size; > >> + EFI_STATUS status; > >> + uint8_t checksum; > >> + unsigned int i; > >> + > >> + bgrt_debug_info.preserved =3D false; > >> + bgrt_debug_info.failure_reason =3D NULL; > >> + > >> + bgrt =3D find_bgrt_table(SystemTable); > >> + if ( !bgrt ) > >> + { > >> + bgrt_debug_info.failure_reason =3D "BGRT table not found in > XSDT"; > >> + return; > >> + } > >> + > >> + if ( !bgrt->image_address ) > >> + { > >> + bgrt_debug_info.failure_reason =3D "BGRT image_address is NUL= L"; > >> + return; > >> + } > >> + > >> + old_image =3D (void *)bgrt->image_address; > >> + bmp =3D (struct bmp_header *)old_image; > >> + > >> + if ( bmp->signature !=3D 0x4D42 ) > >> + { > >> + bgrt_debug_info.failure_reason =3D "Invalid BMP signature"; > >> + return; > >> + } > >> + > >> + image_size =3D bmp->file_size; > >> + if ( !image_size || image_size > MAX_IMAGE_SIZE ) > >> + { > >> + bgrt_debug_info.failure_reason =3D "Invalid image size"; > >> + return; > >> + } > >> + > >> + status =3D efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, > &new_image); > >> + if ( status !=3D EFI_SUCCESS || !new_image ) > >> + { > >> + bgrt_debug_info.failure_reason =3D "Memory allocation failed"= ; > >> + return; > >> + } > >> + > >> + memcpy(new_image, old_image, image_size); > >> + > >> + bgrt->image_address =3D (uint64_t)new_image; > >> + bgrt->status |=3D 0x01; > > > > Why forcing the "displayed" bit here? > > And if this is needed, why by way of a literal number rather than a > suitable > #define? > > >> + bgrt->header.checksum =3D 0; > >> + checksum =3D 0; > >> + for ( i =3D 0; i < bgrt->header.length; i++ ) > >> + checksum +=3D ((uint8_t *)bgrt)[i]; > >> + bgrt->header.checksum =3D (uint8_t)(0 - checksum); > >> + > >> + bgrt_debug_info.preserved =3D true; > >> + bgrt_debug_info.old_addr =3D (uint64_t)old_image; > >> + bgrt_debug_info.new_addr =3D (uint64_t)new_image; > >> + bgrt_debug_info.size =3D image_size; > >> +} > >> + > > > > This is quite a bit of code, maybe move to a separate file? But I'd lik= e > > to hear what others think. > > I believe it won't be necessary to add a separate file for this since it's just a 2 functions. I believe this since most of the ESRT patches, which I based my patches on didn't use a separate file. But now since with the whole, header issue and redefining the structs I think a separate file would also be a viable option too. Perhaps any 2 options: Moving with a separate file for cleaner code. Moving with existing file for non-standardized code. I would love your opinions on this. Further, I think I should revise the further patches to RFC for clarity. Before coming to a conclusion. And sending as patch to be pulled. Whether to put in a separate file is only the 2nd question imo. The first i= s > whether this much code is needed in the first place. > > Jan > --000000000000e035cd064cab2cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 9, 2026 at 1= :01=E2=80=AFPM Jan Beulich <jbeulich@suse.com> wrote:
On 08.03.2026 19:30, Ma= rek Marczykowski-G=C3=B3recki wrote:
> On Fri, Mar 06, 2026 at 12:48:08AM +0530, Soumyajyotii Ssarkar wrote:<= br> >> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -7,6 +7,7 @@
>>=C2=A0 #include <xen/ctype.h>
>>=C2=A0 #include <xen/dmi.h>
>>=C2=A0 #include <xen/domain_page.h>
>> +#include <xen/errno.h>
>>=C2=A0 #include <xen/init.h>
>>=C2=A0 #include <xen/keyhandler.h>
>>=C2=A0 #include <xen/lib.h>
>> @@ -173,6 +174,14 @@ static struct file __initdata ramdisk;
>>=C2=A0 static struct file __initdata xsm;
>>=C2=A0 static const CHAR16 __initconst newline[] =3D L"\r\n&qu= ot;;
>>
>> +static __initdata struct {
>> +=C2=A0 =C2=A0 bool preserved;
>> +=C2=A0 =C2=A0 uint64_t old_addr;
>> +=C2=A0 =C2=A0 uint64_t new_addr;
>> +=C2=A0 =C2=A0 uint32_t size;
>> +=C2=A0 =C2=A0 const char *failure_reason;
>> +} bgrt_debug_info;
>> +
>>=C2=A0 static void __init PrintStr(const CHAR16 *s)
>>=C2=A0 {
>>=C2=A0 =C2=A0 =C2=A0 StdOut->OutputString(StdOut, (CHAR16 *)s );=
>> @@ -747,6 +756,171 @@ static void __init efi_relocate_esrt(EFI_SYS= TEM_TABLE *SystemTable)
>>=C2=A0 =C2=A0 =C2=A0 efi_bs->FreePool(memory_map);
>>=C2=A0 }
>>
>> +struct bmp_header {
>> +=C2=A0 =C2=A0 uint16_t signature;
>> +=C2=A0 =C2=A0 uint32_t file_size;
>> +=C2=A0 =C2=A0 uint16_t reserved_1;
>> +=C2=A0 =C2=A0 uint16_t reserved_2;
>> +=C2=A0 =C2=A0 uint32_t data_offset;
>> +} __attribute__((packed));
>> +
>> +/*
>> + * ACPI Structures - defined locally,
>> + * since we cannot include acpi headers
>> + * in EFI Context.
>> + */
>> +
>> +struct acpi_rsdp {
>> +=C2=A0 =C2=A0 char signature[8];
>> +=C2=A0 =C2=A0 uint8_t checksum;
>> +=C2=A0 =C2=A0 char oem_id[6];
>> +=C2=A0 =C2=A0 uint8_t revision;
>> +=C2=A0 =C2=A0 uint32_t rsdt_physical_address;
>> +=C2=A0 =C2=A0 uint32_t length;
>> +=C2=A0 =C2=A0 uint64_t xsdt_physical_address;
>> +=C2=A0 =C2=A0 uint8_t extended_checksum;
>> +=C2=A0 =C2=A0 uint8_t reserved[3];
>> +} __attribute__((packed));
>> +
>> +struct acpi_table_header {
>> +=C2=A0 =C2=A0 char signature[4];
>> +=C2=A0 =C2=A0 uint32_t length;
>> +=C2=A0 =C2=A0 uint8_t revision;
>> +=C2=A0 =C2=A0 uint8_t checksum;
>> +=C2=A0 =C2=A0 char oem_id[6];
>> +=C2=A0 =C2=A0 char oem_table_id[8];
>> +=C2=A0 =C2=A0 uint32_t oem_revision;
>> +=C2=A0 =C2=A0 uint32_t asl_compiler_id;
>> +=C2=A0 =C2=A0 uint32_t asl_compiler_revision;
>> +} __attribute__((packed));
>> +
>> +struct acpi_xsdt {
>> +=C2=A0 =C2=A0 struct acpi_table_header header;
>> +=C2=A0 =C2=A0 uint64_t table_offset_entry[1]; /* Variable array l= ength */
>
> uint64_t table_offset_entry[];
>
> BTW, do we have some canonical place with list of files imported (and<= br> > kept in sync) with other projects? xen/include/acpi/actbl.h doesn'= t
> exactly follow Xen coding style, but it's unclear to me if it need= s to
> stay this way.

I don't really understand why the headers we've got can't be us= ed. Even
some of the library-like code under xen/acpi/ may be usable here.

While we don't exactly keep xen/include/acpi/ in sync with Linux, when<= br> things are added we preferably add them in the way Linux has them.

=C2=A0
I was trying to avoid including the = headers from the xen/include/acpi/ since it was specified in the comment. t= o not include them.
Specific comment specified below this paragra= ph.
Also since acpi was using datatypes like "u32" whil= e boot.c had types of "uint32", so it felt a bit non-standardized= .
I checked the rest of the boot.c which followed the same manner= . So I went with this choice.

/* * Keep this arch-= specific modified include in the common file, as moving=C2=A0
=C2= =A0* it to the arch specific include file would obscure that special care i= s=C2=A0
=C2=A0* taken to include it with __ASSEMBLER__ defined.= =C2=A0
*/=C2=A0
#define __ASSEMBLER__ /* avoid pulling = in ACPI stuff (conflicts with EFI) */=C2=A0
#include <asm/fixm= ap.h>=C2=A0
#undef __ASSEMBLER__=C2=A0
#endif=C2=A0<= /div>

The ACPI headers in /xen/include/acpi uses defines= such as=C2=A0ACPI_NAME_SIZE,=C2=A0ACPI_OEM_ID_SIZE=C2=A0
and=C2= =A0ACPI_OEM_TABLE_ID_SIZE these require adding additional <acpi/acconfig= .h> header.
Also since their is no acpi headers included in th= e boot.c file, so i thought to I avoid it.

Thus to= get it fully working with ACPI headers from the xen/include/acpi I would r= equire these three headers.
#include <acpi/acconfig.h>
#= include <acpi/actbl.h>
#include <acpi/actbl3.h>
I thought this would lead to cross contamination, and confusin= g to further modifications in future so weighing my options I thought best = to redefine them,
for code clarity.
Can you suggest me = best option to move forward, should I redefine them as is or include the he= aders?=C2=A0

>> +} __attribute__((packed));
>> +
>> +struct acpi_bgrt {
>> +=C2=A0 =C2=A0 struct acpi_table_header header;
>> +=C2=A0 =C2=A0 uint16_t version;
>> +=C2=A0 =C2=A0 uint8_t status;
>> +=C2=A0 =C2=A0 uint8_t image_type;
>> +=C2=A0 =C2=A0 uint64_t image_address;
>> +=C2=A0 =C2=A0 uint32_t image_offset_x;
>> +=C2=A0 =C2=A0 uint32_t image_offset_y;
>> +} __attribute__((packed));
>> +
>> +static struct acpi_bgrt* __init find_bgrt_table(EFI_SYSTEM_TABLE = *SystemTable)

Nit (style): The first * is misplaced.

>> +{
>> +=C2=A0 =C2=A0 EFI_GUID acpi2_guid =3D ACPI_20_TABLE_GUID;
>> +=C2=A0 =C2=A0 struct acpi_rsdp *rsdp =3D NULL;
>> +=C2=A0 =C2=A0 struct acpi_xsdt *xsdt;
>> +=C2=A0 =C2=A0 struct acpi_bgrt *bgrt;

Here and ...

>> +=C2=A0 =C2=A0 uint32_t entry_count, actual_size;
>> +=C2=A0 =C2=A0 unsigned int i;
>> +
>> +=C2=A0 =C2=A0 for ( i =3D 0; i < SystemTable->NumberOfTable= Entries; i++ )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if ( match_guid(&acpi2_guid, &= ;SystemTable->ConfigurationTable[i].VendorGuid) )
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rsdp =3D SystemTable-&g= t;ConfigurationTable[i].VendorTable;
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 if ( !rsdp || !rsdp->xsdt_physical_address )
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return NULL;
>> +
>> +=C2=A0 =C2=A0 xsdt =3D (struct acpi_xsdt *)rsdp->xsdt_physical= _address;
>> +=C2=A0 =C2=A0 if ( !xsdt )
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return NULL;
>> +
>> +=C2=A0 =C2=A0 actual_size =3D (xsdt->header.length - sizeof(st= ruct acpi_table_header));
>> +=C2=A0 =C2=A0 entry_count =3D (actual_size / sizeof(uint64_t)); >> +
>> +=C2=A0 =C2=A0 for ( i =3D 0; i < entry_count; i++ )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct acpi_table_header *header =3D = (struct acpi_table_header *)xsdt->table_offset_entry[i];

... here and elsewhere - please use pointer-to-const wherever possible.

>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (=C2=A0 =C2=A0header->signature= [0] =3D=3D 'B'
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 && header->s= ignature[1] =3D=3D 'G'
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 && header->s= ignature[2] =3D=3D 'R'
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 && header->s= ignature[3] =3D=3D 'T' )
>
> strncmp?

Or even memcmp() in this case. Plus there is ACPI_SIG_BGRT.

Yeah, my apologies. Since I was going with the whole not i= ncluding acpi headers idea,=C2=A0
I thought this would be better = stylistic choice.=C2=A0

New patch version with str= ncmp upcoming.
=C2=A0
The headers are in xen/include/ac= pi, so was trying to work around without including them.
Perhaps = including the headers would be the move forward?

W= hat is your opinion Marek?

=C2=A0
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt =3D (struct acpi_b= grt *)header;
>
> You can just return it here, avoiding the extra variable.
>
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return bgrt;
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> +=C2=A0 =C2=A0 }
>> +=C2=A0 =C2=A0 return NULL;
>> +}
>> +
>> +#define MAX_IMAGE_SIZE=C2=A0 (16 * 1024 * 1024)=C2=A0 =C2=A0 /* S= anity check: reject if bigger */
>> +
>> +static void __init efi_preserve_bgrt_img(EFI_SYSTEM_TABLE *System= Table)
>> +{
>> +=C2=A0 =C2=A0 struct acpi_bgrt *bgrt;
>> +=C2=A0 =C2=A0 struct bmp_header *bmp;
>> +=C2=A0 =C2=A0 void *old_image, *new_image;
>> +=C2=A0 =C2=A0 uint32_t image_size;
>> +=C2=A0 =C2=A0 EFI_STATUS status;
>> +=C2=A0 =C2=A0 uint8_t checksum;
>> +=C2=A0 =C2=A0 unsigned int i;
>> +
>> +=C2=A0 =C2=A0 bgrt_debug_info.preserved =3D false;
>> +=C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D NULL;
>> +
>> +=C2=A0 =C2=A0 bgrt =3D find_bgrt_table(SystemTable);
>> +=C2=A0 =C2=A0 if ( !bgrt )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D &q= uot;BGRT table not found in XSDT";
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 if ( !bgrt->image_address )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D &q= uot;BGRT image_address is NULL";
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 old_image =3D (void *)bgrt->image_address;
>> +=C2=A0 =C2=A0 bmp =3D (struct bmp_header *)old_image;
>> +
>> +=C2=A0 =C2=A0 if ( bmp->signature !=3D 0x4D42 )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D &q= uot;Invalid BMP signature";
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 image_size =3D bmp->file_size;
>> +=C2=A0 =C2=A0 if ( !image_size || image_size > MAX_IMAGE_SIZE = )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D &q= uot;Invalid image size";
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 status =3D efi_bs->AllocatePool(EfiACPIReclaimMe= mory, image_size, &new_image);
>> +=C2=A0 =C2=A0 if ( status !=3D EFI_SUCCESS || !new_image )
>> +=C2=A0 =C2=A0 {
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 bgrt_debug_info.failure_reason =3D &q= uot;Memory allocation failed";
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
>> +=C2=A0 =C2=A0 }
>> +
>> +=C2=A0 =C2=A0 memcpy(new_image, old_image, image_size);
>> +
>> +=C2=A0 =C2=A0 bgrt->image_address =3D (uint64_t)new_image;
>> +=C2=A0 =C2=A0 bgrt->status |=3D 0x01;
>
> Why forcing the "displayed" bit here?

And if this is needed, why by way of a literal number rather than a suitabl= e
#define?

>> +=C2=A0 =C2=A0 bgrt->header.checksum =3D 0;
>> +=C2=A0 =C2=A0 checksum =3D 0;
>> +=C2=A0 =C2=A0 for ( i =3D 0; i < bgrt->header.length; i++ )=
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 checksum +=3D ((uint8_t *)bgrt)[i]; >> +=C2=A0 =C2=A0 bgrt->header.checksum =3D (uint8_t)(0 - checksum= );
>> +
>> +=C2=A0 =C2=A0 bgrt_debug_info.preserved =3D true;
>> +=C2=A0 =C2=A0 bgrt_debug_info.old_addr =3D (uint64_t)old_image; >> +=C2=A0 =C2=A0 bgrt_debug_info.new_addr =3D (uint64_t)new_image; >> +=C2=A0 =C2=A0 bgrt_debug_info.size =3D image_size;
>> +}
>> +
>
> This is quite a bit of code, maybe move to a separate file? But I'= d like
> to hear what others think.


I believe it won't be necessary to add a se= parate file for this since it's just a 2 functions.
I believe= this since most of the ESRT patches, which I based my patches on didn'= t use a separate file.
But now since with the whole, header issue= and redefining the structs I think a separate file would also be a viable = option too.

Perhaps any 2 options:
Movin= g with a separate file for cleaner code.
Moving with existing fil= e for non-standardized code.
I would love your opinions on this.<= /div>

Further, I think I should revise the further patch= es to RFC for clarity. Before coming to a conclusion.
And sending= as patch to be pulled.

Whether to put in a separate file is only the 2nd question imo. The first i= s
whether this much code is needed in the first place.
=C2=A0
Jan
--000000000000e035cd064cab2cd5-- From xen-devel-bounces@lists.xenproject.org Tue Mar 10 13:58:13 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 13:58:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250138.1547599 (Exim 4.92) (envelope-from ) id 1vzxb4-0001Hs-DD; Tue, 10 Mar 2026 13:58:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250138.1547599; Tue, 10 Mar 2026 13: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 ) id 1vzxb4-0001Hl-9E; Tue, 10 Mar 2026 13:58:06 +0000 Received: by outflank-mailman (input) for mailman id 1250138; Tue, 10 Mar 2026 13:58:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzxb2-0001Hf-RS for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 13:58:05 +0000 Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 280db40d-1c89-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 14:58:03 +0100 (CET) Received: from mail-vs1-f70.google.com (mail-vs1-f70.google.com [209.85.217.70]) (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 smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 2D8BF3F78D for ; Tue, 10 Mar 2026 13:58:03 +0000 (UTC) Received: by mail-vs1-f70.google.com with SMTP id ada2fe7eead31-5fff2d5756fso4741146137.2 for ; Tue, 10 Mar 2026 06:58:03 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 280db40d-1c89-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20251003; t=1773151083; bh=Z/PYnzyJL6zP+aWtvHJwSYzvqQxLGB8OMV1YGzIoCCo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GskMFkflCxKzERaY25RjiwFjxMcgoqTHn1R0Y2YpQEMqkBw2d0gkmtVjAS06W2hSJ 6sQvAyEiEMYA0O56esM9FhExa2p7ShggQ1yNoGpgc3IL3jfgjQ9fx57/CVJ2kJAqmc z4BhAfs3zFELre2/YDxN5+FbcT7r0G2qFYWGFeOFlvSmQKQ55pfqLddmntocRMqfH+ XfsPZXdhE2RsGh7eKkOj6u5fT6J4dhefQGWMHcPS8jEMKM6Mozgti4FibFpdYKdT07 sVArQpoGydbtjyTEpuDxbXO4RkWb2VxgOplL+ao0cypAAoVPSEl8rZH4yfyvYX6+OS 2gRZRXV4YVDN6J33Ap8flqz3LpW/Ng55GN0FBY/BY9T/rUkiafC3bPb4KaJ84oSHMT hO9Wyy/Xtit/7f/abGnnWGJ/4TXuGzAQRLEJo5Ira8NEhYYggvC/4z1g7/e5ZC8t4l 68zv3bU73BCmPK3fHfIlB2/qjrp6btvSNENxHY6GqrKRZHx8FbBisj8t4xtlrcUAng VHj7lxdvhK0C4uZcj9zTaiF8SqbUIq/0P4AJ8wVsim99vaim8AZSLbaGqGvZNAMJIj ICUp2cSnQW544uGnlF0WW+lM47I3758BSPYmJjjB6wnXBJBkkpqeUHAZRsMooKXLcu t0YhI2bLpzy5Ka9eXQY2roEE= ARC-Seal: i=1; a=rsa-sha256; t=1773151082; cv=none; d=google.com; s=arc-20240605; b=Fyzt2go6A1YR2v1umCDt0VC87kpMxzvRnd6Hmqai8UAgCNoHGr0O+Yz4fzrkvBWj1I nzv2010AwiCkMHTsJ9MN1m/nRPVkjIMBpML5NQ+FWO0B5ST89S78ESVycGiaac3cQiB2 ON1XLb03BaIQvvPCV+c8EMr/GFTENighUgXq55WOkIieg8jMoYwLbY20JRFG59U4adfZ 08ME5S25UoCXCozIC1BvjS8j5p6oelTFKsEp4E/c087pgUn+fwWugoaIBJEqdVYqOEvB 4QYifsmAgQm6Dq/+caevqmKAdWtNsfXa8VDKGOPbuGNKYQXzZ+vesUNRtbgRkPgNaeQB LMyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=Z/PYnzyJL6zP+aWtvHJwSYzvqQxLGB8OMV1YGzIoCCo=; fh=GG3qP5pAj8neOF7eJs2TsVLgJFvZh3XvVRvvhfAQMzA=; b=i38BuFxKs8CNaHq48hI1VKVnaBFV7e5rsbU5NHRc3V2CNIyq17HZcYRyLIVfWdpz/5 RIOxRb2mPGHh9oq0+FZWMO3B8xE+LPWEb5F3ZFcq2vnEEb3se91zzSMU48UP7fodeN+M 68uBp+96NnrPmi6mlJjEeKfToBkNgcQ4JEaEto/t02eHid9rctGm6pgyhzKcfrh8hsvG Kw2E8n8mzbpzuvONsZ1r86m/Y9eEFYTagQSIwr1iEh0FmpqvyVRE0tmz2bB4cz/DJp5T rozY+n4utcrE+COh4M5UbvwsKZ/qFu/FFJH7Hz3vs4+fvRZZZ0RiSXleLPHAw3yctefc Kx0A==; darn=lists.xenproject.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773151082; x=1773755882; h=content-transfer-encoding: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; bh=Z/PYnzyJL6zP+aWtvHJwSYzvqQxLGB8OMV1YGzIoCCo=; b=HvpYUprfe9NOZhh04umHQeaAgMN9M5VjuRAf1vwZmpABKhQaV1cbjttytxhYN1y84q ekrKaADbF3yENBGgHY+bK/G61mjoTaQXH/gfhgRLPigeGMA9Ga1Y9Dfn7EkRg1vie9Xt HRd0K8jiELlVSlulKo0gK523YifiDtMlVsm2sMxiQch8PT/Qvjuc3kU2gFH/mSenExlU 0i+1LYFLLlEzHRQGhrXqPKlRuLpwiSdyUHDAgNGmn5Ko7hccisuL+ogE9lfsMXwF5y1X 84OuyXeIcydlLj3s+RP8b0mfVU6R4EPr+Uh8+RgwYtog/CRwKo9I6SPcawQSlxCHlGTb ETxg== X-Gm-Message-State: AOJu0YzabTon/cAYSU36XnDI+fTHogfbwyEAJr2yoOo7tA8wvoUccODs gOYWBMMppP3CgHnPRqlBmEFJUaG09s8LccG0Vv5nSMWLDC0quOkMu7y/0QXfJr0hRpcy6iq4IZq DX/EQWuvNbgYQjnnqBola1Xpv2qp4CS3rQEHrRaP/eqFGrrM+tlTMAfke/3K+5iTRQsur/3nYbs kyXxRQT/wb+WWiOe8RPoHOj+jZ0PmIAMDdMTjQYda5hijpORvp/DUqmAExNU0= X-Gm-Gg: ATEYQzzEv6ALU4hOIXW6eabNT0iHSpsjR00nMu4XhpBdUuJNPRDfmnb+MX04N3TgZ9P 5ksAjqQAkWKNFJyZcGLm08ccvhjC2NEgiC8gAknxzEUF0mrd6dGjAXkPr0q368fzEQIwBenHDvv EJb7toaHgJE8hJqi/zNhB95C9KngFjtr2j+ih0y97wkup7Fj2Fd7J9LgdaQGtkkwfeSsUv1HENL p4i X-Received: by 2002:a05:6102:3f0e:b0:5f5:4055:4556 with SMTP id ada2fe7eead31-5ffe5ef61f3mr5221857137.4.1773151076285; Tue, 10 Mar 2026 06:57:56 -0700 (PDT) X-Received: by 2002:a05:6102:3f0e:b0:5f5:4055:4556 with SMTP id ada2fe7eead31-5ffe5ef61f3mr5221820137.4.1773151074350; Tue, 10 Mar 2026 06:57:54 -0700 (PDT) MIME-Version: 1.0 References: <20260305135208.2208663-1-jgross@suse.com> <20260305135208.2208663-10-jgross@suse.com> In-Reply-To: <20260305135208.2208663-10-jgross@suse.com> From: Nick Rosbrook Date: Tue, 10 Mar 2026 09:57:43 -0400 X-Gm-Features: AaiRm51XO1_uiu1CVtnFq_O9sbsjJ7JISVvlAgVOf0T9WAmvHD0P3QquLwgQmhY Message-ID: Subject: Re: [PATCH 09/11] tools/libxl: add support for xenstore quota in domain_config To: Juergen Gross Cc: xen-devel@lists.xenproject.org, George Dunlap , Anthony PERARD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2026 at 8:53=E2=80=AFAM Juergen Gross wrot= e: > > Add support for xenstore quota in the struct domain_config. Initially > it will be used only for migration of a domain. > > Signed-off-by: Juergen Gross > --- > tools/golang/xenlight/helpers.gen.go | 6 ++++++ > tools/golang/xenlight/types.gen.go | 1 + > tools/libs/light/libxl_dom.c | 8 ++++++++ > tools/libs/light/libxl_domain.c | 10 ++++++++++ > tools/libs/light/libxl_types.idl | 1 + > 5 files changed, 26 insertions(+) > > diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight= /helpers.gen.go > index 6c9af904c5..416c2d3e07 100644 > --- a/tools/golang/xenlight/helpers.gen.go > +++ b/tools/golang/xenlight/helpers.gen.go > @@ -1286,6 +1286,9 @@ if err :=3D x.TrapUnmappedAccesses.fromC(&xc.trap_u= nmapped_accesses);err !=3D nil { > return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err) > } > x.XenstoreFeatureMask =3D uint32(xc.xenstore_feature_mask) > +if err :=3D x.XenstoreQuota.fromC(&xc.xenstore_quota);err !=3D nil { > +return fmt.Errorf("converting field XenstoreQuota: %v", err) > +} > > return nil} > > @@ -1825,6 +1828,9 @@ if err :=3D x.TrapUnmappedAccesses.toC(&xc.trap_unm= apped_accesses); err !=3D nil { > return fmt.Errorf("converting field TrapUnmappedAccesses: %v", err) > } > xc.xenstore_feature_mask =3D C.uint32_t(x.XenstoreFeatureMask) > +if err :=3D x.XenstoreQuota.toC(&xc.xenstore_quota); err !=3D nil { > +return fmt.Errorf("converting field XenstoreQuota: %v", err) > +} > > return nil > } > diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/t= ypes.gen.go > index 5393277190..7e7292cf70 100644 > --- a/tools/golang/xenlight/types.gen.go > +++ b/tools/golang/xenlight/types.gen.go > @@ -629,6 +629,7 @@ VmtraceBufKb int > Vpmu Defbool > TrapUnmappedAccesses Defbool > XenstoreFeatureMask uint32 > +XenstoreQuota XsQuotaSet > } > > type DomainBuildInfoTypeUnion interface { For the golang stuff: Acked-by: Nick Rosbrook Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 14:08:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250146.1547627 (Exim 4.92) (envelope-from ) id 1vzxkw-0003AL-HD; Tue, 10 Mar 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 1250146.1547627; Tue, 10 Mar 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 ) id 1vzxkw-0003AE-ER; Tue, 10 Mar 2026 14:08:18 +0000 Received: by outflank-mailman (input) for mailman id 1250146; Tue, 10 Mar 2026 13:59:05 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzxc0-0001jj-N6 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 13:59:04 +0000 Received: from smtp.forwardemail.net (smtp.forwardemail.net [121.127.44.73]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4af57da7-1c89-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 14:59:02 +0100 (CET) Received: by mail-vs1-f70.google.com with SMTP id ada2fe7eead31-6003c120943so6639439137.2 for ; Tue, 10 Mar 2026 06:59:00 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4af57da7-1c89-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ubuntu.com; h=Content-Transfer-Encoding: Content-Type: Cc: To: Subject: Message-ID: Date: From: In-Reply-To: References: MIME-Version; q=dns/txt; s=fe-953a8a3ca9; t=1773151141; bh=E8wOigURf3csG2yq02yND2Sc/5WalRx/lbNH4MbDwRw=; b=AejbEsofOMMyMmMS0yYvZBls1/15GBRvpae7SNq3R7NC/aPZ9vHAJyNEXcG/w4SO2UHVegsTg 4YhN9N07/k/5SBmyeCeoY2cy5D+O31HDDuZ5qr7IBQVckNAtZGLaXojPQzqV7gQdck4cuIAS/iQ 1b8bakKlwBk2kPPxSTGwCb35hOYh38Mp+nW4G8a+TIOt4gAIw/a8+Ueby4oaQNZwAEy5z7/dEPd 2Cs80xEGdMEyg+6EUAO2ACoFfMJ1lcidh/zydZ3nX25eryQlrqy0Vv0BFsK6C3HRFWvUdQiImiW smBBjypw88s/pQhEq9I+8+JyrkRvAg2fgtgm2jlwJ+qw== X-Forward-Email-ID: 69b023a4d3315ad1d148bf1c X-Forward-Email-Sender: rfc822; enr0n@ubuntu.com, smtp.forwardemail.net, 121.127.44.73 X-Forward-Email-Version: 2.6.49 X-Forward-Email-Website: https://forwardemail.net X-Complaints-To: abuse@forwardemail.net X-Report-Abuse: abuse@forwardemail.net X-Report-Abuse-To: abuse@forwardemail.net X-Gm-Message-State: AOJu0YxHwLYLqq+FLoZyMHTcfSPQApZh1eirrwj3uU/WDvLxRBHFnPCn 9fyTM/xZWoJcpWVqZoWX32xWn8FmlZRrGGgPA+AyzMKnD9p7QX6LR7b83cb/ka6ozFaVMXBczZB lzBrmbWcuKiP4YZ9Kj9AptO47cJPSRO1waCSLWOvvVfYG2YKc5uaxZ3sg6khooSoYfIBQWpGTfP ZO66oWZ6GJOm6OEBej4ivMYUhqkXg0xY6oe7bQLyO+erk8a1wKHvPPxhlcbDA= X-Gm-Gg: ATEYQzyp2Kk6teQxfX04cvWd6sQhIIbz24X2nNQkFQJ1B6lStVjBThiMwVm6+qRMOld czwLbM1pH2foswcNy/tq8VeBt9R2k6e4Ga+vk9oNQCQg6r1XnueXZFAn7rWbQqToATABCvY4zbE L1unlCZf+5cch8M26APqZM6X8QtN5YihP3OUH8iNgghc6vG+VbYpnZmyglJ4AdWA5FjL74Z9uJi FVR X-Received: by 2002:a05:6102:292a:b0:5ef:6550:e9f0 with SMTP id ada2fe7eead31-5ffe635a38fmr6893836137.36.1773151138280; Tue, 10 Mar 2026 06:58:58 -0700 (PDT) X-Received: by 2002:a05:6102:292a:b0:5ef:6550:e9f0 with SMTP id ada2fe7eead31-5ffe635a38fmr6893824137.36.1773151137997; Tue, 10 Mar 2026 06:58:57 -0700 (PDT) MIME-Version: 1.0 References: <20260305135208.2208663-1-jgross@suse.com> <20260305135208.2208663-9-jgross@suse.com> In-Reply-To: <20260305135208.2208663-9-jgross@suse.com> From: Nick Rosbrook Date: Tue, 10 Mar 2026 09:58:47 -0400 X-Gmail-Original-Message-ID: X-Gm-Features: AaiRm53qgMAlPJhzUrnE_Zj7Ytw_vbgbJ_PVVbxIhcKkx9lbTlUItY5sR8f6mRg Message-ID: Subject: Re: [PATCH 08/11] tools/libxl: add functions for retrieving and setting xenstore quota To: Juergen Gross Cc: xen-devel@lists.xenproject.org, George Dunlap , Anthony PERARD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 5, 2026 at 8:52=E2=80=AFAM Juergen Gross wrot= e: > > Add some functions allowing to retrieve and set Xenstore quota (either > global or domain specific). > > Signed-off-by: Juergen Gross > --- > tools/golang/xenlight/helpers.gen.go | 78 ++++++++++++++++++++ > tools/golang/xenlight/types.gen.go | 9 +++ > tools/include/libxl.h | 20 ++++++ > tools/libs/light/Makefile | 1 + > tools/libs/light/libxl_types.idl | 9 +++ > tools/libs/light/libxl_xsquota.c | 102 +++++++++++++++++++++++++++ > 6 files changed, 219 insertions(+) > create mode 100644 tools/libs/light/libxl_xsquota.c > > diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight= /helpers.gen.go > index 8909fe8a1b..6c9af904c5 100644 > --- a/tools/golang/xenlight/helpers.gen.go > +++ b/tools/golang/xenlight/helpers.gen.go > @@ -998,6 +998,84 @@ xc.policy =3D C.libxl_rdm_reserve_policy(x.Policy) > return nil > } > > +// NewXsQuotaItem returns an instance of XsQuotaItem initialized with de= faults. > +func NewXsQuotaItem() (*XsQuotaItem, error) { > +var ( > +x XsQuotaItem > +xc C.libxl_xs_quota_item) > + > +C.libxl_xs_quota_item_init(&xc) > +defer C.libxl_xs_quota_item_dispose(&xc) > + > +if err :=3D x.fromC(&xc); err !=3D nil { > +return nil, err } > + > +return &x, nil} > + > +func (x *XsQuotaItem) fromC(xc *C.libxl_xs_quota_item) error { > + x.Name =3D C.GoString(xc.name) > +x.Val =3D uint32(xc.val) > + > + return nil} > + > +func (x *XsQuotaItem) toC(xc *C.libxl_xs_quota_item) (err error){defer f= unc(){ > +if err !=3D nil{ > +C.libxl_xs_quota_item_dispose(xc)} > +}() > + > +if x.Name !=3D "" { > +xc.name =3D C.CString(x.Name)} > +xc.val =3D C.uint32_t(x.Val) > + > + return nil > + } > + > +// NewXsQuotaSet returns an instance of XsQuotaSet initialized with defa= ults. > +func NewXsQuotaSet() (*XsQuotaSet, error) { > +var ( > +x XsQuotaSet > +xc C.libxl_xs_quota_set) > + > +C.libxl_xs_quota_set_init(&xc) > +defer C.libxl_xs_quota_set_dispose(&xc) > + > +if err :=3D x.fromC(&xc); err !=3D nil { > +return nil, err } > + > +return &x, nil} > + > +func (x *XsQuotaSet) fromC(xc *C.libxl_xs_quota_set) error { > + x.Quota =3D nil > +if n :=3D int(xc.num_quota); n > 0 { > +cQuota :=3D (*[1<<28]C.libxl_xs_quota_item)(unsafe.Pointer(xc.quota))[:n= :n] > +x.Quota =3D make([]XsQuotaItem, n) > +for i, v :=3D range cQuota { > +if err :=3D x.Quota[i].fromC(&v); err !=3D nil { > +return fmt.Errorf("converting field Quota: %v", err) } > +} > +} > + > + return nil} > + > +func (x *XsQuotaSet) toC(xc *C.libxl_xs_quota_set) (err error){defer fun= c(){ > +if err !=3D nil{ > +C.libxl_xs_quota_set_dispose(xc)} > +}() > + > +if numQuota :=3D len(x.Quota); numQuota > 0 { > +xc.quota =3D (*C.libxl_xs_quota_item)(C.malloc(C.ulong(numQuota)*C.sizeo= f_libxl_xs_quota_item)) > +xc.num_quota =3D C.int(numQuota) > +cQuota :=3D (*[1<<28]C.libxl_xs_quota_item)(unsafe.Pointer(xc.quota))[:n= umQuota:numQuota] > +for i,v :=3D range x.Quota { > +if err :=3D v.toC(&cQuota[i]); err !=3D nil { > +return fmt.Errorf("converting field Quota: %v", err) > +} > +} > +} > + > + return nil > + } > + > // NewDomainBuildInfo returns an instance of DomainBuildInfo initialized= with defaults. > func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) { > var ( > diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/t= ypes.gen.go > index ab9d4ca7b4..5393277190 100644 > --- a/tools/golang/xenlight/types.gen.go > +++ b/tools/golang/xenlight/types.gen.go > @@ -543,6 +543,15 @@ Altp2MModeExternal Altp2MMode =3D 2 > Altp2MModeLimited Altp2MMode =3D 3 > ) > > +type XsQuotaItem struct { > +Name string > +Val uint32 > +} > + > +type XsQuotaSet struct { > +Quota []XsQuotaItem > +} > + > type DomainBuildInfo struct { > MaxVcpus int > AvailVcpus Bitmap For the golang stuff: Acked-by: Nick Rosbrook Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 14:14:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250167.1547636 (Exim 4.92) (envelope-from ) id 1vzxqZ-0004ge-3f; Tue, 10 Mar 2026 14:14:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250167.1547636; Tue, 10 Mar 2026 14: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 ) id 1vzxqZ-0004gX-0r; Tue, 10 Mar 2026 14:14:07 +0000 Received: by outflank-mailman (input) for mailman id 1250167; Tue, 10 Mar 2026 14:14:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzxqX-0004gQ-BZ for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 14:14:05 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 63e658c5-1c8b-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 15:14:02 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-439b6d9c981so6420600f8f.1 for ; Tue, 10 Mar 2026 07:14: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-439dada9116sm33731436f8f.14.2026.03.10.07.14.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 07:14:01 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 63e658c5-1c8b-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773152042; x=1773756842; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=IvFj7BAAy+OPVIRcv54K79IILH7WSbxHWhjWNJQS6SU=; b=ciSayuqOFE8H9HO87bw/gthQyLPLMgTHWuIya6yRysO7F1m1D4XRjIuW0mSg+JN2sE VCLWvuTElpsh+LYEdjVg9tNjMGr4R3T1sp33p7VUzFqXZZblhdMRxSQ02HunAmQuZOzN bcwZ8txPcE8gzOiOaT8yGGPngsdzSjHZcWJp8rZKr3nIDHS5vy7b+oH2pdBTSd0TOpUs 5QpBw+jd/VJKy6B+EQThV1UjCEEP2OfcQb6QgN0aszsDOtctDRj3bpRaBXT8rvLYvQ4n wrq1xHijh/wacGN2yOzvosqaJ/BvtXO8N0slZGCplCs5dXLxDXV1anelBJUuwyeM+6gI GpTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773152042; x=1773756842; h=content-transfer-encoding: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; bh=IvFj7BAAy+OPVIRcv54K79IILH7WSbxHWhjWNJQS6SU=; b=bvrR4o6DUVewZ1XRZ/nH/p69yuHZngo/iJRnF+okRA7Qi/XYoN0vY39LvDgAXLJC0+ 83Bv8xp41WhKlAMxYAEGIa6R7+gdjS/1u/NLbb/1bL9iVPnBGPQid+rTgJ6jEoPr+3Xc SpCrSpZrtedOtEHjy8C3G3aKRhsbh3pHxrtEwtH4NY1tdRR7vR8AwbgsHWfLmC1Jz7kp yNE6+6LxHxiAu/n01CRk6Rmo+gn5zOKCWqiy4lQf4IWQDjiE1dJM96EmUYO6f6z+PqZN DedZpPLsYFpDtLdCeBAW51Ou6FtVwuYzc/ghJOAvagHC/A3PRsdBnA3iLeEyiHaX1TyV WGTw== X-Forwarded-Encrypted: i=1; AJvYcCUfJM7AtxY2eMaOgBIC2AKcXoIgTBtbgvcRCkazVnw/lZKQx6g3RA9V14tE1+bNYOHc4ToCXsIh5Cc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyGKx9xpjzNmTXy+PbzW+RScYOMrdW+bkK2x2etb+e/IVtg3VhH 0I2uVYYHYsan50q5ehtC5AmX6yvG9mpIEDGwajzptKf+8R6yPk4c5w2sE1dqKD5dyQ== X-Gm-Gg: ATEYQzwgfcuvGPsTUoR/zJnwCwyTe8QvNgrjuApYHhZtxtaOV0QtFWVssW/3twF8UkE 4GGH6S192As2UafyRki/gcCyB6p/+LdSSeIR+iBM9xcPMORC8HeAI304Y3kiv5zSZugSv/xWFyQ GQ2A9HPOvDXJ6vmhQazun6GFELcCmJjqh7d0ltr2dbLGU3sALX5ws+pY5N1AFpBGdL9qmTfpiLA UqfQgcK+68VYeAxsvGFXaH82DWzEQcOPhK56wQ8fMPlOAt/0vY/tBw1IwoOWjMzaYfOX7UiOsky fN9ctyRyjHxYiHjen1nvwH2sYYRZ3eY7QqJ91ZW1byQ+408rVeI9099dHg5unjvmsBPlBT3FXtE Gaw8kZ8K05fR4uy6GRkXD5A/yrOAuAWi2cIdAMRuq91Stni+9Lz7JvNd3M1Q4sgPemPUuVKIfrC JRktgqTqCFmMjvWNDnvkRN8PtkBgVv0IcK9KEQo+RXIJL+13JAU8Ljk+3O5Tllp4qC0BIB1cCk7 W1i7JcWc4xbFM4= X-Received: by 2002:a05:6000:1847:b0:439:b6b3:faa7 with SMTP id ffacd0b85a97d-439eff5cdb7mr6880582f8f.28.1773152041960; Tue, 10 Mar 2026 07:14:01 -0700 (PDT) Message-ID: <7adc329e-6690-46ad-b706-74548dc7ccbc@suse.com> Date: Tue, 10 Mar 2026 15:14:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] x86/efi: Add BGRT image preservation during boot To: Soumyajyotii Ssarkar Cc: =?UTF-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com, "Daniel P . Smith" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper References: <20260305191810.31033-1-soumyajyotisarkar23@gmail.com> <20260305191810.31033-2-soumyajyotisarkar23@gmail.com> <609060f4-d94b-4b65-a10b-5126f10307db@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10.03.2026 14:05, Soumyajyotii Ssarkar wrote: > On Mon, Mar 9, 2026 at 1:01 PM Jan Beulich wrote: > >> On 08.03.2026 19:30, Marek Marczykowski-Górecki wrote: >>> On Fri, Mar 06, 2026 at 12:48:08AM +0530, Soumyajyotii Ssarkar wrote: >>>> --- a/xen/common/efi/boot.c >>>> +++ b/xen/common/efi/boot.c >>>> @@ -7,6 +7,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> #include >>>> #include >>>> #include >>>> @@ -173,6 +174,14 @@ static struct file __initdata ramdisk; >>>> static struct file __initdata xsm; >>>> static const CHAR16 __initconst newline[] = L"\r\n"; >>>> >>>> +static __initdata struct { >>>> + bool preserved; >>>> + uint64_t old_addr; >>>> + uint64_t new_addr; >>>> + uint32_t size; >>>> + const char *failure_reason; >>>> +} bgrt_debug_info; >>>> + >>>> static void __init PrintStr(const CHAR16 *s) >>>> { >>>> StdOut->OutputString(StdOut, (CHAR16 *)s ); >>>> @@ -747,6 +756,171 @@ static void __init >> efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) >>>> efi_bs->FreePool(memory_map); >>>> } >>>> >>>> +struct bmp_header { >>>> + uint16_t signature; >>>> + uint32_t file_size; >>>> + uint16_t reserved_1; >>>> + uint16_t reserved_2; >>>> + uint32_t data_offset; >>>> +} __attribute__((packed)); >>>> + >>>> +/* >>>> + * ACPI Structures - defined locally, >>>> + * since we cannot include acpi headers >>>> + * in EFI Context. >>>> + */ >>>> + >>>> +struct acpi_rsdp { >>>> + char signature[8]; >>>> + uint8_t checksum; >>>> + char oem_id[6]; >>>> + uint8_t revision; >>>> + uint32_t rsdt_physical_address; >>>> + uint32_t length; >>>> + uint64_t xsdt_physical_address; >>>> + uint8_t extended_checksum; >>>> + uint8_t reserved[3]; >>>> +} __attribute__((packed)); >>>> + >>>> +struct acpi_table_header { >>>> + char signature[4]; >>>> + uint32_t length; >>>> + uint8_t revision; >>>> + uint8_t checksum; >>>> + char oem_id[6]; >>>> + char oem_table_id[8]; >>>> + uint32_t oem_revision; >>>> + uint32_t asl_compiler_id; >>>> + uint32_t asl_compiler_revision; >>>> +} __attribute__((packed)); >>>> + >>>> +struct acpi_xsdt { >>>> + struct acpi_table_header header; >>>> + uint64_t table_offset_entry[1]; /* Variable array length */ >>> >>> uint64_t table_offset_entry[]; >>> >>> BTW, do we have some canonical place with list of files imported (and >>> kept in sync) with other projects? xen/include/acpi/actbl.h doesn't >>> exactly follow Xen coding style, but it's unclear to me if it needs to >>> stay this way. >> >> I don't really understand why the headers we've got can't be used. Even >> some of the library-like code under xen/acpi/ may be usable here. >> >> While we don't exactly keep xen/include/acpi/ in sync with Linux, when >> things are added we preferably add them in the way Linux has them. >> >> > I was trying to avoid including the headers from the xen/include/acpi/ > since it was specified in the comment. to not include them. > Specific comment specified below this paragraph. > Also since acpi was using datatypes like "u32" while boot.c had types of > "uint32", so it felt a bit non-standardized. > I checked the rest of the boot.c which followed the same manner. So I went > with this choice. > > /* * Keep this arch-specific modified include in the common file, as moving > * it to the arch specific include file would obscure that special care is > * taken to include it with __ASSEMBLER__ defined. > */ > #define __ASSEMBLER__ /* avoid pulling in ACPI stuff (conflicts with EFI) > */ > #include > #undef __ASSEMBLER__ > #endif > > The ACPI headers in /xen/include/acpi uses defines such > as ACPI_NAME_SIZE, ACPI_OEM_ID_SIZE > and ACPI_OEM_TABLE_ID_SIZE these require adding additional > header. > Also since their is no acpi headers included in the boot.c file, so i > thought to I avoid it. > > Thus to get it fully working with ACPI headers from the xen/include/acpi I > would require these three headers. > #include > #include > #include > > I thought this would lead to cross contamination, and confusing to further > modifications in future so weighing my options I thought best to redefine > them, > for code clarity. > Can you suggest me best option to move forward, should I redefine them as > is or include the headers? First - see about re-using ACPI functions we already have. Then put new ACPI code you need to add in a file different from the EFI one. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 15:29:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 15:29:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250197.1547665 (Exim 4.92) (envelope-from ) id 1vzz1d-000524-EG; Tue, 10 Mar 2026 15:29:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250197.1547665; Tue, 10 Mar 2026 15:29:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz1d-00051x-BP; Tue, 10 Mar 2026 15:29:37 +0000 Received: by outflank-mailman (input) for mailman id 1250197; Tue, 10 Mar 2026 15:29:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz1b-00051r-Pq for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:29:35 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f0396879-1c95-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 16:29:34 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5536.namprd03.prod.outlook.com (2603:10b6:a03:28a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Tue, 10 Mar 2026 15:29:30 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9700.010; Tue, 10 Mar 2026 15:29:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0396879-1c95-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LOf+kk2cB9Ku1MGa+Px3wJqXYTBDJCAHL4ripO/5mhdG0Jaz3azeUGxvRvev4B2pyAQVS1V7/HqQ7EDq8RxugQAyLdxsv0GGNUK3qRfoqHsanOh0imHsSCW1JxaxgiqxN58tv0uHV+IqS0JODv7W45AQm1cs34b7/PXISbDriUx+lWPTVvlsAYa7k79Npqa1aCkYOjBw1PVgtAsxE5g1wjsptChvR7gR3iMOQpJoVbhBf28YNMMWRZr5EwyOCiGfoH5TUKfpc/ZLwdufQqVNMQbha/fEBnv7OBx+VlFU53JY6B62l35TS+Azx76GHK6x3TtPfEmz7MRuTf1YEUz5mw== 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=ZSYeDnj5tO0lb7ERQWCY+4rIFbqwAmh28D8IGMmNgxE=; b=WC/uI60B/U06IYDIGDP+QeMpaH25qIWnZ2EMsKmcaSthgANcESKvNfen/yu514CmcCeQeZX2F+7JvqInRFz8eVMmftFZdYYDqsTJOwOIBpl9Mbw7TpgfX+HtSZGl6FLo3pseBmtQ8Ynnx87DsHvbmV+lQYFuhapGvcPWkPyN7baW0O7FGHx+aUPJwywoaSepNKaSHBzfpgmChOX3wbXkG1cYbdVW/XNAXzQ8oySLwzJpKg/oGH4vbkFnPMLoSex0Q4UOukn3/98WHq6iEJoTRL+G6uivUn2VDgtw9l/7EnwcN505qfLLyq1ySCizYXhEKlYjuWw0CwN5WeSdNJMoeQ== 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=ZSYeDnj5tO0lb7ERQWCY+4rIFbqwAmh28D8IGMmNgxE=; b=pUQmiYZQnGKBvMEhyYMgfgfcOnQyeiHYbye2H8ElasNFi9g7TLNN+jClOHTB99+vVZYXW/VpxyhYGfWQsfmJc/sC/1h13pNcOvyKGjfoiDPv5eS5E4zInRbW3PqtjdDIW1MUGjGbSJb0Cwyr62s4XtM/P1qaeoI3xqOdqP3cG9w= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <9eed183c-4157-4432-94ec-a7b7a689fd4a@citrix.com> Date: Tue, 10 Mar 2026 15:29:26 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , roger.pau@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH 3/6] x86: Remove x86 prefixed names from hvm code To: Jan Beulich , Kevin Lampis References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-4-kevin.lampis@citrix.com> <4a5018a2-9867-432b-9464-874532241316@suse.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <4a5018a2-9867-432b-9464-874532241316@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: PA7P264CA0473.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:3dc::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_|SJ0PR03MB5536:EE_ X-MS-Office365-Filtering-Correlation-Id: 837ccb74-9d8c-4847-9f89-08de7eb9d2a2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: GP/t20XMfvDaVQYmZP7SbCYxy3A/U0AuMvaKK+kXjKCk4qk5S3G6n14Fzh0luZKjfz/cdsTczrLw6WsL2u4Iy0/wo9mId7M9TLin+o1UDseSIfvcJGwrFfGo29qpHKlabesyRRBET3eEh27eWPEwtytSea9VaX0jkdYXwqzfyMu07pFmdN3q6YEQh7i6MUG9x0kgYtivVzaZyN/JmgZLTSMpaSI19o+3dDMk6sDalZNxLATLPhhg4Tapi3RSK8utwo4/X81udgMlUsg/Lj4RLEyfdTjCwHmFOmyDttIEkBs/E3Wg+jQZEbotwHIoJVp8QhIVwUxMyirlxljZMR8SisBTWN9HtawQq+G/WDqtc+DCNHUX4BtvNSPjK+gJURnfUEb46oa/PUszYdsflaheJ9Aq1nSKcBNEtWdADRnw+Ke4hZ4aqtxDxmB9izY8vX81ExkCuj2TY/wHYNGEootzchuVP0Ry7qHSw92S6zLmL8a0gEnSlgfDhTFxJxg+IuVyVhN5+Y4KtUNIrmNl1nL+/HcK99lm0Naxn7FM4dLeAcBk/Vn55lhfynWXiGdNzmDWneYwPmcy4jiSu7RX4PO6Iy6XWADEd57ugZXj7zZ+Tm9F2nj81sAXbQ6fA/iXSB2/8ARR7b/o5njF7gD+ZqmU2K9Si4+KUp25PUBO2tVTELX0XZ9rZoWql+ZeDk+jAWNg1bEvcro5JHM0511oyKotfCF7ITDO/f2dCSGsimMG+lU= 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)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?elBoa0RPRWpCcTlvV2kzVnFjWTA4NWxBa3ZXaEV0VjF3RVhaZVZwY2ZrTzY4?= =?utf-8?B?Y200RHFBcUJ4UXFFNEMzdmZFaHo5YWNCbWUxTUlZTTFuQVpMQXBheEhjck9x?= =?utf-8?B?KzVnMDdodTFIRm1ram8wQ0kvK3BwYjE4K05UUjkrd3BlNDlzRDdQNE9wSWJC?= =?utf-8?B?Q1AxSG9hbVlreGluQ3BoYWh3N2lLMEErUVV3Mzh6RVBhZWQrWWluUlVqYjZF?= =?utf-8?B?Q3ZRY2ZVSzM2RGF5VXFhOUFWdGw0ZjR3VHdHU0pON21sVHpsL3lHRktFVmI1?= =?utf-8?B?c2hRcVZTYzU2ZlAvckVLRVBZZTJKRkEwalNDQkVqQlRFMnNpeFJWNXNjQXJY?= =?utf-8?B?K01JSkxUa1hKSFcrdU9RaWtxcXpKeUFuTERVWThqNTJ0UXJubURKUWVmc2dO?= =?utf-8?B?ejFYaHkrZFdLL2Y1VWFOdnBYUHdKVElmNlBnRGgzVkxNT2htOUp5eHgvbThR?= =?utf-8?B?VzNuaVpHQzZvaFZIYi94bFlrVlkzNW1xVnJ4RnBveFJLWW9VNVBGTHNHS3pw?= =?utf-8?B?aXk1UVB2NENYM0xHaFBTQ1ZsZVpmOVRrYk5aanZxc2ljSXNUV3orY3VWZmYr?= =?utf-8?B?TGdTK3dIdkRnUjcwTmFiVWNTU0hiS2cxUWp1UnJlNk1GWTMwOHdLVTBGYzFI?= =?utf-8?B?UkprdVpybStFMGdFV2YwYmMwcTNacXBxZ2lBVkdISlFOVXR3WmRtQVNEOWpR?= =?utf-8?B?NTM1cGY4WmdiNU5wcXFUdVRibVBjSVpIYUJxQSsyUHlaSUU5NnpudVlFWXBT?= =?utf-8?B?RU5PM3E1YVM2d2xUQjZYb2VQRnptR0hzd2RrcXZuTDV6dTRPcmQwK0pKKzgw?= =?utf-8?B?bUo0a0pneUdDcnQ3NDhMZGl2RFA2V2p3UCtmclhFZEdSdEVOQ2VZZWVZeVNL?= =?utf-8?B?eGhSeFA2WENrMUQzWHVRY3pRaGdMUFI3QXpXU1lYcTFkMEpuazNGNjI4UGRF?= =?utf-8?B?WFdteXdtbDgwZDVXUlFxTE5IUXdwbzhRbGpRUkxjYWRFbXVuU3JsZFBCUUVy?= =?utf-8?B?Wm9SNHVwRWhpeHJoRjlKeTQ4ZXFKRTlhaTdaZUx3TTJkeU13VVZJTEJpWTRW?= =?utf-8?B?Q3lnNzkycmo3ODcxNXJjQ3kyNEVUOW5kSFFDTDl3U0g1Z3o4WGtqQjlYVmlm?= =?utf-8?B?NjdXL04rUURrZWN2bjU4MVYvY201OFJnMGR4bTJrSG9nc2R5czF0cFRveFY2?= =?utf-8?B?bG4vQ2ZIZDI4VU9EbEE3Yk05eWs1UEdndWxHVlNyalBtVlVCMThwaTlOUFBO?= =?utf-8?B?MEZlWVplMkVkaVlZMmxGVWF6Vktsd2RHZlNzQy9IU25qS0RTNmM5Zlh3bStY?= =?utf-8?B?dFFVVldTQjVlcjBvZnhHSFB4SHhhK0NqTFR3alR6RXI3dUM0d1FpS0t5VmhC?= =?utf-8?B?MUhiY3V2R1ZFTTBUdXd3OHZtRWQ1Yi9WYjRvMkJLMFJsdEEydURnTHplQlA1?= =?utf-8?B?QmNFbWFyd05iZUJ3aHdTZnN1cHg5M0ZabHVLSXBuZ2sraDVDMEpwOXNPKzlw?= =?utf-8?B?YzJRb3M4TFVjY3U3eGpGM1kyWE1kY2orVzZaTFNDYkVmRmQwR3VkRVlxc1ZR?= =?utf-8?B?NERhUnFsTkNrR3ZRcDJyaDczeTRpdWtuSk8zNnIxcE5GZG1QWmlUTksrcWRG?= =?utf-8?B?dnd3M2Jic0lDU1pacms1OFJkZm9lRnh1akIvRnBQMEVVY3dNT0xWbXgyK3N6?= =?utf-8?B?emVHck1IdEJvekxCUE9kYlMreUEyUGg3TEFINXFnMnE3MXZ4SG9aejZTbnlz?= =?utf-8?B?WVlGVGgvUzB4WjJMZk1LNXRKelJFa2ZaWkk4cUZBalJhSTVIY0w2TytYbFFC?= =?utf-8?B?R29SY0liZzBtVlFRT3ZsRVZoVjBnMmhRNW9TVnlLdExSaUhOa0oxTnR6VzdX?= =?utf-8?B?WFA4T2doMnZ6bSttNkRxK3Vrd3ZiZk1KVE8wN3JvNWI4S2FjRW1QdlM1USty?= =?utf-8?B?N1J3MjBoangxY21RVkREcGpCNmdtd2NZd05SamJhUnVnUmN3OHRmTWd6MUhN?= =?utf-8?B?MUpmVm5DbEFjaWJLWjRlVUpHR1FSSUxrUyt2TU0wZmI5V0pvRmliV0owTG1J?= =?utf-8?B?S3JjT3dxQTlxZTdheWgwR2w1N0xSYWE5SW1Yd3VtMUdNNjJabm1ZUkxCdzFo?= =?utf-8?B?c0swVitsY2dDWU9IMCtobzQ1NGFIZkM0U3ZaNEQwU3dVTnpUZkRaSkQrRm5R?= =?utf-8?B?MGNHckYxcGFldXIzRWc3TnRBZ3ZDMTkwZ0FmVmdxa2MzL2J0NkNCem5YNnpB?= =?utf-8?B?SmV3cFRSWWZVZFJPa25KRFA5cDRIY214eVUvTEtuT09teU95OWpjM080VkM4?= =?utf-8?B?OXFrTE9wOFhQc0tzejFCcWU2K3VNNmMvSG9uNlpWNGkwOXNiVW81Zz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 837ccb74-9d8c-4847-9f89-08de7eb9d2a2 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 15:29:30.1901 (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: 8YWBDZz4nc8ZqbUI8TcOlZvEssWjg5aZowXblsR9LyJgXXoh1rnaZNdbZTNl3lSZpaDvp487q5ke5H187yZlqDH01XBykGDV1vvf6EQrNwc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5536 On 10/03/2026 10:26 am, Jan Beulich wrote: > On 04.03.2026 20:53, Kevin Lampis wrote: >> struct cpuinfo_x86 >> .x86 => .family >> .x86_vendor => .vendor >> .x86_model => .model >> .x86_mask => .stepping >> >> No functional change. >> >> This work is part of making Xen safe for Intel family 18/19. >> >> Signed-off-by: Kevin Lampis >> --- >> I couldn't find any information about these Intel family 6 processors: >> model 0x5d: /* SoFIA 3G Granite/ES2.1 */ >> model 0x65: /* SoFIA LTE AOSP */ >> model 0x6e: /* Cougar Mountain */ >> Should I add them to intel-family.h? > We should keep that in sync with Linux, I think, so "no" unless you mean to > first have respective entries added there. > > 0x5d is listed in the SDM, so I'd recommend keeping the entries (using IFM() > directly for the time being). > > 0x65 and 0x6e aren't listed in the SDM, so may never really have hit the > public. Respective cases can perhaps be dropped, but such dropping would > again likely better be done in a separate change. These are the 5G basestations I mentioned during the x86 meeting.  Linux has declined to take take these models into intel-family.h because they're not general purpose. I suggest we drop them, including 0x5d.  I can do a separate patch. > >> @@ -3073,71 +3077,71 @@ static bool __init has_if_pschange_mc(void) >> * IF_PSCHANGE_MC is only known to affect Intel Family 6 processors at >> * this time. >> */ >> - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || >> - boot_cpu_data.x86 != 6 ) >> + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || >> + boot_cpu_data.family != 6 ) >> return false; >> >> - switch ( boot_cpu_data.x86_model ) >> + switch ( boot_cpu_data.vfm ) >> { >> /* >> * Core processors since at least Nehalem are vulnerable. >> */ >> - case 0x1f: /* Auburndale / Havendale */ >> - case 0x1e: /* Nehalem */ >> - case 0x1a: /* Nehalem EP */ >> - case 0x2e: /* Nehalem EX */ >> - case 0x25: /* Westmere */ >> - case 0x2c: /* Westmere EP */ >> - case 0x2f: /* Westmere EX */ >> - case 0x2a: /* SandyBridge */ >> - case 0x2d: /* SandyBridge EP/EX */ >> - case 0x3a: /* IvyBridge */ >> - case 0x3e: /* IvyBridge EP/EX */ >> - case 0x3c: /* Haswell */ >> - case 0x3f: /* Haswell EX/EP */ >> - case 0x45: /* Haswell D */ >> - case 0x46: /* Haswell H */ >> - case 0x3d: /* Broadwell */ >> - case 0x47: /* Broadwell H */ >> - case 0x4f: /* Broadwell EP/EX */ >> - case 0x56: /* Broadwell D */ >> - case 0x4e: /* Skylake M */ >> - case 0x5e: /* Skylake D */ >> - case 0x55: /* Skylake-X / Cascade Lake */ >> - case 0x7d: /* Ice Lake */ >> - case 0x7e: /* Ice Lake */ >> - case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ >> - case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ >> - case 0xa5: /* Comet Lake H/S */ >> - case 0xa6: /* Comet Lake U */ >> + case INTEL_NEHALEM_G: >> + case INTEL_NEHALEM: >> + case INTEL_NEHALEM_EP: >> + case INTEL_NEHALEM_EX: >> + case INTEL_WESTMERE: >> + case INTEL_WESTMERE_EP: >> + case INTEL_WESTMERE_EX: >> + case INTEL_SANDYBRIDGE: >> + case INTEL_SANDYBRIDGE_X: >> + case INTEL_IVYBRIDGE: >> + case INTEL_IVYBRIDGE_X: >> + case INTEL_HASWELL: >> + case INTEL_HASWELL_X: >> + case INTEL_HASWELL_L: >> + case INTEL_HASWELL_G: >> + case INTEL_BROADWELL: >> + case INTEL_BROADWELL_G: >> + case INTEL_BROADWELL_X: >> + case INTEL_BROADWELL_D: >> + case INTEL_SKYLAKE_L: >> + case INTEL_SKYLAKE: >> + case INTEL_SKYLAKE_X: >> + case INTEL_ICELAKE: >> + case INTEL_ICELAKE_L: >> + case INTEL_KABYLAKE_L: >> + case INTEL_KABYLAKE: >> + case INTEL_COMETLAKE: >> + case INTEL_COMETLAKE_L: >> return true; >> >> /* >> * Atom processors are not vulnerable. >> */ >> - case 0x1c: /* Pineview */ >> - case 0x26: /* Lincroft */ >> - case 0x27: /* Penwell */ >> - case 0x35: /* Cloverview */ >> - case 0x36: /* Cedarview */ >> - case 0x37: /* Baytrail / Valleyview (Silvermont) */ >> - case 0x4d: /* Avaton / Rangely (Silvermont) */ >> - case 0x4c: /* Cherrytrail / Brasswell */ >> - case 0x4a: /* Merrifield */ >> - case 0x5a: /* Moorefield */ >> - case 0x5c: /* Goldmont */ >> - case 0x5d: /* SoFIA 3G Granite/ES2.1 */ >> - case 0x65: /* SoFIA LTE AOSP */ >> - case 0x5f: /* Denverton */ >> - case 0x6e: /* Cougar Mountain */ >> - case 0x75: /* Lightning Mountain */ >> - case 0x7a: /* Gemini Lake */ >> - case 0x86: /* Jacobsville */ >> + case INTEL_ATOM_BONNELL: >> + case INTEL_ATOM_BONNELL_MID: >> + case INTEL_ATOM_SALTWELL_MID: >> + case INTEL_ATOM_SALTWELL_TABLET: >> + case INTEL_ATOM_SALTWELL: >> + case INTEL_ATOM_SILVERMONT: >> + case INTEL_ATOM_SILVERMONT_D: >> + case INTEL_ATOM_AIRMONT: >> + case INTEL_ATOM_SILVERMONT_MID: >> + case INTEL_ATOM_SILVERMONT_MID2: > Can the Silvermonts please be grouped together? > >> + case INTEL_ATOM_GOLDMONT: >> + //case 0x5d: /* SoFIA 3G Granite/ES2.1 */ // XXX ??? >> + //case 0x65: /* SoFIA LTE AOSP */ // XXX ??? >> + case INTEL_ATOM_GOLDMONT_D: >> + //case 0x6e: /* Cougar Mountain */ // XXX ??? >> + case INTEL_ATOM_AIRMONT_NP: > Same for the Airmonts and ... > >> + case INTEL_ATOM_GOLDMONT_PLUS: > ... the Goldmonts. We need another sync to intel-family.h.  Christian made a correction or two in this area.  I'll do a patch. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 10 15:33:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 15:33:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250209.1547682 (Exim 4.92) (envelope-from ) id 1vzz5C-0006cA-4A; Tue, 10 Mar 2026 15:33:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250209.1547682; Tue, 10 Mar 2026 15:33:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz5C-0006c3-17; Tue, 10 Mar 2026 15:33:18 +0000 Received: by outflank-mailman (input) for mailman id 1250209; Tue, 10 Mar 2026 15:33:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz5B-0006bn-5h for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:33:17 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 72f44dfd-1c96-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 16:33:14 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5536.namprd03.prod.outlook.com (2603:10b6:a03:28a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.25; Tue, 10 Mar 2026 15:33:09 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9700.010; Tue, 10 Mar 2026 15:33:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 72f44dfd-1c96-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=HxFMpE/pQMLi+wMcJYqrBc/qcKgdfG9XBfKOv6ZPQj8wWob6R+VZxHj+Sakp3oxjMVeNOTw0ioy7YejVEkRRNBTrScM3S2icPWhdOlLEhGuLLuCrLETtC9z/HjEoHIRpBV7iRS/5OcXCR6JqKzUJepq2mLsQgAZXkW43QSruUnDm9LLQfPrOD4QImUYZo4BhLnl0YKklgPlmEfxiyovgKzhukMdZpZp/Kq1TiQYs/cLlLCGg/Y6KocRjQgLL9zj+quVyH58rMRq4PwPtOT4w8CO3FSEcwf27tQjqSYcpQWgC/bTIxrt+mHdKx7ecymaLipxBKG7fgg7YuGEQn/ohvA== 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=KvYyQWMH+apiELISRx4dcMqrsGKmwXo2+p/KCJkUEDY=; b=pVlrlSIr0WeW6UoSvDgZCJ75qbgMeyeOASpnYCry7C8G3hwxXdMvovRHvIdCK903ulZcnPpO2vMke2z+L9ronREx3JIBqZLHs4Up/8Fh2/j+6cjC8xXQWG2ZbcszNp225ZUBCerzh5ym6ixvYaJ2rAFaqg4aFe2BXL/kQmXrPB4y4eDdIGGpP0kSQfeybm6Dvlzfj3YK9JfJ0OGugi5ldlwed44GObFH8Mbviyxn3HOKEkDr1MkZCey0GCtjLYxoPlJKppXEhor+ardI/RsXbEAluXHejul5znLIKj1tPK9nEYgVTYZyjPSVGUPlueRdwU94vmcEM3lxPQCDvkILqA== 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=KvYyQWMH+apiELISRx4dcMqrsGKmwXo2+p/KCJkUEDY=; b=nq6Dx2gAHjbI6oaAzScj3mYUFhEzVGTNnlRvgOWj2If1yEOfTaQP/0nkMbKKKFbmil7CiM9eU+/vCbMXoF/Cvh5rAKlZot7aZPcMkMIfWxNyagWR7a8cLJKSCa8t2ZipnFVEvuKAyTikA1+csw+41xnw9hGm7NVD7VLr7pb9E9g= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: Date: Tue, 10 Mar 2026 15:33:05 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , roger.pau@citrix.com, xen-devel@lists.xenproject.org Subject: Re: [PATCH 3/6] x86: Remove x86 prefixed names from hvm code To: Jan Beulich , Kevin Lampis References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-4-kevin.lampis@citrix.com> <4a5018a2-9867-432b-9464-874532241316@suse.com> <9eed183c-4157-4432-94ec-a7b7a689fd4a@citrix.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <9eed183c-4157-4432-94ec-a7b7a689fd4a@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0029.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:313::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_|SJ0PR03MB5536:EE_ X-MS-Office365-Filtering-Correlation-Id: 5a2fc338-3d5f-4a25-5cba-08de7eba552c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: z+OjmC2FsSw0ViyG5W8zka31gZIL4MI1Dd6e1Ww9dd45G6Sxv4JeRjrhCCX4iTOBYbi8lf4R5RLgeVbVXgH7CezoQD9l0OoIHnbCBneHkA+2VKt2YwEK1o1LXkjETgopc12kn2bbkr+wgw0sqRNKFpKR1TMm0xRb686h8bOD7Tk/ZcOTTIi230bbXWerltYOnKoAD4NI8h5BubEk1F3d6Aarfkvo7in1Ona0jEiwWVfYUoNmC53NlvQSzmb4pb8gqwBuo2YK2p9fRLnlUaT+/o2PTjy2iTI7jcaBUGNJxG778J+xJ6oxooyZbnq2MSgY7XabuXJHr7sxP2E8LK2RBraH4dcyl8MFfL75cC8lc+Nm/KNbkjbAz5a/py5S/aqmdskZyzaSoaLnvobGmTG+MWgmkMnFGZTtRZOc+mcPnvmaT511dnbSzTbeZleD7T0k0T+5xtP1FRw4nAxyIbow67yBfeeqBxcQfR0Qbj6ONKpuwY3A/T4KSalKbqojeq0BsFUMLNgHtMS+AbNhRTfLFPKMgx1KYxTCKao9CzJbmM4rj378V6JNGT4q7WBSduKIf62naNNsc9Jy71A/QJPG57QzkEfI0GnEc4x96zbW985eKd1qu95pI8CEXdkpR0xMiOJlT7pykVKVz0JYQ0ODVir5GOpuG8iFtcgCAGt9ZBc45yHIZjAxdQV3FQx/2qQNqX8EV0ZRZExY9OPDp64KZvvQx7o9BuFdaQ1Uxz0AaO0= 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)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NjVNR0E3K2VsWkpvcFZNclVhNUtOVVRpbjJXUmJyWjRFL3VTL1RhWGMyb0Nz?= =?utf-8?B?RFB1dkVTcmd0QStzaGo2Ni95WHc4S3RZOWVPMjQ1VmorbjNxQUV2eCtibTFP?= =?utf-8?B?SUxnaU1mUk0wa2tVRG1kQmo5Y1ovSDYvN3NMK3Y0dE0zdzVBdENwbjg4ejdj?= =?utf-8?B?Rmpqc3R1WE1mT2hja2g2UnFmRXQ1KzhhOTR4RWR0TnZma3FCZ1I0MG41TE1W?= =?utf-8?B?bmFFWTNMU2dFUWphbFFuZW84Mmlia212WTBRZHBhdlNmREJzSGNFejQ0anJa?= =?utf-8?B?V0xxVFFLQXczK2ozWFBRejdaWUIwVysxUTdROEhoYnBwY2JEdzA3L3dXRDFm?= =?utf-8?B?MnloRWNTcm9kcENkZ01mb0RvY29WR21YbWRHZktjclhzaitUN0RFYnFQYVFp?= =?utf-8?B?YkpjclduclM0bzdvLzluUlkrckIxL0RGL3FWdVdCb0c0YjdQMTM3OHZ5SSs3?= =?utf-8?B?N3ZseE03U1c1bXo4Q3liK25jaXFmbXl2amhGVmpWQk9hWDAvVlg5WGdGTDQw?= =?utf-8?B?bmlyWG5WQlJ5b2tLaElKbzRhRjMxODhRdVNrSWd3eDAxYmpKWDhFb29jc25v?= =?utf-8?B?VTdtcFVva2xZUndKcFlqaDhoUTVabnJZSG5WSkNaYlVXT0pQWkRpK2FINGpZ?= =?utf-8?B?Y1Y1aGtMejd0MmdPR3pUNVQ4NEZjWTVucFRXSy9lRnM0OTIvek1OM1dFMmVt?= =?utf-8?B?TkFuWjVMMzFjVW5Hdk9aenJmZHlPRldSSkplMTZwRlB3THk5U0tCVFhJOVRE?= =?utf-8?B?SmJXQ3J5OEhzR0tNb09KSExlbFVyb3lqQjNRc1hieGpZdlpxaEljaURhL0xn?= =?utf-8?B?VFhHeC81YWl0TkdYbGtHeU95WDdwemJsV0JwVDdSTVhGOHk5aStEMXFCdTZF?= =?utf-8?B?K3ZjWlV3VjJCMHBmbjNXNTZ5UEtWMml4ZktPYjlCem1vUktzQ1dDQ3dDM3c5?= =?utf-8?B?SlYzSUJ1T3VEdVJTT0VNWGg0Z0lQbk95RFZSWjRpd0JQSFMwYlQrdjB1ZWF0?= =?utf-8?B?TkxJRHFCcTFkbUV5V1BTRzF0cTlaUzluTmYyYlhoT01Qb0psdTVnaTUxMEFk?= =?utf-8?B?aTdjRHgwNVFFLytJRXJxZ2MrVXRIdVN2WmsyVTZibDFjSEhCcTk5T0lsZ1pM?= =?utf-8?B?RWs2b3ZuNFpJQ2F3cGdtNTU0dTFmZC9mNWJwb0xiaGtCMjNNSXBBVG4zajNj?= =?utf-8?B?cStMYnBHNElCV1ozZWdaUzNDYm5NTEYzTHRjRElhUVJEclRabDdpWkY4dUV5?= =?utf-8?B?Z2NlRyt5T3NSc1MxNnNKazlJYkhLUHU1M01vOGt0NlFqeVUrWHVleHVnbXB1?= =?utf-8?B?WGZwV2twS2lmZ004Y0s3RTJvQ1R0dExqVUIyeVNWeW1pc0owcExMRG91bktR?= =?utf-8?B?M2RKa243WXJSeFMrbDlSZlJ5RS8zd2tpbzcvajQzeXdDNWluZWlyeG8ydzlE?= =?utf-8?B?MkcxVC90U0wvUllvS3dseVpmUzRmN21lS2Z2NW1VSFZjSXdTWWtrdnlkOW12?= =?utf-8?B?bVFTbkVrMG9KQ1hHTEVDQmRHaDhXTFk3WURTdmI5Vm9NR09SZ3dSUkh1UnZp?= =?utf-8?B?eDB0QUVrVXRKMVFJRXZXSTJwdm1mYmZ4dkx6Vk5LRFhCNVZ5OUFyd3lYU0JT?= =?utf-8?B?dTE2UEp4eVFTWVg0cVhEaHgrQ1lOMVR2Qzd2WWJwTWJrdExxOUVHeTBpelNS?= =?utf-8?B?VmJMdFpYa1FkdWk0c0dHK0l0OE16ZWFJM1hmR1krVGpaQXZ4SDJrOHBjL2la?= =?utf-8?B?Uk9ERFpxTW9FTUU5VW96TVVNN21RWFBJeEJwa01sclI5SkZMTHlveTZSZnRN?= =?utf-8?B?SUNGOWtJYllyQUF5UDhXSTdyMEFDZWVxamg5MkZrTHExcDh6ZHM0U2lFTi9P?= =?utf-8?B?ZlVGa1FyZzZuSVBqVUxTcnE5VUQzSkNBNGhyVzhwMlJLRUp0UTEzb2JvVlQ1?= =?utf-8?B?L3BpY05FYm5meEVZUWJTS1VDZ2pOMlZVT0FSU0RoOG9rNk1Wb0hiZG16eUdz?= =?utf-8?B?L1B6Yy82NHVha2xKYWcxaFp6L0xpWUZqTzlSOEF3UjVicm5rd1NJbjhNdVdv?= =?utf-8?B?Z1FKWnZVa2RvVlhIVTFFckoyNVhjMWpXY1NVUUVkMmdMNlI4RGtNdW5oTG5M?= =?utf-8?B?UzJ1VktrM0xud0R3amJKKy9vUUwvOFh5TFY0YjdWcks1WlJxQ3BRZ3JHclVZ?= =?utf-8?B?cXVraWhybTFQeURWbkVYSm5yenFPeTU5QkdPUjAyb3hIbWdFd0ZMbjhmcmFw?= =?utf-8?B?d0hMSUZJQW5heVMzZnB0dEgzbDR2eUdnOC95UXI0K0VUcHZmU2ZZTzlxeito?= =?utf-8?B?c3hIQ1IrcTZGb3dIbTFmcFZRM2duUUtjVkljZlRmdzdnV1grYjFyQT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a2fc338-3d5f-4a25-5cba-08de7eba552c X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 15:33:09.2068 (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: NUxPpIJHuzTxN/gUUBG0uqag4s2Uq2f4sRq7XQCAAoOjlndGYG2ciBY/796NVL7X65dp6KxwqHjnTYWGjomcFnWW6NpwqZW+AYVaai4n27c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5536 On 10/03/2026 3:29 pm, Andrew Cooper wrote: >>> @@ -3073,71 +3077,71 @@ static bool __init has_if_pschange_mc(void) >>> * IF_PSCHANGE_MC is only known to affect Intel Family 6 processors at >>> * this time. >>> */ >>> - if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL || >>> - boot_cpu_data.x86 != 6 ) >>> + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL || >>> + boot_cpu_data.family != 6 ) >>> return false; >>> >>> - switch ( boot_cpu_data.x86_model ) >>> + switch ( boot_cpu_data.vfm ) >>> { >>> /* >>> * Core processors since at least Nehalem are vulnerable. >>> */ >>> - case 0x1f: /* Auburndale / Havendale */ >>> - case 0x1e: /* Nehalem */ >>> - case 0x1a: /* Nehalem EP */ >>> - case 0x2e: /* Nehalem EX */ >>> - case 0x25: /* Westmere */ >>> - case 0x2c: /* Westmere EP */ >>> - case 0x2f: /* Westmere EX */ >>> - case 0x2a: /* SandyBridge */ >>> - case 0x2d: /* SandyBridge EP/EX */ >>> - case 0x3a: /* IvyBridge */ >>> - case 0x3e: /* IvyBridge EP/EX */ >>> - case 0x3c: /* Haswell */ >>> - case 0x3f: /* Haswell EX/EP */ >>> - case 0x45: /* Haswell D */ >>> - case 0x46: /* Haswell H */ >>> - case 0x3d: /* Broadwell */ >>> - case 0x47: /* Broadwell H */ >>> - case 0x4f: /* Broadwell EP/EX */ >>> - case 0x56: /* Broadwell D */ >>> - case 0x4e: /* Skylake M */ >>> - case 0x5e: /* Skylake D */ >>> - case 0x55: /* Skylake-X / Cascade Lake */ >>> - case 0x7d: /* Ice Lake */ >>> - case 0x7e: /* Ice Lake */ >>> - case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ >>> - case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ >>> - case 0xa5: /* Comet Lake H/S */ >>> - case 0xa6: /* Comet Lake U */ >>> + case INTEL_NEHALEM_G: >>> + case INTEL_NEHALEM: >>> + case INTEL_NEHALEM_EP: >>> + case INTEL_NEHALEM_EX: >>> + case INTEL_WESTMERE: >>> + case INTEL_WESTMERE_EP: >>> + case INTEL_WESTMERE_EX: >>> + case INTEL_SANDYBRIDGE: >>> + case INTEL_SANDYBRIDGE_X: >>> + case INTEL_IVYBRIDGE: >>> + case INTEL_IVYBRIDGE_X: >>> + case INTEL_HASWELL: >>> + case INTEL_HASWELL_X: >>> + case INTEL_HASWELL_L: >>> + case INTEL_HASWELL_G: >>> + case INTEL_BROADWELL: >>> + case INTEL_BROADWELL_G: >>> + case INTEL_BROADWELL_X: >>> + case INTEL_BROADWELL_D: >>> + case INTEL_SKYLAKE_L: >>> + case INTEL_SKYLAKE: >>> + case INTEL_SKYLAKE_X: >>> + case INTEL_ICELAKE: >>> + case INTEL_ICELAKE_L: >>> + case INTEL_KABYLAKE_L: >>> + case INTEL_KABYLAKE: >>> + case INTEL_COMETLAKE: >>> + case INTEL_COMETLAKE_L: >>> return true; >>> >>> /* >>> * Atom processors are not vulnerable. >>> */ >>> - case 0x1c: /* Pineview */ >>> - case 0x26: /* Lincroft */ >>> - case 0x27: /* Penwell */ >>> - case 0x35: /* Cloverview */ >>> - case 0x36: /* Cedarview */ >>> - case 0x37: /* Baytrail / Valleyview (Silvermont) */ >>> - case 0x4d: /* Avaton / Rangely (Silvermont) */ >>> - case 0x4c: /* Cherrytrail / Brasswell */ >>> - case 0x4a: /* Merrifield */ >>> - case 0x5a: /* Moorefield */ >>> - case 0x5c: /* Goldmont */ >>> - case 0x5d: /* SoFIA 3G Granite/ES2.1 */ >>> - case 0x65: /* SoFIA LTE AOSP */ >>> - case 0x5f: /* Denverton */ >>> - case 0x6e: /* Cougar Mountain */ >>> - case 0x75: /* Lightning Mountain */ >>> - case 0x7a: /* Gemini Lake */ >>> - case 0x86: /* Jacobsville */ >>> + case INTEL_ATOM_BONNELL: >>> + case INTEL_ATOM_BONNELL_MID: >>> + case INTEL_ATOM_SALTWELL_MID: >>> + case INTEL_ATOM_SALTWELL_TABLET: >>> + case INTEL_ATOM_SALTWELL: >>> + case INTEL_ATOM_SILVERMONT: >>> + case INTEL_ATOM_SILVERMONT_D: >>> + case INTEL_ATOM_AIRMONT: >>> + case INTEL_ATOM_SILVERMONT_MID: >>> + case INTEL_ATOM_SILVERMONT_MID2: >> Can the Silvermonts please be grouped together? >> >>> + case INTEL_ATOM_GOLDMONT: >>> + //case 0x5d: /* SoFIA 3G Granite/ES2.1 */ // XXX ??? >>> + //case 0x65: /* SoFIA LTE AOSP */ // XXX ??? >>> + case INTEL_ATOM_GOLDMONT_D: >>> + //case 0x6e: /* Cougar Mountain */ // XXX ??? >>> + case INTEL_ATOM_AIRMONT_NP: >> Same for the Airmonts and ... >> >>> + case INTEL_ATOM_GOLDMONT_PLUS: >> ... the Goldmonts. > We need another sync to intel-family.h.  Christian made a correction or > two in this area.  I'll do a patch. Scratch this.  It looks like we're already up to date. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Mar 10 15:36:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 15:36:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250222.1547698 (Exim 4.92) (envelope-from ) id 1vzz8B-0007FJ-Kc; Tue, 10 Mar 2026 15:36:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250222.1547698; Tue, 10 Mar 2026 15:36:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz8B-0007FC-Hr; Tue, 10 Mar 2026 15:36:23 +0000 Received: by outflank-mailman (input) for mailman id 1250222; Tue, 10 Mar 2026 15:36:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzz89-0007Eq-RF for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:36:21 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e2c59489-1c96-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 16:36:20 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4852c9b4158so27902375e9.0 for ; Tue, 10 Mar 2026 08:36: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-48541b7f3cdsm94249015e9.14.2026.03.10.08.36.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 08:36:19 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e2c59489-1c96-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773156979; x=1773761779; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=ChPtLyUjSlXIN1qUGMITksg94TOXzdsCupOaSiQ6YKM=; b=Lk+lFEJNwGT+klcpA78Onv1G4LhwjEeP/hskYVNt0tTPOzjuqJHTAxoyJNHYczC3Qt h+1M11lCh/NJKRF7vuZlKM15ic4yhhibdr87tu8G5po3c5SoQ4IUoCps6nWRceTTJgRD 3dg5Cq86/Xy5C8hqcFpfGH3mNg0bf5xFFr/W3C0xcOmKHn6ZjWWil/TmiSIlnMhVVAdS qREhzpaGRAZaXWeFPeNmpxoBM7pInOPEaP94+KxKz9uZiryzPG9slsv2S5ykmDX9lMa5 sHcUaGRrCKAih2KH1I86Rmddn92xSaMWb1J3M1Q80qV6uqSEOSSPUfK/RVvAC61eDeZC 5dnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773156979; x=1773761779; h=content-transfer-encoding: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; bh=ChPtLyUjSlXIN1qUGMITksg94TOXzdsCupOaSiQ6YKM=; b=GA8EXTcpmZqJoT05rnoRW5l3uLYz3HwC6Ao1hj5ojFpK7vOz0QZnI5G17DMc+lrF6O GVDMslIDMb3I8ednHSmKUw55R2gd5RYxzE6v0KD7nH8zKcPY8gPmpEYq53yV/uEW4NKU i5zB+f9iYeaCcdz8K1/8SGtHaeZi9wm5bpnrbTTJdygWj4BES8/2fO5yZ6IsDT+PIOp6 8GXd6SZbTDcn7Vka35L64tN1VF+qrUHuLhq6j4Sw7ly1fGILXokwBPJ4cIiIDjVJg2hL s4RQHfdDZ1ysH7FrdyD68NRhjjRei2uRps4Tp5mJ/t7OiqEQG02h5yt1JIdMEoQK8fOw yn0w== X-Forwarded-Encrypted: i=1; AJvYcCU8t7fDSuC7CeZvwWiFLo3PckgpPOZxoFEWA7bpEFspXlSWh2CZX977qkalnjXX/sauqqWNygVVK6g=@lists.xenproject.org X-Gm-Message-State: AOJu0Yxm1XDBwsbmVKM1u/5b4OpPK8b8mdOIgP5t0CLxtebco3EGZsA1 xrBUWVYFTomCq0X+oBis7dxOA/FiuZ0SmdM14sQU9e3hi+eDU7zWAOSUxBnrFxjD4Q== X-Gm-Gg: ATEYQzyzk6ALo2C7E9H8cwwK7Obe+nkc9WKvdCFNVvCL32WknpdvS8Qi+RIZNdSXwdu BtMxgA/VS0fqRtGn3ndA1lqO0x8ZwEpCFr2yVF/r1hQG67EBUYJMmsT3+Cyfi46/TczmNHJGheS SanuvQuesgWSlRIQIL2TNp6cB3avQgv95wPUzw3C2jFqZUJkIBgB+8rWUpQ0aYXhbzDVGjfaAYe wO/irysdfdlvv0b9+1KVq3SGRSVI5AT5tokRs27t5+UhglgM13NMby13KrjEAm/k3JkdTFO8XHi Swx2TPO9YGCt4zrSUhJmWbGRq5LYBq2HjE9GN9isEgL6Ph7p3RcWQRggWzMfrhubiPeO1dNg89z vY1m4PorM2E/OeaEgsZmLEctP66KfbdRZeKcTsWHEyeJcvemJHbLEPeYSCS3HGyi05784/meHiD fUE1Z8DJpfVUfmdj1LcB6OVtKj1bDCAvDNcLdDqdewckRWbBauKGN2KQP4B2xiHQuIe+JOWu+Jb bKqUsncwVVmuIg= X-Received: by 2002:a05:600c:4751:b0:485:3ae3:b394 with SMTP id 5b1f17b1804b1-4853ae3b587mr141608455e9.31.1773156979432; Tue, 10 Mar 2026 08:36:19 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 16:36:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] x86/ioreq: Extend ioreq server to support multiple ioreq pages To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> <20260305130434.635276-2-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260305130434.635276-2-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05.03.2026 14:04, Julian Vetter wrote: > @@ -45,7 +52,8 @@ struct ioreq_server { > /* Lock to serialize toolstack modifications */ > spinlock_t lock; > > - struct ioreq_page ioreq; > + ioreq_t *ioreq; > + gfn_t ioreq_gfn; > struct list_head ioreq_vcpu_list; > struct ioreq_page bufioreq; This change in data arrangement should in principle be independent of the step to supporting multiple pages. Hence it should be possible to separate out. Problem being that just by looking here and at hvm_{,un}map_ioreq_gfn() I can't conclude how you get away without the "page" field that struct ioreq_page had. If you can get away without, it's not quite clear why the field exists in the first place. If it's not needed, dropping it would be yet another separate, prereq change. At which point the remaining pair of fields could continue to be used, i.e. the change above then wouldn't be needed; va could be renamed if need be, and its type changed. And if the "page" field is still needed, then even more so you would imo want to retain the present data layout. In any event, if at all possible a goal imo ought to be to avoid duplication of logic, like what is happening in the two named functions. I.e. preferably the bufio case would continue to be as similar as possible, just known to be single-page. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 15:40:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 15:40:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250232.1547708 (Exim 4.92) (envelope-from ) id 1vzzCS-0000OL-5b; Tue, 10 Mar 2026 15:40:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250232.1547708; Tue, 10 Mar 2026 15: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 ) id 1vzzCS-0000OE-1k; Tue, 10 Mar 2026 15:40:48 +0000 Received: by outflank-mailman (input) for mailman id 1250232; Tue, 10 Mar 2026 15:40:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzCQ-0000O8-Vs for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:40:46 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 807a96ce-1c97-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 16:40:44 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-482f454be5bso131175e9.0 for ; Tue, 10 Mar 2026 08:40: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 5b1f17b1804b1-48541b8d4easm90405155e9.15.2026.03.10.08.40.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 08:40:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 807a96ce-1c97-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773157244; x=1773762044; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=v6oDr0hNtfVv64oxcM72cctFqHNAOLFAB55PJOHsCkY=; b=EB4dcX3EaxT3/0SzGEkWlL68tT+p+58qhcrDxufITWCpFurn/9nwIHqBIWnlZHG7y2 +HkbN4kd47mCoc+Sp3RSXdfJj8/K0kvp+jBi777P4lONfcCsx9SNXbAFnP1UZ+SSjVue 23fnyR4xTeHc3L/vSMFG7jAyr+IPgLvbWfSS5DC6fbEi4xgg+X0wvZVQ+iod7rJzPeUe cNvRdwSsqYHey0AhYobfFA7jdK9JaSlEEBl/yBiDCyGRjdm0i2/+vaVsy1y1h7nRmuPj HrX/oKK1XKMhkJYPsPE1+13lc00NMWIGC611nVhcnZGiYaqZx4bh4konyvoqi7ziBU7U RyZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773157244; x=1773762044; h=content-transfer-encoding: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; bh=v6oDr0hNtfVv64oxcM72cctFqHNAOLFAB55PJOHsCkY=; b=reFgq9ydrXgRNX4JII+KEr1P4X3fk9pEaag731JFL6haf8HfoExKwYpRxoTIsk5Y+o 49meOxt3McPArpMB1PkVJyUVsF/YIm4VNIM48fB9askKEq+67oxNC8Qf2UCiVumDROI/ TT6NteU8YepOsOLEfAcuE6Vn+oTUtT7icmOhg0jowWacGPY+yKfQhQW1l33bSmDFkmQk Mh4jKsz6HXd7O2Dk2hDs/xnaq8ji7PZCfag5DtvU6NmuOdKhw+J9eMsfUBkP5gz93Hrr FzAOIq4NnJuUUM0FvjNvV0osbhK1PDk/Yaz5EXIj3TU9+uQqe4H3wKxkwSpaO4KiB0Rs tgYw== X-Forwarded-Encrypted: i=1; AJvYcCWl5MLN0pF56u0DFavSOqzCtPwfcEWky1sSkddlKaA1sU2Tm2eRSeyKUpqxXJmww4hpM8hW3KeXBEk=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywi9dGaoNz8HrpT2M2Lc/xPW9tcfwpw3rfQTtkv8CHygskcgUYX LEY14h53TNbpX92mzt1JIFxvHquQQulJsdwG6giBAbs7DpKiqrVYiPdcY5uffZxz1A== X-Gm-Gg: ATEYQzy/mVz/JoaDnMcrHI7kyWcLTai2W+b3SE+JkiF6ta67TfLHOfVmC1ggOAxrFUx uV57cVEuVX6dXqJEr51bOje3+nYyt4IOY4HTOfddTYMBAuql/OCRrisVxvEcc4jmPFmy6XhkKjx ZFkUm3opLg6sXOlCw5dJWwD7ILiPhB+N/CtkoBwyu7rmabRMz/oKKAgBZLEH/cBU+uOnTtdyZnQ fHRrxJcdyOwB1DHv4egTURYPh1xW5GL4mtTfd5EXh04baXPlZVHI/dtpt/aZ2lbylFU+AfpxNaW idEri2JwJgeUy+jO+dwbSy8EyqaDDu6Ai6lB6ztL3I5Z2O4hyprpVptyONljASKow6k2jvGlxiK ikZkNctFOr1V0HWPFlwTgiydwgy/9H9YlEm9I/wGAvKcBvjwJcGVEo0NpwdZg9Fmb7E7BSWc+/I dIbXOV+4BT6d0J32/c7/J25xBYIKa6EF+9cFKU/cTA89Pb7sxXw88HvD8/P/18shLdnQD5zKohG YHzrjiZU/G2J+k= X-Received: by 2002:a05:600c:1d04:b0:485:3428:774c with SMTP id 5b1f17b1804b1-485419a286cmr66050045e9.4.1773157244032; Tue, 10 Mar 2026 08:40:44 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 16:40:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] x86: Remove x86 prefixed names from hvm code To: Andrew Cooper Cc: roger.pau@citrix.com, xen-devel@lists.xenproject.org, Kevin Lampis References: <20260304195350.837593-1-kevin.lampis@citrix.com> <20260304195350.837593-4-kevin.lampis@citrix.com> <4a5018a2-9867-432b-9464-874532241316@suse.com> <9eed183c-4157-4432-94ec-a7b7a689fd4a@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <9eed183c-4157-4432-94ec-a7b7a689fd4a@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10.03.2026 16:29, Andrew Cooper wrote: > On 10/03/2026 10:26 am, Jan Beulich wrote: >> On 04.03.2026 20:53, Kevin Lampis wrote: >>> struct cpuinfo_x86 >>> .x86 => .family >>> .x86_vendor => .vendor >>> .x86_model => .model >>> .x86_mask => .stepping >>> >>> No functional change. >>> >>> This work is part of making Xen safe for Intel family 18/19. >>> >>> Signed-off-by: Kevin Lampis >>> --- >>> I couldn't find any information about these Intel family 6 processors: >>> model 0x5d: /* SoFIA 3G Granite/ES2.1 */ >>> model 0x65: /* SoFIA LTE AOSP */ >>> model 0x6e: /* Cougar Mountain */ >>> Should I add them to intel-family.h? >> We should keep that in sync with Linux, I think, so "no" unless you mean to >> first have respective entries added there. >> >> 0x5d is listed in the SDM, so I'd recommend keeping the entries (using IFM() >> directly for the time being). >> >> 0x65 and 0x6e aren't listed in the SDM, so may never really have hit the >> public. Respective cases can perhaps be dropped, but such dropping would >> again likely better be done in a separate change. > > These are the 5G basestations I mentioned during the x86 meeting.  Linux > has declined to take take these models into intel-family.h because > they're not general purpose. > > I suggest we drop them, including 0x5d.  I can do a separate patch. For 0x5d it's not quite clear what the justification would be. Looking at the SDM, those X3-C3000 don't look any more or less general purpose as C2000 and C1000. I guess I'll learn once you've sent the patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 15:56:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 15:56:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250249.1547717 (Exim 4.92) (envelope-from ) id 1vzzRi-0002DN-G6; Tue, 10 Mar 2026 15:56:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250249.1547717; Tue, 10 Mar 2026 15:56:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzRi-0002DF-Cl; Tue, 10 Mar 2026 15:56:34 +0000 Received: by outflank-mailman (input) for mailman id 1250249; Tue, 10 Mar 2026 15:56:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzRh-0002D9-6f for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:56:33 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b0c59f11-1c99-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 16:56:25 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVdlq5Hksz1XLF12 for ; Tue, 10 Mar 2026 15:56:23 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 01e064fb06d54d30b8ea52b39efaa898; Tue, 10 Mar 2026 15:56:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b0c59f11-1c99-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773158183; x=1773428183; bh=FENQz4sBH2k2YM19ydf9S4jWXysIFZNaNow0h7SDNkQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=uNA14AUNQ3+VqnHHYGAwaKuElHbhyjElNZhBUIEb9CGi+92+C2MwQTjjkSHisTyjY YLvHzg24lGOaf+y/XaEn2uXNw6kiD527DKEkDeqkC1FRxJcm7mhRcHz/p6V54REPFy OtGzK8XDyIU8nigAWeWKBCaZFRT6blVA5eI72qHs2tcgauKfbKZbTNmHqpLicKhyhl hhxHZwuXk4rsCyxcvmiQVwvloeCeCXWQWS9fglyVkJuU9Ni1hD4ThlSm8VoP4VSmMH LvgmKOvrx7ZulbwBjqHVOtNQD3gTtBnEbkiBis6xsmK2nvlqXhtVm+U/Uj58XqOSye BvOVNIiLjiRPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773158183; x=1773418683; i=julian.vetter@vates.tech; bh=FENQz4sBH2k2YM19ydf9S4jWXysIFZNaNow0h7SDNkQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=fziHjF5l2OHmmAzZmwY8rjHFeVQshxwT1aNU6wO/48bAt7tavK/DxHYq3wkCzBcD2 wPlmbYkMRDkn55QJnt+3BUlqRnfyIyKX83SUtwVjIypXFi6oVCA5t6Uf0PlGWeoMYf aD7J+7Wm/GozwUKjZKXzNCZW29ymDQ9ulfL1MOPxrfEw19gPPQOT2VkgmAr7JePftS VEL2jjOlmQb+hW4k4TOff7g4P/z/ZB/B+WEYFoZvUWuhPHVsENDL84PPK5LZRUD7nA lqohT4q1UvaUbwON9B4GHZdnbKS74eBwQGzfjyW2rAvThdx53TSMbaAfETvjrZYLy4 4nfTfHHl4zCJw== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH=20v4=202/2]=20x86/ioreq:=20Extend=20ioreq=20server=20to=20support=20multiple=20ioreq=20pages?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773158182407 Message-Id: To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> <20260305130434.635276-2-julian.vetter@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.01e064fb06d54d30b8ea52b39efaa898?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 15:56:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/10/26 16:36, Jan Beulich wrote: > On 05.03.2026 14:04, Julian Vetter wrote: >> @@ -45,7 +52,8 @@ struct ioreq_server { >> /* Lock to serialize toolstack modifications */ >> spinlock_t lock; >> >> - struct ioreq_page ioreq; >> + ioreq_t *ioreq; >> + gfn_t ioreq_gfn; >> struct list_head ioreq_vcpu_list; >> struct ioreq_page bufioreq; > > This change in data arrangement should in principle be independent of the > step to supporting multiple pages. Hence it should be possible to separate > out. Problem being that just by looking here and at hvm_{,un}map_ioreq_gfn() > I can't conclude how you get away without the "page" field that struct > ioreq_page had. If you can get away without, it's not quite clear why the > field exists in the first place. If it's not needed, dropping it would be > yet another separate, prereq change. At which point the remaining pair of > fields could continue to be used, i.e. the change above then wouldn't be > needed; va could be renamed if need be, and its type changed. > Thank you again Jan for your feedback! I don't need the page anymore. When I use vmap(), I don't need to keep track of it, because during teardown, I can recover it via vmap_to_page(). Currently it's necessary because in destroy_ring_for_helper we need the page, to be destroyed. But I see now, on X86 the map_domain_page_global called from prepare_ring_for_helper actually does vmap(&mfn, 1). So the page is also from the vmap range. So for the teardown I assume a vmap_to_page() could be used as well. But I also see there is a special case, if NDEBUG=1, map_domain_page_global short-circuits to mfn_to_virt() for low MFNs (putting the VA in the directmap range) and bypassing vmap. In that case vmap_to_page() would not work. So, this would be really messy. I would rather switch the bufioreq also to an explicitly vmap()'ed page, then we could remove the page pointer and both cases would be aligned again. > And if the "page" field is still needed, then even more so you would imo > want to retain the present data layout. > > In any event, if at all possible a goal imo ought to be to avoid > duplication of logic, like what is happening in the two named functions. > I.e. preferably the bufio case would continue to be as similar as possible, > just known to be single-page. Yes, I agree. Thank you for you insight. I will have a look again how I could align them as much as possible. Julian > > Jan -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:00:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:00:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250261.1547726 (Exim 4.92) (envelope-from ) id 1vzzVp-0004Ms-0y; Tue, 10 Mar 2026 16:00:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250261.1547726; Tue, 10 Mar 2026 16:00:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzVo-0004Ml-UJ; Tue, 10 Mar 2026 16:00:48 +0000 Received: by outflank-mailman (input) for mailman id 1250261; Tue, 10 Mar 2026 16:00:48 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzVn-0004Mf-Vd for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:00:48 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4c636630-1c9a-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:00:45 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso106670615e9.1 for ; Tue, 10 Mar 2026 09:00:45 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4852470c697sm115928445e9.31.2026.03.10.09.00.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 09:00:44 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4c636630-1c9a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773158445; x=1773763245; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=AQV8fZ84ZRFEpZsKly3NgEQ81YLTvarXOg/rJ1/KrGM=; b=kjdNPiDr/0vTz7EHCuB8qc26VNR02x9P5X/Nie+nvYbqzyw/JEQkZs1TBdIup3nSzO cJqpVbq9/q7k8OczsKSoLz7wIB5qMZvUxOKt9SlMIO6kJvXiukVZYT3fHXiNpZtbFAVx PqrsKZ8vlbvOWhZ4uceiXJaSvpcy1BFzRjMot0o/tFXJe2igixED/Tyrn8accQcSWILU jLBM5P1Q/DCDjjI55da9jWlSpHucOfeN2xRJVMqt9NvzLGbUNDJd/fPnBQretcxhmybp BGeTKYpHwHJ5Rv4ORHg+QbZXxBOYwGEJNX0LmK8xHlRa+d9ZbTp07A5Y9p+HJ5iK637C uypw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773158445; x=1773763245; h=content-transfer-encoding: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; bh=AQV8fZ84ZRFEpZsKly3NgEQ81YLTvarXOg/rJ1/KrGM=; b=MyszPuNCq6UXkHO0OFXlHmEFebHO78nywxG7/xJm9fpcwuvNMFmfNguPLFWPwBrgoE qRS9CLYf/zg6iMj4iEQ+KqrIB8Bjby9K9omWY1lg5jNuewwpn6xQKWINY8XlDEVNK8Y/ G2IJYY3NsjIFr4MTyXVYrj7WQ69DKx34zv11+T30j0uos2sLUHfkYR5Ml7OEMSav+A7P qwklf4Ahm6LGT+CJbCZMa4oT+IloqHpTKpc7SeLi9twl++TvfF1vinAOowzPp13P52Js RXhLGFESIAxTFjQBoPo2vdcMRB5oZ0U9Lj0r4SPRoWqhOTS5ytzL7RDP/LyxBRXv19hQ Sgag== X-Forwarded-Encrypted: i=1; AJvYcCW4Av+Uhlask9kuY2O5OQlbLTcPMeIqB+nIcNez2geaH50dS8ZGxcUpC++UqqQbDBZv/6Taqd228j8=@lists.xenproject.org X-Gm-Message-State: AOJu0YzqUNIBKxpYkZ82+zBfqgCPS6IE5QsoJTckLSfP7OYK8YCY2P+K mk9MkklYjKwnKm1gA6sQJj7g5KZ5pqgM9p/FbRuvSeuWNv+39IIbECmB X-Gm-Gg: ATEYQzwAi0Ane0SWwD9Ijs6AVE8eDfsMt0AFBKJJXsSbMFe1XJ6EFBOHRb9cKwV0TQZ PoyQ+D+gmT/kYhq/tVpZr6dkc8K+luuA59OxcVWwLnOx+lGj5cA5KoHvIUkoYUY+knxhPeYXB07 Kuj7m8xMaAak+KmjGTAeteAT37uuNFg3vcQTuSCkYHJSwPWAyQw9MxekaZKAoo1/GWoM16E3eTe zj2BHK56XMjiSnkVPUmb+gBTJ/U5fMqo1e4DSxaWneAw70F2B2gIvRUSg9Md0pQ13poNhht2P+i pQXIvf+/3n1vlC7DZ4BPQNcCc+rmcBCy1726XU99Z2clhDVrGPtChXFSDehIHWsYXWUH2gIZqKS /J9GrNLnahdv3nmgrmk+joy1MrZj97eOJCFBoBwi9tiNH2MAL6W6/XacHKSLTlCw36PQ3eRtz2q dYkxVzryE70rjJ7NokB+lNU7/ex4O6Dtm3wKOJsbinewODARstTSZWJUdb0jLqhah+V+gAuDvc3 dHCEFs= X-Received: by 2002:a05:600c:3b92:b0:485:3b00:f939 with SMTP id 5b1f17b1804b1-4853b00fa43mr148729915e9.8.1773158444677; Tue, 10 Mar 2026 09:00:44 -0700 (PDT) Message-ID: <5d15bc9b-ead9-4690-b5cd-3b63d83537b6@gmail.com> Date: Tue, 10 Mar 2026 17:00:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Jan Beulich Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/10/26 9:11 AM, Jan Beulich wrote: > On 06.03.2026 17:33, Oleksii Kurochko wrote: >> Some hypervisor CSRs expose optional functionality and may not implement >> all architectural bits. Writing unsupported bits can either be ignored >> or raise an exception depending on the platform. >> >> Detect the set of writable bits for selected hypervisor CSRs at boot and >> store the resulting masks for later use. This allows safely programming >> these CSRs during vCPU context switching and avoids relying on hardcoded >> architectural assumptions. >> >> Use csr_read()&csr_write() instead of csr_swap()+all ones mask as some >> CSR registers have WPRI fields which should be preserved during write >> operation. >> >> Also, ro_one struct is introduced to cover the cases when a bit in CSR >> register (at the momemnt, it is only hstateen0) may be r/o-one to have >> hypervisor view of register seen by guest correct. >> >> Masks are calculated at the moment only for hedeleg, henvcfg, hideleg, >> hstateen0 registers as only them are going to be used in the follow up >> patch. >> >> If the Smstateen extension is not implemented, hstateen0 cannot be read >> because the register is considered non-existent. Instructions that attempt >> to access a CSR that is not implemented or not visible in the current mode >> are reserved and will raise an illegal-instruction exception. >> >> Signed-off-by: Oleksii Kurochko >> --- a/xen/arch/riscv/domain.c >> +++ b/xen/arch/riscv/domain.c >> @@ -2,9 +2,66 @@ >> >> #include >> #include >> +#include >> #include >> #include >> >> +#include >> +#include >> + >> +struct csr_masks { >> + register_t hedeleg; >> + register_t henvcfg; >> + register_t hideleg; >> + register_t hstateen0; >> + >> + struct { >> + register_t hstateen0; >> + } ro_one; >> +}; >> + >> +static struct csr_masks __ro_after_init csr_masks; >> + >> +#define HEDELEG_AVAIL_MASK ULONG_MAX >> +#define HIDELEG_AVAIL_MASK ULONG_MAX >> +#define HENVCFG_AVAIL_MASK _UL(0xE0000003000000FF) >> +#define HSTATEEN0_AVAIL_MASK _UL(0xDE00000000000007) > It's not quite clear to me what AVAIL in here is to signal. It signal that these bits are potentially available for s/w to be set. If you want to suggest the better naming and can change that in the follow-up patch. > It's also not > quite clear to me why you would use _UL() in #define-s sitting in a C file > (and hence not possibly being used in assembly code; even for asm() I'd > expect constants to be properly passed in as C operands). I thought it is always be good to use _UL() for such type of constants as ULONG_MAX also uses UL, but not in form of _UL() macros. If it would be better to drop, I can do that in follow-up patch. > >> +void __init init_csr_masks(void) >> +{ >> + /* >> + * The mask specifies the bits that may be safely modified without >> + * causing side effects. >> + * >> + * For example, registers such as henvcfg or hstateen0 contain WPRI >> + * fields that must be preserved. Any write to the full register must >> + * therefore retain the original values of those fields. >> + */ >> +#define INIT_CSR_MASK(csr, field, mask) do { \ >> + register_t old = csr_read_set(CSR_##csr, mask); \ >> + csr_masks.field = csr_swap(CSR_##csr, old); \ >> + } while (0) >> + >> +#define INIT_RO_ONE_MASK(csr, field, mask) do { \ >> + register_t old = csr_read_clear(CSR_HSTATEEN0, mask); \ >> + csr_masks.ro_one.field = csr_swap(CSR_##csr, old) & mask; \ >> + } while (0) >> + >> + INIT_CSR_MASK(HEDELEG, hedeleg, HEDELEG_AVAIL_MASK); >> + INIT_CSR_MASK(HIDELEG, hideleg, HIDELEG_AVAIL_MASK); >> + >> + INIT_CSR_MASK(HENVCFG, henvcfg, HENVCFG_AVAIL_MASK); >> + >> + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) >> + { >> + INIT_CSR_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); >> + INIT_RO_ONE_MASK(HSTATEEN0, hstateen0, HSTATEEN0_AVAIL_MASK); >> + } > The 3rd macro parameters are now redundant. At the example of INIT_CSR_MASK(), > you could now have > > #define INIT_CSR_MASK(csr, field) do { \ > register_t old = csr_read_set(CSR_ ## csr, csr ## _AVAIL_MASK); \ > csr_masks.field = csr_swap(CSR_ ## csr, old); \ > } while (0) > > This would reduce the risk of incomplete editing after copy-and-paste, or > other typo-ing. > > Note also that ## being a binary operator, ./CODING_STYLE wants us to put > blanks around it just like for non-pre-processor binary operators. I'll > try to remember to make that adjustment when committing. Good point. Thanks a lot! ~ Oleksii From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:04:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:04:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250258.1547734 (Exim 4.92) (envelope-from ) id 1vzzZE-0004sU-F2; Tue, 10 Mar 2026 16:04:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250258.1547734; Tue, 10 Mar 2026 16:04:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzZE-0004sN-CR; Tue, 10 Mar 2026 16:04:20 +0000 Received: by outflank-mailman (input) for mailman id 1250258; Tue, 10 Mar 2026 15:59:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzU8-0002mp-Hq for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 15:59:04 +0000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by se1-gles-sth1.inumbo.com (Halon) with ESMTP id 0e27e170-1c9a-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 16:59:01 +0100 (CET) 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 74A8B16A3; Tue, 10 Mar 2026 08:58:54 -0700 (PDT) Received: from [192.168.20.93] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 384493F7BD; Tue, 10 Mar 2026 08:58:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0e27e170-1c9a-11f1-b164-2bf370ae4941 Message-ID: <657142d1-1632-4a3e-8800-ee1dd5763d78@arm.com> Date: Tue, 10 Mar 2026 10:58:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform To: Chengwen Feng , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" Cc: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org, Wathsala Vithanage References: <20260310032049.25387-1-fengchengwen@huawei.com> <20260310032049.25387-3-fengchengwen@huawei.com> Content-Language: en-US From: Jeremy Linton In-Reply-To: <20260310032049.25387-3-fengchengwen@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, +Wathsala who has been looking at TPH too. On 3/9/26 10:20 PM, Chengwen Feng wrote: > pcie_tph_get_cpu_st() is broken on ARM64: > 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. > cpu_uid should be the ACPI Processor UID [1]. > 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via > cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, > generated and managed by kernel (e.g., [0,255] for a system with 256 > logical CPU cores). > 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the > MADT table, and this UID may not match the kernel's logical CPU ID. > When this occurs, the mismatch results in the wrong CPU steer-tag. > 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID > so the mismatch is not seen. > > Resolution: > 1. Implement acpi_get_cpu_acpi_id() for x86, which replaces > cpu_acpi_id(). All ACPI platforms now have an implementation. > 2. Use acpi_get_cpu_acpi_id() in pcie_tph_get_cpu_st() to translate from > logical CPU ID to ACPI Processor UID needed for the DSM call. > 3. Rename pcie_tpu_get_cpu_st() parameter from cpu_uid to cpu to > reflect that it is a logical CPU_ID. > > [1] According to ECN_TPH-ST_Revision_20200924 > (https://members.pcisig.com/wg/PCI-SIG/document/15470), the input > is defined as: "If the target is a processor, then this field > represents the ACPI Processor UID of the processor as specified in > the MADT. If the target is a processor container, then this field > represents the ACPI Processor UID of the processor container as > specified in the PPTT." The bit about "processor containers" is not supported by linux yet, and is potentially a problem worth considering. The original rename comments from the previous patch versions are on point, but since they have grown large, i'm going to suggest the x86 rename/shuffle here is also in its own patch seperate from the TPH specific changes like the arm ones now are. Thanks for looking after this. > > Fixes: d2e8a34876ce ("PCI/TPH: Add Steering Tag support") > Cc: stable@vger.kernel.org > Signed-off-by: Chengwen Feng > Reviewed-by: Jonathan Cameron > --- > Documentation/PCI/tph.rst | 4 ++-- > arch/x86/include/asm/acpi.h | 2 ++ > arch/x86/include/asm/cpu.h | 1 - > arch/x86/include/asm/smp.h | 1 - > arch/x86/kernel/cpu/common.c | 12 ++++++++++++ > arch/x86/xen/enlighten_hvm.c | 4 ++-- > drivers/pci/tph.c | 11 ++++++----- > include/linux/pci-tph.h | 4 ++-- > 8 files changed, 26 insertions(+), 13 deletions(-) > > diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst > index e8993be64fd6..b6cf22b9bd90 100644 > --- a/Documentation/PCI/tph.rst > +++ b/Documentation/PCI/tph.rst > @@ -79,10 +79,10 @@ To retrieve a Steering Tag for a target memory associated with a specific > CPU, use the following function:: > > int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type, > - unsigned int cpu_uid, u16 *tag); > + unsigned int cpu, u16 *tag); > > The `type` argument is used to specify the memory type, either volatile > -or persistent, of the target memory. The `cpu_uid` argument specifies the > +or persistent, of the target memory. The `cpu` argument specifies the > CPU where the memory is associated to. > > After the ST value is retrieved, the device driver can use the following > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h > index a03aa6f999d1..b968369715c1 100644 > --- a/arch/x86/include/asm/acpi.h > +++ b/arch/x86/include/asm/acpi.h > @@ -157,6 +157,8 @@ static inline bool acpi_has_cpu_in_madt(void) > return !!acpi_lapic; > } > > +u32 acpi_get_cpu_acpi_id(unsigned int cpu); > + > #define ACPI_HAVE_ARCH_SET_ROOT_POINTER > static __always_inline void acpi_arch_set_root_pointer(u64 addr) > { > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h > index ad235dda1ded..57a0786dfd75 100644 > --- a/arch/x86/include/asm/cpu.h > +++ b/arch/x86/include/asm/cpu.h > @@ -11,7 +11,6 @@ > > #ifndef CONFIG_SMP > #define cpu_physical_id(cpu) boot_cpu_physical_apicid > -#define cpu_acpi_id(cpu) 0 > #endif /* CONFIG_SMP */ > > #ifdef CONFIG_HOTPLUG_CPU > diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h > index 84951572ab81..05d1d479b4cf 100644 > --- a/arch/x86/include/asm/smp.h > +++ b/arch/x86/include/asm/smp.h > @@ -130,7 +130,6 @@ __visible void smp_call_function_interrupt(struct pt_regs *regs); > __visible void smp_call_function_single_interrupt(struct pt_regs *r); > > #define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu) > -#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu) > > /* > * This function is needed by all SMP systems. It must _always_ be valid > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 1c3261cae40c..93f4f3283c81 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -29,6 +29,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -57,6 +58,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2643,3 +2645,13 @@ void __init arch_cpu_finalize_init(void) > */ > mem_encrypt_init(); > } > + > +u32 acpi_get_cpu_acpi_id(unsigned int cpu) > +{ > +#ifndef CONFIG_SMP > + return 0; > +#else > + return per_cpu(x86_cpu_to_acpiid, cpu); > +#endif > +} > +EXPORT_SYMBOL_GPL(acpi_get_cpu_acpi_id); > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c > index fe57ff85d004..0a5cde7865b2 100644 > --- a/arch/x86/xen/enlighten_hvm.c > +++ b/arch/x86/xen/enlighten_hvm.c > @@ -161,8 +161,8 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu) > */ > xen_uninit_lock_cpu(cpu); > > - if (cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) > - per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu); > + if (acpi_get_cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) > + per_cpu(xen_vcpu_id, cpu) = acpi_get_cpu_acpi_id(cpu); > else > per_cpu(xen_vcpu_id, cpu) = cpu; > xen_vcpu_setup(cpu); > diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c > index ca4f97be7538..c1bd60637b5a 100644 > --- a/drivers/pci/tph.c > +++ b/drivers/pci/tph.c > @@ -236,18 +236,19 @@ static int write_tag_to_st_table(struct pci_dev *pdev, int index, u16 tag) > * with a specific CPU > * @pdev: PCI device > * @mem_type: target memory type (volatile or persistent RAM) > - * @cpu_uid: associated CPU id > + * @cpu: associated CPU id > * @tag: Steering Tag to be returned > * > * Return the Steering Tag for a target memory that is associated with a > - * specific CPU as indicated by cpu_uid. > + * specific CPU as indicated by cpu. > * > * Return: 0 if success, otherwise negative value (-errno) > */ > int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, > - unsigned int cpu_uid, u16 *tag) > + unsigned int cpu, u16 *tag) > { > #ifdef CONFIG_ACPI > + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); > struct pci_dev *rp; > acpi_handle rp_acpi_handle; > union st_info info; > @@ -265,9 +266,9 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, > > *tag = tph_extract_tag(mem_type, pdev->tph_req_type, &info); > > - pci_dbg(pdev, "get steering tag: mem_type=%s, cpu_uid=%d, tag=%#04x\n", > + pci_dbg(pdev, "get steering tag: mem_type=%s, cpu=%d, tag=%#04x\n", > (mem_type == TPH_MEM_TYPE_VM) ? "volatile" : "persistent", > - cpu_uid, *tag); > + cpu, *tag); > > return 0; > #else > diff --git a/include/linux/pci-tph.h b/include/linux/pci-tph.h > index ba28140ce670..be68cd17f2f8 100644 > --- a/include/linux/pci-tph.h > +++ b/include/linux/pci-tph.h > @@ -25,7 +25,7 @@ int pcie_tph_set_st_entry(struct pci_dev *pdev, > unsigned int index, u16 tag); > int pcie_tph_get_cpu_st(struct pci_dev *dev, > enum tph_mem_type mem_type, > - unsigned int cpu_uid, u16 *tag); > + unsigned int cpu, u16 *tag); > void pcie_disable_tph(struct pci_dev *pdev); > int pcie_enable_tph(struct pci_dev *pdev, int mode); > u16 pcie_tph_get_st_table_size(struct pci_dev *pdev); > @@ -36,7 +36,7 @@ static inline int pcie_tph_set_st_entry(struct pci_dev *pdev, > { return -EINVAL; } > static inline int pcie_tph_get_cpu_st(struct pci_dev *dev, > enum tph_mem_type mem_type, > - unsigned int cpu_uid, u16 *tag) > + unsigned int cpu, u16 *tag) > { return -EINVAL; } > static inline void pcie_disable_tph(struct pci_dev *pdev) { } > static inline int pcie_enable_tph(struct pci_dev *pdev, int mode) From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:10:16 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:10:16 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250280.1547744 (Exim 4.92) (envelope-from ) id 1vzzeu-0006XN-4N; Tue, 10 Mar 2026 16:10:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250280.1547744; Tue, 10 Mar 2026 16:10:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzeu-0006XG-1f; Tue, 10 Mar 2026 16:10:12 +0000 Received: by outflank-mailman (input) for mailman id 1250280; Tue, 10 Mar 2026 16:10:10 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzes-0006XA-DR for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:10:10 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 96812c5b-1c9b-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:09:59 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4852f8ac7e9so42037655e9.1 for ; Tue, 10 Mar 2026 09:09: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-485244b6e9esm217818755e9.5.2026.03.10.09.09.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 09:09:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 96812c5b-1c9b-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773158999; x=1773763799; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=ZKb99p8Z8dwMpOwrxkhYrxmhrN8VUsSCJFX1+xevsaU=; b=g1R21WKvdxVpPRmrTY+O28PIvaa/uNZCVJ7JIpkykS4dn+pDw/nWgdmt9gLkGJPYRT 0e49uOR8CG5tIbMCeVFwxo0wnx6WxYlH3vjeZguVqz4TQFEdMEJODaqHsYZkxQ7aIKaa 1IjSi3G/4XW19WoBSiYx3eH323z4LEJFKymxfuF4qsOAddEnS1X4eLmJrnEg3p/X8YLK UyNhz+1H8viNkklV7oq3TSols1NHbJQ9kvcbLNWR0W0411A5VHKS0b0sRsT1lqfIkbVd XQso/EJt6rfHWHqFMa2KL2H1MmkmWBk0qs6T6f+Vm73vt0MAdM7ymB4B1frR0n8wvnRx as6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773158999; x=1773763799; h=content-transfer-encoding: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; bh=ZKb99p8Z8dwMpOwrxkhYrxmhrN8VUsSCJFX1+xevsaU=; b=YS7Py1qAXCDaglKQLtldiRF9q+EgcCjTYVf5KAxjQPu/tnqpktKOHq/ScvRk724Ra0 935H4kVec4UWT5tXOnBPt9JR/vL3VrXTDoCol20eigGH4aQmLtUjCEs5XmRFHCDvlip+ 9yDS9Rfr7pnl0kMQFAULkHEfgzj66InQJOrF8WycV0WCaj2hc2SWEAicoFt0PSK5wX7H pJzQBFS0MdwROkH3JJhnhqYOi3KDRjVtb8Z8S5ygvIGTIpbgaJONRzpQLNSL6N0Qmto9 CXZs1Eh1eEjK+6IFYBabj+ljjxMrtdbJ/KneqPA7z3MSkofVUU+46aAftKJ7aC29cVTm 6q7w== X-Forwarded-Encrypted: i=1; AJvYcCVv7gNbls+tU08RKSSm7SSBmYFGHyrP5bRHvIp0vPjgMIsI6r4T/LwCREn/SHJc0GlCJdvssjlBRIY=@lists.xenproject.org X-Gm-Message-State: AOJu0YxSQXEALnotKJL0AX+F5VjmbSiVlUkzC+e1ntSmtjeFBBUglI4q s/sZgzgLT7ATNfeTBrT8PlpH/7Fe3UsEdG8c+SsIKwISnfclgTSdrK4W6TkH5lfJYQ== X-Gm-Gg: ATEYQzwPnn6z/tn722zcZ1eLmU7Sa9EcL4eTOaBoT3wdekJ7a6ldmGHb8sdE/KBp2nH vTeEtXuyEuQhEoLJkZVDQAW/+SEAMM02x2zR9dG9iNGVVX+VGNVVQfQEYsys7F9J5Jz3G68zF0A jI0h7M0k5xIBA3NCKSTv2mLWpSMsiWhxvVhaWSpIvhBeErmr5C16fiFG6txTWG4ddZ/T2j4ix9n tjg33AOPOKyTiHjW83E73pAzYfe6vp1SLq2/uEog8hBzQ0iJKCyNDDNQBcn9leNkCAv96OkslgN /X6bocoNpPEnrz72ldt4Vfby+J/Zfd2AHSyb+gr1D+xD965UX5UCx7W5sOMpeIMq1UpSqHPrwOJ IxxGDX/RwnKgZStNKiYdmY3r2wF4PyVwpcsfE2NNRd8S17ZCKsfS4/aUoWhHpOYCds27jdL2RdL JjZUfLxc/3d+wZedAmoFmxfLUyZlYEX3at34Qk/YH8Y9jr/KQQONXlCN8JZBLyol69LOHlVNMKm FIZszMknOO/R4M= X-Received: by 2002:a05:600c:c8f:b0:483:2c98:4368 with SMTP id 5b1f17b1804b1-4852695aec4mr261574495e9.18.1773158998968; Tue, 10 Mar 2026 09:09:58 -0700 (PDT) Message-ID: <5724bdb3-bec5-4159-a4f4-9bdad39acd7b@suse.com> Date: Tue, 10 Mar 2026 17:09:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] x86/ioreq: Extend ioreq server to support multiple ioreq pages To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> <20260305130434.635276-2-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.03.2026 16:56, Julian Vetter wrote: > On 3/10/26 16:36, Jan Beulich wrote: >> On 05.03.2026 14:04, Julian Vetter wrote: >>> @@ -45,7 +52,8 @@ struct ioreq_server { >>> /* Lock to serialize toolstack modifications */ >>> spinlock_t lock; >>> >>> - struct ioreq_page ioreq; >>> + ioreq_t *ioreq; >>> + gfn_t ioreq_gfn; >>> struct list_head ioreq_vcpu_list; >>> struct ioreq_page bufioreq; >> >> This change in data arrangement should in principle be independent of the >> step to supporting multiple pages. Hence it should be possible to separate >> out. Problem being that just by looking here and at hvm_{,un}map_ioreq_gfn() >> I can't conclude how you get away without the "page" field that struct >> ioreq_page had. If you can get away without, it's not quite clear why the >> field exists in the first place. If it's not needed, dropping it would be >> yet another separate, prereq change. At which point the remaining pair of >> fields could continue to be used, i.e. the change above then wouldn't be >> needed; va could be renamed if need be, and its type changed. > > Thank you again Jan for your feedback! I don't need the page anymore. > When I use vmap(), I don't need to keep track of it, because during > teardown, I can recover it via vmap_to_page(). Currently it's necessary > because in destroy_ring_for_helper we need the page, to be destroyed. > But I see now, on X86 the map_domain_page_global called from > prepare_ring_for_helper actually does vmap(&mfn, 1). So the page is also > from the vmap range. So for the teardown I assume a vmap_to_page() could > be used as well. But I also see there is a special case, if NDEBUG=1, > map_domain_page_global short-circuits to mfn_to_virt() for low MFNs > (putting the VA in the directmap range) and bypassing vmap. In that case > > vmap_to_page() would not work. So, this would be really messy. I would > rather switch the bufioreq also to an explicitly vmap()'ed page, then we > could remove the page pointer and both cases would be aligned again. That's an option. Yet are you aware of domain_page_map_to_mfn()? Perhaps that's what you want to switch to using in the patch removing the "page" field. To then, conditionally or uniformly, switch to vmap_to_{mfn,page}() when doing the multi-page work in the subsequent patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:14:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:14:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250289.1547753 (Exim 4.92) (envelope-from ) id 1vzzjM-00075M-Ki; Tue, 10 Mar 2026 16:14:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250289.1547753; Tue, 10 Mar 2026 16:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzjM-00075F-Hc; Tue, 10 Mar 2026 16:14:48 +0000 Received: by outflank-mailman (input) for mailman id 1250289; Tue, 10 Mar 2026 16:14:47 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vzzjL-000759-8J for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:14:47 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d026b3d-1c9c-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 17:14:39 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439ac15f35fso9525843f8f.0 for ; Tue, 10 Mar 2026 09:14: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 ffacd0b85a97d-439dada9116sm34495246f8f.14.2026.03.10.09.14.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 09:14:38 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d026b3d-1c9c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773159278; x=1773764078; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=xtI+z3R8YsFXQL9uSgC7sP0cd+QLnw4JPhISRguRJyc=; b=Nlhnb8TtX2FboJx/TTAa09bLRhnTjSOo7kSqxYf2HF7asJT+V/OEeTl2DueTVCl/Zt iMloZ8LdswePQYk9K43WyHXcNA9P/j8CmqjhokGTsHMqLnRLqCUPf1Q4HmO23D/vY37B amX9ilVNlhMj7OTeoFhXoEnY1j4M/bYimbx6vAPRW8AsjdY72n9F3lMUI8RS3s4iCNE2 sn1OCR3OGtYpOy9AGqNYEBzJEAVC6AZrr9HGvd8GEYr1AT1G6lAU+Ym69nfIQuVSbA3Y +j+HiIQS6StVWEI07XSiZ+Tf6+TYqygYvcxwQ7DCHmMaFYvLCwAdasmt/CkILeK/GLak SFzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773159278; x=1773764078; h=content-transfer-encoding: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; bh=xtI+z3R8YsFXQL9uSgC7sP0cd+QLnw4JPhISRguRJyc=; b=lbUmWjwz54SsjW4BfmG84efQo7cahM9O5KAzSfhHdky6jxmUrMe1B78SKpIVXhHMgT bP6xChsgh3YArhQmWf6Yk6oFBNVzyq68+BrtJ+LshBFfhRCXs96VKXGU+8PYux521RjM +uz9K/eyUPVKd4QWLFHkRSzpPXLSp8xZTxWjBwxit+74OBh7fCYnf4F9lt9MUua4t9fN DKNM0upF2dqk2Y3aOWVDtCwmPyjJ3QeM5im4gd8d7CYA1cOzgopV2FbIjrNdhIvt8xzm ZdUHWLiDIU8d78rJU/5FUCAMasQMxgLexLGbb3sdLT+WUlGQ0D6T83bHhxgENLTg+FqL QLpA== X-Forwarded-Encrypted: i=1; AJvYcCU5fcieNf3rBIEEcwbP3SB0GL9s/yA7Sb0sSwXCkHlYMK0oXIZIJ830js7yEqQLxHpROgSdhyxIQ70=@lists.xenproject.org X-Gm-Message-State: AOJu0Yx7tq5Sut9qqDRObhlEpxa200qSWubLS2c1Dqv6vSoLzN3wiR+z xhq6IJXtRyYk2k2CXd5hZpl4PK7juRUJf0VveCPx9RKCtpJaddjz7IRU7bJaIXPOHg== X-Gm-Gg: ATEYQzw0inbWydp8/Wj4qx9FbKp6MNMXQAo7N0SKy/oC81WudTMh1SS0S3LVMh0bQE2 wqvT67h+YUjITJFsvLhD5bW7+YXT8IKiYjmKJx3PAfzOl1UykzxUcdrwe9ZUIphdjXQXMwKaM5m 6Ul5Fz9HKD5WINHTEjOFtS7aRHtNV7c+oHPQI/Zx0YquGmC0U5ou40mmrl3808xTH0HCRTE4b6V /zfNgwh4rODQHVv2pF4Y/ZFJEO33LMRP0whmqkl68BFMf/54V5RqWFL/vsy4aWQ4++atNcEZlV1 zt5TWGrPMKv0wngRubymRfh4wK4lPzJGG/kcKwg0AHZvcYSWtsedzKGyEXqqITwXZ+Ry7jXI5Oh O7gJWqnHFkNm/XE7aWTlNsLGPyJjpmqpvzKOODmOPU+OFGcubVl3uJePDHxFzUEijnPLzuj//OK aE1yJz4ZX2NVw5I5qDWsiasjdIHmz2pEnutyiFXbMC1MnuvoZFTiL0hnNFfBItRV5njdh5YkkY+ r0j9S+zg+KE+YQ= X-Received: by 2002:a05:6000:2888:b0:439:afea:aff2 with SMTP id ffacd0b85a97d-439da337f97mr27539193f8f.23.1773159278406; Tue, 10 Mar 2026 09:14:38 -0700 (PDT) Message-ID: <45b66d43-07ad-4acc-bb0a-f311fef0261d@suse.com> Date: Tue, 10 Mar 2026 17:14:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 01/14] xen/riscv: detect and store supported hypervisor CSR bits at boot To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <3201951150104f17593e16c7ba00ada51ac1e10f.1772814110.git.oleksii.kurochko@gmail.com> <2de7f459-00b3-4968-aaa2-9067cb0c4aa4@suse.com> <5d15bc9b-ead9-4690-b5cd-3b63d83537b6@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <5d15bc9b-ead9-4690-b5cd-3b63d83537b6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.03.2026 17:00, Oleksii Kurochko wrote: > On 3/10/26 9:11 AM, Jan Beulich wrote: >> On 06.03.2026 17:33, Oleksii Kurochko wrote: >>> --- a/xen/arch/riscv/domain.c >>> +++ b/xen/arch/riscv/domain.c >>> @@ -2,9 +2,66 @@ >>> >>> #include >>> #include >>> +#include >>> #include >>> #include >>> >>> +#include >>> +#include >>> + >>> +struct csr_masks { >>> + register_t hedeleg; >>> + register_t henvcfg; >>> + register_t hideleg; >>> + register_t hstateen0; >>> + >>> + struct { >>> + register_t hstateen0; >>> + } ro_one; >>> +}; >>> + >>> +static struct csr_masks __ro_after_init csr_masks; >>> + >>> +#define HEDELEG_AVAIL_MASK ULONG_MAX >>> +#define HIDELEG_AVAIL_MASK ULONG_MAX >>> +#define HENVCFG_AVAIL_MASK _UL(0xE0000003000000FF) >>> +#define HSTATEEN0_AVAIL_MASK _UL(0xDE00000000000007) >> It's not quite clear to me what AVAIL in here is to signal. > > It signal that these bits are potentially available for s/w to be set. > If you want to suggest the better naming and can change that in the > follow-up patch. I'd either omit the infix altogether ("avail" after all often means "available for software use"), or use "valid" or (less desirable) "defined". >> It's also not >> quite clear to me why you would use _UL() in #define-s sitting in a C file >> (and hence not possibly being used in assembly code; even for asm() I'd >> expect constants to be properly passed in as C operands). > > I thought it is always be good to use _UL() for such type of constants as > ULONG_MAX also uses UL, but not in form of _UL() macros. If it would be > better to drop, I can do that in follow-up patch. The suffixes want to be there, at the very least for Misra's sake. But you can just write 0xabcdUL, there's no need to involve a macro there. That's only needed when the appending of the suffix needs to be conditional upon is being C or assembler code that includes a header. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250305.1547779 (Exim 4.92) (envelope-from ) id 1w00CZ-0002ss-5F; Tue, 10 Mar 2026 16:44:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250305.1547779; Tue, 10 Mar 2026 16:44:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00CY-0002ro-W0; Tue, 10 Mar 2026 16:44:58 +0000 Received: by outflank-mailman (input) for mailman id 1250305; Tue, 10 Mar 2026 16:44:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00CY-0002px-13 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:44:58 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 77b54216-1ca0-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 17:44:56 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqp5vQqz1XLF4k for ; Tue, 10 Mar 2026 16:44:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c66df3a63a2745999a983d58575806a8; Tue, 10 Mar 2026 16:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 77b54216-1ca0-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161094; x=1773431094; bh=CfuPpakjv5VmFwTUwLXalLDXQ40VB5TUP6pk/iH94Mc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=NlfPTojucJusZHKLi6w6bLI+26+pMCkFf+LmI0t2hsSNyXRwQYYcNrytcU7y2r/BN ySRFDfvRjMQzfQt17OvPPexYh5YTv+tteWSo4yi/h6MGAlF3L3YAJpuZHsM7NoWjpT /KgajU85j8Tgnunm+WWKMH9LS3lamAMH8xBAIIGygKPVBxqk6LGz23Jv1nk7P7miFk 71B8bkQdWDk/oig5YftVIkBYo825SjLTk4wr7QLZ4clBBRPswWd/otT/mSM5QGU19L bCJVkILZQjxKYyUnG73iQnIjVbtGilhJg3lQ3OfnmYXATdeDcbPzUy3wF47ho+M/S1 jhg48+CASmoJw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161094; x=1773421594; i=teddy.astie@vates.tech; bh=CfuPpakjv5VmFwTUwLXalLDXQ40VB5TUP6pk/iH94Mc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=jUWiZix4iMfwXTgNinrqPvUPRLbR1PWDcCQvOlThYYof7lF/1IwZ6I1prTfX0f1OJ LizvwpgYDVklA38XGcfBa4Nn9SKpDfvNuDsxe7HVev6C7YGu4KUiEjUZFHCVSezeOu WumJf4gqoTwRa+On5JkFc8LNWbxxI9BcWTt6JTUK6dYIrPMiCneQACqdOx7uTgw31e Pt1doXVYbAHEQnSISOiAfRh1RqXoFJJTOEr1VsjJS8YuHydPbU0HxaHY+gWU+j6R8X HGaCOtGGMskaJSKPknGFwg967aQ00z2Tz+7bH+kJb6ogqaX9tFOBy9sIvVbCBQfMFz UmL49GlFYiAtg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=203/6]=20x86:=20Define=20some=20Intel=20vPMU=20leafs?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161093903 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <83a573dcb365761c0f089325365090b6f963fb03.1773160025.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c66df3a63a2745999a983d58575806a8?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Signed-off-by: Teddy Astie --- xen/arch/x86/cpu/vpmu_intel.c | 4 ++-- xen/arch/x86/domain.c | 2 +- xen/include/xen/lib/x86/cpu-policy.h | 10 +++++++++- 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 1e3b06ef8e..f43faf9567 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -818,8 +818,8 @@ static int cf_check core2_vpmu_initialise(struct vcpu *v) u64 msr_content; static bool ds_warned; - if ( v->domain->arch.cpuid->basic.pmu_version <= 1 || - v->domain->arch.cpuid->basic.pmu_version >= 6 ) + if ( v->domain->arch.cpuid->basic.pmu.version <= 1 || + v->domain->arch.cpuid->basic.pmu.version >= 6 ) return -EINVAL; if ( (arch_pmc_cnt + fixed_pmc_cnt) == 0 ) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index e658c2d647..5762b38fce 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -458,7 +458,7 @@ void domain_cpu_policy_changed(struct domain *d) /* If PMU version is zero then the guest doesn't have VPMU */ if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && - p->basic.pmu_version == 0 ) + p->basic.pmu.version == 0 ) vpmu_destroy(v); } } diff --git a/xen/include/xen/lib/x86/cpu-policy.h b/xen/include/xen/lib/x86/cpu-policy.h index d29e380359..9161e2ad8d 100644 --- a/xen/include/xen/lib/x86/cpu-policy.h +++ b/xen/include/xen/lib/x86/cpu-policy.h @@ -162,7 +162,15 @@ struct cpu_policy uint64_t :64, :64; /* Leaf 0x9 - DCA */ /* Leaf 0xa - Intel PMU. */ - uint8_t pmu_version, _pmu[15]; + struct { + uint8_t /* a */ version, num_gp_ctrs, gp_ctr_width, + event_enum_length; + uint32_t /* b */:32; + uint32_t /* c */ fixed_ctr_mask; + uint32_t /* d */ num_fixed_ctr:5, fixed_ctr_width:8, :1, + anythread_depreciation:1, slots_per_cyc:4, + :13; + } pmu; uint64_t :64, :64; /* Leaf 0xb - Topology. */ uint64_t :64, :64; /* Leaf 0xc - rsvd */ -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250310.1547824 (Exim 4.92) (envelope-from ) id 1w00Cd-0003zj-Id; Tue, 10 Mar 2026 16:45:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250310.1547824; Tue, 10 Mar 2026 16:45:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cd-0003yf-Cu; Tue, 10 Mar 2026 16:45:03 +0000 Received: by outflank-mailman (input) for mailman id 1250310; Tue, 10 Mar 2026 16:45:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cc-000397-Na for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:45:02 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7a49f90b-1ca0-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:44:59 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqq1hYkz1XLF4d for ; Tue, 10 Mar 2026 16:44:55 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id dba5e090b02c4a199bdbd3059630d207; Tue, 10 Mar 2026 16:44:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a49f90b-1ca0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161095; x=1773431095; bh=3Wd0xKWdvd2LCo+Aysi0R4yuf0yNnldMdvsEMKvsrOI=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=1qUf6IvwcYn+YBCjZb+CiiNsxrDid8C1mWUh+mEZGnICezlZpOT7U/T9aRF0wgG4q 5Fbk9vj5CqsaZ4qzIXjSl6e9kZR+784xJX8oc/FYq6+eWQJa+adD5554wHgi8X7RSK Lg8VqpJZiSimRVxNVBNLldCbQ4c8sPXM74tdFzBJYewAtotjHoAnTEFI93Kxw2Ftgg InICSKP3V3hFKS5Lw1hmXujD/td+RELRLcLBmT+0g6FO7F/qrGfWqvVVB2H3Lu94fy asS2zRfo3zsrgPXs4QXRcqO2a/pTZlXI9swU7oEIBkesgY42ektu4QwC0maQFBu7Gd UfHGxYC61tABw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161095; x=1773421595; i=teddy.astie@vates.tech; bh=3Wd0xKWdvd2LCo+Aysi0R4yuf0yNnldMdvsEMKvsrOI=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=BKmy+efIBRyDb9esunrpL58xXMqJt6/vCoQXH79LQX5aUzXatNm0caT83CFzIdg+b EkRH/OScUju4yfFdjJjCPULwuycRypUJ+VM13L+w+si2YfsNM1LmN5XrLxuMZT8b3C Lj4MXkmcAPMsPpIi6V3hx3fmUd1O5Rt+34k2xZHhWMizqjcbGp2viDmmAktTskedBO uqCeu1FDYMQDfKYHkJpbc/eB4jRiK0WhTbD2sTC6eiZHKASFm7P2qQZeuj8w3dYoJs tG9XYpymA7Y+WigUf1CM4NFV8voEVKjKalg9maltqVWgzq7NDp7fwTK7xfM21Z8mOd f4JComHw8BrIw== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=205/6]=20x86/vpmu:=20Limit=20to=20using=20supported=20general/fixed=20counters?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161094391 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <854c5fe569f1a2f1f60e0768ee3d9a921ad54215.1773160025.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.dba5e090b02c4a199bdbd3059630d207?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hardware can support more than 8 general or 3 fixed counters, which could lead to inconsistent access to MSRs (thus failure to initialize vPMU in guest) as we don't support accessing more than these limits. Signed-off-by: Teddy Astie --- I'm not aware of a processor that have more than that, but the specification tells that this is possible. xen/arch/x86/cpu-policy.c | 6 ++++++ xen/arch/x86/cpu/vpmu_intel.c | 15 +++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 7f4456d5a2..46db7f0726 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -276,6 +276,12 @@ switch ( p->x86_vendor ) if ( p->basic.pmu.version > 2 ) p->basic.pmu.version = 2; + /* Truncate control register count to what we support */ + if ( p->basic.pmu.num_gp_ctrs > 8 ) + p->basic.pmu.num_gp_ctrs = 8; + + if ( p->basic.pmu.num_fixed_ctr > 3 ) + p->basic.pmu.num_fixed_ctr = 3; break; } } diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 85539ce6c5..0871795218 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -924,7 +924,22 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) } arch_pmc_cnt = core2_get_arch_pmc_count(); + if ( arch_pmc_cnt > 8 ) + { + printk(XENLOG_INFO + "VPMU: Too many general counters (%u), emulating 8 registers\n", + arch_pmc_cnt); + arch_pmc_cnt = 8; + } + fixed_pmc_cnt = core2_get_fixed_pmc_count(); + if ( fixed_pmc_cnt > 3 ) + { + printk(XENLOG_INFO + "VPMU: Too many fixed counters (%u), emulating 3 registers\n", + arch_pmc_cnt); + fixed_pmc_cnt = 3; + } if ( cpu_has_pdcm ) { -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250306.1547792 (Exim 4.92) (envelope-from ) id 1w00Ca-0003GR-9s; Tue, 10 Mar 2026 16:45:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250306.1547792; Tue, 10 Mar 2026 16: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 ) id 1w00Ca-0003GK-71; Tue, 10 Mar 2026 16:45:00 +0000 Received: by outflank-mailman (input) for mailman id 1250306; Tue, 10 Mar 2026 16:44:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00CZ-0002px-1I for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:44:59 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 789a7155-1ca0-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 17:44:57 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqq3K7VzkL for ; Tue, 10 Mar 2026 16:44:55 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 98e738de90924bc686cc968f1472c66f; Tue, 10 Mar 2026 16:44:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 789a7155-1ca0-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161095; x=1773431095; bh=1m7dPcMlJIb03kreZNPze6+WVgaHDmdl8ulwk259SZM=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=ale4B8aZNnm+IhxftIYstS2ITGOARPsmP2404cd+PXkOdEHx/ISNUtyLVXqpqa5js D6fegAL8rFFrvB9AjNyWdFAqj8nWm23zC0wJbidc93EOGBiZk2yEObFkQg7mric73F LZD2gCdWuOh3Df4C1Co9LGWFj1zQAHh6v2IB1AlrhB1hz9wTjI77UBYlkMgjH6ru/X tQjTLJSVeMgnFtG38ncAJo72ipNaenbwnbWT6Jj9Hivxlmiy5Hb5pvFcJ746QSVVwL B7ZVQAPsmYxDlnQtEqS/5yVC+9HcqSXK3eaFCF87KtHSUeD3e5+4xvNlHXkh7eDO/6 aoJ5PYpNO4P+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161095; x=1773421595; i=teddy.astie@vates.tech; bh=1m7dPcMlJIb03kreZNPze6+WVgaHDmdl8ulwk259SZM=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=fkhdNI1O+TmcQ+LMOmsMhLo9axcKs2ka3+WR1ZwDDfEeKcuV2yStGlmBKRrsc5o62 jLaKyt52PWmITR4fjnhrC5lOsMl6rcxfXP0umPFhzeuo5819lNZkssT3vO4GJZvPg8 ChaCYwMH9fPOBMuJAe4fkn2AulRuIMf0BJYIpAPDEWrvlGRJ/Kp+VkyvumYAhBmnig cePVJDovm3oE8EQ0XuQDRKPr8yf8CjZllJ7rhH+5rd8Jfv+JnjHnWsrZMWgVM9THEI bS5FREaL7yOAd93DDkic/U31afk4YcU7Y71c1j9u88pIk4JX4nuDbV5nVcB/Qcc3Ff suwqk2sA1+snA== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=206/6]=20x86/vpmu:=20Allow=20PMU=20version=206?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161094603 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <151db665c8e9014f0b09d3fbaed3f60448298f0f.1773160025.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.98e738de90924bc686cc968f1472c66f?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:55 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit PMU version 6 (notably implemented in Intel Core Ultra) is backward compatible with older versions, as we're exposing version 2 to the guest, it is not expected not try using PMU version 6 features. Signed-off-by: Teddy Astie --- I don't have the hardware to test vPMU on Intel Core Ultra, but I guess it's supposed to work, as it only introduces new features and doesn't disable existing ones. That could want a changelog entry regarding vPMU support on Intel Core Ultra and alike ? xen/arch/x86/cpu/vpmu_intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 0871795218..9c8802b285 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -819,7 +819,7 @@ static int cf_check core2_vpmu_initialise(struct vcpu *v) static bool ds_warned; if ( v->domain->arch.cpuid->basic.pmu.version <= 1 || - v->domain->arch.cpuid->basic.pmu.version >= 6 ) + v->domain->arch.cpuid->basic.pmu.version >= 7 ) return -EINVAL; if ( (arch_pmc_cnt + fixed_pmc_cnt) == 0 ) @@ -904,6 +904,7 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) case 3: case 4: case 5: + case 6: printk(XENLOG_INFO "VPMU: PMU version %u is not fully supported. " "Emulating version 2\n", version); /* FALLTHROUGH */ -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250308.1547805 (Exim 4.92) (envelope-from ) id 1w00Cc-0003Wv-05; Tue, 10 Mar 2026 16:45:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250308.1547805; Tue, 10 Mar 2026 16:45:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cb-0003Vh-PX; Tue, 10 Mar 2026 16:45:01 +0000 Received: by outflank-mailman (input) for mailman id 1250308; Tue, 10 Mar 2026 16:45:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Ca-000397-NC for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:45:00 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 78c2238b-1ca0-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:44:58 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqp6mX4z1XLF5C for ; Tue, 10 Mar 2026 16:44:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 0562b25a3dc94e9d99b134cfb4b7fefe; Tue, 10 Mar 2026 16:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 78c2238b-1ca0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161094; x=1773431094; bh=feLmUaztYuUh2fFzuOxUOsSPIeQAriCM6y3WlsJDI3Y=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=cPfLADyHXB7i4QDSOQMdwDF/yoyMj0lMubt4jvYERR/4ZY+bGnMDb+XqvLzH+vk8Q hl8sq/c0+JZWoa7NkdlJv1xxpBujLvrgyeSthhgzzKqOnp1yiXK7v7gIzsYCkr62QX ihi1hC8fPnEXnr8gN8xMr9ACCyqO8vp5HfY1QxCV4S24Ck3X3rJe/pHgwaghacF+U+ 2VBPILB7Ipd5Q3UqpkQDO6tPl9NGBo3A2DKdeIlhel2vfw5XjkjZywjHwDuCnJ9aQW f0So/kDViO/3JY21X+NhIVQB8sNj4XZDNiRq07Axpd+oIyvNvsgyyjHLA4pD2IY1MX ArTRTabGKvbtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161094; x=1773421594; i=teddy.astie@vates.tech; bh=feLmUaztYuUh2fFzuOxUOsSPIeQAriCM6y3WlsJDI3Y=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=MVZr07ljRao5Y85v4CvBX/wDJZ9FZuvMdFMBeG4oyPzpZU0ZrvuLDPOB7Yzr+KWUy BI8llkDDBfAwoW3lnse3iKpXLbFKM8+EA9dBClcFX5QQo5pCkAJOiA3La5RHXJCxva +AUNCFLRJHgROC5MXv3x2NyS35lkoYm7EzdChGWpqSnk6t22CDstNFyDqDCUX3KtTQ 7Abowyr+Tbw+MKteihirFvarGoqh9luWmrmiqhoG7dHIvyQ6kg1WUTOijGMhL3hI/Q yJey2tuIGX9vaGBrFBEcWSBUDzBDSXzdZZWoEf6GHN2Rkg2C7bYP0yeBO1n3AsQYZy VzpetchOaLenQ== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=204/6]=20x86/vpmu:=20Sanitise=20Intel=20PMU=20version?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161094185 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.0562b25a3dc94e9d99b134cfb4b7fefe?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Currently, Xen exposes the host CPUID as-is, which is not correct on hardware that implements PMU features that are not supported by Xen (e.g AnyThread bit of PMU version 3, IA32_PERF_GLOBAL_INUSE of PMU version 4, and many other things). As we're actually virtualizing PMU version 2 (as version 3 is the same as version 2 with the addition to AnyThread bit, which is we don't support since [1]), adjust the messages related to PMU emulation to account that. [1] 9f5390441a6e ("x86/vpmu_intel: handle SMT consistently for programmable and fixed counters") Signed-off-by: Teddy Astie --- It could sound weird that we're now exposing version 2, while we were previously (wrongly) exposing version 3. Version 3 mostly works because the guest is not aware of hyperthreads, hence is not expected to try using AnyThread bit (which currently faults due to consistency checks). But we were still actually virtualizing PMU version 2. xen/arch/x86/cpu-policy.c | 33 ++++++++++++++++++++++++++++++++- xen/arch/x86/cpu/vpmu_intel.c | 4 ++-- 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu-policy.c b/xen/arch/x86/cpu-policy.c index 5273fe0ae4..7f4456d5a2 100644 --- a/xen/arch/x86/cpu-policy.c +++ b/xen/arch/x86/cpu-policy.c @@ -253,6 +253,33 @@ static void recalculate_xstate(struct cpu_policy *p) } } +static void sanitise_vpmu(struct cpu_policy *p) +{ +switch ( p->x86_vendor ) + { + case X86_VENDOR_INTEL: + if ( !p->basic.pmu.version ) + return; + + /* + * Expose up to PMU version 2 + * + * PMU version 3 introduced the AnyThread bit we don't want + * to support (see "AnyThread Counting and Software Evolution" + * regarding notes with virtualization). This is the only known + * feature introduced in PMU version 3. + * + * PMU version 5 deprecated AnyThread, and introduced a CPUID + * bit (ANYTHREAD_DEPRECATION) to indicate that this bit isn't supported. + * That CPUID bit should be set for PMU version 5. + */ + if ( p->basic.pmu.version > 2 ) + p->basic.pmu.version = 2; + + break; + } +} + /* * Misc adjustments to the policy. Mostly clobbering reserved fields and * duplicating shared fields. Intentionally hidden fields are annotated. @@ -391,6 +418,8 @@ static void __init calculate_host_policy(void) /* When vPMU is disabled, drop it from the host policy. */ if ( vpmu_mode == XENPMU_MODE_OFF ) p->basic.raw[0xa] = EMPTY_LEAF; + else + sanitise_vpmu(p); /* 0x000000ce MSR_INTEL_PLATFORM_INFO */ /* probe_cpuid_faulting() sanity checks presence of MISC_FEATURES_ENABLES */ @@ -841,7 +870,7 @@ static void __init calculate_hvm_max_policy(void) /* Enable features which are always emulated. */ p->extd.raw[0xa].d |= (1u << SVM_FEATURE_VMCBCLEAN); } - + guest_common_max_feature_adjustments(fs); guest_common_feature_adjustments(fs); @@ -1054,6 +1083,8 @@ void recalculate_cpuid_policy(struct domain *d) if ( vpmu_mode == XENPMU_MODE_OFF || ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) ) p->basic.raw[0xa] = EMPTY_LEAF; + else + sanitise_vpmu(p); if ( !p->extd.svm ) p->extd.raw[0xa] = EMPTY_LEAF; diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index f43faf9567..85539ce6c5 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -901,14 +901,14 @@ const struct arch_vpmu_ops *__init core2_vpmu_init(void) switch ( version ) { + case 3: case 4: case 5: printk(XENLOG_INFO "VPMU: PMU version %u is not fully supported. " - "Emulating version 3\n", version); + "Emulating version 2\n", version); /* FALLTHROUGH */ case 2: - case 3: break; default: -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250309.1547819 (Exim 4.92) (envelope-from ) id 1w00Cd-0003uN-5k; Tue, 10 Mar 2026 16:45:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250309.1547819; Tue, 10 Mar 2026 16:45:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cd-0003u2-1v; Tue, 10 Mar 2026 16:45:03 +0000 Received: by outflank-mailman (input) for mailman id 1250309; Tue, 10 Mar 2026 16:45:01 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cb-000397-NT for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:45:01 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 778c4381-1ca0-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:44:55 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqp2xqRz1XLF3j for ; Tue, 10 Mar 2026 16:44:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id c7ef4ba09d5f46b69712cc53bcc0a6d4; Tue, 10 Mar 2026 16:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 778c4381-1ca0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161094; x=1773431094; bh=eqSCrcSKmBLhF87BI+hUSczC6Ih5ZDFON3mh4aw5Ni4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=e02g2aN6mbhbK5LuxMvOVTDizZIErWmSbE0COLnw9mdA7aflFGidiVL2Y0QASXDl4 FFADotGlrrvN8ETNvZJW7iBb1YZo04vKItdkFtK7DyHwmuOTQFqgf8quvWrZClLsi9 zs2zgKVBc7nkHWEAh9hJAN4BOC7s0IHL6+lREMctUhWvhMGyEYp9IvxGT1Wle4ffXn WNGzmqOYbAfFcWWxH2eNobDD665DR+SoorgKRAt+IHRCa5Ffy2o+9q+awlDoaGGb3R 1fxrLOHr5AyKHJqZDaWpW/rFoVMTxirvQRFCIbPUDW7kqKGc1chDEy0Pn0KxEnG/Xl mZxpiUKdmJadg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161094; x=1773421594; i=teddy.astie@vates.tech; bh=eqSCrcSKmBLhF87BI+hUSczC6Ih5ZDFON3mh4aw5Ni4=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=U4TOixaMNpMTv96wYDgKiJTVULXYPM/iYIV9N9zZp70sCSaeawf+P0LslXK0l8Ccg i+r81qno3t/uASUo6InT6FIL6/Dr4SrktI7LvBHj2O2AiU0dB/yiYiCg2ww9sHUPlJ LNucsBf3GYlL8RSyCJ+MrylLEbVJnC7+uQFhx4wdEWj3ATWz5j/7Z1sUdUt60rtDkR Tif8Fj4XTO5viC2W7vilVskuUlZAOJcSUM1q6zLbtfU2FD5Oya/liNnCuH3o/xY4dm so/T5vYaYTw3sxuz0zgkjtTXnaqzPOKEQlQ/+k6lK7H+4nr8/xwfLTa36l4/GYE1N2 iFlhtvK+m8LdQ== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=201/6]=20x86/vpmu:=20Expose=20up=20to=208=20Intel=20event=20selectors=20in=20PV=20Dom0?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161093473 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <715834969eb198850e1fe0d1e66046f929c8d658.1773160025.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.c7ef4ba09d5f46b69712cc53bcc0a6d4?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Most (if not all) Intel CPUs starting from Sandy Bridge have up to 8 event selectors per core, which could be halved per hyperthread. However, current PV emulation logic doesn't support up to 8 event selector, leading to errors when trying to access them, hence, preventing Linux from driving the vPMU correctly. Make sure up to MSR_P6_EVNTSEL(7) is usable, which is the same upper bound as used in VMX code. The check if the event selector actually exist for the hardware is done in core2_vpmu_do_{rdmsr,wrmsr}, hence we're not allowing to access non-existent MSRs. Fixes: 27c554198666 ("x86/VPMU: add support for PMU register handling on PV guests") Signed-off-by: Teddy Astie --- xen/arch/x86/pv/emul-priv-op.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index 64d47ab677..b2556f9213 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -990,7 +990,7 @@ static int cf_check read_msr( return X86EMUL_OKAY; case MSR_P6_PERFCTR(0) ... MSR_P6_PERFCTR(7): - case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(3): + case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7): case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2: case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL: if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) @@ -1167,7 +1167,7 @@ static int cf_check write_msr( break; case MSR_P6_PERFCTR(0) ... MSR_P6_PERFCTR(7): - case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(3): + case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7): case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2: case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL: if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250304.1547773 (Exim 4.92) (envelope-from ) id 1w00CY-0002qG-SP; Tue, 10 Mar 2026 16:44:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250304.1547773; Tue, 10 Mar 2026 16:44:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00CY-0002q9-Pb; Tue, 10 Mar 2026 16:44:58 +0000 Received: by outflank-mailman (input) for mailman id 1250304; Tue, 10 Mar 2026 16:44:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00CX-0002px-ED for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:44:57 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 778b7e3d-1ca0-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 17:44:56 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqp0shXz38V for ; Tue, 10 Mar 2026 16:44:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id ab72382673ed4219823e03700adaec69; Tue, 10 Mar 2026 16:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 778b7e3d-1ca0-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161094; x=1773431094; bh=PDKUA/ghCpgwOyp0wj5kBTfKQs5YlszkqJ+BY+fssTw=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=OJhyg9SKKlUdl7O3lpFHkmEUOf9MjtgLaKrKxX89QZLR0iyI4Fi/KtiGfjKYDRIpD b15pxQOws7eY3U8Rl2R6T2EWg3QBifWTd1QhnQOG69tB8EiL8UY2uMxuNzStwmScsc U9vetnDDhJmURtXVAZB9LGsjOOOUnZgviWdQjQx2oAgexC0BJoTGzQAw+yeuKK6GMU oIDzGQiSPm8FDq6GQbGjH1XH8+WSY03wUdPhptE1KqRsB/xTtoWW/MHuLJr+4x/L3x BtuXAXbLnp50XDM9uqoizB3zzS+Zi03/qoOOjog6nYuQMi/mCbWOGDKC+THEfL1CFl pKL/BS1k1X+Nw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161094; x=1773421594; i=teddy.astie@vates.tech; bh=PDKUA/ghCpgwOyp0wj5kBTfKQs5YlszkqJ+BY+fssTw=; h=From:Subject:To:Cc:Message-Id:Feedback-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:CC:Date:Subject:From; b=RHUniUrECtGwPXN1Uwl7AlAb3UfH+29S0aTDsbL4f7p5fHZpuLA8Igz1SnHWc2jj6 hAA2GKL8EXDkOHOGaYttkdmVOB6R3wKLEzfZA0g6Q2NxYGgnXr0ttj09bKFI8IS/T0 Vvwuz0QMK6nNV/m9upbHQUdgUQZO0MOD8MdwCjusupZGnF5dJ6zF+/jozf4Pyh5k06 TAntwPxvNBnTc3w28UQogHhIq/r52aQHqLLbDnZXl7nt/oLxTLIYqGdJSY2xfLQgwC 3xeWRmCU6oGktkqbUfxjPqlyE4OF6j6YQD0ZkOwifOQO9oM7WJste1/EZ6aHSfsAyK J/gur438yD7UA== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=200/6]=20Intel=20vPMU=20improvements?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161093132 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.ab72382673ed4219823e03700adaec69?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit First patch fix a problem that prevents vPMU from properly working with a PV domain on a processor that doesn't have hyperthreading. The second patch adds a missing PEBS/DS_AREA MSR handler for PV. The next patches tries to introduce a proper CPUID handling and restrict some hardware limits to Xen ones. Last patch allow vPMU to work with PMU version 6 (Intel Core Ultra and alike). Teddy Astie (6): x86/vpmu: Expose up to 8 Intel event selectors in PV Dom0 x86/vpmu: Expose PEBS and DS area in PV mode x86: Define some Intel vPMU leafs x86/vpmu: Sanitise Intel PMU version x86/vpmu: Limit to using supported general/fixed counters x86/vpmu: Allow PMU version 6 xen/arch/x86/cpu-policy.c | 39 +++++++++++++++++++++++++++- xen/arch/x86/cpu/vpmu_intel.c | 24 ++++++++++++++--- xen/arch/x86/domain.c | 2 +- xen/arch/x86/pv/emul-priv-op.c | 8 ++++-- xen/include/xen/lib/x86/cpu-policy.h | 10 ++++++- 5 files changed, 74 insertions(+), 9 deletions(-) -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:45:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:45:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250307.1547801 (Exim 4.92) (envelope-from ) id 1w00Cb-0003U4-MH; Tue, 10 Mar 2026 16:45:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250307.1547801; Tue, 10 Mar 2026 16:45:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Cb-0003Tx-Ix; Tue, 10 Mar 2026 16:45:01 +0000 Received: by outflank-mailman (input) for mailman id 1250307; Tue, 10 Mar 2026 16:45:00 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Ca-000397-1C for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:45:00 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 778e17c0-1ca0-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 17:44:55 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVfqp4Pfbz3Xd for ; Tue, 10 Mar 2026 16:44:54 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 9b6333b3049249c998ca885eb31c564d; Tue, 10 Mar 2026 16:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 778e17c0-1ca0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773161094; x=1773431094; bh=tvGZ8I5yGbu47GPCSHdjFhh+QbtkVjwXJ0lx4QYZVe0=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=f+ok+lZ1MIhQ10pUJKYcsy3e+6upbZvj+PaxUR+G77adqmsuV3e+Ru0rPOnU9aJGH dSZZd37YZQnbFnDVR10pTnhJJwfnO7B7hIsxOj/ao453TeedkCtCR6b5TAnvGfat0n myQtOYShmp0OBxAowTgaLAKWwNlm2eJcz2KFo94Q5My3TcNppkCgiUIBYoaYDL5GMW lnBv24K3T4Yu6ISfUolkDjYAOHo0fqXcGwE3a3nTYezVMVezKxEiCYJFop8dtOlbIa y56I1w3L6IX+msOfRyBOcgPgJtOgIAzM4HQZjx6vqLcT3cOFnSZE/FN1IYgSCbnjN6 lvheCSAgDxO1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773161094; x=1773421594; i=teddy.astie@vates.tech; bh=tvGZ8I5yGbu47GPCSHdjFhh+QbtkVjwXJ0lx4QYZVe0=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=KXMnZNFrrA8b5m3sXEqulAOlvCodPU4aOi824JbxmHOOBaMydwSI4kll1wCHP04dt MSQ8sS2ZECDYuaI6jGuX8bLPMg6AkjSJ5uBYe0z95G1Zq+4I62AkHDp+p6ersiGlVc 6PVHV+nPUnYjPTU6q3tX3gKbzTwuCPRDAbw2qxeAgBdgiR5TKEb0D8XG65QuXGio73 SXERIvLCXuep4hVniAlNdAaFGwmbTKbUAeNfdvUYECaGo0rYZw+WRkdYrso6iy1PJL 5WQ3IErRYShy9BoF8dQRHczHTsfvNHRZkuLkmFn3PJxSo00OXi6EZHN7hD/N+xr7Vd CgAr1XfAzr2tg== From: "Teddy Astie" Subject: =?utf-8?Q?[PATCH=202/6]=20x86/vpmu:=20Expose=20PEBS=20and=20DS=20area=20in=20PV=20mode?= X-Mailer: git-send-email 2.53.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773161093696 To: xen-devel@lists.xenproject.org Cc: "Teddy Astie" , "Jan Beulich" , "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" Message-Id: <0762ceb722be83bbdf6703cf419debf30609feb0.1773160025.git.teddy.astie@vates.tech> In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.9b6333b3049249c998ca885eb31c564d?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 16:44:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I don't see any reason for them for not be available, especially since core2_vpmu_do_wrmsr has PV specific logic for MSR_IA32_DS_AREA. Fixes: 27c554198666 ("x86/VPMU: add support for PMU register handling on PV guests") Signed-off-by: Teddy Astie --- xen/arch/x86/pv/emul-priv-op.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index b2556f9213..0d93218030 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -993,6 +993,8 @@ static int cf_check read_msr( case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7): case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2: case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL: + case MSR_IA32_PEBS_ENABLE: + case MSR_IA32_DS_AREA: if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) { vpmu_msr = true; @@ -1170,6 +1172,8 @@ static int cf_check write_msr( case MSR_P6_EVNTSEL(0) ... MSR_P6_EVNTSEL(7): case MSR_CORE_PERF_FIXED_CTR0 ... MSR_CORE_PERF_FIXED_CTR2: case MSR_CORE_PERF_FIXED_CTR_CTRL ... MSR_CORE_PERF_GLOBAL_OVF_CTRL: + case MSR_IA32_PEBS_ENABLE: + case MSR_IA32_DS_AREA: if ( boot_cpu_data.vendor == X86_VENDOR_INTEL ) { vpmu_msr = true; -- 2.53.0 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 16:55:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 16:55:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250371.1547836 (Exim 4.92) (envelope-from ) id 1w00Mo-0007gc-GW; Tue, 10 Mar 2026 16:55:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250371.1547836; Tue, 10 Mar 2026 16:55:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Mo-0007gV-Dr; Tue, 10 Mar 2026 16:55:34 +0000 Received: by outflank-mailman (input) for mailman id 1250371; Tue, 10 Mar 2026 16:55:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00Mm-0007gP-RY for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 16:55:32 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f2b4a817-1ca1-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 17:55:31 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso107282585e9.1 for ; Tue, 10 Mar 2026 09:55: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-48534fa65a6sm172083335e9.2.2026.03.10.09.55.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 09:55:30 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f2b4a817-1ca1-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773161731; x=1773766531; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=yifBnf9TlEonB14TYREFh6/NspZbrRBdgUShsp6cVUA=; b=BrmRzpMzs4PDAeDxCLgSrFx/iHsz7QUs9cf/qr8wvKAelja+sWL4oYZ8aUO2AYq5wu CTy3uODFG/gJkKPVw8YN4CbU9CCcWvFGcoePIxT2wMODCUy7gWan21ema23EPT3vjblH ryGnc293yUj/VKs8q3aiua6uAQuTeFiuaYaeKSP+wMXpgBLbQ1JGFfLuiIm5QWm6prCR qNkJRTymZaBjH3SJg6SGCW8YylvOQzXC5DGbt8ucqtWqzffnKqjDSj15ngFcrG6xONjE klITRg/Clr3E075At88wm2azskTWZFd/T0mF24ctETQrm+0lwa5a+s6Kcu1MunTqrWcS LVeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773161731; x=1773766531; h=content-transfer-encoding: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; bh=yifBnf9TlEonB14TYREFh6/NspZbrRBdgUShsp6cVUA=; b=p1ejcFgXhYfuBSx4k8NGL+bUwbBGWwOS/EdkxJTcuoCBGFW/1tDIMfYu/RoXxdUhyb PoKLqLLeAyAfDJh2LTayQojsbd3bqAl5Gr5dWyDxpbmtv6o9okEN7vSo4GuMYMoTV3Zf YYuEy7sklgXiUBClmUUiKZz638mtWf8OE+FJ+FIKpzm1Vw/1OAsfcVGpIyGDFBFCJ9Xq YKoO06U0L/2SXx7TsR2YmlQ/bxj40+PiltjvcUJSYrAY+QXiicAI+ZkjTzLOcxhlk0dd 2ucCNmI1hrCQIM0Lp7kUQd6O7IvPeruAYQdis20kSPtQKpDG337tuHec2yGFSMDXxMgh rzFw== X-Forwarded-Encrypted: i=1; AJvYcCVFGE1ERbEoAs2Lw7ULpC0zUS8UE8JxCDdq73t+MQbN+7W7wxV/22MakDN+CEeHIQpsmc7VOtGahLY=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw7EomEahZqTMG6PUdUnZSABJXB/yeDIZTWoxEMPgoH7BmEbwyf g5lxvYO18RIh+AAwNes3aacDUoZXxyyvIYgar+pTprO20M35cRDFsBjZU2eULVuwXQ== X-Gm-Gg: ATEYQzxkkUyRAUZsUF5cTOWi5jh6DAs0+FCEkfOcmBQiC3rgRQDimJMBf2zTYgEkreG veTsIUPrCmnesStMb/hruUL3wiYyt1vlTvml06jS4YWLh5/2nIbpI7vrk6I5c/hNKplaJKvzL0i Y8jWDCiKZMsZI1i8QWnj4xfD3N0b2ADs76z7nxt+VJZQ+7XH1KqeWPD/v4cIo1+4aQ1VfnMLCGY HuNCkFWrFQbObMQOsk2l858DB3Le+oEyLZFBvgOjMaxgSxSVsGVy9sj+SKcxUjY88/D0ECLWEvS AbrxKjTR1nHoBpcqenw/EexErt0qOxse1/xXj5nxNul4kr87huoO+tsRYd7iZMaQOZYcnS4Bf/g 5DR1CTZViyoTgHtrgdPAOCN2AJsfGiUpKjQDEgppaqiBo4zIvn0tJuVHlIVEYiP8ojgHLGoYjra MUbNei4OvjejsIx6VKQlIqQ7iHCc1XkP0JPc7yEN7FVdLuNu6MaqIbySISdamexjBvqoWHlo4aD ZhBnpO21PX77hM= X-Received: by 2002:a05:600c:a4a:b0:480:690e:f14a with SMTP id 5b1f17b1804b1-4852691e00dmr256773305e9.14.1773161730685; Tue, 10 Mar 2026 09:55:30 -0700 (PDT) Message-ID: Date: Tue, 10 Mar 2026 17:55:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/7] x86/vioapic: Add ioapic_check() to validate IO-APIC state before restore To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-1-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -594,6 +594,35 @@ int vioapic_get_trigger_mode(const struct domain *d, unsigned int gsi) > return vioapic->redirtbl[pin].fields.trig_mode; > } > > +static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h) > +{ > + const HVM_SAVE_TYPE(IOAPIC) *s; > + unsigned int i; > + > + if ( !has_vioapic(d) ) > + return -ENODEV; > + > + s = hvm_get_entry(IOAPIC, h); > + if ( !s ) > + return -ENODATA; > + > + for ( i = 0; i < ARRAY_SIZE(s->redirtbl); i++ ) > + { > + const union vioapic_redir_entry *e = &s->redirtbl[i]; > + > + /* > + * Check to-be-loaded values are within valid range, for them to > + * represent actually reachable state. > + */ > + if ( e->fields.reserve || > + e->fields.reserved[0] || e->fields.reserved[1] || > + e->fields.reserved[2] || e->fields.reserved[3] ) > + return -EINVAL; Are comment and code actually in sync? I can't spot anything preventing the reserved fields to be set by a guest. Such setting would simply be ignored. (And this is actually why I was asking you to add such a function: By adding the checks you should have noticed that the fields can be non-zero if a guest writes them this way. Which in turn may pose a problem for your extid intentions.) > + } > + > + return 0; > +} If it wasn't for the above, something like this may do for starters. Would be nice if base_address, ioregsel, and id also had some sanity checking applied. However, does this build at all with the function unused? You lack ... > static int cf_check ioapic_save(struct vcpu *v, hvm_domain_context_t *h) > { > const struct domain *d = v->domain; ... a hunk altering the HVM_REGISTER_SAVE_RESTORE() further down. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250385.1547858 (Exim 4.92) (envelope-from ) id 1w00a4-0001fg-5R; Tue, 10 Mar 2026 17:09:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250385.1547858; Tue, 10 Mar 2026 17: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 ) id 1w00a4-0001ee-0r; Tue, 10 Mar 2026 17:09:16 +0000 Received: by outflank-mailman (input) for mailman id 1250385; Tue, 10 Mar 2026 17:09:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a2-0001QA-8G for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:14 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dbfb5bb6-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:12 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-485445e80bdso8157385e9.0 for ; Tue, 10 Mar 2026 10:09:12 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:11 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dbfb5bb6-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162551; x=1773767351; 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; bh=dQTAxI2vfkx2VNhH7t+uCNbpYCzRGkHrgeV3afpytNg=; b=kIjMY2TcOtVm0g3FH3qXIIVTveg8pfwxQiN1UaWiKLI1fZEE8HG/LKLIhsdl0rAsh0 aq/FFZcQtk17wFCtGONbgOBUZZOnrKVqbftQ2dmEwfetAuEss+9wvpJBkjm+IwCecz2o VYhBe7tYXanN0Ty6qFlPuxfjBRzUNAkBPNLxnDiTXxp+kdKoHGrdpwWeBZZy4VvFnprc mlT9NKMjz2LlewR5T90QVcGTGyApkbsK2sdAPBehqrif06Zxl40wZ0pILSZOG7GTkijz 62ZrQXWyHa9ltAck5tcpUTV0T9wVouuOpoQbxBscADJ+CL/JI2YYr0Gg3PEUDSy+QxOh DWEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162551; x=1773767351; 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; bh=dQTAxI2vfkx2VNhH7t+uCNbpYCzRGkHrgeV3afpytNg=; b=OpqSUlkLAp5FiFhB3WgTZ62cqOqCiFrSJgdjMowzjBgjw1QZ+yPPFf257MXOmNhXow M+XVDU+6NRyJzqkXxB7Dj62plnc7bzzir4jIRFORGYbA9tXTUVeywR6KpDaJuS/QP5tt 1E9rP7t+cO8dFNJ8NYG5fac8ZLztGPFtWGVSz1oy1vX3t4skoi/3AkxmtNSwo6zTdHGk 8t6Amvk8r8dLscuHQ1KedLFt6rwzrAsD28i0eVJ0OHyWH9FNcjm03E8S+nPuCr4RroPA wyF9ki6YRuI0bBepqN0moTIp/Dr5VmMlaHyH4hx2b6xLXlA0ivHT/aHww33BtiG6wiFR rpEw== X-Gm-Message-State: AOJu0Yz9IObBU1SDPmzipXcRqWwaUXBqSBPm9K6cs90ipWcVQfB17JrQ mzk1AUyZ+9Q89eMK4LsnGAoy1sgYyjtnG0Bzyf5Jkzau2l4fFosBkQI8KZLigJo7 X-Gm-Gg: ATEYQzxT76sa6bVxEiqIc8mFvyMGd4kKUJtTPeiD1/ZqBUdvKlvEaiINWl12AM6rd7M /wWvqmFfT/yrsELfQhN/LWLjqwprkomjoDYKIB0Gee39Tch+VgSs+5B6S4tO3mctHgS4oBRGnbx lNpckjTO1QAcMSs6oHNpTNuJHjdodotpzsnPh2JeE/StQI7mpkiVTwwVCJTPbXhm6nqRGR8/Alj 6Otulw6vb4H0byMUKNBRepDoivlroMTQZOM6Xaqlk1Lv8OHdD/MN1VJnDgmLAZl/4grOCUpH+J7 fOIJ+WAdZ/Hg9UcaW4mKUOwvK+I11zyszQ/8M0bCcoGzlrx+gwiKnRsVyEihTjtKNDvjksvvCO5 /yImGnLXE4QYRkcJQGeCVNdX5b9AJy6CBBQpC81U06/Hy+NJcFYY2q/GKEddyQWnmpu+Zm+3ThG sBg2VhW0saqCJcn07ekZQ0xMMZl04z2wcXyS+0SDE7MqlsssSsntkAH0hOoWhGNdf/lBf7sg== X-Received: by 2002:a05:600c:6995:b0:485:3a27:a961 with SMTP id 5b1f17b1804b1-4853a27a9eamr154877525e9.0.1773162551415; Tue, 10 Mar 2026 10:09:11 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 02/27] xen/riscv: Implement construct_domain() Date: Tue, 10 Mar 2026 18:08:35 +0100 Message-ID: <3a86599284108e6f2a27488a03145f8dd1b71def.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- xen/arch/riscv/domain-build.c | 46 +++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 xen/arch/riscv/domain-build.c diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c new file mode 100644 index 000000000000..0ce903a911ae --- /dev/null +++ b/xen/arch/riscv/domain-build.c @@ -0,0 +1,46 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include + +#include +#include + +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(d->vcpu[0] == NULL); + BUG_ON(v->is_initialised); + + 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++ ) + { + if ( vcpu_create(d, i) == NULL ) + { + printk("Failed to allocate %pd v%d\n", d, i); + break; + } + + printk("Created vcpu %d for %pd\n", i, d); + } + + domain_update_node_affinity(d); + + v->is_initialised = 1; + clear_bit(_VPF_down, &v->pause_flags); + + return 0; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250383.1547846 (Exim 4.92) (envelope-from ) id 1w00a1-0001QI-Nt; Tue, 10 Mar 2026 17:09:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250383.1547846; Tue, 10 Mar 2026 17:09:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a1-0001QB-KW; Tue, 10 Mar 2026 17:09:13 +0000 Received: by outflank-mailman (input) for mailman id 1250383; Tue, 10 Mar 2026 17:09:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a0-0001Q4-55 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:12 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dac0d254-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:10 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4852f73d0a3so29537295e9.3 for ; Tue, 10 Mar 2026 10:09:10 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:08 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dac0d254-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162549; x=1773767349; 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; bh=fS3m/olTHFR+S5wMOXBBTVEk4F6WPK3GOur8e80WWZg=; b=O6ssJ5irhIT4Rn4mYXzd7xFT0mBwKwfo+YpZb3gcKjPAx+pQeRYbhpQ1BROdWBUsYS 7T7Y0NDkbivQiygkK5ClZDG2kQYYtIuXciD/hHh+HcGIubGn5vkL2vdORSZ70NiqRHaQ f92s/3LT79a7OdVowAqZB3J33ZPPyxsAF0uXb9umoJuLo8E9W1MetVFBkd2p4hi0ynaU n22sAZ7kdMNFvrlkXRKYTwtY3m3izZ3wQWqfzoBYwXbIsIj+d9At1r0ryr9CwlSZWm/O gUWn08203WG9MbMULgr8mprifoVS+XduRgVzauQPfN0OssojwaLLtchsHerXrB7uYsBH uYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162549; x=1773767349; 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; bh=fS3m/olTHFR+S5wMOXBBTVEk4F6WPK3GOur8e80WWZg=; b=BzL+qwv/EPkJ/JZoJP7XOuZ/j9BP9UyWp/Yzr3M9p8i8+UMti9PFguy2m1JCBCcIlT LpECCmq6SchQDrPny6Mn19rSas7oU3Uw2AAAtSejNTbZBFwA+JtaGXIbHfsf3o2nGrFQ p68w19PeVk4LES86y9vqOHgBqMlX8Yiv3uPszwZRX/Vp0v7y2q5m+Uh/1QzuVQD38K23 guodkvV0WWt5fyuP0AYdh+8j/b6zm4g6euDzNZcS+KEs37Qqmdq+hFDz1f+qhsaiVCNV wojjMqCwfFb6MCn8N54u7La3FBX6X9rntDJYlO8NneX5z3sHUNYLzbQb06mshWqoympD htnA== X-Gm-Message-State: AOJu0YyUrGIPDSStL6W/37bCoK77GVKVR7uUqPP57u32ngE6NKDnZTpc 1/ybe6UvDn10BAamxZWt7nc8JCdW9xc2vXxQowj38tOETq0sXE2S08MsMOUh6cYD X-Gm-Gg: ATEYQzxhN7konqIaqbkSmUnskjXFnjpqqFAVqiocDHfcFcLPTjzrkNq8rVCvzK2h7hp mk4CBDRnn2oZreGEWsGSLx3LIfoGV6OW+yjwTm8gDWqSVsoVsjh4x+EqAJm3I6lHnnIZ8lwGikn 2r0UHm+BPSENBT9jLosp0QPg4lGQPkTowjTfUYNc6FV9fDoq4oagL6IYI99Kz9Duh7ClCLkgERR PRpJAtacdiQF/QYT4i3pG/p5TaewMV6fiPYHLn3OWiC286vdk0/st7tvFkPcpl4/Iba40cRMq5o xNjIsnTG1OfmTbzwJa+DwxD0/gzntr1Uc0X5C2BHkpAXXjA3pELfp/ZKaUxK04mY+JHHoqrVhkF OsdajdW3d8Q3DbJ5TZtjP3Iorly0NCPralJl7hCaDH43ILiJgOKSmjf5jv1cM2vhc8Ekmo4+H3w b7tfmZZ7OMBDrEV2sNu7WmhAfT3flBOBslWHpQYgMnegdA8sASElEbPW6tALFETk303o/bdA== X-Received: by 2002:a05:600c:6387:b0:485:3983:aba8 with SMTP id 5b1f17b1804b1-4853983ad1amr137276295e9.27.1773162549157; Tue, 10 Mar 2026 10:09:09 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 00/27] [RISC-V] Introduce enablemenant of dom0less Date: Tue, 10 Mar 2026 18:08:33 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. This patch series is based on [1], but a lot of patch could go even without it. [1] https://lore.kernel.org/xen-devel/cover.1770821989.git.oleksii.kurochko@gmail.com/ Oleksii Kurochko (27): xen/riscv: Implement ARCH_PAGING_MEMPOOL xen/riscv: Implement construct_domain() xen/riscv: implement prerequisites for domain_create() xen/riscv: rework G-stage mode handling 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: implement make_intc_domU_node() xen/riscv: generate IMSIC DT node for guest domains xen/riscv: create APLIC DT node for guest domains xen/riscv: introduce aia_init() and aia_available() xen/riscv: add basic VGEIN management for AIA guests xen/riscv: introduce per-vCPU IMSIC state xen/riscv: add very early virtual APLIC (vAPLIC) initialization support xen/riscv: implement IRQ mapping for device passthrough xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h. xen/riscv: add vaplic access check xen/riscv: emulate guest writes to virtual APLIC MMIO xen/riscv: emulate guest reads from virtual APLIC MMIO xen/riscv: introduce (de)initialization helpers for vINTC xen/riscv: implement init_intc_phandle() xen/riscv: call do_initcalls() in start_xen() xen/riscv: init rcu xen/riscv: setup system domains xen/riscv: provide init_vuart() xen/riscv: add initial dom0less infrastructure support xen/arch/riscv/Kconfig | 2 + xen/arch/riscv/Makefile | 6 +- xen/arch/riscv/aia.c | 135 +++++++ xen/arch/riscv/aplic.c | 83 +++++ xen/arch/riscv/cpufeature.c | 33 ++ xen/arch/riscv/dom0less-build.c | 63 ++++ xen/arch/riscv/domain-build.c | 175 +++++++++ xen/arch/riscv/domain.c | 41 ++- xen/arch/riscv/imsic.c | 155 ++++++++ xen/arch/riscv/include/asm/aia.h | 28 ++ xen/arch/riscv/include/asm/aplic.h | 37 ++ xen/arch/riscv/include/asm/cpufeature.h | 2 + xen/arch/riscv/include/asm/domain.h | 17 + xen/arch/riscv/include/asm/imsic.h | 24 ++ xen/arch/riscv/include/asm/intc.h | 51 ++- xen/arch/riscv/include/asm/p2m.h | 9 +- xen/arch/riscv/include/asm/setup.h | 21 +- xen/arch/riscv/include/asm/vaplic.h | 36 ++ xen/arch/riscv/intc.c | 60 ++++ xen/arch/riscv/p2m.c | 91 +++-- xen/arch/riscv/setup.c | 14 + xen/arch/riscv/stubs.c | 9 +- xen/arch/riscv/vaplic.c | 449 ++++++++++++++++++++++++ xen/arch/riscv/vmid.c | 2 +- xen/include/public/arch-riscv.h | 3 + xen/include/public/device_tree_defs.h | 1 + 26 files changed, 1488 insertions(+), 59 deletions(-) create mode 100644 xen/arch/riscv/aia.c create mode 100644 xen/arch/riscv/dom0less-build.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.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250387.1547882 (Exim 4.92) (envelope-from ) id 1w00a5-0002Gn-Ob; Tue, 10 Mar 2026 17:09:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250387.1547882; Tue, 10 Mar 2026 17:09:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a5-0002Gb-KB; Tue, 10 Mar 2026 17:09:17 +0000 Received: by outflank-mailman (input) for mailman id 1250387; Tue, 10 Mar 2026 17:09:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a4-0001QA-M9 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:16 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dd807af5-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:14 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-485410a0a8aso16042795e9.2 for ; Tue, 10 Mar 2026 10:09:14 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dd807af5-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162554; x=1773767354; 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; bh=y2l9GSTVdHf37ct2dJEvx0io7ScAIs5lEweSLfZGouo=; b=iIuPKO4b+qUhMQwTITvT3pvAvG6IJR50piZmXbxla5v5v6ZUcQx+0PAERuup0F1qlo g+FE2eOCLD8mjE0gXjHmdmxpAgiwWuZdOaWlO3IefvaqRIQtkhnHWmOiYGIkKNtXYLew c2TrlXp0JEhUZGoOBTJoT1jiqDQ4t2nLhvhT/16OSaxAflo58U8L5NMDJPbRgwvkkOrw fWej3C0xAQ5hvmvPh4hOgQ64RBzdavG4B9uU4sVCEA6lkpInrhHeTedkBC8wQvIQ5Ofa iCbzDRUgAoHILRIEB6kt9FMU1QXS3xOrp1Bu1cVxBuM5K6SlH3YZaNZXNmzLEps2tA10 RDMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162554; x=1773767354; 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; bh=y2l9GSTVdHf37ct2dJEvx0io7ScAIs5lEweSLfZGouo=; b=MusXI6CI1bXU+TVEazp83y9f5vrpZoeWQygPJLTYc8pkPDwi0kXNrN6j/DJBMvFdkR TfyBMUtgZT+42ctFQ7YzI/yO6Pl3O8JM99nXBq+W92s3loFIDBeYZzEfgZqIlz3PPxy+ w79mR6Oy4biyVBq/xCutI9F4GcMnd0zHru5fKLyuZB7OBM3BUoaK4rZHI5u40VYAzqJw SFR585z/HuBYnUiM3sWrnsMIc/dNVh9txRv7v19/A6GuY+ATM1cDC+5CeF4EcihlB7R3 3SZjUzSZ2LBCKmnKzq5MEJHcWtq852JTkTTQCIEvwhe/KwIu0fN7HMHf3tDIp6ny1DVS e8ew== X-Gm-Message-State: AOJu0YyN9sxMqexhh67wh+yTR/Rvo6e2m3q+QyI5dufTLdKT+48mvyfE Y8eXMJN3hqQYwYwpWsaGAmz33zKA7++ouWIAss0mid7kiihgBM0Ny3wQ3xBJcKMt X-Gm-Gg: ATEYQzzbuSk7Qv9YN0xCaZhJA+xrSIbwJQSnzkdGONzi20jpYAa5jeJ+qlhKXz7dIGX Hju9abVBhIt/V0A88CeIKgGv+uuP5OXVAwMO37rxr6JcgLyCuLn9r2UpCTV7Q9Ei5QQ0j/Ve6G/ rPSNoTWaHaG5/oAp1zjMslUuoM5PsHsybKG0YvtgQWe0PzVTr1BrRfVmsn9YP+fJOZcRnAzEbn6 BeuwwNAmbOhBJfdptYXPhmSObybJO2HBbOyd6zM2A6H11omDItrO34DIJMkBNi1qdgwy1aSfXaG CUmVfRvLB5SuKDHBX6a8W23LoKSu40yI0HgOv0wOJr6h/T9a241pz19HwngaC7I7qkBWkjVZwGC xoXqB+OH41NMjRPPx+560g4IrgMlBssqezdvb5JCk38T5oD+qGu6o1rTc/vhtopr4xrrFC0JFRA XZ849b55hPNphvrboaCMIU1PzBysaAr0Rf2rL0lLGUyl3kv4sXeGMcn1rrTBAvguicJg== X-Received: by 2002:a05:600c:a12:b0:483:badb:618f with SMTP id 5b1f17b1804b1-48526966b07mr244053275e9.25.1773162553878; Tue, 10 Mar 2026 10:09:13 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 04/27] xen/riscv: rework G-stage mode handling Date: Tue, 10 Mar 2026 18:08:37 +0100 Message-ID: <2c8f1ea25b8d3ec78b00510fbe604a87e759e194.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Rework G-stage mode handling to make the selected mode descriptor reusable outside of p2m initialization. As max_gstage_mode is going to be reused by code that creates CPU nodes for guest domains, not only max_gstage_mode->mode but also max_gstage_mode->name is required. To support this, make max_gstage_mode a global pointer to one of the entries in a global modes[] array, and remove get_max_supported_mode(). Update struct p2m_domain to store a pointer to a mode descriptor instead of embedding the structure directly. Refactor the modes[] array so that mode->name contains only the MMU scheme name (without the "x4" suffix), as this value is reused when filling the maximum MMU type passed to the guest. According to DT bindings [1], the MMU type must not include the "x4" suffix. Use "none" for the Bare mode to match the DT binding requirements. Adjust modes[]->paging_levels to represent the maximum paging level rather than the total number of levels. This ensures that P2M_ROOT_LEVEL() and its users behave correctly without relying on hardcoded p2m mode values. Finally, drop __initconst from the modes[] declaration, as the array is referenced via p2m->mode and max_gstage_mode beyond the init stage. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/riscv/cpus.yaml?h=v6.19-rc3#n82 Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/include/asm/p2m.h | 7 ++-- xen/arch/riscv/p2m.c | 60 +++++++++++++------------------- xen/arch/riscv/vmid.c | 2 +- 3 files changed, 30 insertions(+), 39 deletions(-) diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h index c6d846b96fb4..4441c0400b83 100644 --- a/xen/arch/riscv/include/asm/p2m.h +++ b/xen/arch/riscv/include/asm/p2m.h @@ -13,7 +13,7 @@ #define P2M_ROOT_ORDER (ilog2(GSTAGE_ROOT_PAGE_TABLE_SIZE) - PAGE_SHIFT) #define P2M_ROOT_PAGES BIT(P2M_ROOT_ORDER, U) -#define P2M_ROOT_LEVEL(p2m) ((p2m)->mode.paging_levels) +#define P2M_ROOT_LEVEL(p2m) ((p2m)->mode->paging_levels) /* * According to the RISC-V spec: @@ -58,6 +58,8 @@ struct gstage_mode_desc { char name[8]; }; +extern const struct gstage_mode_desc *max_gstage_mode; + /* Per-p2m-table state */ struct p2m_domain { /* @@ -71,7 +73,7 @@ struct p2m_domain { /* The root of the p2m tree. May be concatenated */ struct page_info *root; - struct gstage_mode_desc mode; + const struct gstage_mode_desc *mode; /* Back pointer to domain */ struct domain *domain; @@ -218,7 +220,6 @@ static inline bool arch_acquire_resource_check(struct domain *d) } void guest_mm_init(void); -unsigned char get_max_supported_mode(void); int p2m_init(struct domain *d); diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 886e06196ba2..dce1eb205ec9 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -45,18 +45,32 @@ struct p2m_pte_ctx { unsigned int level; /* Paging level at which the PTE resides. */ }; -static struct gstage_mode_desc __ro_after_init max_gstage_mode = { - .mode = HGATP_MODE_OFF, - .paging_levels = 0, - .name = "Bare", -}; - /* * Set to the maximum configured support for IPA bits, so the number of IPA bits can be * restricted by external entity (e.g. IOMMU). */ unsigned int __read_mostly p2m_ipa_bits = PADDR_BITS; +static const struct gstage_mode_desc modes[] = { + /* + * Based on the RISC-V spec: + * Bare mode is always supported, regardless of SXLEN. + * When SXLEN=32, the only other valid setting for MODE is Sv32. + * When SXLEN=64, three paged virtual-memory schemes are defined: + * Sv39, Sv48, and Sv57. + */ + [0] = { HGATP_MODE_OFF, 0, "none" }, +#ifdef CONFIG_RISCV_32 + [1] = { HGATP_MODE_SV32X4, 1, "sv32" } +#else + [2] = { HGATP_MODE_SV39X4, 2, "sv39" }, + [3] = { HGATP_MODE_SV48X4, 3, "sv48" }, + [4] = { HGATP_MODE_SV57X4, 4, "sv57" }, +#endif +}; + +const struct gstage_mode_desc * __ro_after_init max_gstage_mode = &modes[0]; + static void p2m_free_page(struct p2m_domain *p2m, struct page_info *pg); static inline void p2m_free_metadata_page(struct p2m_domain *p2m, @@ -69,11 +83,6 @@ static inline void p2m_free_metadata_page(struct p2m_domain *p2m, } } -unsigned char get_max_supported_mode(void) -{ - return max_gstage_mode.mode; -} - /* * If anything is changed here, it may also require updates to * p2m_{get,set}_type(). @@ -154,23 +163,6 @@ static pte_t *p2m_get_root_pointer(struct p2m_domain *p2m, gfn_t gfn) static void __init gstage_mode_detect(void) { - static const struct gstage_mode_desc modes[] __initconst = { - /* - * Based on the RISC-V spec: - * Bare mode is always supported, regardless of SXLEN. - * When SXLEN=32, the only other valid setting for MODE is Sv32. - * When SXLEN=64, three paged virtual-memory schemes are defined: - * Sv39, Sv48, and Sv57. - */ -#ifdef CONFIG_RISCV_32 - { HGATP_MODE_SV32X4, 2, "Sv32x4" } -#else - { HGATP_MODE_SV39X4, 3, "Sv39x4" }, - { HGATP_MODE_SV48X4, 4, "Sv48x4" }, - { HGATP_MODE_SV57X4, 5, "Sv57x4" }, -#endif - }; - for ( unsigned int mode_idx = ARRAY_SIZE(modes); mode_idx-- > 0; ) { unsigned long mode = modes[mode_idx].mode; @@ -179,16 +171,16 @@ static void __init gstage_mode_detect(void) if ( MASK_EXTR(csr_read(CSR_HGATP), HGATP_MODE_MASK) == mode ) { - max_gstage_mode = modes[mode_idx]; + max_gstage_mode = &modes[mode_idx]; break; } } - if ( max_gstage_mode.mode == HGATP_MODE_OFF ) + if ( max_gstage_mode->mode == HGATP_MODE_OFF ) panic("Xen expects that G-stage won't be Bare mode\n"); - printk("Max supported G-stage mode is %s\n", max_gstage_mode.name); + printk("Max supported G-stage mode is %sx4\n", max_gstage_mode->name); csr_write(CSR_HGATP, 0); @@ -289,7 +281,7 @@ static void clear_and_clean_page(struct page_info *page, bool clean_dcache) unsigned long construct_hgatp(const struct p2m_domain *p2m, uint16_t vmid) { return MASK_INSR(mfn_x(page_to_mfn(p2m->root)), HGATP_PPN_MASK) | - MASK_INSR(p2m->mode.mode, HGATP_MODE_MASK) | + MASK_INSR(p2m->mode->mode, HGATP_MODE_MASK) | MASK_INSR(vmid, HGATP_VMID_MASK); } @@ -369,9 +361,7 @@ int p2m_init(struct domain *d) #endif /* TODO: don't hardcode used for a domain g-stage mode. */ - p2m->mode.mode = HGATP_MODE_SV39X4; - p2m->mode.paging_levels = 2; - safe_strcpy(p2m->mode.name, "Sv39x4"); + p2m->mode = &modes[2]; return 0; } diff --git a/xen/arch/riscv/vmid.c b/xen/arch/riscv/vmid.c index 8fbcd500f24d..11c7e9d6d6c8 100644 --- a/xen/arch/riscv/vmid.c +++ b/xen/arch/riscv/vmid.c @@ -52,7 +52,7 @@ static DEFINE_PER_CPU(struct vmid_data, vmid_data); static unsigned int vmidlen_detect(void) { unsigned int vmid_bits; - unsigned char gstage_mode = get_max_supported_mode(); + unsigned char gstage_mode = max_gstage_mode->mode; /* * According to the RISC-V Privileged Architecture Spec: -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250388.1547891 (Exim 4.92) (envelope-from ) id 1w00a6-0002Wy-UO; Tue, 10 Mar 2026 17:09:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250388.1547891; Tue, 10 Mar 2026 17:09:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a6-0002Wi-RD; Tue, 10 Mar 2026 17:09:18 +0000 Received: by outflank-mailman (input) for mailman id 1250388; Tue, 10 Mar 2026 17:09:17 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a5-0001QA-DA for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:17 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id de296016-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:15 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4852e9ca034so34282465e9.2 for ; Tue, 10 Mar 2026 10:09:15 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:14 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: de296016-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162555; x=1773767355; 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; bh=F37HFkhRbnNKMwdsdySIIUyxwC6WRGnT9uYuIwl9b5U=; b=BQC/eGi62ImYEG6jyp1sk7rfyLMl1c+jlrrDijPte6RZOeiV6ty0CH5C67cGie0P7v hcW/eYDNFWtSZBxZBecbt75gRfF6PnQlgJRSGzN7a5leJFNrMvs1GxMZv8+eqIJjY+4w ck0H8s5UguQTmw32G49tEJGiaQ6/il7alxiANHrZ+duSh6l8lMLQ5Vq9jMdjm8+9djiI Q6kSx6AfgnGQXtQAVV7iWMMxSRJgkgY9PXh9ZFXdtvm4MhzCZqI05SP1M9le+QRJdpk7 US2iaCdzuVxDEKfLzsMI6+4P7O053U0fV6pHeFflsmRsH/FVUohVsfBLDc+l9suu2/gC Cyjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162555; x=1773767355; 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; bh=F37HFkhRbnNKMwdsdySIIUyxwC6WRGnT9uYuIwl9b5U=; b=L+sCK/pY7zBWrFeULSBsucdxRnZyuBaVLnB9Ic2gzd4RlInBeNKEhAwPqNj3VUQe7A r9LM6U/ykaVSqqQwSnqZLCVfoT9P80Sb/91vyR3cCX/CtwCMZXxIcvDC70P1Cfqg8G52 jDuVR49tPXQK5uri0WFXEm3n2kbiDOt43n+FawI1qCs0tTJrD2oTh9NOXe0t2+CsKasV ZR5InQkGwNaeBlkP/NvMPzvLGaYOZu5+OMv+xW6mriL+j4QSO2yAvWkfsuKqvI2qIu/X 3KHeAfio5IRG8LqGuXBB+dWQOTnAJwAfTdTK0fEdCGkINdHwtJU5i2lit5mgeMYqCqhS YbtQ== X-Gm-Message-State: AOJu0YwRY+qy9MTyF3loIENSdUS5f4vhnvXqvB/iMt5l0vcfGHZ4kNPl 25oN52dwENnsQyHFoBFRADclJUKCQT3gY1cPSCFV7LJeSqE1DWzUqh7i/qyKcV33 X-Gm-Gg: ATEYQzzY16nUmn1/Lv3Eg/mMC4mzsxYjKB2AW6zijlaBghD36yUR7mLZa2gLxKS7z/J P0IF+0mOPj96oSoPMdnkbbUEohf0CE8XNLLXDitk1X5TYozZvfJ1y8pkq2nvAcz7ipY0F0dUxR0 1PkCdVVc6ZpVDbPZ0P+brQQ4dxtlHeHb4gyhZjF8LV5y9T1gBpLzggMoR+AdZArfCYF5Ap2Tb/8 Kbp9HQ91aQXJGicoxK5Ciifn4J67T6y3dpYni7QB7dDyVRcD9n0RWg9TAVxIVVCxfaILtGiE4Hw qdB/sdZdbKM2na2I3YVLeiDAYv9uqsE+rovg5TXZooFQ95HQUjZg771UKr3xqKxCsaUQNFRvVra MlWMOYnshwB4PFGgdvhOAecKre3YNKOzlsetLeh7PEBvSvj3DJQmHoviV+zbFmOSpljN/MToAIe cd+6zQCo+JPuu6K8lZPEChenesoMylSeDIIH7qhZEd325mPfdW7jqkbbxCs4NJ/RM7lQ== X-Received: by 2002:a05:600c:3b83:b0:485:35d3:ce57 with SMTP id 5b1f17b1804b1-48535d3cf0cmr190710405e9.34.1773162554952; Tue, 10 Mar 2026 10:09:14 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 05/27] xen/riscv: introduce guest riscv,isa string Date: Tue, 10 Mar 2026 18:08:38 +0100 Message-ID: <007c0a0243ac7ff1d1ab3faa4ebcdd6fcd14e485.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Introduce generation of the riscv,isa string passed to the guest via the Device Tree riscv,isa property. The following changes are introduced: - According to the RISC-V privileged specification, M-mode software controls the XLEN value used by S-mode and U-mode. For RV64 harts, the SXL and UXL fields of the mstatus register are WARL fields that define the XLEN for S-mode and U-mode. The XLEN value is provided by M-mode software (OpenSBI in the case of Xen) via the riscv,isa DT property. Introduce and initialize an xlen variable when parsing the host riscv,isa string in riscv_isa_parse_string(). - Introduce the guest_isa_str variable to store the riscv,isa string generated for a guest domain during riscv,isa property parsing. Update match_isa_ext() to populate guest_isa_str accordingly. - Introduce guest_unsupp_bmp and guest_unsupp_exts[] to filter out ISA extensions that should not be exposed to guests. For example, FPU-related extensions are currently not supported for guests (at the moment) and are therefore removed from the guest riscv,isa string. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/cpufeature.c | 33 +++++++++++++++++++++++++ xen/arch/riscv/include/asm/cpufeature.h | 2 ++ 2 files changed, 35 insertions(+) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 987d36dc7eee..d7e483603dbe 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -38,6 +38,8 @@ struct riscv_isa_ext_data { /* Host ISA bitmap */ static __ro_after_init DECLARE_BITMAP(riscv_isa, RISCV_ISA_EXT_MAX); +static __ro_after_init unsigned int xlen; + static int __init dt_get_cpuid_from_node(const struct dt_device_node *cpu, unsigned long *dt_cpuid) { @@ -160,6 +162,19 @@ static const struct riscv_isa_ext_data __initconst required_extensions[] = { RISCV_ISA_EXT_DATA(svpbmt), }; +static const unsigned int __initconst guest_unsupp_exts[] = { + RISCV_ISA_EXT_f, + RISCV_ISA_EXT_d, + RISCV_ISA_EXT_h, + RISCV_ISA_EXT_q, + RISCV_ISA_EXT_v, +}; + +static __ro_after_init DECLARE_BITMAP(guest_unsupp_bmp, RISCV_ISA_EXT_MAX); + +#define MAX_GUEST_ISA_STR_LEN 256 +char guest_isa_str[MAX_GUEST_ISA_STR_LEN]; + static bool __init is_lowercase_extension_name(const char *str) { /* @@ -193,6 +208,15 @@ static void __init match_isa_ext(const char *name, const char *name_end, !memcmp(name, ext->name, name_end - name) ) { __set_bit(ext->id, bitmap); + + if ( riscv_isa_extension_available(guest_unsupp_bmp, ext->id) ) + break; + + if ( ext->id >= RISCV_ISA_EXT_BASE ) + safe_strcat(guest_isa_str, "_"); + + safe_strcat(guest_isa_str, ext->name); + break; } } @@ -207,13 +231,17 @@ static int __init riscv_isa_parse_string(const char *isa, #if defined(CONFIG_RISCV_32) if ( isa[2] != '3' && isa[3] != '2' ) return -EINVAL; + xlen = 32; #elif defined(CONFIG_RISCV_64) if ( isa[2] != '6' && isa[3] != '4' ) return -EINVAL; + xlen = 64; #else # error "unsupported RISC-V bitness" #endif + snprintf(guest_isa_str, sizeof(guest_isa_str), "rv%d", xlen); + /* * In unpriv. specification (*_20240411) is mentioned the following: * (1) A RISC-V ISA is defined as a base integer ISA, which must be @@ -487,6 +515,11 @@ void __init riscv_fill_hwcap(void) bool all_extns_available = true; struct trap_info trap; + for ( i = 0; i < ARRAY_SIZE(guest_unsupp_exts); i++ ) + { + __set_bit(guest_unsupp_exts[i], guest_unsupp_bmp); + } + riscv_fill_hwcap_from_isa_string(); if ( bitmap_empty(riscv_isa, RISCV_ISA_EXT_MAX) ) diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/include/asm/cpufeature.h index ef02a3e26d2c..aabbbf0c2cc3 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -43,6 +43,8 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_MAX }; +extern char guest_isa_str[]; + void riscv_fill_hwcap(void); bool riscv_isa_extension_available(const unsigned long *isa_bitmap, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250386.1547864 (Exim 4.92) (envelope-from ) id 1w00a4-0001mV-FF; Tue, 10 Mar 2026 17:09:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250386.1547864; Tue, 10 Mar 2026 17: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 ) id 1w00a4-0001lY-AG; Tue, 10 Mar 2026 17:09:16 +0000 Received: by outflank-mailman (input) for mailman id 1250386; Tue, 10 Mar 2026 17:09:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a2-0001Q4-Hp for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:14 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dcbe1f1b-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:13 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4852a9c6309so37120805e9.0 for ; Tue, 10 Mar 2026 10:09:13 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:12 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dcbe1f1b-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162553; x=1773767353; 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; bh=ZTdWdjcrO6LbYgQhxDIWi1k5AvTcDOv59FKJtZgzw4Y=; b=Pq+32YmSwW69cDEgpXSzatnouzEHbw6wKVbf0WjLKqmyXj1S97/e+R66ZR7/lfA9uF /gqm5n26AS7l9jrWRXCFCMjebCvDBa+s+yzHDh72tmVkwf+BVWH5vejURnXP2rf8DEw8 HdMUvVwCcFbQxzNJu2piHTqjWgsK9oI3RLgkM04vTUxfPUFfpp5+CUFFOuu4r73TYHAd JTuBIgnDHxWgaVMuUovHwHgocV8duEJS6vvU4kXfFj6zOE3pvqAGh955mjVDqg+GyrTz J3sVEWROd2oodR0vM0dLOGE3wnrJo/58ctoZbWSGe+pydI48W2W9c7gaHlmmLk89CjbE OEDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162553; x=1773767353; 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; bh=ZTdWdjcrO6LbYgQhxDIWi1k5AvTcDOv59FKJtZgzw4Y=; b=YXaNUCxWo5igCJ1u1SqSz37yOJDzZf6hZfbXqZuzHExJiTqZhVNnvqQlIxbVMbaYZw YyM/MDuaVEik9FDlCU3iHr33XyoSIMEHy8t+YANM5shnB2ZUoP2AO53DZRtFSuMAkt6M gZHMgrv3cuOZDrDGNyh6g6Z+F0w2DogQ+3YwXhYOMlyjEa8a0StB6G8x6cqFHwgDeRhX wKY/ISNk/Y5dvaPP7grZmJOrHVTr63xnlZbiA1CEFD/Rx7bT7HrZFGPjaY2ryLaBTj0k LrVqC8oNn3r9NgkSBJ8g8m+bBVO+4q6cRInWVP/VUiY5V3qy6EBQOLdptyJJvf0gmMFg BDLA== X-Gm-Message-State: AOJu0Yx0tPC21I/FSMRWVkxTKDKq0Nyn+LlkGLzJTDCqVfgJ66uZy5eu 9tq0bX69KeByqpVwDmB+bNcKd7cM4tfrnAxyOpIXFefrp62xReo+72oJvRP/FZC7 X-Gm-Gg: ATEYQzwlU/BvtplZp3dBlRD9Cq1D1iSOZ0rE1ghQDjKTxorm+0yhpiM6/J9H+UsjjIV 0hKmI0HGe5KjNjsrV2QFSIB9gJakkg8wcPsFhNxqZdKkBmnWx5ErhxRDCSSet1TiGtOL/jASqa7 eVVEShUMSu+eKAwWeNyqSneuzRtn32clD3Ozde/H9lzguiYDt8OMIxy9DnzhXNTRf7UFIRFC7oS +z1QUNmb9YqeUbzPJF048wNREyApszLKq0K6K3//DIYMrGHr8yo58pLqn/US1P1iWvjYcxRg7xS Lg1J7iTT+x7YhdQg6tKiEbIZMZj7YqT/VbACBLaG2DbvnLvVDDoYDLczDe61I8YF5lY9OaIS2io 6x+pnXaExokpXWju+C3A+XP1LJfk4NFs/1SiU1mR7XO38CChfC4At5Tb7GkfC0BnwQjzcliuEeY of+SKD4z/RvNyjkvb8cLer67OWp+ETQCQpRT39dpX5Ctx3RoL4MVfOBH8aW4rXklNP2A== X-Received: by 2002:a05:600c:8b01:b0:477:561f:6fc8 with SMTP id 5b1f17b1804b1-485269195afmr262309165e9.5.1773162552633; Tue, 10 Mar 2026 10:09:12 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 03/27] xen/riscv: implement prerequisites for domain_create() Date: Tue, 10 Mar 2026 18:08:36 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit arch_domain_create() and arch_sanitise_domain_config() are prerequisites for domain_create(). arch_sanitise_domain_config() currently returns 0, as there is no specific work required at this stage. arch_domain_create() performs basic initialization, such as setting up the P2M and initializing the domain's virtual timer. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/domain.c | 27 +++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 3 +++ xen/arch/riscv/stubs.c | 9 +-------- xen/include/public/device_tree_defs.h | 1 + 4 files changed, 32 insertions(+), 8 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 7e3070101714..515735b32e30 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -288,6 +288,33 @@ void sync_vcpu_execstate(struct vcpu *v) /* Nothing to do -- no lazy switching */ } +int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) +{ + return 0; +} + +int arch_domain_create(struct domain *d, + struct xen_domctl_createdomain *config, + unsigned int flags) +{ + int rc = 0; + + if ( is_idle_domain(d) ) + return 0; + + if ( (rc = p2m_init(d)) != 0) + goto fail; + + d->arch.next_phandle = GUEST_PHANDLE_LAST + 1; + + return rc; + + fail: + d->is_dying = DOMDYING_dead; + arch_domain_destroy(d); + return rc; +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 0caacf92b5a2..506365f199c7 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -95,6 +95,9 @@ struct arch_domain { #ifdef CONFIG_ARCH_PAGING_MEMPOOL struct paging_domain paging; #endif + + /* Next unused device tree phandle number */ + uint32_t next_phandle; }; #include diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index acbb5b9123ea..d139f8786cb5 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -101,14 +101,7 @@ void dump_pageframe_info(struct domain *d) BUG_ON("unimplemented"); } -int arch_sanitise_domain_config(struct xen_domctl_createdomain *config) -{ - BUG_ON("unimplemented"); -} - -int arch_domain_create(struct domain *d, - struct xen_domctl_createdomain *config, - unsigned int flags) +void vcpu_switch_to_aarch64_mode(struct vcpu *v) { BUG_ON("unimplemented"); } diff --git a/xen/include/public/device_tree_defs.h b/xen/include/public/device_tree_defs.h index 9e80d0499dc3..c9679cb3543c 100644 --- a/xen/include/public/device_tree_defs.h +++ b/xen/include/public/device_tree_defs.h @@ -14,6 +14,7 @@ */ #define GUEST_PHANDLE_GIC (65000) #define GUEST_PHANDLE_IOMMU (GUEST_PHANDLE_GIC + 1) +#define GUEST_PHANDLE_LAST GUEST_PHANDLE_IOMMU #define GUEST_ROOT_ADDRESS_CELLS 2 #define GUEST_ROOT_SIZE_CELLS 2 -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:20 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250384.1547855 (Exim 4.92) (envelope-from ) id 1w00a3-0001dh-Ua; Tue, 10 Mar 2026 17:09:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250384.1547855; Tue, 10 Mar 2026 17:09:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a3-0001da-RD; Tue, 10 Mar 2026 17:09:15 +0000 Received: by outflank-mailman (input) for mailman id 1250384; Tue, 10 Mar 2026 17:09:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a2-0001QA-0m for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:14 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id db5603bb-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:11 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso107421775e9.1 for ; Tue, 10 Mar 2026 10:09:11 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:10 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: db5603bb-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162550; x=1773767350; 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; bh=mMLvC7RrPAqRfMztOqd3dBSpw1saOMdIpsVoEROSJU4=; b=fTY59slMZv+YgNJ0FI+XhCaJfoa2S8SsRq5ufCKrVciZ1ayTcRMxFydVtUMQK3cDk4 GVI4OBGmfoGE7Uw568eY9pv7ru7N4GbWKBdTIh0RU67QXgSgKrhhYrFEi59TQvHZQ5qU kbj3FHyIkM3LXSmQYE5xn5neJ97FMVt8UTGnIG+Sf2MiZGsYVT2Zqu7eAsFKUCqSAPER MVAH5lG3EXGjU5jWrbJ24hk/348KRwlNoxnywua3ajmzgZbShzek/n7hddDKl9t9FsJe z/VUr5WcckW46OSPM/BhqqHW/XwtoSSKRVWdTix7+jugf/XwFg5PZqsohyD4+keF2jvq gAKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162550; x=1773767350; 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; bh=mMLvC7RrPAqRfMztOqd3dBSpw1saOMdIpsVoEROSJU4=; b=X5IvfySpgqBN4Bcns1LKvve2WiPKCF9H79Lw3OAWkewzhxjcOChK6ik+qctMhyu6U1 01aGvYoXL7oQoTSNeRRe3dHUg+DppnSV42OQeJ4JCNleIS8yPmOg/qUNWAUy9bIIJa0h uK+VDO53RsZlgaoPwumsNNJ9cPj3xjqQ034QZBn5sudlJo+9OzTcf12Gay02euBTcSZC ohVi/kIOp+WJMDVx6yNQ8uC96Jme/eIQUZPXiEMCuRpdPVgKRI/E5aQWDCfdIxoHd0Zp wHJkzPCX2pE7T4gzLl472XgiPzVt9ZyJ4XAWctbOlJT7LXvOSzMTtQbXJALOh6epEdku fr4A== X-Gm-Message-State: AOJu0YxI/BLDISg+ecHO8vKnjkV/07dkpcQAjiSJdjLdPvxIXIcxCvju Q9wWq0aM9uVpWkT/AJHjsijF/ZuLFeXzus/924oTnM0oA5lva/Mwh23U3yjvAl+e X-Gm-Gg: ATEYQzxmAPrDseGS1jvJFtrBjH9XFcJ/1NJAM/B1EnjsLdvyN0ECZMxgbxAjHsK3ZyS zM108ncVv4Lszs1bjU9TdClFul9P6fLx9+BUj1Lcbu4cNwYgtz4iPDf9FILpuyf6I7nmKBXSJe8 16PaxmL2s1GkivT5CjYMQBgvXh1wcsXm6sAOFYjxDWtMdWeFQSKp3QfASjckhR5tDtJznNFcv9r 2/zy6au2O811TWl88Pk2rbuUShwGod5Athzx7Rd/sswtsO/E3NlYsdAIaG4XK0R+g8H06P+kJgK uN3uiAb+7xCljqILueWT+qGZSbkXjvukJFpZ6eqJ8kthsB+UE12xVgpTJhoeaHGW/eJzvz2P6Iu 9iZKPqJIv1sFtou/DTkqKFtdJFqI5O55rqN6/Lwb8o6wA1zdUBLRkRxkBFQpvOn5GLInCDRAi0+ 4lsfeVFm1jIz1XkBp9k2Ex9NUFibw+d77pp0ySq/7AN3b3Emjk2U07KUbQp172afeifg== X-Received: by 2002:a05:600c:8b6d:b0:485:364e:9328 with SMTP id 5b1f17b1804b1-485364e9569mr156488245e9.16.1773162550327; Tue, 10 Mar 2026 10:09:10 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 01/27] xen/riscv: Implement ARCH_PAGING_MEMPOOL Date: Tue, 10 Mar 2026 18:08:34 +0100 Message-ID: <887d914aa0ddb1884c19c9567d4633ecaf810066.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The p2m_freelist is used to allocate pages for the P2M, but to initialize this list, domain_p2m_set_allocation() might be called. This function is invoked in construct_domU() within the common Dom0less code, and providing an implementation of domain_p2m_set_allocation() when CONFIG_ARCH_PAGING_MEMPOOL=y is appropriate for RISC-V. Additionally, implement arch_{set,get}_paging_mempool_size(). They are not used directly for now, but are required to support the XEN_DOMCTL_{get,set}_paging_mempool_size() hypercalls. Remove 'struct paging_domain' from RISC-V's 'struct arch_domain' when the field is not required. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/Kconfig | 1 + xen/arch/riscv/Makefile | 2 +- xen/arch/riscv/include/asm/domain.h | 2 ++ xen/arch/riscv/p2m.c | 31 +++++++++++++++++++++++++++++ 4 files changed, 35 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index 12b337365f1f..091510380949 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -1,5 +1,6 @@ config RISCV def_bool y + select ARCH_PAGING_MEMPOOL select DOMAIN_BUILD_HELPERS select FUNCTION_ALIGNMENT_16B select GENERIC_BUG_FRAME diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 48957104e0b5..b1514f1514a2 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -10,7 +10,7 @@ obj-y += irq.o obj-y += kernel.o obj-y += mm.o obj-y += p2m.o -obj-y += paging.o +obj-$(CONFIG_ARCH_PAGING_MEMPOOL) += paging.o obj-y += pt.o obj-$(CONFIG_RISCV_64) += riscv64/ obj-y += sbi.o diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 6c48bf13111d..0caacf92b5a2 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -92,7 +92,9 @@ struct arch_domain { /* Virtual MMU */ struct p2m_domain p2m; +#ifdef CONFIG_ARCH_PAGING_MEMPOOL struct paging_domain paging; +#endif }; #include diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index fba93bce24d9..886e06196ba2 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -1568,3 +1568,34 @@ struct page_info *get_page_from_gfn(struct domain *d, unsigned long gfn, return page; } + +#ifdef CONFIG_ARCH_PAGING_MEMPOOL + +int arch_set_paging_mempool_size(struct domain *d, uint64_t size) +{ + unsigned long pages = PFN_DOWN(size); + bool preempted = false; + int rc; + + if ( (size & ~PAGE_MASK) || /* Non page-sized request? */ + pages != PFN_DOWN(size) ) /* 32-bit overflow? */ + return -EINVAL; + + spin_lock(&d->arch.paging.lock); + rc = p2m_set_allocation(d, pages, &preempted); + spin_unlock(&d->arch.paging.lock); + + ASSERT(preempted == (rc == -ERESTART)); + + return rc; +} + +/* Return the size of the pool, in bytes. */ +int arch_get_paging_mempool_size(struct domain *d, uint64_t *size) +{ + *size = (uint64_t)ACCESS_ONCE(d->arch.paging.total_pages) << PAGE_SHIFT; + + return 0; +} + +#endif /* CONFIG_ARCH_PAGING_MEMPOOL */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250389.1547900 (Exim 4.92) (envelope-from ) id 1w00a9-0002ok-7m; Tue, 10 Mar 2026 17:09:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250389.1547900; Tue, 10 Mar 2026 17:09:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a9-0002oO-2t; Tue, 10 Mar 2026 17:09:21 +0000 Received: by outflank-mailman (input) for mailman id 1250389; Tue, 10 Mar 2026 17:09:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a7-0001QA-AZ for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:19 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df095baa-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:17 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4838c15e3cbso119284305e9.3 for ; Tue, 10 Mar 2026 10:09:17 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df095baa-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162556; x=1773767356; 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; bh=B5Dqi7QE0P+NZcaNQ4Uuko5WRqJ3CVy0ngqKC6es19A=; b=nD53nNjwmA/lbqg4xCHcfXQrbVYhV5OqWNbt6K5tiI1lciiMxxVNBrIkCP5Qhq86PQ xz4tMjoen8Fch0yA33lS3NPN65kRYnV9yg3clqoaLAbFFqPIlmVGiQQqcDbvqhT7Istd k0BhuEdjc1LU86Mrk8wbxG2o/T7Pv9lQ/JxrOWEhAkUpriL4FUeHBvb4hIiy/7UTSr/e lPaknNQlGwefi3kCGFLNCmxex7eNv9JjD0WfLoSqdTcdaV8QgCWFwt8td8hDpdWOnpzq aOw0BpE63w7nGdb6HgzMli3QhOBPlgEZ8Vv11KWDW4oUUSX+2uWINTQXZa072E6HvqTY bakA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162556; x=1773767356; 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; bh=B5Dqi7QE0P+NZcaNQ4Uuko5WRqJ3CVy0ngqKC6es19A=; b=Qn53DSGpIPvAvjCejPB1+Jv3XqYdNUvDRHpRjGKzYMEZlcQJ/d6e1rh4XH7s+bf6jZ hbJWiXkBIb2cPyarJCFIh8eGkHq0sKx720vhgZHehRgSkI5CCtBHAaL50qSneNq/tpol XS/fxJmjuzqK0gCeecQvVL7KbLmDVfT1b/H2BEfAY1qLVuhXUD8Zg3h1Nnplrrk2nkAW cFsPBHg8rh9cvIxPNeLw3DIVAPq2kgYf4egY01OGiZWvfA/9to1L++X+2qGxiGvifF+z l1AYbK/SC9gZgdb/jPgYOhJvPtwU05ht+ar9HY2a9c/cooZCfSuKoP/UVlWX6TbuBU/+ LL8w== X-Gm-Message-State: AOJu0Yz4Wwi508SJb20q5EBZmfyziBBrYGZqgFDeWXTsMtfxIT7yY1Xg 9lg8i5NNTx52qjorVXHm4nMpW785edZivoFKZxnywjHHTMaoUK7Rk5XDFfwH+WOc X-Gm-Gg: ATEYQzztahiCkTpZWpKbUqqmkRVRxPJLPGQKl9LHil858Ki5j0MCFZ0QB0yE2gPFB61 WiM4pqRCDoTSdOgfP6VH/z+i6cbF78tBe2bRiO9WykGVHVM2vQt+cU/3hLX0aYdpRHr5vzoYpED ibcG6E37ROOwzTMxQDpiF6siJbbEwY+zlt9Nab/oL8NK2j6MOhJhWrYcCoq4hEPjhtwJtY/zLlm Y4ajGR1bm6Cu50+yPbDQTNini2LpsRxz9WC3EW442lX2XvGYe+jZlYrapOMe/kqbauIbPF6+FEJ Om/89IFMRK4W2P4ecmwGlXLb1loAzqS/M+vvfT/eRNu1IltQdrl1CEK+tUlZX4+CVFd1mLezETt axs3TCPL4DDSqMX+2A+TVMhQQj3vPGXAUJctB7TNtqsCkxcxj2esdcawoLXd3dQeer6IRP5Jhh3 +RdJ3WyTJIb7Gf3T3iT7R5JOnfJ5WobxMPVg8FxaQu+Uz2yn7sz6Duhrhq3YSyemsoXA== X-Received: by 2002:a05:600c:3f0b:b0:485:3bb5:92c5 with SMTP id 5b1f17b1804b1-4853bb598e8mr120108175e9.14.1773162556236; Tue, 10 Mar 2026 10:09:16 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 06/27] xen/riscv: implement make_cpus_node() Date: Tue, 10 Mar 2026 18:08:39 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain-build.c | 108 ++++++++++++++++++++++++++++++++++ 2 files changed, 109 insertions(+) diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index b1514f1514a2..6c6c58ed1ac0 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.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o obj-y += entry.o obj-y += guestcopy.o diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index 0ce903a911ae..633f02e42c5e 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -3,8 +3,10 @@ #include #include #include +#include #include +#include #include #include @@ -44,3 +46,109 @@ int __init construct_domain(struct domain *d, struct kernel_info *kinfo) return 0; } + +int __init make_cpus_node(const struct domain *d, void *fdt) +{ + int res; + const struct dt_device_node *cpus = dt_find_node_by_path("/cpus"); + unsigned int cpu; + u32 timebase_frequency; + bool frequency_valid; + uint32_t *next_phandle = &((struct domain *)d)->arch.next_phandle; + + 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 ( cpu = 0; cpu < d->max_vcpus; cpu++ ) + { + char buf[64]; + uint32_t reg = cpu_to_fdt32(cpu); + + snprintf(buf, sizeof(buf), "cpu@%u", cpu); + res = fdt_begin_node(fdt, buf); + if ( res ) + return res; + + res = fdt_property(fdt, "reg", ®, sizeof(reg)); + 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) + 1) >= sizeof(buf)); + snprintf(buf, sizeof(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", guest_isa_str); + if ( res ) + return res; + + res = fdt_property_string(fdt, "device_type", "cpu"); + if ( res ) + return res; + + 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", (*next_phandle)++); + 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; + } + + res = fdt_end_node(fdt); + + return res; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250390.1547905 (Exim 4.92) (envelope-from ) id 1w00a9-0002s0-Ia; Tue, 10 Mar 2026 17:09:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250390.1547905; Tue, 10 Mar 2026 17:09:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a9-0002rC-Ci; Tue, 10 Mar 2026 17:09:21 +0000 Received: by outflank-mailman (input) for mailman id 1250390; Tue, 10 Mar 2026 17:09:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a7-0001QA-Ml for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:19 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id df90eba6-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:18 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4853c1ca73aso20324425e9.2 for ; Tue, 10 Mar 2026 10:09:18 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:17 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: df90eba6-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162557; x=1773767357; 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; bh=WI2GmymuZn5ZjF6sh0Pndyef5xHCptAQOPGu6/MNHsM=; b=bZDa2dD6Q+j7MrXH/ZZyIvTY0Nnz7lWJ9KKfC4nl98XtkpGVoRyqi5c1knYFbNhUdk wMIDA0aruN5LBiTmanT8k24o7lLTdRdjLb362aVbt/IaJt3yFYvqLjBhaHw5o6qLKsoD sdckNLKjOCV+vQLf9UIqsC0KYRGzY2Sy8UY/6L6XKyDRyj6d/yzVb9dC/aV97OLX8enT go6lRkUqokO7gkWQmLYlXSTEGAljMDCzYXGCrogaPokidV5SOHNBWGWgwT5yU8Pg97/t 9fFjvU5IePrf6hDvFVcbtk+xrYy4/jl13QzrNxmO/6IwqOSfN8LkcD8pH/vtAu/7R7Xd R75A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162557; x=1773767357; 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; bh=WI2GmymuZn5ZjF6sh0Pndyef5xHCptAQOPGu6/MNHsM=; b=XqqG+LAPwWLReFRUWv0hZ91Vy3TnYzCtYMAmLDEIUqlEiEEp1xAOYXPDpQGdlqtCDb epJOYwEQ5Kg7+rPk+t0oCaV6mlhDtY6IaOjftEQmcn0RXhtevr32Fqx/77vo2D7P8ruB ebbdfp5koFDBV9TZkVKTWXrC7tUkp/0gQ1XYzcL4mzjr2Mhy23z4kOlJexUvEvWFNYRM nSYZNS/Fwn+ft0vkx9D/QwEprTUKjyoKwi19RsC0dv0Uh+lVEQhxNXxLXfIs5/PL+uiv DPYwVag7lOZjLu9eE68XnBxRhAboqRdo1KZBglbwHzMXCOw/Q2CHUcwlvKqrcT82NbYR CN7w== X-Gm-Message-State: AOJu0YwkZwVuisl22YCF+slQdADHQ3RUx3UfBqsC0+Cgy+dZJWLaNs3N L+p2TraKga5q5JR54xefxtrboSE+mZrtahNeAKcTEzKdC9HbJ9jKNnv03nlxLpxk X-Gm-Gg: ATEYQzwkJnMYF+6qhbSzJODuEM6p/TxoBlrso8hmuNNGRy7upSYqvURl6Pc2DwrL1Ru IiaBqAGHr0KdSOEJ9Gk4ij2H6UJQyE1ygt55FM4GWiiTMMFgYhSzuH/FtYfLf0H5Xq2Af7Nvdtz +nMSP/c4Ac/kWD0D2TT3ElNvcp8PbKQ6asBYzks/M7JVxZu9VJHpV3Eh13L2LOanxuhXDcfnpxU l4PJHWPZhAtHVj+fSYcDWvbFYJfw0ctdqFvXHR58EQJ2oSTjdyWObdEOUH1+q6VrUwaRs0YyJVp 4Bcsb84SDGlpg8jwh8TI+71c2MUMcwMbNaukO711KYHRWGY4hbRusHjsqdQkZGrCaBtnkCUuBWb hTZjA+wrTZlR4MjUGH1uBPnBkaffC+CLGxcHgTuTkRzOZoscrc1JRRzCoKvg+4SdDmsKex2pSMQ 2zTsDsmC8hCmG/CJjxxIfH/8YeWR5W8r/d/prLfvpwrmFF4LE2AX+G/ckvhJxEA7UP1g== X-Received: by 2002:a05:600d:f:b0:485:345b:ccb1 with SMTP id 5b1f17b1804b1-485345bce86mr165965485e9.27.1773162557447; Tue, 10 Mar 2026 10:09:17 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 07/27] xen/riscv: implement make_timer_node() Date: Tue, 10 Mar 2026 18:08:40 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The make_timer_node() function is implemented to return 0, as RISC-V does not require the creation of a timer node. Signed-off-by: Oleksii Kurochko --- 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 633f02e42c5e..ae26faed09ed 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include @@ -152,3 +153,10 @@ int __init make_cpus_node(const struct domain *d, void *fdt) return res; } + +int __init make_timer_node(const struct kernel_info *kinfo) +{ + /* There is no need for timer node for RISC-V. */ + + return 0; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250391.1547910 (Exim 4.92) (envelope-from ) id 1w00aA-00032U-7x; Tue, 10 Mar 2026 17:09:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250391.1547910; Tue, 10 Mar 2026 17:09:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aA-000300-2G; Tue, 10 Mar 2026 17:09:22 +0000 Received: by outflank-mailman (input) for mailman id 1250391; Tue, 10 Mar 2026 17:09:20 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a8-0001Q4-Af for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:20 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e0890da2-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:19 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4853510b4f3so41185485e9.0 for ; Tue, 10 Mar 2026 10:09:19 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:18 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e0890da2-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162559; x=1773767359; 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; bh=nhr/YFfUk73fJbCvGKZFP0P0mCzExALFTOhZRjG1AeU=; b=ZFB8LKD577w5idg3ca7RIHLuzqpe2Fu47tUN54QV/8l+a3/zswFtxLLB+X9pw7D70S 4kPdDAGUl6qYCf5lOijzS+sXCPjMYio140HCkdMOVoKkyqJEcw1RMxCMITOvpG2e1gzs cwUNyOq5UYaRnjNHZ3WoQObixO/L4pezOHHPrDwAXPid03gO07yqG2xbH9T0O4ILYRpi PQP8E0dPXzQWRKGnHlW4h5ZpE8Z1aCSCQZ7q8X/3k0DRioJ999zuS6GEnWT3K31Xy6Ou 4qPG+l80rJj3hTxPuNkINB0e4FcAX6KiimVdnHlRaAtWgjAYu/eaWV3OQD+phCoEH+Qq /qEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162559; x=1773767359; 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; bh=nhr/YFfUk73fJbCvGKZFP0P0mCzExALFTOhZRjG1AeU=; b=SRtqobsqq4ggtMGsYnwTFEI2sP8OFabO9IMc6UiJo6/jFQRdVU55dXNL/7MB7c/uGt 7+d0rwV9JmL2DzOKvSIDomaTX4TXH6YKYJ8g+j2C6+Z3Ic9Q491spU1LKJun6BgcW7tr FsObgh5fr3ICfXBnLISHrZqsKWw9Kq5Mb7ce+5xb9VXO3MhawB4PzHrE0wIfdrGa6ng2 qu1JM52ea+B2LWbd8iKGw+zWZ+QcwTBcylMW2LKIJcawKssnSPPP0qBFvNKvIsK/oRWt tlwSzdl7DI4LndijfgqwmVgH/UPqfvoaqSWm3PpZSNf3WTk3VST8WJLxWHihATjLsBOi oyzQ== X-Gm-Message-State: AOJu0YwMN1IR8Rx3cs4SkliJPpq5z794UqsCOn0s8gWNaDYCJq1+n/Jx oSavh44WKPWBsJz3b/q5/etEdXNTz5CRk2KsC80GPXIh8XY/hk0slgElaioABJhJ X-Gm-Gg: ATEYQzwTJdFqqZUyxY1CpAZP+OOj2DXV3O1qXW2Ot8qr+T9ZNgk0UK19WrhkMMspw7g cNn+99Ilp5ax1cJFrtG8CHw+0a3JPSCKutyMv9ZUT/A1ab1oEVZ6aQZpQCLhvhErSWepTX4U1xF hlr2MpxddjImo0IcjjXok0agmijOJt14lOtwwZw8dFXED/5Fsm6B7AuKe7c8j7lsyLfkZnrk19G xwUj8exfS6GHzzZxSaBp99rIbsu9fiT1aS+ff8yYrBbwE9fqB/j+hE+WCNUGYizp9lJWnkg+gCg uLdlaOjLLAh+C/KQfT6NoIdFl/AgZIyFytAH2aXwQxqKjEG/eIc/WzUGaJA3NZ+NE9LfhNlfK5c QizKS9i4BxSGIOOfcOhlOYa7zXzh1K/WZyiT6rUotXzNv6CwBhzdR4zAiB440MUkWO9MzeEot5Z VEiLUzp+/8vQzw2TWLkZI9q9U8EmgXqx5MzlcakbESidRD3OmKxJOYp60ubdWDA+UU7w== X-Received: by 2002:a05:600c:1e2a:b0:47e:e57d:404 with SMTP id 5b1f17b1804b1-485269582efmr253670135e9.16.1773162558685; Tue, 10 Mar 2026 10:09:18 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 08/27] xen/riscv: implement make_arch_nodes() Date: Tue, 10 Mar 2026 18:08:41 +0100 Message-ID: <9c97b4bc6fb8a5e556c38cfe7e34de0eb3cbbbb0.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit No RISC-V-specific nodes need to be created at the moment, so make_arch_nodes() is implemented to simply return 0. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/dom0less-build.c | 11 +++++++++++ 2 files changed, 12 insertions(+) create mode 100644 xen/arch/riscv/dom0less-build.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 6c6c58ed1ac0..fb04cc5a56b2 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -1,5 +1,6 @@ obj-y += aplic.o obj-y += cpufeature.o +obj-y += dom0less-build.o obj-y += domain.o obj-y += domain-build.o obj-$(CONFIG_EARLY_PRINTK) += early_printk.o diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c new file mode 100644 index 000000000000..10863cffc96b --- /dev/null +++ b/xen/arch/riscv/dom0less-build.c @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include + +int __init make_arch_nodes(struct kernel_info *kinfo) +{ + /* No RISC-V specific nodes need to be made, at the moment. */ + + return 0; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250392.1547915 (Exim 4.92) (envelope-from ) id 1w00aA-00039u-Qn; Tue, 10 Mar 2026 17:09:22 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250392.1547915; Tue, 10 Mar 2026 17:09:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aA-00038q-J7; Tue, 10 Mar 2026 17:09:22 +0000 Received: by outflank-mailman (input) for mailman id 1250392; Tue, 10 Mar 2026 17:09:21 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00a9-0001Q4-Gb for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:21 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e11448e7-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:20 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-485392de558so15013885e9.1 for ; Tue, 10 Mar 2026 10:09:20 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:19 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e11448e7-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162560; x=1773767360; 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; bh=/l+2sfUlHi+3W7tldQuhyj7te+foi9fBjieEM15WHyQ=; b=ZAK36sIlsfOk4hW9Bb7BChtrCIV28Sid3O9vbFB3gC2iVx0qWb4/GSNl2bKt0eRBAq WT47fAnrqMH3QdgU3oMD9LVUPDJAx39Z4nV2R5xe2HqbLW6+2g5Gl4fWGHtxYIAmYtFG grN3QsJ3opTlj7q36I+/NVNyF/vaR95dpMoIbgF/tmc3QsQ47hM5KSAwB0MJVUC+tTWm bbOmaevwCoZQD+RT95OzP8Ccqk4KHVbgQO4PCbfXHZfRPCPWZTJnPCVDiPZPGLfg4pqU XXKzS1tPIhHN6anLHFRhd/HMhsyH3w590akpfFIWeBomVc9FJ3gKGN/L5h9AyjyGRXN+ SUWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162560; x=1773767360; 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; bh=/l+2sfUlHi+3W7tldQuhyj7te+foi9fBjieEM15WHyQ=; b=XKrojN2ypzF0CG/eTPhVLlAMXbivQV0F8uKHcVzHTvZgUT0nbkuG1Y0gQ/G8t3+t0E VT+LaVGSgnGxNLW01iABuo7CIKD3bFkWSOm1y1PRv9uohe+rn8qQ8MXcvcChQSU0UaWS depDiXgqqc86H0o8RpCLWy/ADwvQ0CKyz8Z6hdxkS4b2gZ2uBPNCyTdrp/Swd60lAexv uVuvf1pz1k6cGbXalTSZyAAjfsKrbrd4M0QQTMqP98i1WtV5GGmORyfoMq2z2uR4XiZ/ LiHRTR75m0FSfXB6k1ehiZvvRAoZY1n54H8KUmowczoF9rIONma2+uZvgtmj0f6ckBZh wBbA== X-Gm-Message-State: AOJu0YzTnMQDZVUdZWLK0ma9ROSNvBFt6tDjsrulScKtgDepbuwjllfm cQjNrg6m52mWXMmlv8axx/tJoXUY3o97aB5e/sDcz9KsEYrOcjFGVtnMxQbtxkUP X-Gm-Gg: ATEYQzyJ/l2cTlL3dlpl/2BuKkuDIU0UUrG8TA0Gkx7cV0CoAWAxra9UqROpoa6NbnY kk5WeRG5UOsxULuEjJfULUzyVD1RMoSe0bj0mkbvVsWQjZ7Q3j2yR2nDamdYkRRCNfziyUe+uNm IjqZRp0vkddZXdszNG90SBPt3Ns7BfajrTaBbgq13+pzPdw6dkHQh6y14xEqDPQocleaIPfF0sL k9kGf/cm9nmcPsgaPMT+1ZP/VVb5hHg7DaOVwjCp1h0x4fO4aN2v5HpRQJqgtTx1BqwN4A6oSlN ioKESIzbXEcyOrJpjgLPUrXE1bWmILUtqu3a561diqKpzWqKtFj06q7jFoaZZ4i2fkh96QGa7cy QERmB+gZrPGILQ71/IEc2D6zBAXzBGfvdm34U9Fzsd4pBbOyfO48zpoN0NYLdBjXZS8uGo7p3Ug C1cNCxbxeaR2GEcDE2mImWFphpEpjF7qpJpFUT4t78UiGKayoM1tPGB4z3gpHWpT7K2ac7OA== X-Received: by 2002:a05:600c:1f0f:b0:483:703e:4ad5 with SMTP id 5b1f17b1804b1-48526967cd9mr255015965e9.22.1773162559897; Tue, 10 Mar 2026 10:09:19 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 09/27] xen/riscv: implement make_intc_domU_node() Date: Tue, 10 Mar 2026 18:08:42 +0100 Message-ID: <7a7f1430090eaf50cc3bff25e894c13404bffad5.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 intc_hw_ops. Extend struct intc_hw_operations with a make_dom_dt_node callback and expose the required interfaces in the interrupt controller header, allowing individual interrupt controller drivers to populate DomU DT nodes as needed. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/dom0less-build.c | 9 +++++++++ xen/arch/riscv/include/asm/intc.h | 10 ++++++++-- xen/arch/riscv/intc.c | 8 ++++++++ 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index 10863cffc96b..312c5d7d4979 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -3,6 +3,15 @@ #include #include +#include + +int __init make_intc_domU_node(struct kernel_info *kinfo) +{ + intc_make_domu_dt_node(kinfo); + + return 0; +} + int __init make_arch_nodes(struct kernel_info *kinfo) { /* No RISC-V specific nodes need to be made, at the moment. */ diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index ecdc8a5e6577..8300d71d472f 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -8,14 +8,14 @@ #ifndef ASM__RISCV__INTERRUPT_CONTOLLER_H #define ASM__RISCV__INTERRUPT_CONTOLLER_H -struct dt_device_node; - enum intc_version { INTC_APLIC, }; struct cpu_user_regs; +struct dt_device_node; struct irq_desc; +struct kernel_info; struct intc_info { enum intc_version hw_version; @@ -41,6 +41,10 @@ struct intc_hw_operations { /* handle external interrupt */ void (*handle_interrupt)(struct cpu_user_regs *regs); + + /* Create interrupt controller node for domain */ + int (*make_dom_dt_node)(const struct kernel_info *kinfo, + const struct dt_device_node *intc); }; void intc_preinit(void); @@ -53,4 +57,6 @@ void intc_route_irq_to_xen(struct irq_desc *desc, unsigned int priority); void intc_handle_external_irqs(struct cpu_user_regs *regs); +int intc_make_domu_dt_node(const struct kernel_info *kinfo); + #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */ diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index ea317aea5ad8..a6f8c30f4771 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -67,3 +67,11 @@ 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 intc_make_domu_dt_node(const struct kernel_info *kinfo) +{ + if ( intc_hw_ops && intc_hw_ops->make_dom_dt_node ) + return intc_hw_ops->make_dom_dt_node(kinfo, intc_hw_ops->info->node); + + return -ENOSYS; +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250393.1547933 (Exim 4.92) (envelope-from ) id 1w00aC-0003cY-Dh; Tue, 10 Mar 2026 17:09:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250393.1547933; Tue, 10 Mar 2026 17:09:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aC-0003aq-1Z; Tue, 10 Mar 2026 17:09:24 +0000 Received: by outflank-mailman (input) for mailman id 1250393; Tue, 10 Mar 2026 17:09:22 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aA-0001Q4-OC for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:22 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e1d78722-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:22 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-482f454be5bso1342825e9.0 for ; Tue, 10 Mar 2026 10:09:22 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:20 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e1d78722-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162561; x=1773767361; 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; bh=/11lx8z8RjsX/40S39HnVeCzAcwg/3pYH5ySRoyED38=; b=IDEcmZtXox9yFNvqonGXK66GEwZ8hOgVJ9ldECm3HF4HnrcKAgCD9bQmbt3NkejLKz sdFTs8eZiSibYdmsemV+yd3LbUtbquVV0uhXKNNr5IzLy96CiONXz0RhV1mwz9vX2AIF DhAlhQRlKXlxBCX3L5BZxIUZuRKor3XEdBcdluvtcCMMQZRUKRirgzBX0WyXogatKA6d O7bl9YlQnGHvDSfQk9QPAyJzHi42BjFUZyUodtQjDhGDftXTMRr4zer/tM3cizD6Ic3B EAvnKxaWS9KD5L5E9/7556H+gqzMUraDv7bxFDeI4EIffLzLJHEvKYowo/j/MiTe41LC UT7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162561; x=1773767361; 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; bh=/11lx8z8RjsX/40S39HnVeCzAcwg/3pYH5ySRoyED38=; b=CRWfW/Tcqf/4O5n2z+vdGd1EkJFoj8ETzqQbFzza6bwNM3aqLmviiGzY2RYWqfZkkf GLWGV9trwy0j8leNeGBog4UN9k40FWxssMLCPbQmcmW+5Q3TLuVIxTgvYwJGlgHylpPZ QZZEE7qUEFiX0qpZ+G7PgsADv5brc5deqM0N8dpS6TUU1QQnkCuDhsLDei36/9z9aibr /FgH0hpGtMaBGsL+GwAz8EQNJ89NzCodqSuDq48zM4dmvjZLXm/NeOFZ2r+T4lnOAtXy n91DNHgaYVrlH+hjlJA/+pPgIQgfcm8Nr74a40LH60XJr2pCh9c6rpcRF1mH3q62MCE3 29FA== X-Gm-Message-State: AOJu0YxUvUYQEm0bOtzuO/LFtNmbjerprvL+cciWT2P8z/7gH9UcvFuE TUa8Qi85CIKk7wEZmux4iQlyB+ZdYRuwzCjJn+i+qeWEDIKi4LQ2bu/N6qd9kSJ6 X-Gm-Gg: ATEYQzywI2CmxGHr/bRg7Gg9HwC2JEqO8WXqrWQxtdbq+5iJNW69pAd9Cnwh8XShtxj 3tXTXLtiBaDYNLDIbepkJUirpMOnL8DRhb+c21uGU8Syed0l+hDnIcrFoMAq9HlADFSa+umo7/B E2XozrkjJb+cMLIbAV4WS1f39b4+T+n4JdJ8EY1a2Tq4LtYi2PFvRpy948/gmI03DJFirkzTXW3 A+biSlWWcxlUcgdtOZQva7QIhZAZyQDziR2M5wXRJfDFlvEp+/5tTB0UPUA57GDNsSRQUYeqFW0 nPAW9inxFGfgJT1YwOLyrSJg04TwrUSAgACVu2lX/15j+tgkvVNGOcpClbE+Ot525Ttbo+qt+l4 o0sPn01xr9j6IrgCbSt/RgSur75MY8L4qadCvenwoEH6vDWJeYhW6cIFIbj5gtv6CfzF5Tno4YB W563V8QHfqyO4eEYGe/oTXnw4TILIoiJs5ZPkRW0uX6piMjZ91ewfdmlD3lr58OpNPvC46qQ== X-Received: by 2002:a05:600c:468b:b0:47e:e981:78b4 with SMTP id 5b1f17b1804b1-48541a00b6fmr69385575e9.12.1773162561036; Tue, 10 Mar 2026 10:09:21 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 10/27] xen/riscv: generate IMSIC DT node for guest domains Date: Tue, 10 Mar 2026 18:08:43 +0100 Message-ID: <8154eae081d14da89f27bad581270cc5bba6ccfc.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Guests using the IMSIC interrupt controller require a corresponding Device Tree description. Add support for generating an IMSIC node when building the guest DT. Keep a reference to the host IMSIC DT node and reuse its compatible property while constructing the guest-visible node. The generated node contains guest-specific information such as the MMIO region sized for the number of vCPUs and the interrupts-extended property referencing per-vCPU interrupt controllers. This allows guests to discover and use the IMSIC interrupt controller. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/imsic.c | 113 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/imsic.h | 7 ++ 2 files changed, 120 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index a4460576f620..0956b187705f 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -13,8 +13,11 @@ #include #include #include +#include #include +#include #include +#include #include #include #include @@ -329,6 +332,8 @@ int __init imsic_init(const struct dt_device_node *node) struct imsic_mmios *mmios; struct imsic_msi *msi = NULL; + imsic_cfg.host_node = node; + /* Parse IMSIC node */ rc = imsic_parse_node(node, &nr_parent_irqs, &nr_mmios); /* @@ -487,3 +492,111 @@ int __init imsic_init(const struct dt_device_node *node) return rc; } + +static int __init imsic_make_reg_property(struct domain *d, void *fdt) +{ + __be32 regs[4]; + + regs[0] = cpu_to_be32(imsic_cfg.base_addr >> 32); + regs[1] = cpu_to_be32(imsic_cfg.base_addr); + regs[2] = cpu_to_be32((IMSIC_MMIO_PAGE_SZ * d->max_vcpus) >> 32); + regs[3] = cpu_to_be32(IMSIC_MMIO_PAGE_SZ * d->max_vcpus); + + return fdt_property(fdt, "reg", regs, sizeof(regs)); +} + +static int __init imsic_set_interrupt_extended_prop(struct domain *d, + void *fdt) +{ + uint32_t len = 0, pos = 0, cpu, phandle; + uint32_t *irq_ext; + char buf[64]; + int res; + + irq_ext = xvzalloc_array(uint32_t, d->max_vcpus * 2); + if ( !irq_ext ) + return -ENOMEM; + + for ( cpu = 0; cpu < d->max_vcpus; cpu++ ) + { + snprintf(buf, sizeof(buf), "/cpus/cpu@%u/interrupt-controller", cpu); + phandle = fdt_get_phandle(fdt, fdt_path_offset(fdt, buf)); + + if ( phandle <= 0 ) + return phandle; + + irq_ext[pos++] = cpu_to_be32(phandle); + len += sizeof(uint32_t); + irq_ext[pos++] = cpu_to_be32(IRQ_S_EXT); + len += sizeof(uint32_t); + } + + res = fdt_property(fdt, "interrupts-extended", irq_ext, len); + + XVFREE(irq_ext); + + return res; +} + +int __init imsic_make_dt_node(const struct kernel_info *kinfo) +{ + uint32_t len; + const void *data = NULL; + int res = 0; + void *fdt = kinfo->fdt; + const struct dt_device_node *host_imsic_node = imsic_cfg.host_node; + uint32_t *next_phandle = &kinfo->bd.d->arch.next_phandle; + + res = fdt_begin_node(fdt, host_imsic_node->full_name); + if ( res ) + return res; + + data = dt_get_property(host_imsic_node, "compatible", &len); + if ( !data ) + { + printk(XENLOG_ERR "%s: Can't find 'compatible' property\n", + host_imsic_node->full_name); + + return -ENOENT; + } + + res = fdt_property(fdt, "compatible", data, len); + if ( res ) + return res; + + res = imsic_make_reg_property(kinfo->bd.d, fdt); + if ( res ) + return res; + + res = imsic_set_interrupt_extended_prop(kinfo->bd.d, fdt); + if ( res ) + return res; + + res = fdt_property_u32(fdt, "riscv,num-ids", imsic_cfg.nr_ids); + 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; + + imsic_cfg.phandle = (*next_phandle)++; + + res = fdt_property_cell(fdt, "phandle", imsic_cfg.phandle); + if ( res ) + return res; + + return fdt_end_node(fdt); +} diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/asm/imsic.h index c6c59215df20..a63d56fbd5d9 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -57,11 +57,16 @@ struct imsic_config { /* MSI */ const struct imsic_msi *msi; + /* DT node of IMSIC */ + const struct dt_device_node *host_node; + /* Lock to protect access to IMSIC's stuff */ spinlock_t lock; }; struct dt_device_node; +struct kernel_info; + int imsic_init(const struct dt_device_node *node); const struct imsic_config *imsic_get_config(void); @@ -71,4 +76,6 @@ void imsic_irq_disable(unsigned int hwirq); void imsic_ids_local_delivery(bool enable); +int imsic_make_dt_node(const struct kernel_info *kinfo); + #endif /* ASM_RISCV_IMSIC_H */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250395.1547943 (Exim 4.92) (envelope-from ) id 1w00aE-000446-0y; Tue, 10 Mar 2026 17:09:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250395.1547943; Tue, 10 Mar 2026 17:09:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aD-000434-TE; Tue, 10 Mar 2026 17:09:25 +0000 Received: by outflank-mailman (input) for mailman id 1250395; Tue, 10 Mar 2026 17:09:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aC-0001QA-TF for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:24 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e2848d12-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:23 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4838c15e3cbso119285105e9.3 for ; Tue, 10 Mar 2026 10:09:23 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:21 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e2848d12-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162562; x=1773767362; 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; bh=rURaUWIfuvEbzAV4qRTHMl8D0NEHhwV33eVW20ka7rs=; b=C5U75V08T2eumDwAH2EDZUc5bj3oRmeew2Y8x38i48ivsuCKn21B/0v96m3Mtxhgws MCKzwHFbQb96EHhpiDRYl/4ALkWdwIMjH5jL1aUgO2NNyv23eVZiIH5rm60hjyiSaDcd vbEOyhdmaoQweN0RmZv7kavQNUJon81I6Rg8nK1ptDZieyfL6UO4JMfNO9PG79Xhyihn nTxbssDYlIlv5NtEVlwF536WO210wCvkX1jPhB8iJ+Gyb71vSkXsRJO+aavadaxxYNut hNujCpr+4nuOYZtQPYu4E9K8NeOS5gxArN5NwTCesrqzlNV50llGtBKHszC8tbHfGkCI RTww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162562; x=1773767362; 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; bh=rURaUWIfuvEbzAV4qRTHMl8D0NEHhwV33eVW20ka7rs=; b=ogNp1xnCpeGsInlGTEbrwYdrUQttKeLwssmxAZlRQrh8R1UfZkwgqkA8lyaVJ12L9r krdkSFpZJVYYM20LupnK9w5Z2muJs+m+IofcAJxb+Q0udpTiBTSkYdpj/tK45Cu5KHm5 Uoq1MFzGk+tYipRchxSFy9g3DLUa9KuFFfbTxMnTLfoXIIN2d2RNMsU/l+otlyUZVBk4 crv7zzBoTNp4DG8m2Cj7Q8kLJ1IO0Wa0eJS2AgIfnI9GbHoHxbr1M5l6ar8mmeOY5VSQ ARrLn1V3kvdf+x0N1Xto1/uDml93xsYECdjARImCMBM1dcSZLJLkZpASXpAeEkQvdXxC xMNg== X-Gm-Message-State: AOJu0Yy1aklCbKiRzRZgZChYZKnI5q5cSLjM0l6dXuIJd3/RAzdaUPLv KzYvax1YkSVo2GjZw6PX5v6q+rJ3uJTtiXbmFbxZIQcvPy16SOBBeBgpY8ckx2U+ X-Gm-Gg: ATEYQzy7aiaeyT+65hUHg4QmGtwL8aLajPl5mGHpPgZFKj7xkuip5ucbQiV+9ZtueUb Lld2ztB+pHEFf/idDJOVXNWCHp3pztjw8bg/vNJDuiUaEyE9vyOctYWos6sb5DBnlAQZ917xAgw HLQR+uA4NAAanQjFMAplHEvmjjvP2FUel70poEX4rSiXz5vrgZRSYeh+Kle+/dRhVskAmtNL1j1 n0ou2lGXIobBnBeDSFPRB3qFcoFbbRE/Q9b+m0qqVhkXed6jehzDrTJv3/EYXaKqtuyPOVXNApu ICI4JXidB20ubwCsXI0JuEiHKf5uY1wWfba7e+gBHkWuOZhU5k96DZBCPkeb8QYBZXuY9g18fa/ ThoIwqsvzxn11ZtpA38dZZu/MYfivJjgHF+1/Gt/kn/cNrMA3I/NndNHj3+6BY5+MUJW1Ouu05L 5M4Z5aTRa2/xzHz9YYn6lM/hQmMSPKHmITkFP8aYovovclJ3aRQkyShoaIW1Tz/+ghQRpkBA== X-Received: by 2002:a05:600c:528c:b0:485:3d3e:167b with SMTP id 5b1f17b1804b1-4853d3e20d2mr103614505e9.5.1773162562331; Tue, 10 Mar 2026 10:09:22 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 11/27] xen/riscv: create APLIC DT node for guest domains Date: Tue, 10 Mar 2026 18:08:44 +0100 Message-ID: <462b5f7dbe4e5084a35fb869b59327c6c92d1fbf.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Guests require a Device Tree description of the interrupt controller topology. Add support for creating an APLIC node when building the guest DT. The node is derived from the host DT and linked to the guest IMSIC via the msi-parent property, allowing guests to discover and use the APLIC interrupt controller. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/aplic.c | 82 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 739e8dab3498..e139946a05a0 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -12,8 +12,10 @@ #include #include #include +#include #include #include +#include #include #include #include @@ -295,6 +297,85 @@ static void cf_check aplic_set_irq_type(struct irq_desc *desc, spin_unlock(&aplic.lock); } +static int __init cf_check aplic_make_dom_dt_node( + const struct kernel_info *kinfo, + const struct dt_device_node *aplic_node) +{ + uint32_t len; + const __be32 *regs; + const void *data = NULL; + int res = 0; + void *fdt = kinfo->fdt; + + res = imsic_make_dt_node(kinfo); + if ( res ) + return res; + + res = fdt_begin_node(fdt, aplic_node->full_name); + if (res) + return res; + + data = dt_get_property(aplic_node, "#interrupt-cells", &len); + if ( !data ) + { + printk("%s: Can't find '#interrupt-cells' property\n", + aplic_node->full_name); + return -FDT_ERR_XEN(ENOENT); + } + + res = fdt_property(fdt, "#interrupt-cells", data, len); + if ( res ) + return res; + + regs = dt_get_property(aplic_node, "reg", &len); + if ( !regs ) + { + printk("%s: Can't find 'reg' property\n", aplic_node->full_name); + return -FDT_ERR_XEN(ENOENT); + } + + res = fdt_property(fdt, "reg", regs, len); + if ( res ) + return res; + + data = dt_get_property(aplic_node, "riscv,num-sources", &len); + if ( !data ) + { + printk("%s: Can't find 'riscv,num-sources' property\n", + aplic_node->full_name); + return -FDT_ERR_XEN(ENOENT); + } + + res = fdt_property(fdt, "riscv,num-sources", data, len); + if ( res ) + return res; + + res = fdt_property(fdt, "interrupt-controller", NULL, 0); + if ( res ) + return res; + + data = dt_get_property(aplic_node, "compatible", &len); + if ( !data ) + { + printk("%s: Can't find 'compatible' property\n", aplic_node->full_name); + return -FDT_ERR_XEN(ENOENT); + } + + res = fdt_property(fdt, "compatible", data, len); + if ( res ) + return res; + + res = fdt_property_cell(fdt, "msi-parent", aplic.imsic_cfg->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 hw_irq_controller aplic_xen_irq_type = { .typename = "aplic", .startup = aplic_irq_startup, @@ -310,6 +391,7 @@ static const struct intc_hw_operations aplic_ops = { .host_irq_type = &aplic_xen_irq_type, .handle_interrupt = aplic_handle_interrupt, .set_irq_type = aplic_set_irq_type, + .make_dom_dt_node = aplic_make_dom_dt_node, }; static int cf_check aplic_irq_xlate(const uint32_t *intspec, -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250396.1547949 (Exim 4.92) (envelope-from ) id 1w00aE-0004Av-Tz; Tue, 10 Mar 2026 17:09:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250396.1547949; Tue, 10 Mar 2026 17:09:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aE-00049J-EI; Tue, 10 Mar 2026 17:09:26 +0000 Received: by outflank-mailman (input) for mailman id 1250396; Tue, 10 Mar 2026 17:09:25 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aD-0001Q4-7P for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:25 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e34d6159-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:24 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so23996415e9.2 for ; Tue, 10 Mar 2026 10:09:24 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:23 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e34d6159-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162564; x=1773767364; 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; bh=wxAqjKoB8nUBBhDPx/zv6ewxjJzbCrTIbqMHHIHK+cg=; b=Ehou3/FICijR4b2STcMbbQHoyIuCgt5IClHYUlmXUtuc9ZWkk89Vi1gHiNRVMHACRF UPuNFuy3xWozX6NR7JRspEGGh2YTrLHRpVvwiKJKclNN4nJrcdkMrND6dq5PyuILsmBu 6clqBW7+ZiETMV4HM22coVwOM5OcwuJWGZTbXgg2/D4aZM702KuvEV1gdcOvJS6KyGqk SdpSECJz7g45Ck8GRaBruPjkMTr4zeWt9MnE6lh/MO9Q73Xx3c2PJl9S1ZiUWDwr9IA7 x3d+NFy9QTwEWBcNZsPECFkTVO5pNQDMHrMowvq8i2PT2WHW/8z0Lnyos1Fbp4SGy1Et WZuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162564; x=1773767364; 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; bh=wxAqjKoB8nUBBhDPx/zv6ewxjJzbCrTIbqMHHIHK+cg=; b=P+IJwQT7h+GDoAwzZwXtUtLRuqpp2Dvnyd0NC7pcJCysPskiG/OUvHQQoeoWrz6jwf swzXtPSTPAo/5ZBsAechG+Ib10c8QbABYVTuGOsi8IYyhFrpDwmOcMv/yjdzWLCMZ4DW iSo5Xjy2AQFrJHMiTLVNkG6GN5gte3lirVp1lgUDlCvdqKGVN3aPFqHm9S+9Epe2mZYG scR/6qcDb7xeV+jXPxvY55PmxLHfIdE4ZldgqDdm+GGgxvMC40EvZ98WGbbnokHjYkcD iQmq7Y19DN9mV//6NvQ0+GJPNn2oLCP27/X7/nexalP9wTmiF4v+ADQtHr7XpWIV8rX5 cBfA== X-Gm-Message-State: AOJu0Yz9QAfMqrm3EvGSHHg1Wvoz31yBcokwTGf4LYAD9OiTcnJ6fqK6 sQpHRRAYCVFGqOSyAfXQRrAKbPusrp5Lf3fptuYaMxwuP6gs6B8lB4HBZSEpRaLf X-Gm-Gg: ATEYQzytiRDAs2892gWiPFygQzTVqkEm4aWuxcSScA44nKakzJyeK2l7N5LDayETNHg 79sKKdUH9oytk/+RvZTELIv8md1o/eV+c3t3usDE1Bw68pj9/rnZa8C39sFB2B08cNMXYQ1GE6d j8uJkFjPl+z6cH6bjiZyE0em80O+rekQxLSkUB9G6PIweeCPDD+C8pn5KMZT5dRBj6Xo2PralwW wG2DHkRLygk7LuTj4OK0NHOy1v74FUGyPK2lRhrgIs9Vt5UjgxcvhOR5Vy01B8p+TFGxPEf6kxs 7ILSdpVUOXBXkMEFUChPrcJxp1N/JIipuXTNWBBY6CxwECUwp48thNmhF//5Wv3T4sRcF669aN8 oIzByQRhGNDpaHmSKPU5Y7K+30t/T3eKJoFBcFhf7YFD34/zoBvEEAblVArBhxaCJnhHDAAwnlK xxTGdcNQure+zEqTFMSNNFjO4GM64P9rnPdBeVkVXJh5SZAhjNRjpE7vWIjAr2nIIw24hWpQ== X-Received: by 2002:a05:600c:4fc3:b0:485:3692:e906 with SMTP id 5b1f17b1804b1-4853692eacemr162644025e9.13.1773162563586; Tue, 10 Mar 2026 10:09:23 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 12/27] xen/riscv: introduce aia_init() and aia_available() Date: Tue, 10 Mar 2026 18:08:45 +0100 Message-ID: <74f15b1db86139b36b721ef9d12b998fe4f0f348.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit aia_init() is going to contain all the stuff related to AIA initialization. At the moment, it is just Check if SSAIA extension is available and if yes set is_aia_available to true. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/aia.c | 25 +++++++++++++++++++++++++ xen/arch/riscv/include/asm/aia.h | 10 ++++++++++ xen/arch/riscv/intc.c | 3 +++ 4 files changed, 39 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 fb04cc5a56b2..d772b42386c0 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 += dom0less-build.o diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c new file mode 100644 index 000000000000..5e3f190e8e2c --- /dev/null +++ b/xen/arch/riscv/aia.c @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#include +#include +#include +#include + +#include + +static bool __ro_after_init is_aia_available; + +bool aia_available(void) +{ + return is_aia_available; +} + +int __init aia_init(void) +{ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + return -ENODEV; + + is_aia_available = true; + + return 0; +} diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h new file mode 100644 index 000000000000..039607faf685 --- /dev/null +++ b/xen/arch/riscv/include/asm/aia.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ + +#ifndef ASM__RISCV__AIA_H +#define ASM__RISCV__AIA_H + +bool aia_available(void); + +int aia_init(void); + +#endif /* ASM__RISCV__ACPI_H */ diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index a6f8c30f4771..c9f12651fda1 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -8,6 +8,7 @@ #include #include +#include #include static const struct intc_hw_operations *__ro_after_init intc_hw_ops; @@ -27,6 +28,8 @@ void __init intc_preinit(void) void __init intc_init(void) { + aia_init(); + if ( intc_hw_ops->init() ) panic("Failed to initialize the interrupt controller drivers\n"); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250398.1547957 (Exim 4.92) (envelope-from ) id 1w00aG-0004XE-Ci; Tue, 10 Mar 2026 17:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250398.1547957; Tue, 10 Mar 2026 17:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aG-0004W0-35; Tue, 10 Mar 2026 17:09:28 +0000 Received: by outflank-mailman (input) for mailman id 1250398; Tue, 10 Mar 2026 17:09:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aE-0001Q4-Ae for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:26 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e415608c-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:25 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso107423915e9.1 for ; Tue, 10 Mar 2026 10:09:25 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:24 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e415608c-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162565; x=1773767365; 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; bh=0nBjOwOkgmV3ao9VaFguk8mStyy/ASZb20xOrZJU8TM=; b=QvpJqg/cMsyPNKSuJbij6IINo/Kl94JU5kX2IhQPKpO7cshbYtN5OdAQO4lmMn+OXf GaBaD9zT+46iZ8gQxAJ2MUeeE3+GcAqyRY50ZK1HauL2jCPIuZnsBbm+CHCKIJCRwgVs I+7WygMG+89wXoEC02keUhO9DuzpvA3+7VSsHUDFUQVoQKF9rz0A9ETPTP/QYudI/4JZ tRqIJtxIfDxhwYbF5r1x5soRo0Y96sBr3roACC/XmBAA0gXw7fj/lpQbC+VW8+9+V7Dq 8kX0tKl7za/w8HqGHwKuSFtOHvcCMLxbRt4ydPAkrZ45ImS0n639yIoIfoXs+4v4XwYe 0hcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162565; x=1773767365; 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; bh=0nBjOwOkgmV3ao9VaFguk8mStyy/ASZb20xOrZJU8TM=; b=JQzc6+NZU4eU2Tdmgdo668Os1n9nhJ8H2IW2YG6G2+q/rQNcEc9PkgvX98ZB/9HAbU G9crJsRS6/BuHCQyrr+T0135QuPwxstmzcw5vHg6f/5RpdZYAN34dTfo5O6ZgPaLXBPH B2vwSRxjzuXJ3pENAruZAN5rNj02RDuBE3XxCsYjjx1TLAzdpoUQ+7MumTw4rpqlzDV8 e4VdeFUM4ec1db6W2ejQ33F46krlJUHYH4V4NgFkfk7tbpJVQldr/ao+pUPFSL9NG3Kx TwRzswFQJ15HdwRfUF5SjAoedImNsfE+W/LQj1/TH7gjP39yGo4zXzlr7lpaQ0Odx5Pq rNOw== X-Gm-Message-State: AOJu0YwVwg1PrEcoll3jkzhlXYh5w5DfP2Wcm/5hKpQvQX2FtmyPBhWI RFyzD7h8c7mhI8XbmMIsN6nyDNurx/95QI5AxAU2yi24rLHtyTAE54eDwf2ddFrA X-Gm-Gg: ATEYQzx3RWRxtzB2wofTcjnq0zqD3TcB9O6kKIE/ZTcGScoduZnQA1dBZf+PO07U1oN Egrs9QcAuHxF3pfufIejb6PDWyF3xCuJyEKWxXSz/YPyFo7HMUSHtsnrcACj05VEFQNRTc4Lk5k HJhP+UKGZmXSFkDbFcknyHZgCyS/y1t342l4A0PexlVpJWO1Ubpe5Hfv6Y/QqJ9LE29M8No+uXW Zwsw61M8fX116cxxLG/dovb/XqKmplZfxJEK188TcoXGOhN157cajq5/9g/sekgeVCwjo35c3eP TLjLQPmDozrFGnLRkxb89LcJPBjqZ0iu6esDXlDHMRk6aM90kMUGsAzhaSV66+bbvxEEIjad3DO iq+ZxLeKHbcMhD07mhpPlzuL7Oc2KlP3w/yEcLHunkUR9NRHMKTBXW5dscyCanDQSOklFIPJD3N 224pcQ/GEK01tiv4sYHxuy7MHNdLxRNKBzGeaI2VEAN+hxnqkaK9hLCXX9WcSvMczAX28Z+pSbA Xtb X-Received: by 2002:a05:600c:4ed1:b0:485:3a03:ced1 with SMTP id 5b1f17b1804b1-4853a03d7eamr152562415e9.28.1773162564912; Tue, 10 Mar 2026 10:09:24 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 13/27] xen/riscv: add basic VGEIN management for AIA guests Date: Tue, 10 Mar 2026 18:08:46 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- xen/arch/riscv/aia.c | 112 ++++++++++++++++++++++++++++++- xen/arch/riscv/include/asm/aia.h | 18 +++++ 2 files changed, 129 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c index 5e3f190e8e2c..7bd66d1e37c6 100644 --- a/xen/arch/riscv/aia.c +++ b/xen/arch/riscv/aia.c @@ -1,11 +1,24 @@ /* SPDX-License-Identifier: GPL-2.0-only */ +#include #include #include #include +#include +#include #include +#include +#include #include +#include +#include + +/* + * Bitmap for each physical cpus to detect which VS (guest) + * interrupt file id was used. + */ +DEFINE_PER_CPU(struct vgein_bmp, vgein_bmp); static bool __ro_after_init is_aia_available; @@ -14,12 +27,109 @@ bool aia_available(void) return is_aia_available; } +int __init vgein_init(unsigned int cpu) +{ + struct vgein_bmp *vgein = &per_cpu(vgein_bmp, cpu); + + csr_write(CSR_HGEIE, -1UL); + vgein->geilen = flsl(csr_read(CSR_HGEIE)); + csr_write(CSR_HGEIE, 0); + if ( vgein->geilen ) + vgein->geilen--; + + BUG_ON(!vgein->geilen); + + printk("cpu%d.geilen=%d\n", cpu, vgein->geilen); + + if ( !vgein->bmp ) + { + vgein->bmp = xvzalloc_array(unsigned long, BITS_TO_LONGS(vgein->geilen)); + if ( !vgein->bmp ) + return -ENOMEM; + } + + spin_lock_init(&vgein->lock); + + return 0; +} + int __init aia_init(void) { + int rc = 0; + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) return -ENODEV; + if ( (rc = vgein_init(0)) ) + return rc; + is_aia_available = true; - return 0; + return rc; +} + +unsigned int vgein_assign(struct vcpu *v) +{ + unsigned int vgein_id; + + struct vgein_bmp *vgein_bmp = &per_cpu(vgein_bmp, v->processor); + unsigned long *bmp = vgein_bmp->bmp; + unsigned long flags; + + spin_lock_irqsave(&vgein_bmp->lock, flags); + vgein_id = bitmap_weight(bmp, vgein_bmp->geilen); + + /* + * All vCPU guest interrupt files are used and we don't support a case + * when number of vCPU on 1 pCPU is bigger then geilen. + */ + ASSERT(vgein_id < vgein_bmp->geilen); + + bitmap_set(bmp, vgein_id, 1); + spin_unlock_irqrestore(&vgein_bmp->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 priviliged spec: + * 8.2.1 Hypervisor Status Register (hstatus) in RISC-V priviliged 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. + */ + vgein_id++; + +#ifdef VGEIN_DEBUG + printk("%s: %pv: vgein_id(%u), xen_cpu%d_bmp=%#lx\n", + __func__, v, vgein_id, v->processor, *bmp); +#endif + + vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN; + vcpu_guest_cpu_user_regs(v)->hstatus |= + MASK_INSR(vgein_id, HSTATUS_VGEIN); + + return vgein_id; +} + +void vgein_release(struct vcpu *v, unsigned int vgen_id) +{ + unsigned long flags; + + struct vgein_bmp *vgein_bmp = &per_cpu(vgein_bmp, v->processor); + + spin_lock_irqsave(&vgein_bmp->lock, flags); + bitmap_clear(vgein_bmp->bmp, vgen_id - 1, 1); + spin_unlock_irqrestore(&vgein_bmp->lock, flags); + +#ifdef VGEIN_DEBUG + printk("%s: vgein_id(%u), xen_cpu%d_bmp=%#lx\n", + __func__, vgen_id, v->processor, *vgein_bmp->bmp); +#endif + + vcpu_guest_cpu_user_regs(v)->hstatus &= ~HSTATUS_VGEIN; } diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/aia.h index 039607faf685..c2717504cbea 100644 --- a/xen/arch/riscv/include/asm/aia.h +++ b/xen/arch/riscv/include/asm/aia.h @@ -3,8 +3,26 @@ #ifndef ASM__RISCV__AIA_H #define ASM__RISCV__AIA_H +#include +#include + +struct vcpu; + +struct vgein_bmp { + unsigned long *bmp; + spinlock_t lock; + struct vcpu *owners[BITS_PER_LONG]; + unsigned int geilen; +}; + +DECLARE_PER_CPU(struct vgein_bmp, vgein_bmp); + bool aia_available(void); int aia_init(void); +int vgein_init(unsigned int cpu); +unsigned int vgein_assign(struct vcpu *v); +void vgein_release(struct vcpu *v, unsigned int vgen_id); + #endif /* ASM__RISCV__ACPI_H */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:09:30 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:09:30 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250402.1547967 (Exim 4.92) (envelope-from ) id 1w00aI-0004tn-Gb; Tue, 10 Mar 2026 17:09:30 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250402.1547967; Tue, 10 Mar 2026 17:09:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aI-0004s7-0P; Tue, 10 Mar 2026 17:09:30 +0000 Received: by outflank-mailman (input) for mailman id 1250402; Tue, 10 Mar 2026 17:09:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aG-0001Q4-SQ for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:28 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e57a1eca-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:28 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so23997145e9.2 for ; Tue, 10 Mar 2026 10:09:28 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:26 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e57a1eca-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162567; x=1773767367; 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; bh=RQUbsjGqpyJLaNssEnVD+AE4bLsCeyAg53aMfThr8Pc=; b=aJE7+K0BbJsUvk1B1xX1Istj/kPDTotAGS6MqmEnPDM6IyYxmrq/qCAcSFCpIZLU5V aeBci1Zrh92xcvw/OLEJeNnmM3vfcnhZ1JSC2Lux2tW9oFF/e0lgOvQzkRRZvdSGQ4u/ c+9PwLGbmYhYlhSAIsWUgir0fn3ElCUfZSimndynWdCAYyR00WQ1PxO49yo75zfxb5k6 H1rrtaJ5cyX+FC+jAPSlTrocRvfU8szxjqXptUzwd91yKBtUVfm+vG25ysFWl3GMoBYr hYqE/SLV30xgNlDyUSKZ4azsa8QwtdQSb0cAG1O8J3P05g2+QpbBcakLVmcLSfoswHOR 2HPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162567; x=1773767367; 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; bh=RQUbsjGqpyJLaNssEnVD+AE4bLsCeyAg53aMfThr8Pc=; b=ksmbL+54lHEsE0iM6G4Jb5laaA6XXFJXJGtyd2SqnfUoJJVG9dbjXqTX1zO8DxVpBh l7XGTLIGu4HWHV8NlyEGrv6w7xKxoBKkp8dFtl+sps4NL5vKHpDb0o9itohjT5vQ1bNv b9Jk89keU56BZkHzNwGVXfadzEzs/6XvP86RgJPlI/BT9i+mkHilMNv2RtGmDbTVdqRH boB4+zgdIE0DCtJHocN9rl1atWnFVfketcY5VDsbAZmvlxRqkX8BAcSRwnqXiXzvolXw 7xUsDZjTjKZ7YxKrpOzTeEbiJW00Wk2P+LR0yjoPQMBPk3ousICy967ycAGI1iwev18H 9nDw== X-Gm-Message-State: AOJu0YygSFzMmw78j0HpEomguvy+0rzSEAuo8T/lc35ecv/u2uopoKQM IjbCyPdGZqOvfs6TymaqbFUqJSSX1KQbhGG3OO2llIJ+dNF2vKUCjBvleYQdDLV8 X-Gm-Gg: ATEYQzxuCZ/WCOLt8P7p2vtxyZLhi5CXJw1750jTpnF742lxp8+ytoRopOhdIzk6ksZ fREDoxqLx2UCLYywB/PkNhyWEDyRZcxsBkE8TaejjYGnbsjXfVzudojOBwckoKO1i6DbQt3BTdV ej4E9+tMY6sxELwknHQFaZDwqG0R81Yo/F0+JCUsxpImtmuRff68pv7rlpjvDDolZoIVC7JCCmz KWfBwmMeDOuVzdzA87TENu/2zEeVp0yz3kOaqhlPmpWTXtjiBwMWxqmKjzNNpgKbUhuw8Snd0KH 1jZ7z2IUF3zQYNkLPZUpvxfvII2MiwOV13SAwGfGgQJwcVhZjU0FF4/cLFI7H4nH0Ajq32SvxDJ jC/yP4p3m3uiOhZvK+ez9e4POxktRkdvKdObkS43JvX8QW5UqZl/S6pv5PAfuZLVyrdvY/3pOuf 2FD73PPZiqAQ2b3upWgj5HboPBV/nPkR0y8Fp1f0vJd8rf47kg3/Zrt/SX8aMRqzG2sw== X-Received: by 2002:a05:600c:8b86:b0:485:3473:d4a1 with SMTP id 5b1f17b1804b1-4853473d6dcmr167697795e9.34.1773162567282; Tue, 10 Mar 2026 10:09:27 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 15/27] xen/riscv: add very early virtual APLIC (vAPLIC) initialization support Date: Tue, 10 Mar 2026 18:08:48 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. 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 vcpu_vaplic_init() and init vintc_ops->vcpu_init() with it. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 11 ++--- xen/arch/riscv/include/asm/domain.h | 2 + xen/arch/riscv/include/asm/intc.h | 14 ++++++ xen/arch/riscv/include/asm/vaplic.h | 36 ++++++++++++++ xen/arch/riscv/intc.c | 1 + xen/arch/riscv/vaplic.c | 74 +++++++++++++++++++++++++++++ 7 files changed, 131 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 d772b42386c0..b9941a230e03 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -24,6 +24,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 515735b32e30..560b21b16ffb 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -154,14 +155,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/domain.h b/xen/arch/riscv/include/asm/domain.h index bdb1ffd748c9..21a3e6876f36 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -98,6 +98,8 @@ struct arch_domain { struct paging_domain paging; #endif + struct vintc *vintc; + /* Next unused device tree phandle number */ uint32_t next_phandle; }; diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 8300d71d472f..c5a869db8bc5 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -16,6 +16,7 @@ struct cpu_user_regs; struct dt_device_node; struct irq_desc; struct kernel_info; +struct vcpu; struct intc_info { enum intc_version hw_version; @@ -47,6 +48,19 @@ struct intc_hw_operations { const struct dt_device_node *intc); }; +struct vintc_ops { + /* Initialize some vINTC-related stuff for a vCPU */ + int (*vcpu_init)(struct vcpu *vcpu); + + /* Check if a register is virtual interrupt controller MMIO */ + int (*is_access)(const struct vcpu *vcpu, const unsigned long addr); +}; + +struct vintc { + const struct intc_info *info; + const struct vintc_ops *ops; +}; + void intc_preinit(void); void register_intc_ops(const struct intc_hw_operations *ops); diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/asm/vaplic.h new file mode 100644 index 000000000000..7684f3490829 --- /dev/null +++ b/xen/arch/riscv/include/asm/vaplic.h @@ -0,0 +1,36 @@ +/* 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 +#include + +#include + +struct domain; + +#define to_vaplic(v) container_of(v, struct vaplic, base) + +struct vaplic_regs { + uint32_t domaincfg; + uint32_t smsiaddrcfg; + uint32_t smsiaddrcfgh; +}; + +struct vaplic { + struct vintc base; + 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/intc.c b/xen/arch/riscv/intc.c index c9f12651fda1..ff7a76accaca 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c new file mode 100644 index 000000000000..9b105de7ed7d --- /dev/null +++ b/xen/arch/riscv/vaplic.c @@ -0,0 +1,74 @@ +/* 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 +#include +#include + +#include +#include +#include +#include + +#include "aplic-priv.h" + +static int __init cf_check vcpu_vaplic_init(struct vcpu *v) +{ + int rc = 0; + + rc = vcpu_imsic_init(v); + if ( rc ) + return rc; + + imsic_set_guest_file_id(v, vgein_assign(v)); + + return rc; +} + +static const struct vintc_ops vaplic_ops = { + .vcpu_init = vcpu_vaplic_init, +}; + +static struct vintc * __init vaplic_alloc(void) +{ + struct vaplic *v = NULL; + + v = xvzalloc(struct vaplic); + if ( !v ) + return NULL; + + return &v->base; +} + +int __init domain_vaplic_init(struct domain *d) +{ + int ret = 0; + + d->arch.vintc = vaplic_alloc(); + if ( !d->arch.vintc ) + { + ret = -ENOMEM; + goto fail; + } + + d->arch.vintc->ops = &vaplic_ops; + to_vaplic(d->arch.vintc)->regs.domaincfg = + APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM; + + fail: + return ret; +} + +void __init domain_vaplic_deinit(struct domain *d) +{ + struct vaplic *vaplic = to_vaplic(d->arch.vintc); + + XVFREE(vaplic); +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250501.1547996 (Exim 4.92) (envelope-from ) id 1w00i0-0001vb-7H; Tue, 10 Mar 2026 17:17:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250501.1547996; Tue, 10 Mar 2026 17: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 ) id 1w00i0-0001uX-0w; Tue, 10 Mar 2026 17:17:28 +0000 Received: by outflank-mailman (input) for mailman id 1250501; Tue, 10 Mar 2026 17:17:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aV-0001Q4-In for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:43 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ed38e779-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:41 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-48534237460so31768675e9.3 for ; Tue, 10 Mar 2026 10:09:41 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ed38e779-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162580; x=1773767380; 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; bh=gZrHMXcRWo15HX+QGWY61zocvRFQ0LXPM9EZCmb5d0c=; b=FwS7z0Nm9EgEbonSVIKWjMgm4BUaj8RUpf8dvX17wwr6S8MmVBtlAjJoR+M5bFZPxW dikOJ9z3oaR1YNsmBpQrLuqx9xRAaO/5KY2BTpGSzIhaWL8+87b+9QnPJ+l94OmHc0mf JIkdBpd0t2/u/YfLJzkKfo2PrXy2HKn4aAVtSy12gyR7k3RUCivrz79uoMG6kXXk+frD Wy+SFmJBiMmGE3yOcqZ5GcS4u7jtU4jvROs5GXF07rSczuFVVe8ITAeSSnA9Gtozizck 6XkqDWCner9H7oo6V/QclVzekowKuTZVtotHnCUGaCTX1sEzJjiP/BTkzDdQKCfo9GQu aoBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162580; x=1773767380; 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; bh=gZrHMXcRWo15HX+QGWY61zocvRFQ0LXPM9EZCmb5d0c=; b=I1bZtatwmHcRwNtOzbcAh/E9Cm7UQHqEEP/OiFauhahg5ZEB9TR7IF6fxA8WfAjsM0 G/f1AqFl4gQlSfsywYIX7OUZxvscCyRkuJlgI4INQ3sn053Gbe7rDjk9QHqEXcyf/mzx fh0jTt7i0/k3G/ZKTxlKcrHbnmdAE+Cc0F1VP37BdxS1B4nGLsOkyBXCuk8gaFhg8EK7 san/gGm/haqvYGFMR1slEl5gBtNxISII5Zlr/GDqFYUQcnWUmUUqrqz2/lr2WSLsMui5 8hpEZ630J2KP8coAYjaxyb1x1T9+pF1T/nkBDNZsKAdb2S7eKrQdg03hR0h7h6h27KHv PTJQ== X-Gm-Message-State: AOJu0YzVl90Gk9g+tz7VxvCdb95og1W4haxecFvFzu1a/9Cd2gVAqyyG qdov0YCbeLfzx4AseFBPCn5Rv0ImuhZ2YV+AyPx2GA7xJeyV0RAi/HygAlVHvV0K X-Gm-Gg: ATEYQzwvyz85Nau+hCKLzatfP/r4SHsu1p8ITCe43rUabu6a5aIvLI0u0XJnKDqKLjn aPDMOK84p9izsOG0+5n4O4DNflpLlG2H8Vbab1nI72oaTQSKImuJnEZMZ1dJ9q/ZPEg+wB6Cwzl Cu206zBfobaHlO+hadqS98YQn9v/OhgGiXbcnX+1RV3cG+KytV+RQqhYd2ZDDugPFCsR4NflcgJ g/8F5855s9PPybCtsbzYENCaPkHU9l4Q80zW+wDdBOTqiQWCldeAB3nJPWRu5FSdapVOMofwdS2 X6mWkj5uth+64PsBeZWNCmFmwgCJa4Zz9WDC1bZ/3o6t9E8gM0gjDH+Tgswb0pfRcwLvsixuVfx Gciq3lxShi/LVlTOLPkpZoVBc4Em7KomQCOQdM5v3qVqcMTO561ihyfWObrDOvrfscvNEeAxs3U yEClq7MVrYO0Llx9uUK+BTJKQe/x5rvS0NYyHxKrDRrBs56WMRgAlXaOKWe/+cqU9Pcw== X-Received: by 2002:a05:600c:4ecd:b0:485:3c2d:d02b with SMTP id 5b1f17b1804b1-4853c2dd2e5mr118363285e9.22.1773162580213; Tue, 10 Mar 2026 10:09:40 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 26/27] xen/riscv: provide init_vuart() Date: Tue, 10 Mar 2026 18:08:59 +0100 Message-ID: <71483b96126964a7cfcb24253cb04379a9f662c1.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- 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 180d653e5780..43c8bdc52300 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -6,6 +6,14 @@ #include +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.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250486.1547980 (Exim 4.92) (envelope-from ) id 1w00hw-0001d9-MC; Tue, 10 Mar 2026 17:17:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250486.1547980; Tue, 10 Mar 2026 17: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 ) id 1w00hw-0001d2-JM; Tue, 10 Mar 2026 17:17:24 +0000 Received: by outflank-mailman (input) for mailman id 1250486; Tue, 10 Mar 2026 17:17:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aG-0001QA-Ut for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:28 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e4b15c46-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:26 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4852f8ac7e9so42815305e9.1 for ; Tue, 10 Mar 2026 10:09:26 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:25 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e4b15c46-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162566; x=1773767366; 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; bh=wy9UOUys3UP8UGf9H+CdlAJHj+mjN4CkBQ2c+J9DOhU=; b=eNkH5XxLel6q25erVdnuA/b+IoXyWg4q/2/UpEnkdLsPiMKy/4uu2H4blxnTOeL43u mvi9c5fS6pjKKLKoe0XSZOP2XkWZajy6qsALKX6kRK239LJgbNrv2B1iPwCOHdE7ublF ERA6JBJlI9lDkC5G3LpJwJkopK1TSvZlV52/HKToY9qbB9hoKHnK1uM1vc20MS8iMLo6 5C/wve2g6jX4zePoPLBfUafAjkobFF8FRsB4ALCyqDA+VvmhIfx50V+hrw+eprrVcIhq 1zZ6wQOWPwSWMqDsTFOZN4fLNkC6oztnWRPWpKX8OZ8hX1T0GLI4Y8UJa6GKT+28Oc/S L0Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162566; x=1773767366; 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; bh=wy9UOUys3UP8UGf9H+CdlAJHj+mjN4CkBQ2c+J9DOhU=; b=rP8cj9b6+erkrcpdNfhnebUHne8iCqDDYTPebTNEgXIr6ux/5Rp4i3MuLhax1VvblO VNqB1pYEGX35DSyGaIaZYswv+X7Est5Gvq31fSxzx8Z2I70MDDlG9vs3Mg2QalCiPfgV SLSLyVsVkVaG+i1DUaqG6DN2dnIlIxprpLxaSSr3MJwRfql/n38eCBq59LEPvHmcZZr4 2PWIwfDXi0QhjQjxovTSgAAuY5Z7Nqa4mkyWYDd8zWx2jlTI+yyuWuhd1RxyGjcXiqPx ae1kNGDUuP4DOUsU8O+lHtMNs7iwhWXCH6gK/+MHcaU4J4mw+yJHg/+1v7XEvA6kYj+d tG8g== X-Gm-Message-State: AOJu0YwImh8gYk4S0YGZUZflFVnvkN+QrS+dIp71TiOG9Yx/u8GHiw+Z QfI7M5WJbHt/9YqM/4AFAPuR70t2/TTL6wQmYtBLEI6/diQCzTQFMzTpUs+dRqLd X-Gm-Gg: ATEYQzw+hsVIW+JvFrgEPa5FNJbhVxpwf2mJyqWdudyAArZjP/Kj0lFee4OPv61EX6E MjHmx4znsP/aTt8ipilMoPHMW3nbhFxTNEaNguLdVeQAS4DruLv6yE0hlFu54sALeyvRKns0r5C 4qpKfoC0u5JrNH94skM6yEccPHLC3ehV+ybPX4hZ1mcBA2MZOW/b85L9eRpyq0X1xAo1VRCIoc8 JJ9O/VFEc97tdRSWslN+B3/VSicV/7yJtcUN7UNzlgsntRVe/RieElmG9zvqUzZg8ibLcKHi/LK dd4LkFxhhviS4Dp96NEDFiMfIUsTkfmwvraln2nH8QchyUz5YWB8O1xXyT+yq9gMMRrOpUR7xmr F9sPkLqYkBDhGSLlh0mjPpca6Lr4vcE6yht5RMXMQ9sEcSoBqfwItUeYs1BF3VN+sglHHVNLjEb TNWk2ZeY11fpiBjaRMwPZLggi/ojPz8SHpgpjlZpRqaR+i3gvVPNaLta90smBxT/KqIQ== X-Received: by 2002:a05:600c:3b89:b0:485:3f1c:d8a4 with SMTP id 5b1f17b1804b1-4853f1cda4cmr106634755e9.9.1773162566012; Tue, 10 Mar 2026 10:09:26 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 14/27] xen/riscv: introduce per-vCPU IMSIC state Date: Tue, 10 Mar 2026 18:08:47 +0100 Message-ID: <8196fa8f000e384af697a44cb3d50ece966e82a7.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 helpers to retrieve and update the guest interrupt file identifier. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/imsic.c | 42 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/domain.h | 2 ++ xen/arch/riscv/include/asm/imsic.h | 17 ++++++++++++ 3 files changed, 61 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 0956b187705f..bbadbdf352a1 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -59,6 +59,29 @@ do { \ csr_clear(CSR_SIREG, v); \ } while (0) +unsigned int vcpu_guest_file_id(const struct vcpu *v) +{ + struct imsic_state *imsic_state = v->arch.imsic_state; + unsigned long flags; + unsigned int vsfile_id; + + read_lock_irqsave(&imsic_state->vsfile_lock, flags); + vsfile_id = imsic_state->guest_file_id; + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); + + return vsfile_id; +} + +void imsic_set_guest_file_id(const struct vcpu *v, unsigned int guest_file_id) +{ + struct imsic_state *imsic_state = v->arch.imsic_state; + unsigned long flags; + + write_lock_irqsave(&imsic_state->vsfile_lock, flags); + imsic_state->guest_file_id = guest_file_id; + write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); +} + void __init imsic_ids_local_delivery(bool enable) { if ( enable ) @@ -315,6 +338,25 @@ static int imsic_parse_node(const struct dt_device_node *node, return 0; } +int __init vcpu_imsic_init(struct vcpu *v) +{ + struct imsic_state *imsic_state; + + /* Allocate IMSIC context */ + imsic_state = xvzalloc(struct imsic_state); + if ( !imsic_state ) + return -ENOMEM; + + v->arch.imsic_state = imsic_state; + + /* Setup IMSIC context */ + rwlock_init(&imsic_state->vsfile_lock); + + imsic_state->guest_file_id = imsic_state->vsfile_pcpu = NR_CPUS; + + return 0; +} + /* * 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 506365f199c7..bdb1ffd748c9 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -52,6 +52,8 @@ struct arch_vcpu { struct vtimer vtimer; + struct imsic_state *imsic_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 a63d56fbd5d9..13a563dce066 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 #include #include #include @@ -64,8 +65,20 @@ struct imsic_config { spinlock_t lock; }; +struct imsic_state { + /* IMSIC VS-file */ + rwlock_t vsfile_lock; + unsigned int guest_file_id; + /* + * (vsfile_pcpu >= 0) => h/w IMSIC VS-file + * (vsfile_pcpu == NR_CPUS) => s/w IMSIC SW-file + */ + unsigned long vsfile_pcpu; +}; + struct dt_device_node; struct kernel_info; +struct vcpu; int imsic_init(const struct dt_device_node *node); @@ -78,4 +91,8 @@ void imsic_ids_local_delivery(bool enable); int imsic_make_dt_node(const struct kernel_info *kinfo); +int vcpu_imsic_init(struct vcpu *v); +unsigned int vcpu_guest_file_id(const struct vcpu *v); +void imsic_set_guest_file_id(const struct vcpu *v, unsigned int guest_file_id); + #endif /* ASM_RISCV_IMSIC_H */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250499.1547989 (Exim 4.92) (envelope-from ) id 1w00hz-0001sp-Tj; Tue, 10 Mar 2026 17:17:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250499.1547989; Tue, 10 Mar 2026 17:17:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00hz-0001sf-Qa; Tue, 10 Mar 2026 17:17:27 +0000 Received: by outflank-mailman (input) for mailman id 1250499; Tue, 10 Mar 2026 17:17:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aJ-0001QA-9q for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:31 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e635720d-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:29 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48539d21b76so20305135e9.1 for ; Tue, 10 Mar 2026 10:09:29 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:28 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e635720d-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162569; x=1773767369; 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; bh=1QzhisNeEOl5GG/axHTaY1VrOGJ87S7KPahT63K4FL0=; b=QRnE/YbuQxS5aJsCV1+VHm3IC/UsB81S8opwqaYiMnl3i672gr5xq3uwdlCOzBOaHR HzEAe7scP69C2TpkeCRcpAwSZkj2qlea0fdUReJARKMwivOnu1QPubvlHIws9SBO7A6m ll1TAX5d7wHh7VA+ihPtpsJOoO7ud3BQmaBlobhUeC41cKAYhltGByFIqS0kanz0VDTM vW9Dbwg5JO3mhYWWenjb1bbRdCy4euHUot+8tzidopxZ0388Q9GwK0i0Hw6qhcRiKUTN yvp/9CK063/uTOaxKU4+FA550XTu7mHht1eVgRN552Ck+k45H+jx3WNOLEy1CzagNCdr kyTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162569; x=1773767369; 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; bh=1QzhisNeEOl5GG/axHTaY1VrOGJ87S7KPahT63K4FL0=; b=uHhY1BSJcVMoHtrsi6XEY0VoUuRNenbTaAz593RRwsg+H3Znb8gj8Qlw1uGQJV5yU6 mPvpcA1DWm0OamktGw99yTDsWtx5yyk6HUyfLBJtNlZZONmyAmD29hEktzpXJIBrsERi ARAoxDF24ZvQBVBrhd6ofWQ+NA5Qz087di6RS/QuFJhVg8frSkk9W2F/0Mq0PJo0Sm1f K5BnYBie7IofBFf6BlEliWGhAwfQeujqss7KmgeGr0vye6ebT5Y5d9xSKCFcR7jI54Vh OOOJyCTUaYbEOmSZGsS3dLqnmS3MJrXd59g+gsk+K/BUYqhytwNs+/H5Vh1JNdORSkTc r6kQ== X-Gm-Message-State: AOJu0YwUjtVCh53HhmnBe9NzB1H9p2gVx2NwP+o51D3ElOjTAINqB1c5 IpAInqJZFqLx2WdPOaDTqEgBEXotpNTs81gxm8t1Z3WbgIYXh/atgEVKv2nOOgou X-Gm-Gg: ATEYQzybt1JojwHVHE5NESSNSDv6kr2dKw59Ge+Lq6sbMAIzu4k5URkk1oNlt/TZ+gs D1Bl4RW/qAEs4d+sb1PHA7rnh4NC9rRRhmYafay0oYuUrNZlQ+7pBB9VATgUSM5N5EOkN9Yy9J8 VWwVzH4EnbDexnUj8gvkhlA2GNw0L3kfSgIoZET5VDPnmCIx0EAIpp4JozMClpXdmk6IRK89abc 3FpiJppI5shIkgUpwW+KcJ/SFa1Ci60UJS+lcv9GeWCHtT2LIkD/hdzgKZ752qYUr74xgTrPsaq JLYHVNuF+7PuDoRpaidzhj00mqEyM0o8/KsZZ76+KxnpMVPz9hlzHrPWWNYXRGxs5HzDazY+YbJ 7ZbHdfpGRu7aBJN8zfzPEMKZ05JwmSf3NtVKTiS1cGSvZ79n2o4RRXaPF0zUhRnm4qXiJf+FP6r xg/0E8AmWEBX8oSYH/HeprzQwBKVJsZ+KGCuzz/LcgteOiZIstg6sfEEEsgf5EcSmSPA== X-Received: by 2002:a05:600c:8719:b0:485:39d1:b4ca with SMTP id 5b1f17b1804b1-48539d1bb25mr151543855e9.9.1773162568498; Tue, 10 Mar 2026 10:09:28 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 16/27] xen/riscv: implement IRQ mapping for device passthrough Date: Tue, 10 Mar 2026 18:08:49 +0100 Message-ID: <10654a6c38fa929b5fdf6f214badfe4f60fe78d4.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add initial support for assigning device interrupts to domains in dom0less configurations. IRQs described in the device tree are retrieved and authorized for the target domain. Interrupts that are not connected to the primary interrupt controller (at the momemnt, I haven't seen the platform with secondary interrupt controller) are ignored, and IRQs already assigned to another domain are rejected to prevent sharing. Signed-off-by: Oleksii Kurochko --- For better undesrstanding how auth_irq_bmp[] is going to be used it is also introduced two extra patches which are going after this. They aren't really needed now as this code will be used when guest will be ran, but it improves understanding and it in general can go with this patch series. --- --- xen/arch/riscv/include/asm/aplic.h | 2 + xen/arch/riscv/include/asm/intc.h | 12 +++ xen/arch/riscv/include/asm/setup.h | 17 ++++ xen/arch/riscv/intc.c | 8 ++ xen/arch/riscv/vaplic.c | 124 ++++++++++++++++++++++++++++- 5 files changed, 162 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h index b0724fe6f360..55cd4a128de7 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -15,6 +15,8 @@ #include +#define APLIC_NUM_REGS 32 + #define APLIC_DOMAINCFG_IE BIT(8, U) #define APLIC_DOMAINCFG_DM BIT(2, U) diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index c5a869db8bc5..76d2fd09cb8b 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -16,6 +16,7 @@ struct cpu_user_regs; struct dt_device_node; struct irq_desc; struct kernel_info; +struct rangeset; struct vcpu; struct intc_info { @@ -54,11 +55,22 @@ struct vintc_ops { /* Check if a register is virtual interrupt controller MMIO */ int (*is_access)(const struct vcpu *vcpu, const unsigned long addr); + + /* + * Retrieves the interrupts configuration from a device tree node and maps + * those interrupts to the target domain. + */ + int (*map_device_irqs_to_domain)(struct domain *d, + struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges); }; struct vintc { const struct intc_info *info; const struct vintc_ops *ops; + + void *private; }; void intc_preinit(void); diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h index 2215894cfbb1..1c23043f409f 100644 --- a/xen/arch/riscv/include/asm/setup.h +++ b/xen/arch/riscv/include/asm/setup.h @@ -5,6 +5,10 @@ #include +struct domain; +struct dt_device_node; +struct rangeset; + #define max_init_domid (0) void setup_mm(void); @@ -13,6 +17,19 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len); void init_csr_masks(void); +/* TODO: move somewhere to common header? */ +/* + * Retrieves the interrupts configuration from a device tree node and maps + * those interrupts to the target domain. + * + * Returns: + * < 0 error + * 0 success + */ +int map_device_irqs_to_domain(struct domain *d, struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges); + #endif /* ASM__RISCV__SETUP_H */ /* diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index ff7a76accaca..a91dbc5e997c 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -79,3 +79,11 @@ int __init intc_make_domu_dt_node(const struct kernel_info *kinfo) return -ENOSYS; } + +int map_device_irqs_to_domain(struct domain *d, struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges) +{ + return d->arch.vintc->ops->map_device_irqs_to_domain(d, dev, need_mapping, + irq_ranges); +} diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 9b105de7ed7d..0c69f087cf4d 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -9,6 +9,7 @@ */ #include +#include #include #include @@ -19,6 +20,113 @@ #include "aplic-priv.h" +struct vaplic_priv { + /* Contains a legal interrupts for a domain */ + uint32_t auth_irq_bmp[APLIC_NUM_REGS]; +}; + +static bool is_irq_shared_among_domains(const struct domain *d, + const unsigned int irq_num) +{ + struct domain *tmp; + unsigned int reg_num = irq_num / APLIC_NUM_REGS; + unsigned int bit_pos = irq_num % APLIC_NUM_REGS; + + for_each_domain ( tmp ) + { + uint32_t *auth_irq_bmp; + + if ( tmp == d ) + continue; + + auth_irq_bmp = tmp->arch.vintc->private; + + if ( auth_irq_bmp[reg_num] & BIT(bit_pos, U) ) + { + printk("%s: irq%d is shared between %pd and %pd\n", __func__, + irq_num, tmp, d); + + return true; + } + } + + return false; +} + +int vaplic_map_device_irqs_to_domain(struct domain *d, + struct dt_device_node *dev, + bool need_mapping, + struct rangeset *irq_ranges) +{ + unsigned int i, nirq; + int res, irq; + struct dt_raw_irq rirq; + uint32_t *auth_irq_bmp = d->arch.vintc->private; + unsigned int reg_num; + + nirq = dt_number_of_irq(dev); + + /* Give permission and map IRQs */ + for ( i = 0; i < nirq; i++ ) + { + 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 IRQ that have no physical meaning + * ie: IRQ 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 = irq_permit_access(d, irq); + if ( res ) + { + printk(XENLOG_ERR "Unable to permit to %pd access to IRQ %u\n", d, + irq); + return res; + } + + reg_num = irq / APLIC_NUM_REGS; + + if ( is_irq_shared_among_domains(d, irq) ) + { + printk("%s: Shared IRQ isn't supported\n", __func__); + return -EINVAL; + } + + auth_irq_bmp[reg_num] |= BIT(irq % APLIC_NUM_REGS, U); + + dt_dprintk(" - IRQ: %u\n", irq); + + if ( irq_ranges ) + { + res = rangeset_add_singleton(irq_ranges, irq); + if ( res ) + return res; + } + } + + return 0; +} + static int __init cf_check vcpu_vaplic_init(struct vcpu *v) { int rc = 0; @@ -34,6 +142,7 @@ static int __init cf_check vcpu_vaplic_init(struct vcpu *v) static const struct vintc_ops vaplic_ops = { .vcpu_init = vcpu_vaplic_init, + .map_device_irqs_to_domain = vaplic_map_device_irqs_to_domain, }; static struct vintc * __init vaplic_alloc(void) @@ -62,13 +171,26 @@ int __init domain_vaplic_init(struct domain *d) to_vaplic(d->arch.vintc)->regs.domaincfg = APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM; + d->arch.vintc->private = xvzalloc(struct vaplic_priv); + if ( !d->arch.vintc->private ) + { + ret = -ENOMEM; + goto fail; + } + + return ret; + fail: + domain_vaplic_deinit(d); + return ret; } void __init domain_vaplic_deinit(struct domain *d) { - struct vaplic *vaplic = to_vaplic(d->arch.vintc); + struct vintc *vintc = d->arch.vintc; + struct vaplic *vaplic = to_vaplic(vintc); + XVFREE(vintc->private); XVFREE(vaplic); } -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250510.1548008 (Exim 4.92) (envelope-from ) id 1w00iI-0002nF-DU; Tue, 10 Mar 2026 17:17:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250510.1548008; Tue, 10 Mar 2026 17:17:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00iI-0002n8-9c; Tue, 10 Mar 2026 17:17:46 +0000 Received: by outflank-mailman (input) for mailman id 1250510; Tue, 10 Mar 2026 17:17:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aN-0001Q4-HD for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:35 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e916d655-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:34 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4853aec185aso22522015e9.1 for ; Tue, 10 Mar 2026 10:09:34 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:32 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e916d655-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162573; x=1773767373; 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; bh=vggNX4iy/s3rYe31fA6JCPRN0nqiyw41a2u9JUGJC2M=; b=A2A7GGJ0CAL4ikMnK2xD81wYIzdXp39h5Zq/4vsUGRd5AAbzcp2wfPNKv4aCeFr04B C4IbuMfaJg+/kwf7iFC7ERmKa2lyb/rL60QRuKtcY+M5bQ0kRLhYbvE82t5yai5yh3rf /avseKkvQXMffFCmcBc/FeMTFbjpP9WW61twM2zGhRBwzJVbBl9DaB5SHGLr+XVJ2J26 uGpNrwjofjMFzPFKjfSnCPe278/WhkG0LOvCONnmF5/7++mAxzgQu/CrYLHjzobcuMXp xeJacLC+YzLuSdchQgjCPfOWsDtUDr0prU6K+szRuJKjE4jxzn0q3asWrKyvDMvK5Tzy HQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162573; x=1773767373; 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; bh=vggNX4iy/s3rYe31fA6JCPRN0nqiyw41a2u9JUGJC2M=; b=Ig6dVDQ+LcTI/hW/gNALG5n4zaBY5wgNasgTTkJ4IEcQLvm+1Wq8658V+Q84j7rO14 eXVqsgEVi4uWTXQO68mFpKgebN3sHw+E4sFBiYbyngX6A7x4xC2n8bXfMCYvsuDVqN21 sdCoDBrqOmzzb6Vg/Rpii8HVBfOq4W560EjSnPvAS+nrarQ1LTapvErbtHJm387d43JX Jzx+0HwnfNIJ/fRIBwBa5D7sQGaXmj4eTdEsBsuhPuDH1mUt9efG6fG0xabWX5YbgenC tIuKWGqPoBykdjwjASKL7Df5f8v/Lq5dnWG89zK3Ix2jkzVekOXHdgAT5PTs6RPeGDql CIzA== X-Gm-Message-State: AOJu0YxHYzbxq5VrgemTmpLf7h5FhkmIfrK8Fi9ObWdSLz2wOJuE5pHv FFdfmOHZFv0QrMiXQwwGs51QLEOF+ev2K3HAH9iK6BiHqV+3CRgK9FlwB9lZOYo1 X-Gm-Gg: ATEYQzxt0YRSDIoNzbT7YtZ4xE66nEdsGPuZf1CMrlnU2egtqfIJaukap7FwDAhJVMG Bv3IAXfyZTAorslb5BBZgUumzuIqXiSoI7tYB++k1faqAVA+vsyqKYwGGz3ne2QlTncm8WpleKS rOtAewu+pwtW6TnTBYz6GYH9DDeZAu3B8wapYPhB59y7CrPR6R8EczrceWT3CAuzZyStowGC+5m DiKGicdCJuU/SXmH3aFf23LhCYlN+ca2ecqI8n8BA3vzcwm7GMp6PIFCqDs7j1MZTEEom/4nZNE 9P/EnKbLGT7MyHlDbxye5MhdoFzSjdvQsJj4+YhfpX1Y4Ef95C33LJdgmCDVVAjRlVTi0hiNC3x HWIOKZB0mzZ7jfAqBFcZpIHtDx2Y6yRHNU4EYIYqDi2j61xrRJC/cGY3LT0xFCOHKp6mRiLwZMg 5fu30+Oej0zHO7+t75TBUU2+4yRdP9lfxIcpNHL1GqYp6J/O8Fnf/gN+dWy0z1hylL5g== X-Received: by 2002:a05:600c:a08b:b0:485:42ba:fc8 with SMTP id 5b1f17b1804b1-48542ba105dmr58826615e9.4.1773162573184; Tue, 10 Mar 2026 10:09:33 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 20/27] xen/riscv: emulate guest reads from virtual APLIC MMIO Date: Tue, 10 Mar 2026 18:08:53 +0100 Message-ID: <626d0874c2c7ec858725860bc3857691f0f829ad.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Guests may read back APLIC registers to inspect interrupt state and routing configuration. When virtualising APLIC, Xen must intercept these MMIO reads and present a consistent, restricted view of the virtual interrupt controller state. Note that at the moment only MSI mode is supported. Introduce vaplic_emulate_load() to handle guest loads from virtual APLIC registers. Readback is filtered through the domain’s authorised interrupt bitmap so that guests can observe state only for interrupts they are permitted to control. Registers defined by the AIA specification to read as zero are handled accordingly, while other registers return masked values derived from the underlying virtual APLIC state. Unsupported accesses are treated as fatal, as they indicate a emulation error. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/include/asm/intc.h | 4 ++ xen/arch/riscv/vaplic.c | 69 +++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 92a74eede4a0..45d41e191e30 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -56,6 +56,10 @@ struct vintc_ops { /* Initialize some vINTC-related stuff for a vCPU */ int (*vcpu_init)(struct vcpu *vcpu); + /* Emulate load to virtual interrupt controller MMIOs */ + int (*emulate_load)(const struct vcpu *vcpu, unsigned long addr, + uint32_t *out); + /* Emulate store to virtual interrupt controller MMIOs */ int (*emulate_store)(const struct vcpu *vcpu, unsigned long addr, uint32_t in); diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 5540b4884179..293729ad0ad4 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -137,6 +137,74 @@ int vaplic_map_device_irqs_to_domain(struct domain *d, return 0; } +static int vaplic_emulate_load(const struct vcpu *vcpu, + const unsigned long addr, uint32_t *out) +{ + const struct vaplic *vaplic = to_vaplic(vcpu->domain->arch.vintc); + struct aplic_priv *priv = vaplic->base.info->private; + const unsigned long offset = addr & APLIC_REG_OFFSET_MASK; + const uint32_t *auth_irq_bmp = vcpu->domain->arch.vintc->private; + bool auth_bit; + + switch ( offset ) + { + case APLIC_DOMAINCFG: + *out = vaplic->regs.domaincfg; + break; + + case APLIC_SETIPNUM: + case APLIC_SETIPNUM_LE: + case APLIC_CLRIPNUM: + case APLIC_SETIENUM: + /* + * Based on the RISC-V AIA sepc a read of these registers + * always returns zero + */ + *out = 0; + break; + + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: + auth_bit = auth_irq_bmp[regval_to_irqn(offset - APLIC_SETIP_BASE)]; + *out = APLIC_REG_GET(priv->regs, addr - priv->paddr_start) & auth_bit; + break; + + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: + auth_bit = auth_irq_bmp[regval_to_irqn(offset - APLIC_CLRIP_BASE)]; + *out = APLIC_REG_GET(priv->regs, addr - priv->paddr_start) & auth_bit; + break; + + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: + auth_bit = auth_irq_bmp[regval_to_irqn(offset - APLIC_CLRIP_BASE)]; + *out = APLIC_REG_GET(priv->regs, addr - priv->paddr_start) & auth_bit; + break; + + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: + auth_bit = auth_irq_bmp[regval_to_irqn(offset - APLIC_CLRIE_BASE)]; + *out = APLIC_REG_GET(priv->regs, addr - priv->paddr_start) & auth_bit; + break; + + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: + /* + * As target registers start for 1: + * 0x3000 genmsi + * 0x3004 target[1] + * 0x3008 target[2] + * ... + * 0x3FFC target[1023] + * It is necessary to calculate an interrupt number by substracting + * of APLIC_GENMSI instead of APLIC_TARGET_BASE. + */ + auth_bit = auth_irq_bmp[regval_to_irqn(offset - APLIC_GENMSI)]; + *out = APLIC_REG_GET(priv->regs, addr - priv->paddr_start) & auth_bit; + break; + + default: + panic("%s: unsupported register offset: %#lx", __func__, offset); + } + + return 0; +} + static void vaplic_dm_update_target(const unsigned long hart_id, uint32_t *iprio) { *iprio &= APLIC_TARGET_IPRIO_MASK; @@ -327,6 +395,7 @@ static const struct vintc_ops vaplic_ops = { .map_device_irqs_to_domain = vaplic_map_device_irqs_to_domain, .is_access = vaplic_is_access, .emulate_store = vaplic_emulate_store, + .emulate_load = vaplic_emulate_load, }; static struct vintc * __init vaplic_alloc(void) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250520.1548017 (Exim 4.92) (envelope-from ) id 1w00iR-0003JF-OX; Tue, 10 Mar 2026 17:17:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250520.1548017; Tue, 10 Mar 2026 17:17:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00iR-0003J6-Kj; Tue, 10 Mar 2026 17:17:55 +0000 Received: by outflank-mailman (input) for mailman id 1250520; Tue, 10 Mar 2026 17:17:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aM-0001Q4-HC for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:34 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e86f8024-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:33 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-48529c325f0so30678765e9.0 for ; Tue, 10 Mar 2026 10:09:33 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:31 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e86f8024-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162572; x=1773767372; 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; bh=dla2ZfjKuAdtGf39njgNy8xyCVJufRaAAQSeRsdKKdA=; b=RIb/tv4cYnIPfFle98vInh+ohr451UXDC/EyxAOwEMmzdq2mKFZeiAqiXpHz1I7l5A N4T/ncLVrATIdFPF+KY6pzb0aYbWzoe6GaXioto//Ofiv9AP5M/Fk+lpfIZRx46l1OXO /Jb36T0qPXvwryMlZc5z1yb4Ol2uJ+IQZxHdWccwVL5jCaO2INmKkLTJhzBkAJB+ziHF 6w4vWW7qgN4uceQ86Zc5/8CAXWrgXNzmXdXmB7cZgHR/TaAJd8GpozNgbe98GrtyiQOW LQ3+YKnewLEGxXBx2q47yL5AqX16ohdT5T5cGS+AWOw7UhnbNCkmzp0N9gE8vFUOj/rt 1EGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162572; x=1773767372; 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; bh=dla2ZfjKuAdtGf39njgNy8xyCVJufRaAAQSeRsdKKdA=; b=lRN+lRlSQ67kytKB7gVJSz/Tx4zZCawruhHr6LgV0t1uSsMtVKu+OByQRA9FOy+To+ EorKqrA2rbPGTKJ/pqIBoHzSLVxURsjpAvBPkYTpQhLg5JbUqnTRm3SUxRopYMbxo3dz JqlUp01WJEfMqxSzdn+ggsge90JJ2yBnQkP0xenUWHCe2avRpgv/s0PqgZYwoazORlBA YUhqF57NyJHDbkW3Svgw8rpsCyqIDN09yXlYCfeDyMRojGXhoWIWzJEkmKbw7FmstwwM GKwlU37rs1YCZWh8j58npqM6jYGxNgk9u7p1HuW1ETmMaafF+iEcVNNbnmNxNAxJUJkY DzSw== X-Gm-Message-State: AOJu0YxYNN4ctG4lCMHCbzmJp3aEyvA9Ky+iu67+G+qG3+qvR2Ib9zl5 xzVrng4Qf5kVAAvXgyj8+HPM8S/6JaRKlUkr98De8nAKhAcctt6PdPefMRIRNMMh X-Gm-Gg: ATEYQzy2J2cgC/xJ68DXEViZb6l6TESe3/fjBpj/y+JAJ6j2Rjm8ByZ5ux8Gif8KoX+ XtwDb1LOZcnz5agsb87JAJso1CEe13YOCJtWxH48j74sbAQKS39LxGlP9/3uMM27g7eQUW2h6XR lPNBhGgxVdR1R0fRdVy736D0nzDZbVi2yJ7f7a4bxeSm6mj/beHLSr1wSO6V0Mf9xzuIBraJGo+ DbAyrDUoN3mZde4ltqrYaGu2oLK74rim8fRh2hDYSdb2ptjWROUZCqqLcLsbGQeU+X6ghonlSUL XJk9EKGPI5zQkgPlfVFwqj6pCwgyIStoy03ySFguhlyqHVECarzliRS+/g17FNNGXsWmhvZitSs dhHtqXgRzGYamh+GYVjXZGTbosvTieldk3d1Dt29V8mrAoPV4rEx3mEa9gnoQPX6Vvn3qhlhq35 sfR9WHQBPx06QGRuuYTbSEbMiN0AM2mTfH+URL36i6O9LtwNInu8oOchFXqEX0gC1obg== X-Received: by 2002:a05:600c:46c4:b0:485:304a:58cd with SMTP id 5b1f17b1804b1-485304a5a00mr211584565e9.4.1773162571955; Tue, 10 Mar 2026 10:09:31 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 19/27] xen/riscv: emulate guest writes to virtual APLIC MMIO Date: Tue, 10 Mar 2026 18:08:52 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit RISC-V guests program interrupt routing by writing to APLIC registers. When APLIC is virtualised, Xen must intercept these MMIO writes and translate them into updates of the virtual interrupt controller state. Introduce vaplic_emulate_store() to validate guest APLIC accesses and apply only those changes that are permitted by the domain’s authorised interrupt bitmap. Writes targeting unauthorised interrupts are ignored, ensuring that guests cannot affect interrupts they do not own. APLIC TARGET writes are rewritten to reflect the effective interrupt delivery configuration, depending on whether the domain operates in direct (isn't supported by Xen) or MSI mode. This ensures that guest-visible routing requests are correctly mapped onto the underlying virtual interrupt topology. Unexpected or unsupported register accesses are treated as fatal, as they indicate a emulation bug. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/include/asm/intc.h | 4 + xen/arch/riscv/vaplic.c | 169 ++++++++++++++++++++++++++++++ 2 files changed, 173 insertions(+) diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index e6b6c179415a..92a74eede4a0 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -56,6 +56,10 @@ struct vintc_ops { /* Initialize some vINTC-related stuff for a vCPU */ int (*vcpu_init)(struct vcpu *vcpu); + /* Emulate store to virtual interrupt controller MMIOs */ + int (*emulate_store)(const struct vcpu *vcpu, unsigned long addr, + uint32_t in); + /* Check if a register is virtual interrupt controller MMIO */ int (*is_access)(const struct vcpu *vcpu, const unsigned long addr); diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 82e74a609ee6..5540b4884179 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -20,6 +20,16 @@ #include "aplic-priv.h" +#define APLIC_REG_GET(addr, offset) \ + readl((void *)((vaddr_t)(addr) + offset)) +#define APLIC_REG_SET(addr, offset, value) \ + writel(value, (void *)((vaddr_t)(addr) + offset)) + +#define AUTH_IRQ_BIT(irqnum) (auth_irq_bmp[(irqnum) / APLIC_NUM_REGS] & \ + BIT((irqnum) % APLIC_NUM_REGS, U)) + +#define regval_to_irqn(reg_val) ((reg_val) / sizeof(uint32_t)) + struct vaplic_priv { /* Contains a legal interrupts for a domain */ uint32_t auth_irq_bmp[APLIC_NUM_REGS]; @@ -127,6 +137,164 @@ int vaplic_map_device_irqs_to_domain(struct domain *d, return 0; } +static void vaplic_dm_update_target(const unsigned long hart_id, uint32_t *iprio) +{ + *iprio &= APLIC_TARGET_IPRIO_MASK; + *iprio |= (hart_id << APLIC_TARGET_HART_IDX_SHIFT); +} + +static void vaplic_update_target(const struct imsic_config *imsic, + const int guest_id, + const unsigned long hart_id, uint32_t *value) +{ + unsigned long group_index; + unsigned int hhxw = imsic->group_index_bits; + unsigned int lhxw = imsic->hart_index_bits; + unsigned int hhxs = imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; + unsigned long base_ppn = imsic->msi[hart_id].base_addr >> IMSIC_MMIO_PAGE_SHIFT; + + group_index = (base_ppn >> (hhxs + 12)) & (BIT(hhxw, UL) - 1); + + *value &= APLIC_TARGET_EIID_MASK; + *value |= guest_id << APLIC_TARGET_GUEST_IDX_SHIFT; + *value |= hart_id << APLIC_TARGET_HART_IDX_SHIFT; + *value |= group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT) ; +} + +#define CALC_REG_VALUE(base) \ +{ \ + uint32_t index; \ + uint32_t tmp_val; \ + index = regval_to_irqn(offset - base); \ + tmp_val = APLIC_REG_GET(priv->regs, aplic_addr) & ~auth_irq_bmp[index]; \ + value &= auth_irq_bmp[index]; \ + value |= tmp_val; \ +} + +static int cf_check vaplic_emulate_store(const struct vcpu *vcpu, + unsigned long addr, uint32_t value) +{ + struct vaplic *vaplic = to_vaplic(vcpu->domain->arch.vintc); + struct aplic_priv *priv = vaplic->base.info->private; + uint32_t offset = addr & APLIC_REG_OFFSET_MASK; + unsigned long aplic_addr = addr - priv->paddr_start; + const uint32_t *auth_irq_bmp = vcpu->domain->arch.vintc->private; + + switch ( offset ) + { + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: + CALC_REG_VALUE(APLIC_SETIP_BASE); + break; + + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: + CALC_REG_VALUE(APLIC_CLRIP_BASE); + break; + + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: + CALC_REG_VALUE(APLIC_SETIE_BASE); + break; + + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: + CALC_REG_VALUE(APLIC_CLRIE_BASE); + break; + + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: + /* We don't suppert delagation, so bit10 if sourcecfg should be 0 */ + ASSERT(!(value & BIT(10, U))); + + /* + * 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 substracting + * of APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. + */ + if ( !AUTH_IRQ_BIT(regval_to_irqn(offset - APLIC_DOMAINCFG)) ) + /* interrupt not enabled, ignore it */ + return 0; + + break; + + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: + struct vcpu *target_vcpu = NULL; + + /* + * Look at vaplic_emulate_load() for explanation why + * APLIC_GENMSI is substracted. + */ + if ( !AUTH_IRQ_BIT(regval_to_irqn(offset - APLIC_GENMSI)) ) + /* interrupt not enabled, ignore it */ + return 0; + + for ( int i = 0; i < vcpu->domain->max_vcpus; i++ ) + { + struct vcpu *v = vcpu->domain->vcpu[i]; + + if ( v->vcpu_id == (value >> APLIC_TARGET_HART_IDX_SHIFT) ) + { + target_vcpu = v; + break; + } + } + + ASSERT(target_vcpu); + + if ( !(vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM) ) + { + vaplic_dm_update_target(cpuid_to_hartid(target_vcpu->processor), + &value); + } + else + vaplic_update_target(priv->imsic_cfg, + vcpu_guest_file_id(target_vcpu), + cpuid_to_hartid(target_vcpu->processor), + &value); + + break; + + case APLIC_SETIPNUM: + case APLIC_SETIPNUM_LE: + case APLIC_CLRIPNUM: + case APLIC_SETIENUM: + case APLIC_CLRIENUM: + if ( AUTH_IRQ_BIT(value) ) + break; + + return 0; + + case APLIC_DOMAINCFG: + /* + * TODO: + * 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. + */ + + printk_once("%s: Nothing to do, domaincfg is set by aplic during " + "initialization in Xen\n", __func__); + + return 0; + + default: + panic("%s: unsupported register offset: %#x\n", __func__, offset); + } + + APLIC_REG_SET(priv->regs, aplic_addr, value); + + return 0; +} + static int cf_check vaplic_is_access(const struct vcpu *vcpu, const unsigned long addr) { @@ -158,6 +326,7 @@ static const struct vintc_ops vaplic_ops = { .vcpu_init = vcpu_vaplic_init, .map_device_irqs_to_domain = vaplic_map_device_irqs_to_domain, .is_access = vaplic_is_access, + .emulate_store = vaplic_emulate_store, }; static struct vintc * __init vaplic_alloc(void) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:17:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:17:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250521.1548021 (Exim 4.92) (envelope-from ) id 1w00iS-0003Mp-0v; Tue, 10 Mar 2026 17:17:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250521.1548021; Tue, 10 Mar 2026 17:17:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00iR-0003MB-Tp; Tue, 10 Mar 2026 17:17:55 +0000 Received: by outflank-mailman (input) for mailman id 1250521; Tue, 10 Mar 2026 17:17:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00ag-0001Q4-5m for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:54 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f46f539d-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:53 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439c5b40f60so5923229f8f.0 for ; Tue, 10 Mar 2026 10:09: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-439dadb29fdsm37574422f8f.16.2026.03.10.10.09.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Mar 2026 10:09:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f46f539d-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773162593; x=1773767393; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=dZgPk3awh75bNJRkjsQOS3WuaDXX5ZqhTUv4DsGOP+k=; b=PwSRzWGSxxX9Ieq6OlN1OlYFfwLJ/mMpAt3hMlDhGL9wp1jogA/t6IBtxuRbYo5CeS rd7c+EXNKf9suMTAp1AW5sgCOJpS5Q6M5y8ruPC00l669YxDmry0tUupdMA5UGE3KCTm YpPIjgJCvqn4UfVS442VqP+QwmU6qn4C4z9sZiJhNkoTlgj1Fu1Av1fTmOHoOcTLJCV3 l++LqqT5ZedtrOuMf+dslQORLIooA7W9F0axkH5O4QY7hu0fs8G2ii7TXC6x3QHdhPVt BblwGkx+r6La8o/eiXR3w3a3CkZbt7vDM3T9NayIuiQo8bHQSJlImcphdfTJaJnU2QyT t8xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162593; x=1773767393; h=content-transfer-encoding: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; bh=dZgPk3awh75bNJRkjsQOS3WuaDXX5ZqhTUv4DsGOP+k=; b=lKtR4FxWecb/rSKlwifgC/Ssed2NsOd7cO4sk+tbyJq2tqSLCXcULnWxfTzMiayv51 LOIbRtgoRDsIh2qMQifPQ50sO7CIEWgpql/mrdGnCJp1Vie1KU0NAehW8Yhbo7LEOCJZ ApAGZnIHA+AKgPX9GPtlZXM5SLw6A/Wjbq2eypBTiNWeYYvWWUIWfgmgyMoq5Mzmngg1 Gwzm1YXo+RLDVqmMigy3c1IEMflUjOQUUfVTAM37bJDCTOjMtvTpUDY2ePgCQemx5S/1 MFLxMKmiAXJC5Tfu852yZNI1OE9THY6gYTbEgG12IZu4yPPZddHzh0uf6fhEdzyAc2n+ Y1UQ== X-Forwarded-Encrypted: i=1; AJvYcCWkshh0IaH723wy5w8RFLOfyPFterh9/g1VaIf71Z5Iqgb62XZozP4/ZUTPeiYiu8OvVIoXt4DQn9w=@lists.xenproject.org X-Gm-Message-State: AOJu0YxNCBvHIK2EvhxRpAAzBei2gqVr2+TFFO/7Y/VZR+c4hBupZk1p dOMmQ1R/8MSh3Zi7TadFSmTePKRt1s2EljwxDi2H6bqJEi7ksVSW6khjbptUu20jDg== X-Gm-Gg: ATEYQzzXX8E6kRBDmg+lH0uHvzjz2TNFMAwmbwB7XajmIz0ED20PjSzNXYYurvSiGwU 4y/BwaXR0xQTxUNqElqJC7w1BSh6rNFslD7mMAa8J7YK1mc8frcvzOG0tZNHhRj1nl9IzieFv06 mAtcgKfe47bTOaGmMGOkbM+IJWqAMwkrkP9CmX3lamNrl432mLFwSdA8gvr4fhJ5fooslCak2yH xwiWMBqeZGUyu9TUQZsq/8oyhHdqf8PGpS4o0CTuRgYoShzjlop5OaxqvmqTwkmr42celBXvbhC 0Jusy1tRXl7Q5JuDqNAmWY3o135p5IFxp8Lx1Uhwn6CXMaZkQYngOCs7PuRqT5PgltBb/xZbbdh p7KWXqG8L6bKX3rGyGA9csoiG8LVA4+wxBTALnqyJAV2XXWBpmaW3WxH8Xcy9Kq3XQz2uqJqXXy GFDBZbdQMvD0j7HvcZUL2IKu3Z0EZUWU97VNdzSQo5ZVsgy9Qajge9ILNHl8E/PC2qM4kK2rMNh umRz2k1z84kzfY= X-Received: by 2002:a05:6000:2404:b0:430:f985:a7b2 with SMTP id ffacd0b85a97d-439da86e9f5mr28965655f8f.51.1773162592593; Tue, 10 Mar 2026 10:09:52 -0700 (PDT) Message-ID: <06ac2196-71a0-45ba-a9b5-b76f098381dc@suse.com> Date: Tue, 10 Mar 2026 18:09:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/7] x86/msi: Define extended destination ID masks and IO-APIC RTE fields To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-2-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-2-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > --- a/xen/arch/x86/include/asm/hvm/vioapic.h > +++ b/xen/arch/x86/include/asm/hvm/vioapic.h > @@ -32,6 +32,19 @@ > #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_ID_UPPER_BITS 8 The name suggests this is the number of upper bits, which it isn't. You shouldn't need this constant anyway, see below. > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -615,12 +615,14 @@ struct xen_domctl_bind_pt_irq { > struct { > uint8_t gvec; > uint32_t gflags; > -#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0x0000ff > -#define XEN_DOMCTL_VMSI_X86_RH_MASK 0x000100 > -#define XEN_DOMCTL_VMSI_X86_DM_MASK 0x000200 > -#define XEN_DOMCTL_VMSI_X86_DELIV_MASK 0x007000 > -#define XEN_DOMCTL_VMSI_X86_TRIG_MASK 0x008000 > -#define XEN_DOMCTL_VMSI_X86_UNMASKED 0x010000 > +#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0x0000ff > +#define XEN_DOMCTL_VMSI_X86_DEST_ID_BITS 8 This constant is redundant with _MASK. It is generally helpful to avoid such redundancies (especially in the public interface), and derive the wanted value from the main (most generally usable) constant. IOW here maybe #define XEN_DOMCTL_VMSI_X86_DEST_ID_BITS 8 #define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK ((1U << XEN_DOMCTL_VMSI_X86_DEST_ID_BITS) - 1) But of course it could also be done the other way around, albeit in a public header this may end up more difficult. (Generally the mask wants to be the main definition, as everything else can be derived from them.) > @@ -630,6 +632,10 @@ struct xen_domctl_bind_pt_irq { > } u; > }; > > +#define XEN_DOMCTL_VMSI_X86_FULL_DEST(gflags) \ > + (MASK_EXTR((gflags), XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) | \ > + (MASK_EXTR((gflags), XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK) << \ > + XEN_DOMCTL_VMSI_X86_DEST_ID_BITS)) There's no MASK_EXTR() in the public interface. Also, nit: No need to parenthesize gflags when used in macro invocations like this one. Iirc there was a similar pattern elsewhere in the patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250548.1548034 (Exim 4.92) (envelope-from ) id 1w00io-0004VD-7c; Tue, 10 Mar 2026 17:18:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250548.1548034; Tue, 10 Mar 2026 17:18:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00io-0004Ur-4v; Tue, 10 Mar 2026 17:18:18 +0000 Received: by outflank-mailman (input) for mailman id 1250548; Tue, 10 Mar 2026 17:18:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aQ-0001Q4-I4 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:38 +0000 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [2a00:1450:4864:20::335]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ea6f992a-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:36 +0100 (CET) Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4853510b4f3so41190585e9.0 for ; Tue, 10 Mar 2026 10:09:36 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:35 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ea6f992a-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162576; x=1773767376; 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; bh=yJVP2CNX14UgxmTAWNMtAQ5gdpc3OGAi5Vg/Vni1k8k=; b=gLgGsN8SmUSsWitN/PB72s1+nqVMlU3K4dhUR7Y0ngWHxHby5cakYuynZMNdvMXGYz qoOmFWXtorZE/9IJyvBzNk6vTtyCkRmkjlMPX19A5Jk1UIFeWLBmCGXh6zJ+MKtJJty9 lvmKGn4/ZYKLXDgQwsi7WHmy373b8H9+G4LiuH5PmTdfLSjJNfJKa5o3td7f+B/AVlmq SjMDkOtlR/W40ht91XOjZIEa+lI3E5AKTjUf2Wcfagb1MHoxpryG1lEUMarZTWfTz7r+ hIfUDMuJTxZbHPeTePlegX419LD1lIYHawBTaIvOw7PpD+IPSsSWIZDqgDSO5/b55wlL 9Hqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162576; x=1773767376; 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; bh=yJVP2CNX14UgxmTAWNMtAQ5gdpc3OGAi5Vg/Vni1k8k=; b=PI0WoY1KdrYkmC94pZmdh8B4TmZswHwtcDXjGs2tT2BgQdEnp2pLjpi11JikqWdYiT gEaQUjz0OQQwxDHaMGDA2gd3/Frai2v6snROZtOFQ6N7iCXEoAO/sdDOPTPUWZyfIYa5 5aRB/btThnExKpsHseyvBXQxwoWbLK35rolV7SP3gO0nR+cFBZfk8OsN/8wEsotWNCx4 kkMd4ppUigRGE/eGGp2zqlcNYmurZ6yKgVw9aLA+ro+Qfj16OKGsVWA9ezAD4nIAra5/ kFG9TSMiK/954VVi1S4FBTrytLS+By2FPPPQAJ9fXNvcgmC3TSs0W3h3z6A+MkZ/mHeP SoHQ== X-Gm-Message-State: AOJu0Yz8gMkYhuzA5lxjyzLBarABcYRWq+0g2LI+919IzFr1ZSL9VdZo Y82NJUZVyiwtlapKY4p+J+NsnARpbMFg/1cbvxCjF8AlOwbYTNgcLZs72Qmfnmtc X-Gm-Gg: ATEYQzzutfvmvGRD+M8AIosLcyxvDo11ODD2zPcWQfhAQzEF8QNKI4ZgreR9STffxtB r2rcyjedaOqT70a2y7f6tB1L2oo0O5R/GAhJxa0w18QolZEB6mk+3MoRjuhFdFnoT9CBsVjSUNC 7PA6tSxvoofrg7XmbyxXd5ZZ4SpUQm196pbm3hwxfj662me1bweRYmlvzJn/UIDGqg3c5h8wXm1 I9RRRJfclDTOBwkv5QWehrz11PKS47E3bkqlsCBZrfpcLH39EvBoJhR3uMOsefSxwUEc11fTZ1k meP5boI4XwsJa4wRsTpEQBcK7ERmwD4mX41Zf+WntgbYROBk9o6zmbE12oSjek2MsGqZGF9LWqJ ODmd5Ky/5D4VElxQALrHbQp6TqDRyR+fPXwJ2Uyjb2uTUx2R8NIApyKNbYX+ze+AW5wLryVgvkr ar6wRq+h09NKlN2gySZ+t6gJ6hm055yd57YTrm/UfUrdv89coiuFbNi+tcZ4UWFwEyQRP0SrqbK ZHfPqAS X-Received: by 2002:a05:600c:6306:b0:485:40ed:2d1 with SMTP id 5b1f17b1804b1-48540ed03fdmr88457825e9.17.1773162575630; Tue, 10 Mar 2026 10:09:35 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 22/27] xen/riscv: implement init_intc_phandle() Date: Tue, 10 Mar 2026 18:08:55 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- 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 312c5d7d4979..180d653e5780 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -2,9 +2,26 @@ #include #include +#include #include +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_intc_domU_node(struct kernel_info *kinfo) { intc_make_domu_dt_node(kinfo); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250563.1548043 (Exim 4.92) (envelope-from ) id 1w00j5-00059p-F0; Tue, 10 Mar 2026 17:18:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250563.1548043; Tue, 10 Mar 2026 17: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 ) id 1w00j5-00059a-CJ; Tue, 10 Mar 2026 17:18:35 +0000 Received: by outflank-mailman (input) for mailman id 1250563; Tue, 10 Mar 2026 17:18:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aR-0001Q4-ID for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:39 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id eb100563-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:37 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4852f73d0a3so29542695e9.3 for ; Tue, 10 Mar 2026 10:09:37 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:36 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eb100563-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162577; x=1773767377; 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; bh=JBHKAkfBQ+LZpxYmLsiOZkYEb81ClhJSsNte5UEhevw=; b=lIVV+sTLdgY+AaZuM0+BqCxg+XStMGIxkMzhdbplTO5zEC8AztNxPsv4chN4AlXDzO DI/PuPQx3dsPZtBrZ42cTlS9G94bjzh4OiyG3FnN9YDMmfWNTpolqClDjwo7TSpdBB+n Q8wymBlu72N5+JOVa1hO7j7HDpuh0h/lI60SbJtwEZGc/2IPwRMotk6EfsLsX6wa3V8v wDUyNpnX+FUCETLIgJY3/jHnAqgEGtuS++ywcPeSo0SQUI6gMAaolv87G8fGMGmAWbZB 93V/1ovnbdPm0vBFFMFM2iRphhdRXGbFQ/sGy4wonxr1fRoRunTG9ZVqNMuujXbltmGA gZpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162577; x=1773767377; 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; bh=JBHKAkfBQ+LZpxYmLsiOZkYEb81ClhJSsNte5UEhevw=; b=ReV6POYmX6o4Ple0r2H2GKgi5lDMHzUXQoYfT2stxDkwW5mh3q+pIL8ZilUPqL+k3+ if3ss7bQ/3t4PzHWF37JjKi4HuygL32zpqmXpm9X5+XUprXvwOR4yhucsuP/Pzf2krZV kJQCFIwsCEX8+0rSZeOl/grkoBOz8z+j74fGjj3oYdl2RXFMbX4JFeQVavu4+Y3CgxQu iiAIBCnK6wBqSAloQPLDBfPluUA0rU3YhiWQ43p5hD3VIggZMy/KOajZsVrVG61nbclZ R7g1VCjMEAk7xqDwMjSe1cr7UjSD1VqeP6qnUFAhnYPCx5fIyJSOgpnYN6veeAZq78nP XNuQ== X-Gm-Message-State: AOJu0YxfkjqFWGm7XoQc8a78SVswlV0nwqCS9rlrrol+a2J/HQgTqw1s R16jMZmaCNebr126sdyO/7YlbMc3JeeXT9A6J8JbEhjXd8xglhhGvn0nIV8CCG5T X-Gm-Gg: ATEYQzzOAW7304OWTZ3rGPay/e8MQjPBkOWN36j6tAlp4BpF0HIyvgenN0KGQU2C0ZW nYZXx6xmwC80TcJu4edLUdFRzY4o0FqFOX5efzRia3fnLbEoCGBfhehBZDNetg8KhwdGlq4apKc 5GCEwjVJEsNqDBK94qh2KopIJqYUYT/aunOprN1F0lTl4nbOaRQj6pp1zvTPjTvC3MRMR5qubKW HKVFWH77zYwSjUjPNYxzEesSsV9F0xuwTun2CN8amMLIWPLdkiFiPC05f/fUIkqe61VOTn/gtW9 sWqGZKEu3Waj+z7o6PeJcHyV+xd9dp0S/uBuD4ITnkQnqrEAJOx6T9uDNLAg3s9pRI417lDdhHZ Ropirk5h8GM+0l42lwE5m+VSTddBG0ao0Lmq59oXCFpIWVK0dMk0rr6ybW8boIyG5A9uzFyOEXh kV7DhDAXIWGd4swJlFEuXQsKXjHaBOk0QRAipyxyAeNSEYjWTPzJUHuP3UcgglQlrc64O9fo1mz ksF9J6C X-Received: by 2002:a05:600c:c086:b0:485:3f1c:d897 with SMTP id 5b1f17b1804b1-4853f1cd9d1mr91902945e9.9.1773162576726; Tue, 10 Mar 2026 10:09:36 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 23/27] xen/riscv: call do_initcalls() in start_xen() Date: Tue, 10 Mar 2026 18:08:56 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Execute initcall function. Additionally, before do_initcalls() call scheduler_init() which is needed because of cpupool_create_pool() is called by do_initcalls(); otherwise BUG_ON(IS_ERR(pool)) will occur in inside cpupool_create_pool(). Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/setup.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index cae49bb29626..24bad0c606a5 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -159,6 +160,11 @@ void __init noreturn start_xen(unsigned long bootcpu_id, guest_mm_init(); + scheduler_init(); + set_current(idle_vcpu[0]); + + do_initcalls(); + printk("All set up\n"); machine_halt(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250565.1548053 (Exim 4.92) (envelope-from ) id 1w00j6-0005Nz-Os; Tue, 10 Mar 2026 17:18:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250565.1548053; Tue, 10 Mar 2026 17: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 ) id 1w00j6-0005Nm-M2; Tue, 10 Mar 2026 17:18:36 +0000 Received: by outflank-mailman (input) for mailman id 1250565; Tue, 10 Mar 2026 17:18:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aW-0001Q4-J5 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:44 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ede70159-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:42 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4853510b4f3so41192225e9.0 for ; Tue, 10 Mar 2026 10:09:42 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ede70159-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162581; x=1773767381; 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; bh=eS5sSCMJ+IJ1M5ORzLuoNMwjp7zPxai25z8WoDewGMs=; b=V6yZRalt6hfTpxVuBCuArsS79iZpCjhdoZ/pdpi3ir4s30PmTg4uVDZIb3Bdz0SKmK zQ0bPZCAb5S0UnZ8riWtkO6Lm9rEB5jzFI5R3L5EJxuvWaEvlUmsBpJmragGPpyKU8WZ m2MXTahbvFKhSeT6OOhkFaJAtz7LYuEmLN+61st8nbeXKI8iItQ/7ndN9EO3q/qf5Ysn jzl9f/jNc0MuRdtaU5NpIvYK8ypE93OIgz0Lg7hAhQn+gPFhO78t2qyzIvfWUFaejzWx sY0/LpZeASF9UO56c3tnMlZFp83qnk7TZlQjz8w0cuwyxjFUYDBx7v15c0MrveGUDRR+ JSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162581; x=1773767381; 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; bh=eS5sSCMJ+IJ1M5ORzLuoNMwjp7zPxai25z8WoDewGMs=; b=s6ypZ+rYGTliRaIJQywBJCpnFK1NaBmTpRN3jwRVuTbaO8E2dhJMPOMxA+QDNPljMy 5wiNpISxtQrshket458J3WwBbzqONP7IGIN6i1yTAut+sHL5DkVGwaHqm3nxc59e+ndc zCTlN1OS5PyvTaVuCGjCWDTvjmjeTXJ3C6gRFphjg0QdMOieyr6b2c7+UWNp+ubFHn8r 7du7pu7r7vRFgXyZygmOftWn7Bf5RvQ7SckGeXBCOaBegr85+SwuwxnyzWzKQJb5r54h /B3N/mDavKdPiATAwMAfeYAtkxgVoq4Mo6JrignLvM9YXsSyKBDdSW8MdgAI7amEykM2 DNGw== X-Gm-Message-State: AOJu0YwjVfrb6rnYvzki2Rw1pSfSmYKOoKdGoP6AEg4DpaqFvJPszUfQ WgP+mZ4sdnX3J2r1BkkwNv/wzDfDbSYDVlT3R7EvTwLRzKwdSj08+/u9rStKeqE/ X-Gm-Gg: ATEYQzwMo8kkiGOq1YIoWwv1Qi7XhNmu6sDVSpr8Gb6B32rV56VJu3g590ObJcWkaJ7 QPpDowvUT9eDPdrzP5Yd3G/X0qnQ/F1noZ6dCZ1Zb6BY0gIKdKO0LfHKIXvMhAU11yHmYjZ8y0W HWD4uUf4RMWVwsQG6FljNBqpcJeVnuu4pR0wGXSy5Z/oJ2nBxNroqL37NocBKpp9IR0cz7lwf/T eX5baAMOxQXu+SUHFez9ioEUA1RbCr2JD7HIavV8krBRoM1bCajfSgfPqWFErvl/vM+pFOkuzu2 ToN65cMA1fcnmWMjQgjgGY7TkEzMGQ9L6maBQiD7yjZ32tjPiKcKhGQ+vTuN8KwCl6L4aK9d4KC nrKO+2ct272+G5PMidGPGGRVQDQs1t1F1uGBMwcaHu/eUuqLTVZqXO6UhRihcgi0dI3Q0GlEgHf bmdMm3vB2AeB4tdXS3TSM8w5QuCeAGvLEfRcTrZFT0tlOFL+oFumzgHhFAEVS67ANtwbcvag== X-Received: by 2002:a05:600c:19ca:b0:485:3d43:7c9a with SMTP id 5b1f17b1804b1-4853d437d40mr110653125e9.25.1773162581377; Tue, 10 Mar 2026 10:09:41 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 27/27] xen/riscv: add initial dom0less infrastructure support Date: Tue, 10 Mar 2026 18:09:00 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 currently perform no additional work but allow the generic dom0less code to build and run on RISC-V. Introduce max_init_domid as a runtime variable rather than a constant so that it can be updated during dom0less domain creation. 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 in the public RISC-V interface. Signed-off-by: Oleksii Kurochko --- Open questions: - Move declaration of p2m_set_allocation() to xen/fdt-domain-build.h or xen/dom0less-build.h as it is used in common code of Dom0less and there is not too much sense in declaration of it for each arch which supports Dom0less. It could be ifdef-ed in common header as, at the momemnt, it is used only for Dom0less. - Shouldn't declaration/defintion of max_init_domid move to common code instead of having it for each architecture separately? If yes, then what would be the best place. --- --- xen/arch/riscv/Kconfig | 1 + xen/arch/riscv/dom0less-build.c | 18 ++++++++++++++++++ xen/arch/riscv/domain-build.c | 13 +++++++++++++ xen/arch/riscv/include/asm/domain.h | 8 ++++++++ xen/arch/riscv/include/asm/p2m.h | 2 ++ xen/arch/riscv/include/asm/setup.h | 4 +++- xen/arch/riscv/setup.c | 2 ++ xen/include/public/arch-riscv.h | 3 +++ 8 files changed, 50 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig index 091510380949..abd579aa6a54 100644 --- a/xen/arch/riscv/Kconfig +++ b/xen/arch/riscv/Kconfig @@ -6,6 +6,7 @@ config RISCV select GENERIC_BUG_FRAME select GENERIC_UART_INIT select HAS_DEVICE_TREE_DISCOVERY + select HAS_DOM0LESS select HAS_PMAP select HAS_UBSAN select HAS_VMAP diff --git a/xen/arch/riscv/dom0less-build.c b/xen/arch/riscv/dom0less-build.c index 43c8bdc52300..865311ec7037 100644 --- a/xen/arch/riscv/dom0less-build.c +++ b/xen/arch/riscv/dom0less-build.c @@ -43,3 +43,21 @@ int __init make_arch_nodes(struct kernel_info *kinfo) return 0; } + +void __init set_domain_type(struct domain *d, struct kernel_info *kinfo) +{ + /* Nothing to do */ +} + +int __init arch_parse_dom0less_node(struct dt_device_node *node, + struct boot_domain *bd) +{ + /* Nothing to do */ + return 0; +} + +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo, + struct dt_device_node *node) +{ + return 0; +} diff --git a/xen/arch/riscv/domain-build.c b/xen/arch/riscv/domain-build.c index ae26faed09ed..20735f41d646 100644 --- a/xen/arch/riscv/domain-build.c +++ b/xen/arch/riscv/domain-build.c @@ -154,9 +154,22 @@ int __init make_cpus_node(const struct domain *d, void *fdt) return res; } +int __init construct_hwdom(struct kernel_info *kinfo, + const struct dt_device_node *node) +{ + 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) +{ + return -EOPNOTSUPP; +} diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/asm/domain.h index 21a3e6876f36..a8342ca7c5bf 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -20,6 +20,14 @@ struct hvm_domain uint64_t params[HVM_NR_PARAMS]; }; +#ifdef CONFIG_RISCV_64 +#define is_32bit_domain(d) (0) +#define is_64bit_domain(d) (1) +#else +#define is_32bit_domain(d) (1) +#define is_64bit_domain(d) (0) +#endif + struct arch_vcpu_io { }; diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/p2m.h index 4441c0400b83..d97c8d13ef6b 100644 --- a/xen/arch/riscv/include/asm/p2m.h +++ b/xen/arch/riscv/include/asm/p2m.h @@ -259,6 +259,8 @@ void p2m_ctxt_switch_from(struct vcpu *p); void p2m_ctxt_switch_to(struct vcpu *n); void p2m_handle_vmenter(void); +int p2m_set_allocation(struct domain *d, unsigned long pages, bool *preempted); + #endif /* ASM__RISCV__P2M_H */ /* diff --git a/xen/arch/riscv/include/asm/setup.h b/xen/arch/riscv/include/asm/setup.h index 1c23043f409f..2e3f8931d01b 100644 --- a/xen/arch/riscv/include/asm/setup.h +++ b/xen/arch/riscv/include/asm/setup.h @@ -5,11 +5,13 @@ #include +#include + struct domain; struct dt_device_node; struct rangeset; -#define max_init_domid (0) +extern domid_t max_init_domid; void setup_mm(void); diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 5bc34e41fe55..513f94777f38 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -32,6 +32,8 @@ #include #include +domid_t max_init_domid = 0; + /* Xen stack for bringing up the first CPU. */ unsigned char __initdata cpu0_boot_stack[STACK_SIZE] __aligned(STACK_SIZE); diff --git a/xen/include/public/arch-riscv.h b/xen/include/public/arch-riscv.h index 91cee3096041..3c0c786c57ac 100644 --- a/xen/include/public/arch-riscv.h +++ b/xen/include/public/arch-riscv.h @@ -58,6 +58,9 @@ typedef uint64_t xen_ulong_t; #define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE } #define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE } +#define GUEST_MAGIC_BASE xen_mk_ullong(0x39000000) +#define GUEST_MAGIC_SIZE xen_mk_ullong(0x01000000) + struct vcpu_guest_context { }; typedef struct vcpu_guest_context vcpu_guest_context_t; -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250566.1548055 (Exim 4.92) (envelope-from ) id 1w00j7-0005RT-0z; Tue, 10 Mar 2026 17:18:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250566.1548055; Tue, 10 Mar 2026 17: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 ) id 1w00j6-0005PW-Sq; Tue, 10 Mar 2026 17:18:36 +0000 Received: by outflank-mailman (input) for mailman id 1250566; Tue, 10 Mar 2026 17:18:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aK-0001QA-7F for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:32 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e6f7f498-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:30 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4853c3c2fe7so15292575e9.0 for ; Tue, 10 Mar 2026 10:09:30 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e6f7f498-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162570; x=1773767370; 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; bh=PGO25D+/JyzUb694KNoTgwesllMgu7ATeYdD4+csfDI=; b=I0lz8oGkbbdeJGgWF9PwMsPmHrpY0GCoFGgJDiD2sdYkbgaY0pSwBAtBYUYf+DGP+C K/3A+OLTqwP0hkmTMLF1Ffv3Wi6ZElGjtw0hQx+SW2Ba3p2iMXugH8vB18TNY+3JI7dm Z3OalrbQYz/z+xtylwSxOu2bp5cK7wvIgefKq3ffW3ocaCG5ppC6OY50O8nZV9vyEPGf Xa8Oxc/4fylJep3spoLUnIc7Or/hrVijt7UqHXGZAeJXOJ8uA8+hwFjvZBdtzyJjLpAy Mp95IJT4Jje6kfojOzAB8bHldDTskmrqw9j7G2JCxE4X3NBXYkExhhjEayfgP9ZMRlBc OBqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162570; x=1773767370; 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; bh=PGO25D+/JyzUb694KNoTgwesllMgu7ATeYdD4+csfDI=; b=fmYgzj2kIrHOCJGG2/Ri5gsyFMqw7nYudkZhXZHPcTFoz7Q1vJ0TncRSDFhvKEorZX dWdX7flMheowGoUAMSqfLIW0BD6wNE19/gVNvtFJo60QHgsIEzYa8h0asWeM85EHFwH3 ldU8EKXu+SD15qsqtNyDBMW3/heUYZlIm45Z1JzQzp/dxAIhxFIvYNR3GQ3RW2cBknm9 6Slkh6HPzbD6+tx8P093QEyQ6ga0VFbZTze+Hgjw4T53IowHoBqkUxGuB6QrS/Lamxou 5ZWIcFaumiq9G9fOKM3BT5l1IhW6dSfVoOSho2aZRKITFv8tVNOwv54BGnNB5WhVIIm2 uxbg== X-Gm-Message-State: AOJu0YxrsPJq9Z/i5TXKSrAK4hY3KMw5iIiTxbep+0FbdxWZ3cJri1t9 YuiVcf6/1AJ7YP1c6swCHKXc3CeTZ+4Av8OtqiUy6wUn4b0M5eQXrROQmAcwv4EZ X-Gm-Gg: ATEYQzwiwv45qjKiZv7EbveW/SoKohK2W45z9knRZfXknbLFItEyNJHGB3vTyF+3W72 CpiVq3rO1dd+MbRcHnFz6Vnmj7qChUYYv4PYoi9+LROc/JYjmhUEGxBJCYzwJWHgzPY4e7RUsnl uKOLAlANTXREm+PWSAG0e4i9P3SwJ4h4VQP0gfr5KdewTNWH4Q0jRviEu6ThLiBDRpIiSo7nI0j HcBM45bGjB6SUWBkxDJytQLgixNakBYpfyZxjU3k/PjvpBcp8J2yORHrh0Z0AE704PwLDMn0EZR ytLUxSFM6PIn+VQvKlBKw7DxN7uN6lMMBerNDG2DrZztPqlVJjO68Iqo2ci3NbCnjdSjwsO9fa6 fBghiTf+Gnu2RpA0y3YRoVwm0eq6fLkAtlEGbkU0D4iU5c71P+yvzSKIlIrNLD+JZy8JAn3Lb9C tThXcBUYEa8+/r8ECDPE9hU4fWsfysW570fV7vD1c9WjoRpPSkjkR1D9Z4nHOr9FjATA== X-Received: by 2002:a05:600c:8b67:b0:485:4371:539a with SMTP id 5b1f17b1804b1-485437154e5mr59713625e9.31.1773162569788; Tue, 10 Mar 2026 10:09:29 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 17/27] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h. Date: Tue, 10 Mar 2026 18:08:50 +0100 Message-ID: <2097fefb49fca36f641ddd7d7fb31e796a03619e.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/include/asm/aplic.h | 35 ++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/asm/aplic.h index 55cd4a128de7..7e9161d98ceb 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -17,6 +17,11 @@ #define APLIC_NUM_REGS 32 +#define APLIC_REG_OFFSET_MASK 0x3FFF +#define APLIC_TARGET_IPRIO_MASK 0xFF +#define APLIC_TARGET_GUEST_IDX_SHIFT 12 +#define APLIC_TARGET_EIID_MASK 0x7FF + #define APLIC_DOMAINCFG_IE BIT(8, U) #define APLIC_DOMAINCFG_DM BIT(2, U) @@ -27,6 +32,36 @@ #define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 #define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 +#define APLIC_DOMAINCFG 0x0000 +#define APLIC_SOURCECFG_BASE 0x0004 +#define APLIC_SOURCECFG_LAST 0x0FFC + +#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_GENMSI 0x3000 + +#define APLIC_TARGET_BASE 0x3004 +#define APLIC_TARGET_LAST 0x3FFC + #define APLIC_TARGET_HART_IDX_SHIFT 18 struct aplic_regs { -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:38 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250569.1548071 (Exim 4.92) (envelope-from ) id 1w00j8-0005ql-9E; Tue, 10 Mar 2026 17:18:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250569.1548071; Tue, 10 Mar 2026 17:18:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00j8-0005pe-63; Tue, 10 Mar 2026 17:18:38 +0000 Received: by outflank-mailman (input) for mailman id 1250569; Tue, 10 Mar 2026 17:18:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aL-0001Q4-H7 for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:33 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e7a07e20-1ca3-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:09:31 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4852c9b4158so28934155e9.0 for ; Tue, 10 Mar 2026 10:09:31 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:30 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e7a07e20-1ca3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162571; x=1773767371; 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; bh=hH9znhbJsO7IzrzhoOYnrjac5Z3LLI2ieI1hChueBHI=; b=Y4DkD/FJ6idyy/ETSIEB3Lce9eUGQw5qOmA5brIy9bFsihE5ZkKdJivL5KOxB3BaeX SQ0fBpcbDGKb+qltfLu6uqgQMOlYBJr7VfCJ9SCwBET2c7s6k4L9/e2MEtAtvjoKrR4s xXj6GLQGX2pd9W4cPwHj+NNBZUIzP//YY0s6ugNpHuIOVtoQmTAcBdG40mNU8QbAsBr9 tJUV2gKNyw07ofkZy9hc2sNUjKjMJLU7nC7eFh3ZZz+Zu0Jqn3xmd2PgJn3MH8MOxxr+ AFnXIfHCRd0eAm97JNB/vYubKihg7X7tqcXBKxeoDAoRNDa+FKwSQU9s9OIt+b3CobW0 47LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162571; x=1773767371; 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; bh=hH9znhbJsO7IzrzhoOYnrjac5Z3LLI2ieI1hChueBHI=; b=s5bIpSPsmRDMnARCaWBRrBfgJ7kiKLqVfkgygy+f4vsIql46lN0tUGh85UbxzBkHcM H4GC/RLg4Fiuwb1ctU6iSd245i/sOowycwTjlRQAnIh8WGQ8hvC2hB4EGfZT3W55Yeoq NYsXcqGaMVeyUUyYMSOGgVsCq+98Cs9J6LNWL7oF6vp4DQMKMB1fQGMql95P7QDr7mUt A83abdLLH4xjM9df3QiOTunTrXRqQ2HeH92tlUCgrtBIMcT24ygzSICFV9VksGZ6mSNt c6G0B6Juc+wGFoJ6hzOjFuQ6ri8JW+jBZrLwFPANEPq1+N4GSTVsYrJwLk5Vea5jBV6Z n5hQ== X-Gm-Message-State: AOJu0YzXHUVXdt6ffDH5Zma2zKtV5EEJ+6aCOZ0y4WGDOMN8keEm+6ms 4oExoqL05jtpzH84MVngwK9diCZ8eJIp5RHB0lgHLl/mrMj+XfcFSXX6D06hMZR8 X-Gm-Gg: ATEYQzzzPkY4PTwqAcym4km0sRIM7X4QhNVdyN7qvxKjyVRS0gB9mtyU0PI7SB+DdWa I+/7qmRwQUOye3njOV/DRQRFirWK1QLeGlU62Ywj6Xo8TNm8lT53S77z6zXfP22Wz30I3zfXQdk X3thEGSgoXAsb1PgEcyMYCUYtMqjvpglSTWaebSNuaMwG71uqbu6UoRXmhwzFnGWrawrBeSXqYp OCihTGWPjNjW83gEe4UZNAxkUCh4xhmQePyOINiXwFKuRYgO3xAnbWvBUnXEYwmR7tejQhoEugB q1KghQHiiN/c53sqjEmJvo/NaEluMNn4zf7WsqwwYLe6JfZVLS6UHqJykaeTc8PC4oHbNr2peMw A8TFuqljC57yyZk8AXtgl1W3tXUb2N5uxtspaDDpqLg/z7PYvVGPtDi8aA2+xqrCKsAqAIrWhLz LB+aJTin3SZPZ+XvPbsGBYG4XzGiEVyLOQBmlbv0FXXu4iDrPWR+lzFU1yb0dpK2165zjNlQ== X-Received: by 2002:a05:600c:8707:b0:485:3ff1:d5c3 with SMTP id 5b1f17b1804b1-4853ff1d6a6mr122929915e9.5.1773162570910; Tue, 10 Mar 2026 10:09:30 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 18/27] xen/riscv: add vaplic access check Date: Tue, 10 Mar 2026 18:08:51 +0100 Message-ID: <0fc9adf790d4f981e8117bd9759c7e64bb11e439.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Provide a mechanism for the virtual APLIC to determine whether a guest access targets the physical APLIC MMIO region. This is required to correctly identify and route guest APLIC accesses. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/aplic.c | 1 + xen/arch/riscv/include/asm/intc.h | 3 +++ xen/arch/riscv/vaplic.c | 15 +++++++++++++++ 3 files changed, 19 insertions(+) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index e139946a05a0..754b444a2a13 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -38,6 +38,7 @@ static struct aplic_priv aplic = { static struct intc_info __ro_after_init aplic_info = { .hw_version = INTC_APLIC, + .private = &aplic, }; static void __init aplic_init_hw_interrupts(void) diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 76d2fd09cb8b..e6b6c179415a 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -25,6 +25,9 @@ struct intc_info { /* number of irqs */ unsigned int num_irqs; + + /* private data pointer of the interrupt controller */ + void *private; }; struct intc_hw_operations { diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 0c69f087cf4d..82e74a609ee6 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -127,6 +127,20 @@ int vaplic_map_device_irqs_to_domain(struct domain *d, return 0; } +static int cf_check vaplic_is_access(const struct vcpu *vcpu, + const unsigned long addr) +{ + const struct vaplic *vaplic = to_vaplic(vcpu->domain->arch.vintc); + const struct aplic_priv *priv = vaplic->base.info->private; + const paddr_t paddr_end = priv->paddr_start + priv->size; + + /* check if it is an APLIC access */ + if ( priv->paddr_start <= addr && addr < paddr_end ) + return 1; + + return 0; +} + static int __init cf_check vcpu_vaplic_init(struct vcpu *v) { int rc = 0; @@ -143,6 +157,7 @@ static int __init cf_check vcpu_vaplic_init(struct vcpu *v) static const struct vintc_ops vaplic_ops = { .vcpu_init = vcpu_vaplic_init, .map_device_irqs_to_domain = vaplic_map_device_irqs_to_domain, + .is_access = vaplic_is_access, }; static struct vintc * __init vaplic_alloc(void) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250576.1548081 (Exim 4.92) (envelope-from ) id 1w00jG-0006UA-Kc; Tue, 10 Mar 2026 17:18:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250576.1548081; Tue, 10 Mar 2026 17:18:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00jG-0006U3-FT; Tue, 10 Mar 2026 17:18:46 +0000 Received: by outflank-mailman (input) for mailman id 1250576; Tue, 10 Mar 2026 17:18:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aS-0001QA-Ay for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:40 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ebbdf6ba-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:38 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4852a9c6309so37126245e9.0 for ; Tue, 10 Mar 2026 10:09:38 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ebbdf6ba-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162578; x=1773767378; 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; bh=JkvH963wjORCKzFpDWqD/iOnBC1tRJKt38ThB/X1OSI=; b=SVYSgIUc/gt7kFBpsZdXFWHzact7MeXwXv9F+mnUUvkrkyJn8Bevh6HQaqfAcdkkKY kWUAb32UPTu82HMqDjZiQjqEwuJ1gyZn74VT/o241iGVU0fIxk+MCUbc0fOpahgpVMKi VtxZNbLDrvIQHaZayF//MVmv4vqyYXpT/kMj82eWendYM7NFe7DObRZITAUGL8WxVSJ2 DgzBxGa0jJq4ANvobdX1j76oRRbypFtwaxG7v9jLAmO+P0LojMMcf3ipdB5cPNYTzzyq uKfhkwAKP4RdEaP4w5Zhib97P3ix0CQ0oxbJectwOTqjuf6PFp/fh63VJWJQjK8YwOSN LC/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162578; x=1773767378; 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; bh=JkvH963wjORCKzFpDWqD/iOnBC1tRJKt38ThB/X1OSI=; b=m3k/ah1Dh+10kdcDGiWxVl6AA8YlBewNfWxTqwWkafb2mDoGhVnJq2j9AuDFhbhbbN FhRw++uq9HjnkQ0cseyVWhWeUSYz9YGGu89XMHzFZJ7/D7bm8Nm5YybbBeqxqkEc6ZgA r4oVsGD560o495hARYe4px9RQVPcutrI4yL0CahwfHPxT/wr7zwAS7f61iISNjzYR9m0 4I9RG9/+IcgQ/pQNrmVxhC55xkEWOn5MCTuvk/nUa7y39z+LXLtg1ilbw9t72GSA9v/k xj8xG+DC6gr00ToVFNRUorWqHU+YE0BSkEIebiCZDZ4yxCWAeEecYDSeAPp62nFkIRK7 Ef9Q== X-Gm-Message-State: AOJu0YzEWHPqTfMg9UzjeDeyo87yfXFzgFZ0+PqTOzqzHR0Cxc8zGbpc wOiVBwNOBmoF3yyBU1t3gE2M1UPBEOpUkxBFHGFJUqrpTjuM+MWrbNb2TGXEWd7K X-Gm-Gg: ATEYQzz3wryNyedq9lx0CWPXKrQzuCbcav/dTo8XevhuxMzQOJi/SDJ3Zp9x9qeZ6IR Tvupmp9QpIwyVeCZtqwacqsYpZrYYRSCoReEJvcMmiMoXSpNRn0ZnS71momqRiBGhQH6eZNF+3p TNCXY+Q1agrzjgGTI1fvjirnzrc/HEq88JDw+vLL+qKbWP21pkQ8R0CM3gbMLtlzn7Boe0FyU2K 8zFn5zm0vTcXLC2Y9sadSfJ0ZOV+/UYrI+F8l1IdCC5m4BTOPsVp9qgbnzoNo/X+AeNDitaprWo Pvf3uQd8lxyrcEv3ZEIGv/qXz8K0YWGClwCIl9iQ834lt06wiTlxpETa2ILK4k7lBt+VOheYuus mEqBmLApVPIv+8trUK2wSShFv7oYpME282Hhzdk+Ki4vJ/D9svKWHaP7cLCrYryK+rGtohF4IHH BS/tA21Ejd4R1g/IzA7QiQyNZ2pP6BfWTuzl7vrFU+Eqpa1claQ7AtQBUDtFw5ZFumeVj+kA== X-Received: by 2002:a05:600c:1d0b:b0:485:4136:99a8 with SMTP id 5b1f17b1804b1-48541369c0cmr82135465e9.22.1773162577766; Tue, 10 Mar 2026 10:09:37 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 24/27] xen/riscv: init rcu Date: Tue, 10 Mar 2026 18:08:57 +0100 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 24bad0c606a5..3e337bf611fb 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -154,6 +155,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, timer_init(); + rcu_init(); + local_irq_enable(); console_init_postirq(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250580.1548089 (Exim 4.92) (envelope-from ) id 1w00jJ-0006o6-0Q; Tue, 10 Mar 2026 17:18:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250580.1548089; Tue, 10 Mar 2026 17:18:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00jI-0006nv-Sf; Tue, 10 Mar 2026 17:18:48 +0000 Received: by outflank-mailman (input) for mailman id 1250580; Tue, 10 Mar 2026 17:18:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aP-0001QA-Ad for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:37 +0000 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [2a00:1450:4864:20::332]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e9cd1f6e-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:35 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-48534e9076fso20624205e9.0 for ; Tue, 10 Mar 2026 10:09:35 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e9cd1f6e-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162575; x=1773767375; 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; bh=eOghi8Ll3/sbazIkniNGMCKDlS8jGFlMwoa4Be1UqI8=; b=UbWt7u0RbG1GgtM3j559JPupxy1TArRkDuM+GgCbVhjHKbkkcBjdwxW2b4W9B2+QvK eqaxXJBH0A1vAsD6j0pMQ1e2IqZgeZtNLBEufiqwDPi66RcyZt1FS/dBWj5aENgzVeA/ hKhxfaBYPJTNrZnvnBrurAyRkeEKuIQenhlr+u9yv7JK+S9ye2BaJVNEQ/NK09CKTJqL bDkwrgar/6SyGmMdJBFvV/q7UyBlMtn7RMBvTRzq6gasAooR/bQ51wMm/QVJLw84O3q2 szl7eS0sMNFlyoFMv4yLju+Ff5DvF1eynOku5uXRljp7KM9SUZQACVFVZkh8ud82sJ1v OD7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162575; x=1773767375; 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; bh=eOghi8Ll3/sbazIkniNGMCKDlS8jGFlMwoa4Be1UqI8=; b=sL6JhzYNCRQJDZDctajYEuwYwweXgVElFuKvlBuBk30GroBzr08FveM8ZbVGMZmydJ 4l6BwNG47O4zJ4MtKUsRPrbBDKXky0Ffpk/qu5R2Ah9agH3p5eOd/MzdPxNGNnC/TCGu RrmRy50rP/HMHl7VfxFUT1FqjSL7lmqo+NbhCjIU4IxkR3fi33tKK06/8AxWmY26GV1c I2+RquOqjuFvrEEilb2Px59PccygPEnxr7a1f4o7VKb8IzPG38+BI0jjipfZ+F+WrUoD ztZ4WscwOylx+AKUs9BYYM6cGJgfE7iv16WFT+SlREK1MmdYzh7Jb6MiGl7f+yw67i6K B6ig== X-Gm-Message-State: AOJu0YyJBxFViZuWXn+ab9PXplj8EnUZ+S0Bep3BhGYehbpLLL2rLu0I pdInlx2h+j6jLOsJ2gHv8uGFdJRwlvwQ8ltoZK3PP3yNYDt+obx8qAvLTjGI7KB6 X-Gm-Gg: ATEYQzzkmswMZa7ZJDLZIL1/0KbrIwDvqHjX1JRCJRW0Zx548Ng48E4l8C6imuXEqtj wKDlZwWXDqTDb7JuuKTabUOyVUNJleDf+pktykjeCA8XDLw3P2t3rYH9x4MwG1B2Mw2/teN5Oh9 frYRTwrl0yK6Pq3yymtcjjUwgvWZuKgxAFyNpyfDARyJYSkisRnKvCdrmN5XjNd+6l6D9U64QM5 7wahKNXv/fAQFQ495bc7PCJ06TnhEn0q/zs6PV8apwjqauw6RYBbs4Eh63rXOBUMcNReVNnXYtB 2hO6bkxIDzSDRqDUCIF/og/dRRMDM/bsp/Gqqg3BC8h/TZvt1JaLTR832NBfYdMBk2VwbPzWDUP qcnK7tJlSv7NfdynZ0gJNBH2/XmrrIflrQCrfeiYd3m3KHwmpJAc6hV6I7lNBqs4YvII1qHM3iV 0Vcbor96QRCC4xDRPoaa/0SRfi2HS0Fbm3WGRvqs2EPUcge0MRoi0C7z8mrlWjsOSRAw== X-Received: by 2002:a05:600c:4752:b0:480:4a8f:2d5c with SMTP id 5b1f17b1804b1-4852697721cmr266702515e9.29.1773162574476; Tue, 10 Mar 2026 10:09:34 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 21/27] xen/riscv: introduce (de)initialization helpers for vINTC Date: Tue, 10 Mar 2026 18:08:54 +0100 Message-ID: <61311834fef7cf8a736a8fa972b6461bbfd46e6d.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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. Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/domain.c | 3 +++ xen/arch/riscv/include/asm/intc.h | 4 ++++ xen/arch/riscv/intc.c | 40 +++++++++++++++++++++++++++++++ 3 files changed, 47 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 560b21b16ffb..1c08ba7396ea 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -300,6 +300,9 @@ int arch_domain_create(struct domain *d, if ( (rc = p2m_init(d)) != 0) goto fail; + if ( (rc = domain_vintc_init(d)) ) + goto fail; + d->arch.next_phandle = GUEST_PHANDLE_LAST + 1; return rc; diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm/intc.h index 45d41e191e30..fb4188b96a75 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -13,6 +13,7 @@ enum intc_version { }; struct cpu_user_regs; +struct domain; struct dt_device_node; struct irq_desc; struct kernel_info; @@ -96,4 +97,7 @@ void intc_handle_external_irqs(struct cpu_user_regs *regs); int intc_make_domu_dt_node(const struct kernel_info *kinfo); +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 a91dbc5e997c..88ce658a4de0 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -11,6 +11,7 @@ #include #include +#include static const struct intc_hw_operations *__ro_after_init intc_hw_ops; @@ -87,3 +88,42 @@ int map_device_irqs_to_domain(struct domain *d, struct dt_device_node *dev, return d->arch.vintc->ops->map_device_irqs_to_domain(d, dev, need_mapping, irq_ranges); } + +int __init domain_vintc_init(struct domain *d) +{ + int ret = -EOPNOTSUPP; + const enum intc_version ver = intc_hw_ops->info->hw_version; + + switch ( ver ) + { + case INTC_APLIC: + ret = domain_vaplic_init(d); + break; + + default: + printk("vintc (ver:%d) isn't implemented\n", ver); + break; + } + + if ( !ret ) + d->arch.vintc->info = intc_hw_ops->info; + + return ret; +} + +void __init domain_vintc_deinit(struct domain *d) +{ + const enum intc_version ver = intc_hw_ops->info->hw_version; + + switch ( ver ) + { + case INTC_APLIC: + domain_vaplic_deinit(d); + break; + + default: + printk("vintc (ver:%d) isn't implemented\n", ver); + break; + } + +} -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:18:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:18:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250581.1548094 (Exim 4.92) (envelope-from ) id 1w00jJ-0006qv-B0; Tue, 10 Mar 2026 17:18:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250581.1548094; Tue, 10 Mar 2026 17:18:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00jJ-0006q6-5W; Tue, 10 Mar 2026 17:18:49 +0000 Received: by outflank-mailman (input) for mailman id 1250581; Tue, 10 Mar 2026 17:18:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w00aV-0001QA-Az for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:09:43 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ec7c6818-1ca3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 18:09:39 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4852e9ca034so34286755e9.2 for ; Tue, 10 Mar 2026 10:09:39 -0700 (PDT) Received: from fedora (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485359bf807sm119619845e9.2.2026.03.10.10.09.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2026 10:09:38 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ec7c6818-1ca3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773162579; x=1773767379; 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; bh=mamu5j19p2jm+2KOEiHejDQrsNBfFkQPRRGxNqr1KWg=; b=jP8xG9Vp437cBtyvZ9JKQYRtm98WzA7SlDh1p+BbXOoTov03KSwS6WfnKcSF5uawJt aMWUqvixp3wHXgQfekpv0x0Xcm3wVbgnNgX1QGmZFEpq0W9SfvioCnytkgmXIbcDojgZ SypIPwOI502WWqvdreXt3zRzn0F3qeCtmw2LUs/13/7AmVyynlcvw4Gfxb+ACY3+UoZc OrTMMukT45e3pxvfboh/p1rLCl/bBh7dFYNeWH27WBUBa4lj/NC58xrEayubR8hD3agW XavDV9G6sGEK1g02xBIRVJ2VsDt5bzDmxmVXhoTQX5wmgzGd+dH7C4df9jdqaAo9LhM7 tEoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773162579; x=1773767379; 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; bh=mamu5j19p2jm+2KOEiHejDQrsNBfFkQPRRGxNqr1KWg=; b=NnBG4TGMWBGpHjnHJUBifj133Lij6I46x7OnPkKa3YAU3tDwMV6MiLb2MdBHSGVqzX A5hBVTlY3yO97InO6o69rv+Y8+UpqaRGmINbhpa852jfipoV/1mKHVCpUkaqBG4Q9XtD 2Va6pXFj5M4ib36YV+6U1zZ2VsCB7BVwb/hNyCVkY2G+btpCxzRFBsKmf6rqcEUXqAaV UeaDngROXaGxdmZ/TpRnHLocES2E17ixNfjOECKwIo3NMKipbgzpIDQKSqa3CgZBm0zv oVRMd8NMTvdTRvroR9kYl1lVnLPPtA/1Dld4EoO5oLWB87IyCXePDF8qDU8E7FTCqKk/ LHzw== X-Gm-Message-State: AOJu0YxUQeKT9Ejkf13B8vDI2jYKn+pezQIpSJWHnZKpeXgG8ioQAhfq 3IQV8uIPQaHP0+pKtmgCKTefAOPrRoebxLHHGq8havPMazNIBtz3L2Q5VZ7QEP2s X-Gm-Gg: ATEYQzzvqUs1oJbbDe1h84Ou28aP5yeurGtb9cSxusggKVSDraaaEtEieypHlwyEHu4 dxzgqw2j0vEMQREUQeaT+0aIzZPPXGXYjrMg9mfu8seu03nzQQvwhVcOX9+VfMUGKHhr00tbsHm PRuYFvQMYxBvRGZ7Eqj6dOJhVpLg2UKSdwmsMA3yhsQ6Pk6oppelv5r3wzCX0ux7kz8/hwwyiWG fJj6Yq2U9PLBrw80n6BCNftw3klAGWNo8Z/dKnC0mPaMW/mw2boQk02z1QPlwBqbR5tcc4o5QSe Mr5KAm+OKaCO2XExn/vA31WbkTpcznDeWCkVO7+JbMR03eLpCWp7PdRr1T+hsg24BEJkOV7JEOt IHx6G8vDcnalWzD+ADlO8Rzo7Nxe0jj0NLKqeAI3CZCaK9KarIjpeVYKp8MAug5oIwJ+HovTpo0 8VVsO4lLIxje97cETKJRpj/ioDdRuqytwOg3wSIon79aUfpKNWS2o6IQLn3bP0kCCZWA== X-Received: by 2002:a05:600c:4443:b0:485:410c:119b with SMTP id 5b1f17b1804b1-485410c1bfemr84140865e9.13.1773162578900; Tue, 10 Mar 2026 10:09:38 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v1 25/27] xen/riscv: setup system domains Date: Tue, 10 Mar 2026 18:08:58 +0100 Message-ID: <4474cdb8e326c486a806e07d65ad6bdb9e7b9541.1773157782.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Signed-off-by: Oleksii Kurochko --- xen/arch/riscv/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c index 3e337bf611fb..5bc34e41fe55 100644 --- a/xen/arch/riscv/setup.c +++ b/xen/arch/riscv/setup.c @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #include @@ -157,6 +158,8 @@ void __init noreturn start_xen(unsigned long bootcpu_id, rcu_init(); + setup_system_domains(); + local_irq_enable(); console_init_postirq(); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Tue Mar 10 17:53:21 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 17:53:21 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250671.1548111 (Exim 4.92) (envelope-from ) id 1w01GZ-0001Cj-0e; Tue, 10 Mar 2026 17:53:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250671.1548111; Tue, 10 Mar 2026 17:53:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w01GY-0001Cc-Sw; Tue, 10 Mar 2026 17:53:10 +0000 Received: by outflank-mailman (input) for mailman id 1250671; Tue, 10 Mar 2026 17:53:10 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w01GY-0001CW-2E for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 17:53:10 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id feea9b16-1ca9-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 18:53:08 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id EDE8460054; Tue, 10 Mar 2026 17:53:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72949C19423; Tue, 10 Mar 2026 17:53:06 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: feea9b16-1ca9-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773165186; bh=WO2FOycvuuimWf2BBulOdnsAjAo+YazNHVVwxkp7CTQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=eBcXb+X80rgKqCBvLspNlTOV1vd/pku+H6vrMwjnIUc1EPld/SwvI87VOk2v9spAk mQwzcYlSAluwZ68uAzim6BOLYhwuR8hvCczaCcrGemVxRjRgvMRz7of7bwaxtz6kRd 8qySGXq8grwSK5TKxbSjaXWiTsWNvgZx6eHB/8xZY8WWUeaScw3fMAM7MDLDfNxl7z tuQvq86WkhT8OZAzrXBsWUK0J89R9XxcjJg1hqWabtJJwZex+dDwXjeMi63lPBbZNv qOKy8IvjIYCvJ2lP43twwYPykiMiWqj4+PjF4xTACYlgH5VX2O6O8QN3kfkzkExPxm ckaiF6BuuSr7Q== Date: Tue, 10 Mar 2026 12:53:05 -0500 From: Bjorn Helgaas To: Chengwen Feng Cc: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v5 1/2] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 Message-ID: <20260310175305.GA730372@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260310032049.25387-2-fengchengwen@huawei.com> On Tue, Mar 10, 2026 at 11:20:48AM +0800, Chengwen Feng wrote: > To unify the CPU ACPI ID retrieval interface across architectures, > rename the existing get_acpi_id_for_cpu() function to > acpi_get_cpu_acpi_id() on arm64/riscv/loongarch platforms. > > This is a pure rename with no functional change, preparing for a > consistent ACPI Processor UID retrieval interface across all ACPI-enabled > platforms. Really a question for the ACPI folks, but my preferences would be: - Simpler name for the interface, e.g., "acpi_get_cpu_id()" - Single prototype in generic header, e.g., include/linux/acpi.h - Split the x86 part to a separate patch and maybe (a tangent, but looks dubious to me) figure out whether/why xen needs xen_vcpu_id to be ACPI CPU IDs > Cc: stable@vger.kernel.org > Signed-off-by: Chengwen Feng > Reviewed-by: Jonathan Cameron > --- > arch/arm64/include/asm/acpi.h | 4 ++-- > arch/loongarch/include/asm/acpi.h | 2 +- > arch/riscv/include/asm/acpi.h | 2 +- > arch/riscv/kernel/acpi_numa.c | 2 +- > drivers/acpi/pptt.c | 16 ++++++++-------- > drivers/acpi/riscv/rhct.c | 2 +- > drivers/perf/arm_cspmu/arm_cspmu.c | 2 +- > 7 files changed, 15 insertions(+), 15 deletions(-) From xen-devel-bounces@lists.xenproject.org Tue Mar 10 20:56:48 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 20:56:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250710.1548120 (Exim 4.92) (envelope-from ) id 1w0480-000822-Dj; Tue, 10 Mar 2026 20:56:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250710.1548120; Tue, 10 Mar 2026 20: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 ) id 1w0480-00081v-A2; Tue, 10 Mar 2026 20:56:32 +0000 Received: by outflank-mailman (input) for mailman id 1250710; Tue, 10 Mar 2026 20:56:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w047y-00081p-Ez for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 20:56:30 +0000 Received: from mail133-21.atl131.mandrillapp.com (mail133-21.atl131.mandrillapp.com [198.2.133.21]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a916915-1cc3-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 21:56:28 +0100 (CET) Received: from pmta13.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail133-21.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fVmQ13F0Gz1XLMtx for ; Tue, 10 Mar 2026 20:56:25 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 658ad54d60d14c9f9a3e30f1ccc89e7a; Tue, 10 Mar 2026 20:56:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9a916915-1cc3-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773176185; x=1773446185; bh=2Qtix73FtwoQe1av6i/eYyOKy5BRubR6wgFToyFAgfQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=Mcwj6fogJ5/a2kZpLqB5kX9u0PS6Q/JEZSVbxmXL4pb70blATgDAZfYQRkvVyi7K7 XZyVu0aCUdp1b3vnjipbTLV2vJT7cCRGD2/DMzm3VnUupIIymzeWgfm6/61XwVm1G4 CRbz2/6slnbJJqFpiV8RxQsfWKhbZqlwUdj4lvS90bVj2yZ5JWaLJQ/GBVtwTEczm6 O87O7m169bKOQFD4b5McrhqwwWD7w62czAvuCe8KPLKqbTKUHHgkgzx6i8TFerzYrP Vx+iWZiD3lBh5kvm2XFDhWsQdUYzwKGQlSDK3a5C00cpi8BWium4/UPH9sEa0fWwux sfOEEZu/H7p2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773176185; x=1773436685; i=julian.vetter@vates.tech; bh=2Qtix73FtwoQe1av6i/eYyOKy5BRubR6wgFToyFAgfQ=; h=From:Subject:Message-Id:To:Cc:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=wEpcsrzZK6SWL+Oovg2BsGytuA17BlewXxWcz41LftFudy0ohzdO3R8/nK4x8YWWE h1uojDC8lD5PzGCjDmJw3M3qwyBQHYN9NSr6z+YhMaFP7kSctki+WpmHZH+33JUMXh EMFRo0ryQkx3YJZs8Qq60tC5rG1XJ+dqR+91UUIuIa6yjCr98f8BYSKh5tHTphoztI hvW72LgYK1h5AquT8+jtzsogKVCF8hbnyOqyUapI254EnWLsyRKKQMCdJvVNla39ge k8zFH0CObXdI+fE8QzzoqGh5/S5pNMTeGxaD5bCMXLJQvL7nTWp6GGHqUbzN7Ll4ML V86IpQt4jDmEA== From: "Julian Vetter" Subject: =?utf-8?Q?Re:=20[PATCH=20v4=202/2]=20x86/ioreq:=20Extend=20ioreq=20server=20to=20support=20multiple=20ioreq=20pages?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773176184057 Message-Id: <4509bc57-ea36-4208-b76b-465d15b25a09@vates.tech> To: "Jan Beulich" Cc: "Andrew Cooper" , "=?utf-8?Q?Roger=20Pau=20Monn=C3=A9?=" , "Anthony PERARD" , "Michal Orzel" , "Julien Grall" , "Stefano Stabellini" , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> <20260305130434.635276-2-julian.vetter@vates.tech> <5724bdb3-bec5-4159-a4f4-9bdad39acd7b@suse.com> In-Reply-To: <5724bdb3-bec5-4159-a4f4-9bdad39acd7b@suse.com> X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.658ad54d60d14c9f9a3e30f1ccc89e7a?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260310:md Date: Tue, 10 Mar 2026 20:56:25 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 3/10/26 17:09, Jan Beulich wrote: > On 10.03.2026 16:56, Julian Vetter wrote: >> On 3/10/26 16:36, Jan Beulich wrote: >>> On 05.03.2026 14:04, Julian Vetter wrote: >>>> @@ -45,7 +52,8 @@ struct ioreq_server { >>>> /* Lock to serialize toolstack modifications */ >>>> spinlock_t lock; >>>> >>>> - struct ioreq_page ioreq; >>>> + ioreq_t *ioreq; >>>> + gfn_t ioreq_gfn; >>>> struct list_head ioreq_vcpu_list; >>>> struct ioreq_page bufioreq; >>> >>> This change in data arrangement should in principle be independent of the >>> step to supporting multiple pages. Hence it should be possible to separate >>> out. Problem being that just by looking here and at hvm_{,un}map_ioreq_gfn() >>> I can't conclude how you get away without the "page" field that struct >>> ioreq_page had. If you can get away without, it's not quite clear why the >>> field exists in the first place. If it's not needed, dropping it would be >>> yet another separate, prereq change. At which point the remaining pair of >>> fields could continue to be used, i.e. the change above then wouldn't be >>> needed; va could be renamed if need be, and its type changed. >> >> Thank you again Jan for your feedback! I don't need the page anymore. >> When I use vmap(), I don't need to keep track of it, because during >> teardown, I can recover it via vmap_to_page(). Currently it's necessary >> because in destroy_ring_for_helper we need the page, to be destroyed. >> But I see now, on X86 the map_domain_page_global called from >> prepare_ring_for_helper actually does vmap(&mfn, 1). So the page is also >> from the vmap range. So for the teardown I assume a vmap_to_page() could >> be used as well. But I also see there is a special case, if NDEBUG=1, >> map_domain_page_global short-circuits to mfn_to_virt() for low MFNs >> (putting the VA in the directmap range) and bypassing vmap. In that case >> >> vmap_to_page() would not work. So, this would be really messy. I would >> rather switch the bufioreq also to an explicitly vmap()'ed page, then we >> could remove the page pointer and both cases would be aligned again. > > That's an option. Yet are you aware of domain_page_map_to_mfn()? Perhaps > that's what you want to switch to using in the patch removing the "page" > field. To then, conditionally or uniformly, switch to vmap_to_{mfn,page}() > when doing the multi-page work in the subsequent patch. Yes, thank you. I saw this function, but I was wondering whether it's a good idea to wrap the va in two translation functions like: struct page_info *page = mfn_to_page(domain_page_map_to_mfn(va)); and then calling destroy_ring_for_helper() with it. But I will have a look, and this way we would be again aligned between the two cases. So, maybe it's the cleanest way. Julian > > Jan -- Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Tue Mar 10 22:09:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 22:09:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250732.1548127 (Exim 4.92) (envelope-from ) id 1w05Ga-00080d-GF; Tue, 10 Mar 2026 22:09:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250732.1548127; Tue, 10 Mar 2026 22:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w05Ga-00080W-DI; Tue, 10 Mar 2026 22:09:28 +0000 Received: by outflank-mailman (input) for mailman id 1250732; Tue, 10 Mar 2026 22:09:26 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w05GY-0007ze-RY for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 22:09:26 +0000 Received: from tor.source.kernel.org (tor.source.kernel.org [2600:3c04:e001:324:0:1991:8:25]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cb4c4229-1ccd-11f1-9ccf-f158ae23cfc8; Tue, 10 Mar 2026 23:09:23 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 3CBF6600B0; Tue, 10 Mar 2026 22:09:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8F86C19423; Tue, 10 Mar 2026 22:09:21 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cb4c4229-1ccd-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773180561; bh=W80lkFXkPyxzZPzLe6vTEN0SYi+yr5xZNTGscVmS0ko=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=L00YXZHPMVeEfxwGWu/AsurKr2xWM9c1K5M3MtDaIn5nfcen4jicy1Q3i8rLIm5yf WfvG20wIi1QYyAKqVzaODlOcIZAjN1oBjLxF9C/amXt1SGV5lxTwZfkpQvXdvW9gAg U5fgwzShrDb/Z15j0gztxNaymw4OC6qlveBz2cGZnyhROtlLohCqWPm8uXMsbT9F27 CbZuzIyVxmIfJ98YaFyJMcT3cZFIirNKa3bxELZvJJRpc3CFl/8aYvCTYeWpkA6BN0 oBTJJOco6wPHguHYPtf3q7EkbWZ3hux+WxUaIr/01eGtMcm8Pr8xqHRXg8MC7nxSZp RRiGt6sycGkpg== Date: Tue, 10 Mar 2026 17:09:20 -0500 From: Bjorn Helgaas To: Jeremy Linton Cc: Chengwen Feng , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org, Wathsala Vithanage Subject: Re: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Message-ID: <20260310220920.GA826995@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <657142d1-1632-4a3e-8800-ee1dd5763d78@arm.com> On Tue, Mar 10, 2026 at 10:58:49AM -0500, Jeremy Linton wrote: > On 3/9/26 10:20 PM, Chengwen Feng wrote: > > pcie_tph_get_cpu_st() is broken on ARM64: > > 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. > > cpu_uid should be the ACPI Processor UID [1]. > > 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via > > cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, > > generated and managed by kernel (e.g., [0,255] for a system with 256 > > logical CPU cores). > > 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the > > MADT table, and this UID may not match the kernel's logical CPU ID. > > When this occurs, the mismatch results in the wrong CPU steer-tag. > > 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID > > so the mismatch is not seen. > > int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, > > - unsigned int cpu_uid, u16 *tag) > > + unsigned int cpu, u16 *tag) > > { > > #ifdef CONFIG_ACPI > > + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); >From AI review (gemini/gemini-3.1-pro-preview): Does this code need to validate that `cpu` is within bounds before using it? Before this change, the `cpu_uid` parameter was passed opaquely to the ACPI firmware via `tph_invoke_dsm()`, which would gracefully handle invalid values. Now, `cpu` is treated as a logical CPU index and passed to `acpi_get_cpu_acpi_id(cpu)`. On architectures like arm64 and riscv, `acpi_get_cpu_acpi_id()` uses `cpu` directly as an array index (`&cpu_madt_gicc[cpu]` and `&cpu_madt_rintc[cpu]`). On x86, it uses `per_cpu(x86_cpu_to_acpiid, cpu)`. If a caller passes an out-of-bounds `cpu` index (for example, if an IRQ affinity mask is empty and `cpumask_first()` returns `nr_cpu_ids`, or if userspace passes an arbitrary ID via `mlx5_st_alloc_index()`), this will result in an out-of-bounds memory read. Consider adding a bounds check: if (cpu >= nr_cpu_ids) return -EINVAL; I agree that this is an issue, and I think implementations of acpi_get_cpu_acpi_id() should validate their inputs. I don't know if there's a value that can never be a valid ACPI CPU UID and could be used as an error value from acpi_get_cpu_acpi_id(). I do see a few mentions of a ~0 value meaning "all processors" (ACPI r6.6, sec 5.2.12.13). From xen-devel-bounces@lists.xenproject.org Tue Mar 10 22:40:14 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 10 Mar 2026 22:40:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250747.1548138 (Exim 4.92) (envelope-from ) id 1w05kG-0004TZ-Th; Tue, 10 Mar 2026 22:40:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250747.1548138; Tue, 10 Mar 2026 22:40:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w05kG-0004TS-Pl; Tue, 10 Mar 2026 22:40:08 +0000 Received: by outflank-mailman (input) for mailman id 1250747; Tue, 10 Mar 2026 22:40:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w05kF-0004Qt-2q for xen-devel@lists.xenproject.org; Tue, 10 Mar 2026 22:40:07 +0000 Received: from BN1PR04CU002.outbound.protection.outlook.com (mail-eastus2azlp170100001.outbound.protection.outlook.com [2a01:111:f403:c110::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 147ee745-1cd2-11f1-b164-2bf370ae4941; Tue, 10 Mar 2026 23:40:05 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SJ0PR03MB5518.namprd03.prod.outlook.com (2603:10b6:a03:289::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Tue, 10 Mar 2026 22:39: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%6]) with mapi id 15.20.9700.010; Tue, 10 Mar 2026 22:39:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 147ee745-1cd2-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a6FuBQTZVkw6lglQZbZt/z1EmdG/mFVt4TKI9z33VTEjNqO5EZhTJJ9QD3G7M8u862dh2j3Nr685tmvPF4E4RSS2JIucppG/0d4AIFMrSJ1bXxTu8MQ+nbAY3qnL+sjihiZol/Zu1W9pGAcfDiyB/S6P5DLf/oXGJMrKBCsCKW55jYUk+p99gZEISD1Y7Dhqfr8eOA9igocwL8EE8rvRtTL03YW0H0zx2OQh5PBBU5AQ6CqrI1/Cq/a20F6MLQigB97YfgoqGRrcJG6nH5N2m2vSA1q6zPRRULksDQw1luEURVtT61jamdF6p3JL2d3+aYSojiMlJpbGscp4AHSWaQ== 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=T5ya/14xemD/FSVbl/3h5BjXqa8QljYPw+uZsXlmhvw=; b=CeyqxuDd9d2EwajTtPP7/i2FyWwTlaa3rhz0vp9Y4Z2AuCqgoQSIHxAQgq4uH+lvh26ic0eVjrKEdBUhwYAVfLKITe9VNB2RNrOksWoYHn2QeoYCTBxqjNwea0a65Xt7GzwW1rnF0IVqqeHSfjLeeVO9IKbNBeAYTswo2o2URVkVI7fyLwxDAlGDBwK8Wy6JMa9LWJ+n7cfjolLdLqmszeOBtXfraY67/BDT0MLMxg35NfZo3zvuOtuGuI70IwTkwUGJzfhfe+UmExbpwVIlFdc56hT0UUeQLzO30YhRWls1uIzBOgLevgAIojwhlNuVMhWDuLuIHxoxxwO3qsRn/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=T5ya/14xemD/FSVbl/3h5BjXqa8QljYPw+uZsXlmhvw=; b=OLh0befGjmqooOT15+f6FYL3ssxtC8tCGnpIE/bGkf3niQsZWm68QvF385ug3uFfVMNALkBovNip2OiFvErwOWvTvixRQz80wSdHmxEHDRlcnS+BUMS2g/NrdM/RZEVrU8is3v9cwnarRyg/4fIVwpsLzYj9ub6jXHDa2WeNqMg= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <89f34cfe-7b77-4f66-b3ed-8104c5b50eaf@citrix.com> Date: Tue, 10 Mar 2026 22:39:48 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v5 1/2] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 To: Bjorn Helgaas , Chengwen Feng References: <20260310175305.GA730372@bhelgaas> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260310175305.GA730372@bhelgaas> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0131.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::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_|SJ0PR03MB5518:EE_ X-MS-Office365-Filtering-Correlation-Id: 6ec7f3b8-a59e-49fc-4842-08de7ef5f52f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|1800799024|376014|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: 0uGaJBptse/dAAqoo9odz6TEboL6x1eofnu0U5I34ebOa2ydcGqAcURoHxeqKeO3q62Mk5AIsz1uGpcRUD51NtKqNO+im0qexd9ilZKJZwf/sVWbvl9FkuGXGlAR406DyLp52UojePLAqEJKSJJpfuOlxgOnt0mVBkxJN6z+adZXzeuwWlSNTcE2sm5+Mcbo8rlNnBVBK6m2P7UzW2lI03Yai/YAtCivMkx7lshvcpmyQU6beOumt/PhWTn9VavQB6dxRkuFDRldT2anaLSy05shimis65lY/86L7Ph65C0dcQnAikX35j9vq3YffbG+ewMZatuwAvx+VS5mkXNpysipAZE0tCOIsJzprkl2htuAgKHB26cB8Iphxp8mgqHxR/pPpGtfkwbzfEm3umXlA6fyULummSFXzgYr0RBrckPf1CMtH3ML09mhbi9mhxjQUH34bLVxRTXGehvJAOmtHAO6RfZpxctAwHNM7zamEqCkqE8aE/PJuIGvCCiPOImsLdYDetUwzZ0rJHdApQ7O06VJcFegGh3y7W+1o+C0nnQmgSL9PsHd47dg7WEAMnQnNAAWK2NFmnJSgh0YtqnNlIPSgpV3/MKdVTRjoYv+CLIJEvylvZsytoZVU1dHgXCtt+w4UbfdU4HvNSO7E6+tC4V2GQzuo7Q8QClKdx2hbNmPlsDsaLWFnXZqMhwKxEvLMBFb6gQv2PJC14pljFl2sByALSYynly2akYCUwJFGmc= 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)(7416014)(1800799024)(376014)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yk5PbGRvSzVOcnFMOTR0c3hjbVZuNnZ4emp0MTJXcldGRDRRc2JyN0U2R25n?= =?utf-8?B?RXQ0Qng2QlppaWt3N1Nhckt2WS9TRHNkWkJYMVcxQWpzeVNCV2lkanhUajVv?= =?utf-8?B?eWpIbEF4Y1FPMzMvVDUvZFRia0I3M2crMTlEbGplR3VLUml1Ti94aVlyY2NU?= =?utf-8?B?b1MvdnJ6Uzc5S05uUmZPbi9NMzlQYkRuMkpSbTRCK25kMkwzQ3A4ekFmb1ky?= =?utf-8?B?NGJROTNkY05lZnZETVVqOW5tMlYzVk5HWnNQc3VrUkZ2K0xaRkwyVGpmQkl6?= =?utf-8?B?V0RjU2NtN2svclpta3FJa1Y1WGVyN01tQVVFelgrbENrcDdad0lLaUExbnNn?= =?utf-8?B?cUpCUnpVN3BCQ0kvRGdUYlhXa053aFlFVWVyVk5KejR1cWp6bmxNT0h1WXRE?= =?utf-8?B?QjV1L0FNdGhKNlR5QWVZdEZObHliK3czeTFlMUFUbVk5eHZXLzlyZHJYbTly?= =?utf-8?B?UFVtbU1PUVZNU2w1RjFUY0UybjRvbVFFSHl2L1BkTlUwKzlhakoySzI5aFR4?= =?utf-8?B?SHNySnJTNXZ1TDNLbDU2K3hjdFFpeldidUNFaCtGRFc0RkxvMEV1M2lHbjRx?= =?utf-8?B?aWx6d0ZpSVNudDdNUEk5amI3blo3cy9XNzNFZ3BTU0hkK01XTUJ2MUlabk10?= =?utf-8?B?N2x5b0VoZUh1WHhLV3o5dW1LZ2Jtb0RvOW94a1J5a1BBODhKNWpZRnZ4S2xH?= =?utf-8?B?WjlvdEdteWUxRG5ZZnVnbmUvYmE1bHBEciswOW1VbFREbzFlWksvbUJZRno5?= =?utf-8?B?UzFBU0YrVjROdTN0NnkrSXRtUFNuSFhNSE1KOXRTbXc3VUVoNUtWeEViclNa?= =?utf-8?B?d0FRemNqMGhERnZVaTAvMzQ3cFozNWtlczE2UVN5Sk4xNklPZkZkYTAzL2Mw?= =?utf-8?B?YjVxbXNTVjdBdTZSYVprQys4U1pZeUxlVmZ5dXY4S3N3U1VaL1FBazJHZ1Zl?= =?utf-8?B?R0ErTi84MHdlSFh0bENQS1d4d1NMbWdaci9SSkRPcDI1NDM3QlZZc0I2b1g5?= =?utf-8?B?UjFxbTRKVnI5S1dIclZXNVpMdVdnVHdQTDlreXlQRTdIcDQ3NGFwL1diY1kv?= =?utf-8?B?eHR4eWNOd09aNldnMUdaT09BOWhIQmYzM2VYTFVsQU8rcFRQdGdsYkloZkVR?= =?utf-8?B?NU9qRWlCYllPSmkydXFJZTlITHdKcDBFR1VTT3VUcVovcXJ1RnlCYVlNMlJy?= =?utf-8?B?V1RwMXNTblltZHZ3bzFnSmhRMEF1Q2JoM0RESjhYNHoxclVXYkFYZUd6R3oz?= =?utf-8?B?QkQzK0FoQndBRHIyVzl0dHJBRFByWUxZTXdpdURzSVNReXlXQ1BmZTBWVW9L?= =?utf-8?B?WmdwcEpXaU1KektuMFR2ZUlDRVNQelBPbDMvK0xRMTFtRzNHeXA3eEhQSm4r?= =?utf-8?B?WFNGaHVWQktaVTBzRmpmUngvMWQ0R1hGOVlnRjJ4Uk9Qb1o3Uzd0Yk9SUjlr?= =?utf-8?B?VGw4QzBKelF1c05LYnMydEg3ZE1odjczR21WWllIdFJjc3p4M0ZNMEN6MFNK?= =?utf-8?B?N1lrVXRrK3JvVzdVRUcvSlRMWVhFVFpiZDJ3UW1Ob2dkaktvL24zeUFKME8r?= =?utf-8?B?aW83N0dMWmhhUlIxMHRoZWY2UzlYdGd5L0ZHajNFaGh4ckpnblBVdFhJR3VB?= =?utf-8?B?TGx3djJITzJlblJXM1hBRFAvYjFjZWU4VTFQNThzbXBzSjBpMzErNkdCa25Q?= =?utf-8?B?V2Qxc1BPRDdBQkptbGxDaG9YSktVL09DNmV0VEhCTjh5MUMzS2dxV0pFVkpI?= =?utf-8?B?TXJTbGc2K3Mxbm5WWFFvV1JJdU55ZHl1bVg5aVlmQWkxUTdqL29Ra3Eya1Ny?= =?utf-8?B?eVlZZHN2ZWxabXZsdXFkSExFcUFYK0ZqQ2w2MFZ2eW85VGk5bjJ5bWNYZWhR?= =?utf-8?B?Z3FFV200Y1paTm5LV00xRnc2SnVCT0IrMDRkNlYwQkNkSnRlTEZmZXNWNVBK?= =?utf-8?B?NFdGdDIvRlEyZWlsWXVyd3lmeG5VQ3NERDlucndkaHd0a1lQMVpaTEJ5Q1Fl?= =?utf-8?B?by9QUThVdG83a0dPTWdKb081c1BQczBEdlJoU3dKcmVCZFJCZnZicTB4MlJ0?= =?utf-8?B?cUpwU2lTaWJxaDRNVFpUVTR4NHd3TnZXZEFoM0VJaDlPaE9PdDRQR3pRcUkz?= =?utf-8?B?T0s1bW1pem5uSkV2SnBaZ2N1TldjU212N2Z3YW0rNGsvSVJhTVFOcHRqYmVJ?= =?utf-8?B?VHpZK0tZMEZFbDRYbVdKYThoVDY1aXJYTlgraXk3UkdLMVY5RnhmL2RNUXZm?= =?utf-8?B?endqSUs3UWhRbG5mbWQ5NUh4MVh4QzlRT1NSclNJUnRTQXNWNkVQT1hLWlJQ?= =?utf-8?B?ajlPN0t2R2lSVUJwbXpLQTgvVDRDMmhRMkVEa0JYanBWREpRcmNmdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ec7f3b8-a59e-49fc-4842-08de7ef5f52f X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2026 22:39:58.0577 (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: w1CHoC9U+cpBf9KaJCKXbaFHOUzVk/9lCW28q1CpouRGxDPSK3i9wKvtNhtfeZBolw2H3VZagHko59xaJlcwT2gvUMZSFHWjbUx6esRQymE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR03MB5518 On 10/03/2026 5:53 pm, Bjorn Helgaas wrote: > - Split the x86 part to a separate patch and maybe (a tangent, but > looks dubious to me) figure out whether/why xen needs xen_vcpu_id > to be ACPI CPU IDs This is an unfortunate mess made decades ago with no good solution.  It's to do with how Xen and dom0 share responsibility for the system. Xen PV dom0 (only, but still widely in use; ring-deprivileging and predates hardware virt) is OSPM for the whole system, seeing the real ACPI tables but with a number of vCPUs generally less than the whole system. This causes Linux to have a split idea of what CPUs are, held together by hope and duct tape. Xen PVH dom0 (hardware virt) is OSPM, but has an MADT matching it's vCPU layout.  It still sees the system DSDT/etc, so while this is better from Linux's point of view, it's still not great. Regular unprivileged VMs get a fully coherent set of CPUID + ACPI tables. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Mar 11 02:58:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 02:58:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250772.1548146 (Exim 4.92) (envelope-from ) id 1w09ls-0007XH-18; Wed, 11 Mar 2026 02:58:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250772.1548146; Wed, 11 Mar 2026 02:58:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w09lr-0007X9-TT; Wed, 11 Mar 2026 02:58:03 +0000 Received: by outflank-mailman (input) for mailman id 1250772; Wed, 11 Mar 2026 02:58:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w09lp-0007X3-Ax for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 02:58:02 +0000 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1a08db0c-1cf6-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 03:57:57 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4fVwJc46ySz12LFG; Wed, 11 Mar 2026 10:52:16 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 2B67A2012A; Wed, 11 Mar 2026 10:57:52 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 11 Mar 2026 10:57:50 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1a08db0c-1cf6-11f1-9ccf-f158ae23cfc8 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=b36C7PXQWMtROHC3akP80A02jao7I70/cN0HO+5yrzc=; b=OIFuDbC2xS7Rgm+I36JhjfBBuNlrExfOc4b/6nZu5Eci5l3+fQS/kU6c0nfyQEGA12kX/Y7Hm Q4fnrBYIxytCYBOb9gfPVNmdxJt8Tvf2GHBr2Fdo4Eecx+kEiQ1JtKfbeg5YZs6XhpMHGRf3AdS dsh0tpvrdex5MaKPf2KuYUQ= Message-ID: Date: Wed, 11 Mar 2026 10:57:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/2] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 To: Bjorn Helgaas CC: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , References: <20260310175305.GA730372@bhelgaas> Content-Language: en-US From: fengchengwen In-Reply-To: <20260310175305.GA730372@bhelgaas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemk500009.china.huawei.com (7.202.194.94) On 3/11/2026 1:53 AM, Bjorn Helgaas wrote: > On Tue, Mar 10, 2026 at 11:20:48AM +0800, Chengwen Feng wrote: >> To unify the CPU ACPI ID retrieval interface across architectures, >> rename the existing get_acpi_id_for_cpu() function to >> acpi_get_cpu_acpi_id() on arm64/riscv/loongarch platforms. >> >> This is a pure rename with no functional change, preparing for a >> consistent ACPI Processor UID retrieval interface across all ACPI-enabled >> platforms. > > Really a question for the ACPI folks, but my preferences would be: > > - Simpler name for the interface, e.g., "acpi_get_cpu_id()" OK, and how about add u-, like: acpi_get_cpu_uid() > > - Single prototype in generic header, e.g., include/linux/acpi.h OK > > - Split the x86 part to a separate patch and maybe (a tangent, but > looks dubious to me) figure out whether/why xen needs xen_vcpu_id > to be ACPI CPU IDs OK for a separate patch for x86. Btw: the x86 implementation in 2/2 commit may has problem, please see the reply in 2/2 for detail. > >> Cc: stable@vger.kernel.org >> Signed-off-by: Chengwen Feng >> Reviewed-by: Jonathan Cameron >> --- >> arch/arm64/include/asm/acpi.h | 4 ++-- >> arch/loongarch/include/asm/acpi.h | 2 +- >> arch/riscv/include/asm/acpi.h | 2 +- >> arch/riscv/kernel/acpi_numa.c | 2 +- >> drivers/acpi/pptt.c | 16 ++++++++-------- >> drivers/acpi/riscv/rhct.c | 2 +- >> drivers/perf/arm_cspmu/arm_cspmu.c | 2 +- >> 7 files changed, 15 insertions(+), 15 deletions(-) > From xen-devel-bounces@lists.xenproject.org Wed Mar 11 03:00:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 03:00:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250780.1548155 (Exim 4.92) (envelope-from ) id 1w09o2-0000c2-A6; Wed, 11 Mar 2026 03:00:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250780.1548155; Wed, 11 Mar 2026 03: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 ) id 1w09o2-0000bv-71; Wed, 11 Mar 2026 03:00:18 +0000 Received: by outflank-mailman (input) for mailman id 1250780; Wed, 11 Mar 2026 03:00:17 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w09o1-0000bn-NE for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 03:00:17 +0000 Received: from canpmsgout07.his.huawei.com (canpmsgout07.his.huawei.com [113.46.200.222]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a6fdc8e-1cf6-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 04:00:13 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout07.his.huawei.com (SkyGuard) with ESMTPS id 4fVwMy3T5lzLlSf; Wed, 11 Mar 2026 10:55:10 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 7FEF34056C; Wed, 11 Mar 2026 11:00:05 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 11 Mar 2026 11:00:03 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a6fdc8e-1cf6-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=DUKycpPzpFIpG0env8jwSvfK5sQZJJ1YY0eqvDa9Ls4=; b=UIuMwL2ZnQBHKt0OSz5st4Og2VYIGREkqW4SE+XsyKkbHXGhNjJEsAWrxVSqy6OOZJ3NLbK9Z kP8s3Xd0pnLT2F4QMacoWnfn19/NxFuvNNLMkzdoJPW46wBbTVsZOQsEtjgpquwRCBs94A0/o7e g1HUZD+aWdwNP2wFTTnfWEY= Message-ID: <9ef9b529-839b-4cf0-a294-5b68fe8aa768@huawei.com> Date: Wed, 11 Mar 2026 11:00:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform To: Bjorn Helgaas , Jeremy Linton CC: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , Wathsala Vithanage References: <20260310220920.GA826995@bhelgaas> Content-Language: en-US From: fengchengwen In-Reply-To: <20260310220920.GA826995@bhelgaas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemk500009.china.huawei.com (7.202.194.94) On 3/11/2026 6:09 AM, Bjorn Helgaas wrote: > On Tue, Mar 10, 2026 at 10:58:49AM -0500, Jeremy Linton wrote: >> On 3/9/26 10:20 PM, Chengwen Feng wrote: >>> pcie_tph_get_cpu_st() is broken on ARM64: >>> 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. >>> cpu_uid should be the ACPI Processor UID [1]. >>> 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via >>> cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, >>> generated and managed by kernel (e.g., [0,255] for a system with 256 >>> logical CPU cores). >>> 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the >>> MADT table, and this UID may not match the kernel's logical CPU ID. >>> When this occurs, the mismatch results in the wrong CPU steer-tag. >>> 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID >>> so the mismatch is not seen. > >>> int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, >>> - unsigned int cpu_uid, u16 *tag) >>> + unsigned int cpu, u16 *tag) >>> { >>> #ifdef CONFIG_ACPI >>> + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); > > From AI review (gemini/gemini-3.1-pro-preview): > > Does this code need to validate that `cpu` is within bounds before > using it? Before this change, the `cpu_uid` parameter was passed > opaquely to the ACPI firmware via `tph_invoke_dsm()`, which would > gracefully handle invalid values. > > Now, `cpu` is treated as a logical CPU index and passed to > `acpi_get_cpu_acpi_id(cpu)`. On architectures like arm64 and riscv, > `acpi_get_cpu_acpi_id()` uses `cpu` directly as an array index > (`&cpu_madt_gicc[cpu]` and `&cpu_madt_rintc[cpu]`). On x86, it uses > `per_cpu(x86_cpu_to_acpiid, cpu)`. > > If a caller passes an out-of-bounds `cpu` index (for example, if an > IRQ affinity mask is empty and `cpumask_first()` returns > `nr_cpu_ids`, or if userspace passes an arbitrary ID via > `mlx5_st_alloc_index()`), this will result in an out-of-bounds > memory read. > > Consider adding a bounds check: > > if (cpu >= nr_cpu_ids) > return -EINVAL; > > I agree that this is an issue, and I think implementations of > acpi_get_cpu_acpi_id() should validate their inputs. > > I don't know if there's a value that can never be a valid ACPI CPU UID > and could be used as an error value from acpi_get_cpu_acpi_id(). I do > see a few mentions of a ~0 value meaning "all processors" (ACPI r6.6, > sec 5.2.12.13). I only have the ACPI Specification Version 6.5, so I will use v6.5 as an example. The ACPI specification does not define invalid value ranges for the ACPI UID. For the arm64 platform (Section 5.2.12.14): ACPI Processor UID: The OS associates this GICC Structure with a processor device object in the namespace when the _UID child object of the processor device evaluates to a numeric value that matches the numeric value in this field. I am concerned that we cannot implement it like this: int acpi_get_cpu_uid(unsigned int cpu) { if (cpu >= nr_cpu_ids) return -EINVAL; ... } or: u32 acpi_get_cpu_uid(unsigned int cpu) { if (cpu >= nr_cpu_ids) return U32_MAX; ... } How about implementing it as follows: s64 acpi_get_cpu_uid(unsigned int cpu) { if (cpu >= nr_cpu_ids) return -EINVAL; ... } or int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) { if (cpu >= nr_cpu_ids) return -EINVAL; *uid = xxx; return 0; } Another issue: This commit also provides an implementation for the x86 platform. However, further code analysis revealed a potential problem in the implementation: The acpi_get_cpu_acpi_id() retrieves uid from x86_cpu_to_acpiid in SMP, and x86_cpu_to_acpiid is set through the call chain: acpi_parse_lapic() -> topology_register_apic() -> topo_register_apic() -> topo_set_cpuids() -> x86_cpu_to_acpiid. It appears to retrieve the "ACPI Processor UID" from ACPI Section 5.2.12.2, but the problem is that this field is only one byte in length, which may cause issues in huge-core systems. Therefore, I suggest re-implementing the acpi_get_cpu_uid function for the x86 platform. Either I provide a default implementation (shown below), or x86 guys contribute to the implementation: s64 acpi_get_cpu_uid(unsigned int cpu) { if (cpu >= nr_cpu_ids) return -EINVAL; return cpu; } Thanks > From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:01:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:01:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250810.1548164 (Exim 4.92) (envelope-from ) id 1w0EVJ-0001dn-4b; Wed, 11 Mar 2026 08:01:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250810.1548164; Wed, 11 Mar 2026 08:01:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0EVJ-0001dg-0s; Wed, 11 Mar 2026 08:01:17 +0000 Received: by outflank-mailman (input) for mailman id 1250810; Wed, 11 Mar 2026 08:01:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0EVI-0001da-B3 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:01:16 +0000 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [2a00:1450:4864:20::432]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 79ead6ab-1d20-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 09:01:14 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-439f59dfda2so1028878f8f.2 for ; Wed, 11 Mar 2026 01:01: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-439f821e32csm4375761f8f.35.2026.03.11.01.01.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:01:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79ead6ab-1d20-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773216074; x=1773820874; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=oRTAnGYYsAovvMfRW9G1obKwSv/FK+Ba49eC5EWIi1A=; b=ewJCKMJpdTy+LAKbOsX9lC7HE3QztlFAviMyxVAVjhN3VEjf9Jd93/7Wf5NdTp74Fm iX4Hx1oX44MiU3uDCAI5MqUnYo6+q/0rmRhjh8JSODy+iSswp9RYVKznkdClIvgF4nlE 0k3DULclgmcPu7XCnW++9ZOQfNDnSwK6xOMYvmjfXz/xnP10cU4qQYaXAgALk0Wwv5gQ 5xiX+eSLXobeYOBNReUb/1g82tMuZ9U7RLk3lVauokQ4fdfDncrxGE0SZQSNE7nS6q0N xGPyOyemLjFWNwbc0EAMXswr1cj/Y1f9fFlbib5GfnwcB+acuKzUGYHUgFUGu+Kol4UY vm3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773216074; x=1773820874; h=content-transfer-encoding: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; bh=oRTAnGYYsAovvMfRW9G1obKwSv/FK+Ba49eC5EWIi1A=; b=WLP9NRXQ/YKt6aS9oqFfk30qpwRXjKNpN39JUTS97/VNyPwhup7SfZZVFTJf/OQi00 xzArDiMA4Gm6TJ7AecltTwODM9JWRlcjWZnGW72MILwKf8mD3UR0Jp6eVU/r1E8R+SI5 PyNAvjcgrOao58wx7X364x7TqSTZFMw7fuOrfc7i5NLh40szT4/gZXb+dndP3ffgW3S8 2cF+lJqUp7F/F0I4P1Cr8sDNrkoSzXAipPb5+LUeQo4VwpKUI22gPZ+x7Gvo8VSMv5Zq ut5F/3OCOOe/YBqgT75auAyWsGpJs3SgiwM8x7e+KvaNdO+2QPueglV/l4T7Ib3bpoLs AX+Q== X-Forwarded-Encrypted: i=1; AJvYcCWimZf+fNCkAt4/AChsWtVyOXqHPsFwqTO+qGWzY+kSJvxI2tdi8KUQGkRGWCZ8LN1TO/XTcSsZtHE=@lists.xenproject.org X-Gm-Message-State: AOJu0Yys+z/w3s8PgkHwwR/jQO11ssztsTpZbk79qxkAY0emTf/43fmK I8LjVzBGsI50LsRcMiqsMI+mVOCRjwGKydUg3gyjTbkBbZosJhxHGuo1O9dxfUaazjuTyYp0dCP wM0w= X-Gm-Gg: ATEYQzwk/UuF+x8hYOEBDn11wuLnb/wd43ISxB3Wq4EpeE92l6fBvN0wEEym4uEPfrJ YfchoSHLyHdoijzUN223VkmlTLQ0XewbRmPHW19KAZIn5+qPX/djC30D7L0NOtuQz/mNA/y3eZM mLsDTjh8jOgMI8tNLRy642Cio8BvBPPFsc1mZ/sTCLizXsPpfwOv5SNgmlNTc/OgxWQDQggc4tL uNVyu8Pttbw1reX+ZAiAzoOM5cAtTw3rDly9dM1Cs7aq+ZOJc+MnSCwAf45mPPrgtPp1lbmQ9H3 NicHei/iNigJM9hh+6fr86Zt7MASvkgzJFbg8yiygGIC5hcHifR4hPrk7JqPKytGCo2JRabKUVM gWqhs8yX1yXVzqjjr5b7RkkwO3D6sQ+qBQsFVkNDLRqrr/amrpSvgLYqkGOSm7h5Bw94lPluPfU iliKiRVCzZwP1oBprwulXXgQhVKB0suVXbIEh2+4d6GPdmx/qfYL6AucT39G4vF2kP+0TSpr6CW lcs4sPMcGKONkfMVyRCMLgFgw== X-Received: by 2002:a5d:5f82:0:b0:439:f55c:b574 with SMTP id ffacd0b85a97d-439f81f3c13mr2973735f8f.12.1773216073968; Wed, 11 Mar 2026 01:01:13 -0700 (PDT) Message-ID: <9b54666a-c61e-4cae-8234-f67ac8802947@suse.com> Date: Wed, 11 Mar 2026 09:01:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] x86/ioreq: Extend ioreq server to support multiple ioreq pages To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , xen-devel@lists.xenproject.org References: <20260305130434.635276-1-julian.vetter@vates.tech> <20260305130434.635276-2-julian.vetter@vates.tech> <5724bdb3-bec5-4159-a4f4-9bdad39acd7b@suse.com> <4509bc57-ea36-4208-b76b-465d15b25a09@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <4509bc57-ea36-4208-b76b-465d15b25a09@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.03.2026 21:56, Julian Vetter wrote: > On 3/10/26 17:09, Jan Beulich wrote: >> On 10.03.2026 16:56, Julian Vetter wrote: >>> On 3/10/26 16:36, Jan Beulich wrote: >>>> On 05.03.2026 14:04, Julian Vetter wrote: >>>>> @@ -45,7 +52,8 @@ struct ioreq_server { >>>>> /* Lock to serialize toolstack modifications */ >>>>> spinlock_t lock; >>>>> >>>>> - struct ioreq_page ioreq; >>>>> + ioreq_t *ioreq; >>>>> + gfn_t ioreq_gfn; >>>>> struct list_head ioreq_vcpu_list; >>>>> struct ioreq_page bufioreq; >>>> >>>> This change in data arrangement should in principle be independent of the >>>> step to supporting multiple pages. Hence it should be possible to separate >>>> out. Problem being that just by looking here and at hvm_{,un}map_ioreq_gfn() >>>> I can't conclude how you get away without the "page" field that struct >>>> ioreq_page had. If you can get away without, it's not quite clear why the >>>> field exists in the first place. If it's not needed, dropping it would be >>>> yet another separate, prereq change. At which point the remaining pair of >>>> fields could continue to be used, i.e. the change above then wouldn't be >>>> needed; va could be renamed if need be, and its type changed. >>> >>> Thank you again Jan for your feedback! I don't need the page anymore. >>> When I use vmap(), I don't need to keep track of it, because during >>> teardown, I can recover it via vmap_to_page(). Currently it's necessary >>> because in destroy_ring_for_helper we need the page, to be destroyed. >>> But I see now, on X86 the map_domain_page_global called from >>> prepare_ring_for_helper actually does vmap(&mfn, 1). So the page is also >>> from the vmap range. So for the teardown I assume a vmap_to_page() could >>> be used as well. But I also see there is a special case, if NDEBUG=1, >>> map_domain_page_global short-circuits to mfn_to_virt() for low MFNs >>> (putting the VA in the directmap range) and bypassing vmap. In that case >>> >>> vmap_to_page() would not work. So, this would be really messy. I would >>> rather switch the bufioreq also to an explicitly vmap()'ed page, then we >>> could remove the page pointer and both cases would be aligned again. >> >> That's an option. Yet are you aware of domain_page_map_to_mfn()? Perhaps >> that's what you want to switch to using in the patch removing the "page" >> field. To then, conditionally or uniformly, switch to vmap_to_{mfn,page}() >> when doing the multi-page work in the subsequent patch. > > Yes, thank you. I saw this function, but I was wondering whether it's a > good idea to wrap the va in two translation functions like: > > struct page_info *page = mfn_to_page(domain_page_map_to_mfn(va)); There's no fundamental problem with that (we have similar constructs elsewhere, I think), but ... > and then calling destroy_ring_for_helper() with it. But I will have a > look, and this way we would be again aligned between the two cases. So, > maybe it's the cleanest way. ... does destroy_ring_for_helper() actually need to have the page passed in? It's prepare_ring_for_helper() which calls __map_domain_page_global(), so destroy_ring_for_helper() could well obtain the MFN / page itself (using the above construct). VM event and vPL011 code also only ever use the page pointer supplied by prepare_ring_for_helper() to pass into destroy_ring_for_helper(). Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:19:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:19:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250822.1548173 (Exim 4.92) (envelope-from ) id 1w0EmW-0003Q4-J9; Wed, 11 Mar 2026 08:19:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250822.1548173; Wed, 11 Mar 2026 08: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 ) id 1w0EmW-0003Px-G6; Wed, 11 Mar 2026 08:19:04 +0000 Received: by outflank-mailman (input) for mailman id 1250822; Wed, 11 Mar 2026 08:19:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0EmV-0003Pp-9d for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:19:03 +0000 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [2a00:1450:4864:20::42e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f5129a28-1d22-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 09:19:00 +0100 (CET) Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-439b9b1900bso7417045f8f.1 for ; Wed, 11 Mar 2026 01:19: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-439f821d095sm4857322f8f.32.2026.03.11.01.18.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:18:59 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f5129a28-1d22-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773217140; x=1773821940; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=O6sc8H1H+f5MSSkuQGhURBScH13uJ0hgfCYgp5q5ld4=; b=KnSsPwFTrGfgyeDAa7/si7Hgd1gvV6Z7aA4rRGmtfGrqRcCLVl2vS43oZ5bks8n+O8 qKDqPLsTIxOY2vCnjj4HsqnulIBQCqFQrKiQQKh/IOj7Eiak7LHH/dSXNNskC7hQn1sf dJAV/l3v1zAHUrh10cIZ+N83hOkJEoq+2Ucer2codVfDVvD1uBuGZ87fsCXb1yfo/uS0 srYoaAdYiARybGSiCFMp4VigwCkpNLoaJQR5KIa+EHZ/4limnab6l2dJZQf62k/PdcI6 /XdX82v0gGT3UvKwDvP1fNcunVkUOaf5PxYA9pjvScGJdIJHeUI3gu7/wVj4Ed5Zplto Wm9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773217140; x=1773821940; h=content-transfer-encoding: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; bh=O6sc8H1H+f5MSSkuQGhURBScH13uJ0hgfCYgp5q5ld4=; b=elZzJn2G6AXU1BO1Lnkhe9475ataM9T9ES8NKQJ7ymuGAIGBVFp1fNGPXPupYIR7/P XGc5PNxx1Q5RZKoboFInl4pLYUiQ8ckh7yt/2TI5GpPgrTvZ/28NUZZRyF/SA22paLrT W2YHL9mM/Q7cHVSPsRXujX9RwRWZFER1FLTIvAZ40Db9q2suxO7z0BtpwZx3ZDcDwe/E eui8SWTyRiKMXtyfL/4WOCMj8wEy169IWaAUvVO7/RkOCJ7b6lpco/sZDu4Ae/UrjU1p 5by6hN629UcG4pAPKzz+AgKAfYipqUbABpkP7XToAgAq2O4TsIcBimXyJqoYJxaCFUhy 4ELA== X-Forwarded-Encrypted: i=1; AJvYcCWUkLPRI8IyPhfRu7nW6qfa60i/pnTzcWtpTmJIMEnF9y0VD38eqqWTKGbpU3u5dN8g1pofy3zgxBs=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw431vCLXHX7lr1h+WKH6WVcm8riLJH2/IuKOx3T2fdxQ+oFh17 PnYa5RapE129bb03fk0aW2oNGwRbrpIu0kI2O+dboudvEl78lCVqAYBExeEiqH5sHQ== X-Gm-Gg: ATEYQzys/ochPqNa7UPri7wjsB3vfduBK2xckOqGEIHCjrPQrfqb63uKVi8w7fbNOcZ 8cY0/uplTCQxfS1u88PNZ/7HnHvzTKQrLOoS6yYBN7cV7hhYVr20FbRFwIbOmEKsfcgHgjV/gQf nfLLUi6T2mDJiTv+QsWS6WufKxSZyeEo5z7EVS8SoCKJyowm20RKpWlzzPDVN+QZIGh1BBbvGCi +35sPbWlaSBi0PxMmGoWgaDI19DaBxGSNOpIsqh0RkhblWvACVjGUDAJmtYywWQ/vW4TufutmYK gggD22PkhTiVcDR7QpM0qUrRyeEKICH1+qoUHyf9nvyfdb6YPfspB4sTJwPjxzXqjG2gQttBnBz Jsj0FmrKUPuz1O+QwU0bk8x02ZGTkqckR2G4rl301P73YQaSTZOf6DCy0LEfOEezBaJfMRjAhZj 2hNtgO0mPTI46NriNoim+KqSn3EhvsRyla/KvozO5zjOQnzUMZxhsJBUALp7SQBw+wAv+0T7s8e IHMwMDgCXNKvks= X-Received: by 2002:a05:6000:1acc:b0:439:ef03:e0b7 with SMTP id ffacd0b85a97d-439f821ba49mr3269474f8f.27.1773217139684; Wed, 11 Mar 2026 01:18:59 -0700 (PDT) Message-ID: <7340581a-51a3-43b2-b180-c2de37bda4b1@suse.com> Date: Wed, 11 Mar 2026 09:18:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 01/27] xen/riscv: Implement ARCH_PAGING_MEMPOOL To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <887d914aa0ddb1884c19c9567d4633ecaf810066.1773157782.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <887d914aa0ddb1884c19c9567d4633ecaf810066.1773157782.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10.03.2026 18:08, Oleksii Kurochko wrote: > The p2m_freelist is used to allocate pages for the P2M, but to initialize > this list, domain_p2m_set_allocation() might be called. > This function is invoked in construct_domU() within the common Dom0less > code, and providing an implementation of domain_p2m_set_allocation() when > CONFIG_ARCH_PAGING_MEMPOOL=y is appropriate for RISC-V. With this wording it is odd to see ... > --- a/xen/arch/riscv/Kconfig > +++ b/xen/arch/riscv/Kconfig > @@ -1,5 +1,6 @@ > config RISCV > def_bool y > + select ARCH_PAGING_MEMPOOL ... this. You really want to settle on whether it is selected unconditionally or not. Also for the code below, where ... > --- a/xen/arch/riscv/Makefile > +++ b/xen/arch/riscv/Makefile > @@ -10,7 +10,7 @@ obj-y += irq.o > obj-y += kernel.o > obj-y += mm.o > obj-y += p2m.o > -obj-y += paging.o > +obj-$(CONFIG_ARCH_PAGING_MEMPOOL) += paging.o > obj-y += pt.o > obj-$(CONFIG_RISCV_64) += riscv64/ > obj-y += sbi.o ... this change and any #ifdef-ary further down aren't needed unless the select became conditional. (Plus with the change above things likely wouldn't even build if ARCH_PAGING_MEMPOOL could be off under certain conditions.) > --- a/xen/arch/riscv/p2m.c > +++ b/xen/arch/riscv/p2m.c > @@ -1568,3 +1568,34 @@ struct page_info *get_page_from_gfn(struct domain *d, unsigned long gfn, > > return page; > } > + > +#ifdef CONFIG_ARCH_PAGING_MEMPOOL > + > +int arch_set_paging_mempool_size(struct domain *d, uint64_t size) > +{ > + unsigned long pages = PFN_DOWN(size); > + bool preempted = false; > + int rc; > + > + if ( (size & ~PAGE_MASK) || /* Non page-sized request? */ > + pages != PFN_DOWN(size) ) /* 32-bit overflow? */ > + return -EINVAL; Can't this be had with just if ( ((paddr_t)pages << PAGE_SHIFT) != size ) return -EINVAL; (and perhaps utilizing pfn_to_paddr(), even if it's not a PFN we're dealing with here)? > + spin_lock(&d->arch.paging.lock); > + rc = p2m_set_allocation(d, pages, &preempted); > + spin_unlock(&d->arch.paging.lock); > + > + ASSERT(preempted == (rc == -ERESTART)); This actually suggests that (once again) Arm code perhaps shouldn't have been copied verbatim: There shouldn't be a need for the "preempted" state to be returned back in two distinct ways. > + return rc; > +} > + > +/* Return the size of the pool, in bytes. */ > +int arch_get_paging_mempool_size(struct domain *d, uint64_t *size) > +{ > + *size = (uint64_t)ACCESS_ONCE(d->arch.paging.total_pages) << PAGE_SHIFT; As per above, maybe use pfn_to_paddr()? Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:26:43 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:26:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250831.1548181 (Exim 4.92) (envelope-from ) id 1w0Etr-0004yb-8m; Wed, 11 Mar 2026 08:26:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250831.1548181; Wed, 11 Mar 2026 08:26:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Etr-0004yU-5t; Wed, 11 Mar 2026 08:26:39 +0000 Received: by outflank-mailman (input) for mailman id 1250831; Wed, 11 Mar 2026 08:26:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Etp-0004yO-C5 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:26:37 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 0456916a-1d24-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 09:26:35 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-48374014a77so163556905e9.3 for ; Wed, 11 Mar 2026 01:26: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-4854b65fe27sm38636615e9.9.2026.03.11.01.26.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:26:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0456916a-1d24-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773217595; x=1773822395; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=fR/7Rm1L0p85rks3QrTE23p/0Ae6Xjgc1bPPxxz3Xw0=; b=YTOqATIicIimI8ArLpLIlGXXv6YNETQDs28Ik+ZjbVGYENtyXazISp41qNUM+7s+Ol Dk0J7dLytMf3n45C8Sq6kEAhwzxxa39LFo8t9CuUCxMVq5UTmBiw+Rqgo+gQD9d0P0Ac hW74JkuqBFhdrIedR1C/5tyhmIun+IYnSj3RhMpBxotSVcO0jWAoNUKGaQ/DxBjnKqNw nElNIdrqDrKPIhXXKBsEOfAW6Xa1lUxoZsWdI0BVyDxE/76SwLA8JfE4NbCLpXqb4oGP skfv+OyS1TkGc0O5uN9pA0ysHtILElHPHPdLnDqOjdpP/BmIDMgGgG36w1YILcxGw1hU RaDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773217595; x=1773822395; h=content-transfer-encoding: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; bh=fR/7Rm1L0p85rks3QrTE23p/0Ae6Xjgc1bPPxxz3Xw0=; b=RJJeCHgBnWoSReXPuuJd+35Qce+FCY8ggBP+Sz2dI0YesHhKEuIi2RcFVQi6u5yXWL MkdGyY99qhkbnZvc9BI9lAAIO5FiTR2I5uM80Jxm948YWThH8jcP6prjLrj2DV/sxfYO VlD9jVBPyg8ss1xOhucQ8PZaHGL1kojz2JKEgDF50G8pOCBAaIq9HZ36Irjb6vYUsQQG 8Ptwp/fymVRMhrAm2H0cVhNgMxRwWkejsdKliVZZ7O4YENaTUTUCnjibO+EYW9QXpFJ/ YTDMeF31LpHDdtaOSKTaXwwtY/VIXGReVaWjkxcTojSUOFN5Pko0M+gDu8VSgZYR/Q8u tkyA== X-Forwarded-Encrypted: i=1; AJvYcCVQKerLN9I3g1LJFf363LSof1OZHshS2FVxNWBGiQ7WAeRthSziKV68kI5mMBfLRFGsuIK7BCkBp4Q=@lists.xenproject.org X-Gm-Message-State: AOJu0YyAp7m/YUDteKaPzhNxT7DrwLM0zEuUzYUysRIWFfkZqg+HklkO H8tlxLarqCkdJ9FPoXQY6w+QhZhoSdQus6e5vM0w8nI1wYGhE+0RHF3a930wuX3hbA== X-Gm-Gg: ATEYQzyv9p9PlEPh3S/4JDrKQkZnpTpdbX7OJGzncVpr4Yba4yBQPfTSphIPi6ZzYTh L8QlzRhkHk1C7Z2DF4g4FaRW1bm4GEWHOTSAzY6S9SeLXKri8ND3Ga0I2jb9aoQ7aeBB6UgdZvZ Ni1Ku5GwzQOodY78KoGXLPROknwzo32PETvIF6e9TCLSgM/KenaE+U6LcKtnTS32CccisiuBH/Y j61y6/9NP3E6K0Qn1ACc80qT/tQ1bxwd3M5+IIYMRxQ1L7WWllu7/yLdzAWiVIC/n3f8w8h3Dbd gBHGyw2JWlOvmV2oq6gdunN4zGOHNbQfX5S2i0fgo/NtmbsImI1mTSoUTVddCelZMt3m/slTS7i SnyHNdlI4lGd0+qHml1gNPddUoDruHPbEnugMg6TH0z2aJ0DnQWOc6mkodnBXyUNMWvDSWLI9LD Ss/2BeJWPyiPMlI1hM0O+L5OWrsenmYADP2K03zlTrdO7Q6tuCD0g1a8C/EcGkI+2QnovT0F1VQ Xk1kpZcPiK62vs= X-Received: by 2002:a05:600c:4fd5:b0:485:379b:57be with SMTP id 5b1f17b1804b1-4854b0cb6c7mr25223625e9.1.1773217595177; Wed, 11 Mar 2026 01:26:35 -0700 (PDT) Message-ID: <8ba61374-f05e-45d9-b1b2-0140edbb34a6@suse.com> Date: Wed, 11 Mar 2026 09:26:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/4] x86: Reject CPU policies with vendors other than the host's To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-2-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260213114232.42996-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.02.2026 12:42, Alejandro Vallejo wrote: > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -22,6 +22,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 > prior to the version 1.0 release, and there has been no development since > before then in Xen. > + - Domains can no longer run on a CPU vendor if they were initially launched > + on a different CPU vendor. This affects live migrations and save/restore > + workflows accross mixed-vendor hosts. Cross-vendor emulation has always > + been unreliable, but since 2017 with the advent of speculation security it > + became unsustainably so. While the code adjustment looks okay to me, the wording is a little odd. What is "run on a CPU vendor"? How about "Domains can no longer run on a system with CPUs of a vendor different from the one they were initially launched on"? Also, nit: "across". Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:35:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:35:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250842.1548192 (Exim 4.92) (envelope-from ) id 1w0F2U-0006dd-2v; Wed, 11 Mar 2026 08:35:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250842.1548192; Wed, 11 Mar 2026 08:35:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0F2T-0006dW-VZ; Wed, 11 Mar 2026 08:35:33 +0000 Received: by outflank-mailman (input) for mailman id 1250842; Wed, 11 Mar 2026 08:35:32 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0F2S-0006d1-KP for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:35:32 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 42ebfdbd-1d25-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 09:35:30 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-439c9bdc1eeso4312564f8f.3 for ; Wed, 11 Mar 2026 01:35: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-439f818d37fsm5318550f8f.6.2026.03.11.01.35.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:35:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 42ebfdbd-1d25-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773218129; x=1773822929; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=tvbgGrPtY8K4UHMB3U5NEEl1D6YAEBLJS4eiX3RElsc=; b=YQBiOPY0z+fAeKnUjrxP2vECyvRuWskBaxotSbgb7HrHE0Wj8ORr4MHYRZAhfwN94b GBS4kfSbSMUPtISvFETF5+54wuSyksy81MJz0UDoQ7Bn4L8oFu4XLSkSuGmekaifwK8Y tQWK6txVgpH9E9MMekPxaNCk//a7yteZSoj/mFD1erPutLt6R9yU0HScPM7rTKNgr5Np GilO8gNPsnbpafKV1HQmuWTA6rWU5CAT7oLGXYj4efVjmfEHqNvTU7Wcbt3nhkIkgm8D kDTFsUZ7KD4lWlIEdLkfJL7fI4EMJCfZ1pHfV56s9VXGjNPQQ8rwXy4ZL99cqXeWFMlL nPxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773218129; x=1773822929; h=content-transfer-encoding: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; bh=tvbgGrPtY8K4UHMB3U5NEEl1D6YAEBLJS4eiX3RElsc=; b=PaKnI7uqTADcGxwBP974CdR5kby04k86QKZSgyMuVhOt4Xh71UKcmZQg/OxnrdIxhM NwfedQY1qF/BZP6vbh+XXT/ZKY8s9N8DDuRqVdrFUh0KDP3yAhaWSN317XNd2PTjvPU3 T062QetN9okawX0hl9jxyDKksSTemvvWYdaFjvH/W9PBs8klS53b5GTTyBOjT363OBI5 ufnUK+w/6D6QhKhjSk9fGNOHmlaI4dTZ0/FCNA6Q9vE9ukgYWleb2Etqg6WicXs1QEWp +GyzoeHAmiTKQ94v/mbHTFTNTs6YODE+XaFKCdCxdDc/tHI+qKgIxJaTmsTA/adJDudm hVHw== X-Forwarded-Encrypted: i=1; AJvYcCU1mBJZXZfb6fFkxF+eyLmP7zGNige7dpF0CPWKVlkdcZJGBv0oBHEHoQy2YeTWNe1tavoLU81QiUc=@lists.xenproject.org X-Gm-Message-State: AOJu0YyxT+5tUoTLfLzS1aeEwDw687hZ/qMLdwqWTQmSmlykXTmQljR4 29sWaiHlYBHQwWK2l4f6qGjEwjSwymQWoKht9XSQezsVlkHhvWbbodJyBX/kXUJ85A== X-Gm-Gg: ATEYQzxaf5UGwTwQBP/Gq3BztwC4uQ0h+gnPkT37VBlrystbkWgZ0h4ws1/QTJkbx1L nbMhd2xk08zM4IuHQ1ZYCbZZRoANcfX9GRPs2Y1N7BzfJ3z+SD6i/TQgmZ6eu3Tmm2MO0FICas4 ihssMbX5dwClFJELItRTxB8lZMK0QAu/RDd3VuLi6lt7lV6rdR5kMQmFdNJZRhoVfsboMctDTUd /p0ZLC+fH2sChoZpjOZMOGHfB1V/m2UhTcuw2yJfgxjnp/0vZOCBIgQemDO0Z2KL6f4ipdCc1u2 lz4oNYzgITK4QEIVRN99/OcebjuKUNC3hQEQMZh+zmX38iBzy1vLEFsn4JUupsK181tHcpoBUfK Yq3DtnL9qI9upkAuYb2v9N/hLDNsqxI7RNIHzxd2JF6S5NB25376i6hMd6YWA3yVMQfIu+s7WYg 2nlnAGfENElDIDHs/JrcsR+0hSq2FhIAI7RlfxACiYr34yKCnpD0KkD8e94c4IZxSPj3ExZf4Ej XMAzWot2xSwAws= X-Received: by 2002:a05:6000:2283:b0:439:b886:20d3 with SMTP id ffacd0b85a97d-439f8200b9bmr3192877f8f.15.1773218129297; Wed, 11 Mar 2026 01:35:29 -0700 (PDT) Message-ID: <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> Date: Wed, 11 Mar 2026 09:35:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260213114232.42996-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.02.2026 12:42, Alejandro Vallejo wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3832,69 +3832,47 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, > return X86EMUL_OKAY; > } > > -static bool cf_check is_cross_vendor( > - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) > -{ > - switch ( ctxt->opcode ) > - { > - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ > - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ > - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ > - return true; > - } > - > - return false; > -} > - > void hvm_ud_intercept(struct cpu_user_regs *regs) > { > struct vcpu *cur = current; > - bool should_emulate = > - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; > struct hvm_emulate_ctxt ctxt; > + const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; > + uint32_t walk = PFEC_insn_fetch; > + unsigned long addr; > + char sig[5]; /* ud2; .ascii "xen" */ > > - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); > + if ( !opt_hvm_fep ) > + goto reinject; Is this possible at all, i.e. shouldn't there be ASSERT_UNREACHABLE() in addition if already the check is kept? > - if ( opt_hvm_fep ) > - { > - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; > - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > - ? PFEC_user_mode : 0) | PFEC_insn_fetch; Why is this initializer not retained? > - unsigned long addr; > - char sig[5]; /* ud2; .ascii "xen" */ > - > - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > - sizeof(sig), hvm_access_insn_fetch, > - cs, &addr) && > - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > - walk, NULL) == HVMTRANS_okay) && > - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > - { > - regs->rip += sizeof(sig); > - regs->eflags &= ~X86_EFLAGS_RF; > + hvm_emulate_init_once(&ctxt, NULL, regs); > > - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > - if ( !(hvm_long_mode_active(cur) && cs->l) ) > - regs->rip = (uint32_t)regs->rip; > + if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) > + walk |= PFEC_user_mode; > > - add_taint(TAINT_HVM_FEP); > + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > + sizeof(sig), hvm_access_insn_fetch, > + cs, &addr) && > + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > + walk, NULL) == HVMTRANS_okay) && > + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > + { > + regs->rip += sizeof(sig); > + regs->eflags &= ~X86_EFLAGS_RF; > > - should_emulate = true; > - } > - } > + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > + if ( !(hvm_long_mode_active(cur) && cs->l) ) > + regs->rip = (uint32_t)regs->rip; > > - if ( !should_emulate ) > - { > - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > - return; > + add_taint(TAINT_HVM_FEP); > } > + else > + goto reinject; > > switch ( hvm_emulate_one(&ctxt, VIO_no_completion) ) > { > case X86EMUL_UNHANDLEABLE: > case X86EMUL_UNIMPLEMENTED: > - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > - break; > + goto reinject; How about placing the reinject label here, along with the two case one? Jan > case X86EMUL_EXCEPTION: > hvm_inject_event(&ctxt.ctxt.event); > /* fall through */ > @@ -3902,6 +3880,11 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) > hvm_emulate_writeback(&ctxt); > break; > } > + > + return; > + > + reinject: > + hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > } > > enum hvm_intblk hvm_interrupt_blocked(struct vcpu *v, struct hvm_intack intack) From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:39:08 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:39:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250850.1548201 (Exim 4.92) (envelope-from ) id 1w0F5u-0007GU-I2; Wed, 11 Mar 2026 08:39:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250850.1548201; Wed, 11 Mar 2026 08: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 ) id 1w0F5u-0007GN-Dm; Wed, 11 Mar 2026 08:39:06 +0000 Received: by outflank-mailman (input) for mailman id 1250850; Wed, 11 Mar 2026 08:39:05 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0F5t-0007GH-Kw for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:39:05 +0000 Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [2a00:1450:4864:20::32b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id c20788d7-1d25-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 09:39:03 +0100 (CET) Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4853f2826f7so28724405e9.1 for ; Wed, 11 Mar 2026 01:39: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 ffacd0b85a97d-439f82067a2sm4046488f8f.28.2026.03.11.01.39.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:39:02 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c20788d7-1d25-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773218343; x=1773823143; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=aCL9RcADhWoF6tTbBriZJ3Qgz05gqQPhYRTzz+Ie2PY=; b=HTyEcmPF3/anPb8LP+eELRq9RGZljcvgU1K7NfQzKr1+2pKn+RkgWYc27cmvcjwPcO AZ8z271tez/XNub6M9m3p47qyrGg/7zuFlR0pa76sF5J8H8Cr7AvGYi+kyD7X6WF2zA0 0QiDALdgyplJHjZKHMJmqAql/9p2MiMxsGZf+Rk8KZpm56ZARSDEIxyPXnBFTV5GOwUK imdamOlTW0afTAuq3Gw94wyndqYrKOGLrDaqMrs/5QjmV2/dREdCWy4ByLQq089u8uQs UD3/v/pEWHiaN7xdCxBgI8aIP+aYWfestbPx0/UoVihy5+8e8N/xls6MYi09+PLbzfDj pu+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773218343; x=1773823143; h=content-transfer-encoding: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; bh=aCL9RcADhWoF6tTbBriZJ3Qgz05gqQPhYRTzz+Ie2PY=; b=RM0Fm/RWrNP6l9QKJ6gl8dbEgxz2/HmCTZ5odF+PJVxRYzXbONI3y9fA1Lx6HxGfhV 4dKf9xLieVL4Amsurnm/925UNz2pXMXQ5gl3uG6ys64iUy7ryGEii6AAUKjO5SKSoiw4 44h0WR07V76T2CsPfqdRe8T01cJ4nFbK5QPrbjKc6YU6RaN7UdVrEVy8ymymQEHTr2Le zt2myWF0eeSGjjAqydMOsYL9BH55TK/mqQdJ6b8UD9dra+ro835JBl7mYMimcBxN6Y0d P4DcWNo9U8QbHhRGUMyxcHDDgfPlaHruJmeQVS9bhUq28PL+bNj/pXtFmcXEUzmJ3IsT gtNw== X-Forwarded-Encrypted: i=1; AJvYcCUcnLz5/bC2nWjAsJ6S1qwwsTxYPl0stgrHNvckpmCQidzK+66dfh334e8JPOrLSzzIXJ4fp4oKQWw=@lists.xenproject.org X-Gm-Message-State: AOJu0YwygmK+GOqWyslGOHc//QXnvnmERPHWb9lP2V1BZhFDpsitvnTo 69Tqaq4SLOoq4pvkCjkGmLpK4JHCyLg6S/4a6xU2LG3a9W5y6i3Z/99UcoymGJE/4Q== X-Gm-Gg: ATEYQzxWxZLAT9Ra/jRmH1rlpB5C03Scd2JXQX+4IMb7hfTbGoJJAe0DJMevhelH2YB W2gfyOpti4uVhSZD+bL5lwztITZV3tbYxJqWkg0cbBncbnlmc74Uq7e21RxYagMj9AlcX0keGtl 5umPEaHDmdnlpwKAFxfXlp7Oc+O35yYDRATtGRKVguhB8va29EGjpg1slf9YigeW4fpjgslyEhC ucmpUwk2aovqWq3LpKhAZUTwX3/YIo/kybj/1vE4O+FCfxlkzpwhKSF8ZsGTR1650G34j0mSiNO 7YvD6nXJWay9u2kBcwJSVt4kq7F+DVEFYWjiEC/rI0Fa87l/rAM2RNawRoMhfIuMsuUGIpTen/1 GRotrguq9ltrVMxVnVw6q8WBoKRqnyiiwkKfQfKZ2zWxN2d/0BLCjGeitk23l0r71vdpyrNxWX6 3dS66Ti0a/r/MiDXuug4kSppRCkDgUTL1/aJsmwJZeR8S9WjykLHFa5lDwzotBlEyyikOHl+MaN ZuvoEsUIqKavPM= X-Received: by 2002:a05:600c:1d16:b0:485:3aa1:a7f0 with SMTP id 5b1f17b1804b1-4854b0a4a66mr26005415e9.4.1773218342668; Wed, 11 Mar 2026 01:39:02 -0700 (PDT) Message-ID: <6bde607b-7180-488c-a58a-c2eb281c7a47@suse.com> Date: Wed, 11 Mar 2026 09:39:02 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Teddy Astie , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-4-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260213114232.42996-4-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.02.2026 12:42, Alejandro Vallejo wrote: > Not a functional change now that cross-vendor guests are not launchable. > > Signed-off-by: Alejandro Vallejo > Reviewed-by: Teddy Astie Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:47:06 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:47:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250864.1548208 (Exim 4.92) (envelope-from ) id 1w0FDa-0000T2-Aa; Wed, 11 Mar 2026 08:47:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250864.1548208; Wed, 11 Mar 2026 08:47:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0FDa-0000Su-84; Wed, 11 Mar 2026 08:47:02 +0000 Received: by outflank-mailman (input) for mailman id 1250864; Wed, 11 Mar 2026 08:47:01 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0FDZ-0000Sn-9T for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:47:01 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dde0aaaf-1d26-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 09:46:59 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439b97a8a8cso9684433f8f.1 for ; Wed, 11 Mar 2026 01:46: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-439f81fcd65sm5509623f8f.26.2026.03.11.01.46.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:46:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dde0aaaf-1d26-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773218819; x=1773823619; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=oGFDLZX5gM93eSepe3XqoJ7xXgEg+qZIyv9kXP118Mo=; b=XxyHItVWsbE4CaQFqmOoLX8/aGVDEV7FMMwwJ8xLDbx2cEqxHY837LTnHfyfonQtCm H2ioINfFATVIC9v+n51HTH98aD3wrLyRTO3VpONn/4s1NupKPGLmPWArDOFluTmI9RXQ Y9XMilbp93nNUZdlxgEK8OPUSyUxWUQjXilnSBiWYI5VA4C+j44QqEN1vf+5gnt1E1a/ nD6oa6e3SQQrV3S52PnIWeAB6rgSyZoGs969DnV/J9RLLUmmeK7RVjv4aBO9agyqBLXW V6bsDi8H5RCLYxEe6jhrInvIa2UwY6KcQga3CD/UH+Q33mAjroJtVIuyyrEcm24WpOR4 iPCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773218819; x=1773823619; h=content-transfer-encoding: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; bh=oGFDLZX5gM93eSepe3XqoJ7xXgEg+qZIyv9kXP118Mo=; b=BUdpvBFgQpi/rpgfMf9c8MjaBniTvMwL3PfHOZRRDqkOR8ByH4JQdvt+8b3NN+uNlb svHgjD3jjtDPfznHTGT7L93E7aH+9R2kPMCA5xsOCvXhLwtPMRftDj4mvmzCuNLjwb77 VB2aPZWvr/2KZL8FOPqbv2aTfo7GkgMl5EosVj4BarwUJblthnTE1vOQ5+Hsy3c5y9IF 4AbCmHZgqNCnAv+XC0safLWRmRvN90GVf+1LDENLcLNg2j9Yn/LfkN0Ui311w9ecatrV MllCeOI7zl2APiG/g0mnYFzAyX7H1sAGIeCJLqa1NfoG3mzkqyAL64OXsBSEQi//kSal tFew== X-Forwarded-Encrypted: i=1; AJvYcCWR3cx9zAHxMBShNBscvPLBXXgreNUfgGlv2yPV8uM34PqlvlPavEL4ooGB/Qn+rVYIMVOTqcGQvp0=@lists.xenproject.org X-Gm-Message-State: AOJu0YyzKLDmPhbORWbXN+k40ICxOpoK+8x25bD7Tfap+U59dRyUN/uU lF75Sn9u9E9QKQjU3gLzzQzS5G4WLIfcMT/rn03JeGj3Om7JK9weA2isd0qCz591tw== X-Gm-Gg: ATEYQzyk051vkLk6/JuVVn31OiIEK9AU8Ak2isRvK65DFDe1TsjRe6azMiby75Bog+o FbXKmaz2idoKiQBjp7WRRDEqm6XKsAzROCfRVajf/umzKaM7xrD3SZc+mX9beDPUtTykrJecW4c JvkCcJZPN90zK9GpPv3vkvdaIU6xWR2XqDxE3LWOcP2NwMKuohmg2PUiDQCoVozhtVULWLjNap4 k0FNgWy3yMQWw+MuvJvO2hdKYrRAZeP/X7wBQ6StPdw1I/wmrtD/wEFG5e3inlUSOOWcMkbpab9 lgBmhnWql1oUBGQ29VHn8YpbyfIid0sHnQjwiSrxxgXcx6l984m3NPxohNvnnAnh2Knm5iMgXqx Se2rXy3dmU3Dnr4rcgL/hE42FgF3aifrtHg0cFdopGJYsP6X3hpRSF0rwMUzz4Zrwnb3/C5RKo0 zlV54QsJy7u90+s7frxRUBLz3W4rjIuUCmms3mPk2poehHSHKgfVHiaf2RtO9jYVsnsnr0pLPgq /9HesFVY734dvY= X-Received: by 2002:a5d:6702:0:b0:439:cba2:2294 with SMTP id ffacd0b85a97d-439f822a750mr2433089f8f.37.1773218819150; Wed, 11 Mar 2026 01:46:59 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 09:46:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-5-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260213114232.42996-5-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.02.2026 12:42, Alejandro Vallejo wrote: > @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) > { > struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > > + data->sysenter_cs = vmcb->sysenter_cs; > + data->sysenter_esp = vmcb->sysenter_esp; > + data->sysenter_eip = vmcb->sysenter_eip; > data->shadow_gs = vmcb->kerngsbase; > data->msr_lstar = vmcb->lstar; > data->msr_star = vmcb->star; May I suggest to do writes by increasing address order? I.e. while this already looks fine, ... > @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) > { > struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; > > - vmcb->kerngsbase = data->shadow_gs; > - vmcb->lstar = data->msr_lstar; > - vmcb->star = data->msr_star; > - vmcb->cstar = data->msr_cstar; > - vmcb->sfmask = data->msr_syscall_mask; > + vmcb->sysenter_cs = data->sysenter_cs; > + vmcb->sysenter_esp = data->sysenter_esp; > + vmcb->sysenter_eip = data->sysenter_eip; > + vmcb->kerngsbase = data->shadow_gs; > + vmcb->lstar = data->msr_lstar; > + vmcb->star = data->msr_star; > + vmcb->cstar = data->msr_cstar; > + vmcb->sfmask = data->msr_syscall_mask; > v->arch.hvm.guest_efer = data->msr_efer; > svm_update_guest_efer(v); > } ... your additions would want to move down here (and the other writes may then want re-ordering as well). Preferably with that: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 08:54:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 08:54:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250874.1548218 (Exim 4.92) (envelope-from ) id 1w0FKy-0002Cd-0s; Wed, 11 Mar 2026 08:54:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250874.1548218; Wed, 11 Mar 2026 08: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 ) id 1w0FKx-0002CW-UA; Wed, 11 Mar 2026 08:54:39 +0000 Received: by outflank-mailman (input) for mailman id 1250874; Wed, 11 Mar 2026 08:54:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0FKw-0002CQ-BG for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 08:54:38 +0000 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [2a00:1450:4864:20::435]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ee2f319a-1d27-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 09:54:36 +0100 (CET) Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-439aa2f8ebaso6843820f8f.2 for ; Wed, 11 Mar 2026 01:54: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 ffacd0b85a97d-439f81f13c3sm5579070f8f.25.2026.03.11.01.54.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 01:54:35 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee2f319a-1d27-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773219276; x=1773824076; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=KEmzCWoFICHnL/OTdXe2tyFSyHDNaVqSwlMvXnleBfw=; b=SXho9yVjP3OLNiOUkrWIQw8s/sBIOHD2rygH6SX6JHl+A55LJ/DOiNmOyvrw/PlK1y FFyP0YM75y1dMdxMBggTkfvjoKv6BaC907s2Z7JPlw93GhAOeTUAN2GoBby3cOKRAM15 slcUERU+W1//f9O/IQTaaLvzbfI2oKzO8T3NFk9IO6O091pzwPtH0CsUnvp2NcRzVeTB oEoFH/aF9wdvCGswSLTP33yVsLezeXNAM8HxMt80rlAm3lCCd23Apd5Ao3bYEAAstYph NPfhRNgTX3qJuef6gRPv/1cM3CljA26F4qhhu3y5f23IBcRAvmiG4oULRN6U73lfR4bW yFcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773219276; x=1773824076; h=content-transfer-encoding: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; bh=KEmzCWoFICHnL/OTdXe2tyFSyHDNaVqSwlMvXnleBfw=; b=rbsdw81Mwq8Fp61Z9Kv44TyZLFMZcps4I6HinxKrlzfnCRWoKorjgqGdgj9IJM21HL URzjgRvPkQH5FbPR9TbKXqjbbbqalAryfBT4DaSaqeuA7zx6HlEEzEYYdFfCUKhHCMKM bMgcThg2/t/BfDzo7uGztrerSCXocEqNZM/cfnOy4nxP53YlLExwIDmB6aWvYt9H7gsE nr0atNtxs+1iYUT7ZAPx6AlLnjDlHxkawrl7Ozl7UFyruyXi/p2Fov3OHh8Oa+xSZpDf R7l1l0hTZmrgBsA4Q617AWgK9lIWIZW2hvkRXFKTsF9mkcL//mAfrf+coZRgRGM++8Xq H4kg== X-Forwarded-Encrypted: i=1; AJvYcCXmXNGAgC1JzGlDQ1ZEEiw4zYintS0L9XjDmWoNiUswwJQywyU8G7q/KjJKi7Z4KErTdpX4IHkZcLw=@lists.xenproject.org X-Gm-Message-State: AOJu0YygPxAMXkRWw5HCELBaWMLYW7Djd+Sn0P2DKQmTBHMWpPodL+0t vfXBBJz8pvH7ViERT1zhQvx034T5BfUzrTfuCwuIW3HFltuzPNfIwtmnSwXru4BWDg== X-Gm-Gg: ATEYQzy85UM60dt9xV3uQ0sEuIvB7zYIVKhuWsXEpRczr0jEC+ZcnrTHrGqAFYn2QLc ZZkRez8g5/iB8D5qvKrgtJKxMhhYcOWS01/Jmr3dluOitvMWgm6I2nZf7J8/sEwjQWnIeCFXzmx 6NbPAmkdB8toId0ihrnoLmgQfiC32FcZg4xR3PRS3wb1JZY/TQjuXTwmuVr2DdKWprX9EwtQvMH 2dwhL+iQCMPvb05r/SKyy0UTqAyS/x5P+aUGMJGNAJr+xtfj7t8KuveThpyG68PAcr9dpfXq7aT aMxws6nt/9NKzuB+NrcpGMskxHRaNJXrh4axY5o4/GscbV4Xb/5LHhxBspjAqt9SNAPp7Fa8idZ EkCHdn0pZglKVHNCc9oLIrxRtke1DUgD8DF468rh4W83cpezYP39u5FVtWrtopKrNtp5Ab7oQDN 4o+5QUzl1It7GapxUSkIgZf1fVRkiIPkswlH+6f5TuBcKLKyoutvzqqUg8FO5ItsTl/HTDaOcnW Sxmwt061qlKUwY= X-Received: by 2002:a05:6000:2386:b0:439:de1d:74ac with SMTP id ffacd0b85a97d-439f81bd9fdmr3496975f8f.2.1773219276053; Wed, 11 Mar 2026 01:54:36 -0700 (PDT) Message-ID: <7973d3d1-8984-421f-88db-ca17ea3cb2ac@suse.com> Date: Wed, 11 Mar 2026 09:54:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 13.02.2026 12:42, Alejandro Vallejo wrote: > Alejandro Vallejo (4): > x86: Reject CPU policies with vendors other than the host's > x86/hvm: Disable cross-vendor handling in #UD handler > x86/hvm: Remove cross-vendor checks from MSR handlers. > x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,RET} in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still allow its use by introspection? Whether to then also permit those with HVM_FEP=y (but VM_EVENT=n) would be a follow-on question. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:16:23 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:16:23 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250887.1548228 (Exim 4.92) (envelope-from ) id 1w0Ffk-0005DF-Kg; Wed, 11 Mar 2026 09:16:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250887.1548228; Wed, 11 Mar 2026 09:16:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Ffk-0005D8-FZ; Wed, 11 Mar 2026 09:16:08 +0000 Received: by outflank-mailman (input) for mailman id 1250887; Wed, 11 Mar 2026 09:16:07 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Ffj-0005D2-GH for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:16:07 +0000 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [2a00:1450:4864:20::530]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id eeec09ae-1d2a-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 10:16:06 +0100 (CET) Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-6629fcc7460so3402174a12.1 for ; Wed, 11 Mar 2026 02:16: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-b972de092dcsm40225866b.4.2026.03.11.02.16.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 02:16:04 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: eeec09ae-1d2a-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773220565; x=1773825365; darn=lists.xenproject.org; h=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; bh=gmX47k16PCFMCXn0UmTzlCzGKMZSBXrDm/8qKo1TTnA=; b=c0svKAtN38btjWZZKFcLY1jazAFHY+KYpHteUh3nGvL1P/B/YEteM0A+a7GseMuV4U fAANyU6g1Q43AEq23fOZG6BdG4aTHO239YpZU5LKVYzBmKXeIy9jo8w0Fe9kj/x6psjI 2PLx6ccq4VeHQBtK5yX5JUavhjdeXoyDGJqE0ujdL0M63AnzfSNrwnjG3I1w9wJP0M7t swiSx7J/vHyG8QoNc5CakLAaP+64KqCtKH1yMtjvH3msf+5Poua2MjWqZqLuIjlDC0iY U8wOjC4jsvBjJzZDY/50K7IHPZQyYW58uTgKqDxPRYi+swRMpEMeLyMvb2AxpKXKtsZK fp8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773220565; x=1773825365; h=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; bh=gmX47k16PCFMCXn0UmTzlCzGKMZSBXrDm/8qKo1TTnA=; b=kU3ylz2FwqK4980rgZg6E7ddUz/MKmBZXB9XrMeME4tFgRgneBY2GBKPOXF9oTwFky urBClrTz3r8CSac+c2GoVrbbp9HoreAjEq+BawdnX/zDF03/JnaxXUgzToteUCsI0Rlt AQKJz8f5rx1gZ3pJF0QzMQ8X4jTCl+j9OENM6qqbd5ihF4Xp+EWcE6wU+543Z356ZMac eQbr8lR+BttJIsi9mDVNpEFhQD2+6qpKdGgib0ngmp2+zIPFD0OCGXYM2QS7YUr7xYeH yHpuzsgVh/8th6rV4vGsWEblmjn0yFh8kyZHjqL/qKAuceLugL/zgEeJajKSTXt+SAUz qNrw== X-Forwarded-Encrypted: i=1; AJvYcCXw58kYV+FMsJd8FAaJNfGbqz5GRnqkUhnMT501ak5RULuzLFLdJw+YOUDnhDZcHuE1al5gpzOtiu0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwmUDRWKR7pLIYE5grAsUHX2gCk5BDunh6ex7Wr599ILS0+Dkmn vlmNWRXj+MtepEAfy+Jtg/ZceBxCeFNG7gvOohv0QDR2Jv7qlGOryZX0yLseN1E8sfA= X-Gm-Gg: ATEYQzyBDpMMXHzDlkzP01w7Z6ObxGfTsaKzkvuGlWWNXHQyJs1dfqRG0O8MoxLpJDg 6kK56kGRJj01wcjxr/6YeQnsCJnWhcrqzJee80eQTCcf2psH8cMvTI/619SDsPd8OkHr67upjUU L7n0NTzVf6/ipzAj/rLrd2ezjaOxXKjn8CCijIWpzNeNh1ysF4TEFM8xx8cSJV3ltFu7Opt3A5e C6/gPZhNebD6ugE5iWW0hWjVa1Fj821EnrYDTGKa94oum5KWo32QqxFVfKJGnYKx/MbXjC17fOg ahsmOQONLsikp6J0C3cyHimZBLwE3ZhH45xPtKLQKOhcnsTbvfEAFzbdic8C+/U5Wq21eRkmtI+ 8VHEnUAGmbFS65NRJFjrGwBwPsAT7Op/gjd2vzZYUUNTQ+3b986PGD2DALFqLkzl5OKrbG3gWrZ btouUKREu7ymHT0a6RP/iIjI8S3VpMkUSxyjKu4fqobbdVHe+Z5U6+ZS6/4StzyTrYqa8UCg037 OXvcEWf7kI8ZLpS1Vdc9F9pFvngfzuKrEN7rJnlVe010yD0qJgC07yf0/BDa30p X-Received: by 2002:a17:906:fd84:b0:b94:1913:77fc with SMTP id a640c23a62f3a-b972e5f420emr107546366b.30.1773220565380; Wed, 11 Mar 2026 02:16:05 -0700 (PDT) Message-ID: <12b42fb2-092b-4ffc-9c5c-fd0bb7252bd3@suse.com> Date: Wed, 11 Mar 2026 10:16:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/6] x86: Cleanups around slow_down_io() To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe References: <20260119182632.596369-1-jgross@suse.com> Content-Language: en-US From: Juergen Gross 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: <20260119182632.596369-1-jgross@suse.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ly91FhzTvqqnaaaUYBZhau5n" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ly91FhzTvqqnaaaUYBZhau5n Content-Type: multipart/mixed; boundary="------------4QPs0Tl0IvPk0NeNwm0fH0rQ"; protected-headers="v1" From: Juergen Gross To: linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-block@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Ajay Kaher , Alexey Makhalov , Broadcom internal kernel review list , Paolo Bonzini , Vitaly Kuznetsov , Boris Ostrovsky , xen-devel@lists.xenproject.org, Denis Efremov , Jens Axboe Message-ID: <12b42fb2-092b-4ffc-9c5c-fd0bb7252bd3@suse.com> Subject: Re: [PATCH v4 0/6] x86: Cleanups around slow_down_io() References: <20260119182632.596369-1-jgross@suse.com> In-Reply-To: <20260119182632.596369-1-jgross@suse.com> --------------4QPs0Tl0IvPk0NeNwm0fH0rQ Content-Type: multipart/mixed; boundary="------------ykCYmYZPmbNUyjW9yglZ6jAJ" --------------ykCYmYZPmbNUyjW9yglZ6jAJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTkuMDEuMjYgMTk6MjYsIEp1ZXJnZW4gR3Jvc3Mgd3JvdGU6DQo+IFdoaWxlIGxvb2tp bmcgYXQgcGFyYXZpcnQgY2xlYW51cHMgSSBzdHVtYmxlZCBvdmVyIHNsb3dfZG93bl9pbygp IGFuZA0KPiB0aGUgcmVsYXRlZCBSRUFMTFlfU0xPV19JTyBkZWZpbmUuDQo+IA0KPiBEbyBz ZXZlcmFsIGNsZWFudXBzLCByZXN1bHRpbmcgaW4gYSBkZWxldGlvbiBvZiBSRUFMTFlfU0xP V19JTyBhbmQgdGhlDQo+IGlvX2RlbGF5KCkgcGFyYXZpcnQgZnVuY3Rpb24gaG9vay4NCj4g DQo+IFBhdGNoIDQgaXMgcmVtb3ZpbmcgdGhlIGNvbmZpZyBvcHRpb25zIGZvciBzZWxlY3Rp bmcgdGhlIGRlZmF1bHQgZGVsYXkNCj4gbWVjaGFuaXNtIGFuZCBzZXRzIHRoZSBkZWZhdWx0 IHRvICJubyBkZWxheSIuIFRoaXMgaXMgaW4gcHJlcGFyYXRpb24gb2YNCj4gcmVtb3Zpbmcg dGhlIGlvX2RlbGF5KCkgZnVuY3Rpb25hbGl0eSBjb21wbGV0ZWx5LCBhcyBzdWdnZXN0ZWQg YnkgSW5nbw0KPiBNb2xuYXIuDQo+IA0KPiBQYXRjaCA1IGlzIGFkZGluZyBhbiBhZGRpdGlv bmFsIGNvbmZpZyBvcHRpb24gYWxsb3dpbmcgdG8gYXZvaWQNCj4gYnVpbGRpbmcgaW9fZGVs YXkuYyAoZGVmYXVsdCBpcyBzdGlsbCB0byBidWlsZCBpdCkuDQo+IA0KPiBDaGFuZ2VzIGlu IFYyOg0KPiAtIHBhdGNoZXMgMiBhbmQgMyBvZiBWMSBoYXZlIGJlZW4gYXBwbGllZA0KPiAt IG5ldyBwYXRjaGVzIDQgYW5kIDUNCj4gDQo+IENoYW5nZXMgaW4gVjM6DQo+IC0gcmViYXNl IHRvIHRpcC9tYXN0ZXIga2VybmVsIGJyYW5jaA0KPiANCj4gQ2hhbmdlcyBpbiBWNDoNCj4g LSBhZGQgcGF0Y2ggMSBhcyBwcmVyZXEgcGF0Y2ggdG8gdGhlIHNlcmllcw0KPiANCj4gSnVl cmdlbiBHcm9zcyAoNik6DQo+ICAgIHg4Ni9pcnFmbGFnczogRml4IGJ1aWxkIGZhaWx1cmUN Cj4gICAgeDg2L3BhcmF2aXJ0OiBSZXBsYWNlIGlvX2RlbGF5KCkgaG9vayB3aXRoIGEgYm9v bA0KPiAgICBibG9jay9mbG9wcHk6IERvbid0IHVzZSBSRUFMTFlfU0xPV19JTyBmb3IgZGVs YXlzDQo+ICAgIHg4Ni9pbzogUmVtb3ZlIFJFQUxMWV9TTE9XX0lPIGhhbmRsaW5nDQo+ICAg IHg4Ni9pb19kZWxheTogU3dpdGNoIGlvX2RlbGF5KCkgZGVmYXVsdCBtZWNoYW5pc20gdG8g Im5vbmUiDQo+ICAgIHg4Ni9pb19kZWxheTogQWRkIGNvbmZpZyBvcHRpb24gZm9yIGNvbnRy b2xsaW5nIGJ1aWxkIG9mIGlvX2RlbGF5Lg0KPiANCj4gICBhcmNoL3g4Ni9LY29uZmlnICAg ICAgICAgICAgICAgICAgICAgIHwgIDggKysrDQo+ICAgYXJjaC94ODYvS2NvbmZpZy5kZWJ1 ZyAgICAgICAgICAgICAgICB8IDMwIC0tLS0tLS0tLS0NCj4gICBhcmNoL3g4Ni9pbmNsdWRl L2FzbS9mbG9wcHkuaCAgICAgICAgIHwgMzEgKysrKysrKystLQ0KPiAgIGFyY2gveDg2L2lu Y2x1ZGUvYXNtL2lvLmggICAgICAgICAgICAgfCAxOSArKysrLS0tDQo+ICAgYXJjaC94ODYv aW5jbHVkZS9hc20vaXJxZmxhZ3MuaCAgICAgICB8ICA2ICstDQo+ICAgYXJjaC94ODYvaW5j bHVkZS9hc20vcGFyYXZpcnQtYmFzZS5oICB8ICA2ICsrDQo+ICAgYXJjaC94ODYvaW5jbHVk ZS9hc20vcGFyYXZpcnQuaCAgICAgICB8IDExIC0tLS0NCj4gICBhcmNoL3g4Ni9pbmNsdWRl L2FzbS9wYXJhdmlydF90eXBlcy5oIHwgIDIgLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9NYWtl ZmlsZSAgICAgICAgICAgICAgfCAgMyArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9jcHUvdm13 YXJlLmMgICAgICAgICAgfCAgMiArLQ0KPiAgIGFyY2gveDg2L2tlcm5lbC9pb19kZWxheS5j ICAgICAgICAgICAgfCA4MSArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICBhcmNo L3g4Ni9rZXJuZWwva3ZtLmMgICAgICAgICAgICAgICAgIHwgIDggKy0tDQo+ICAgYXJjaC94 ODYva2VybmVsL3BhcmF2aXJ0LmMgICAgICAgICAgICB8ICAzICstDQo+ICAgYXJjaC94ODYv a2VybmVsL3NldHVwLmMgICAgICAgICAgICAgICB8ICA0ICstDQo+ICAgYXJjaC94ODYveGVu L2VubGlnaHRlbl9wdi5jICAgICAgICAgICB8ICA2ICstDQo+ICAgZHJpdmVycy9ibG9jay9m bG9wcHkuYyAgICAgICAgICAgICAgICB8ICAyIC0NCj4gICAxNiBmaWxlcyBjaGFuZ2VkLCA2 MyBpbnNlcnRpb25zKCspLCAxNTkgZGVsZXRpb25zKC0pDQo+IA0KDQpBbnkgY29tbWVudHM/ DQoNCg0KSnVlcmdlbg0K --------------ykCYmYZPmbNUyjW9yglZ6jAJ 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----- --------------ykCYmYZPmbNUyjW9yglZ6jAJ-- --------------4QPs0Tl0IvPk0NeNwm0fH0rQ-- --------------ly91FhzTvqqnaaaUYBZhau5n 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/Ey8FAmmxMtQFAwAAAAAACgkQsN6d1ii/Ey8A eQf8CHdFysN8bD+Zo0Oxso2E1yhRpRH1owAFupCVGF3BUqTaDASBcCuvsG9/Ki0F45119ijMsBjw TFDm/0+5boYGwCqHqvHsFCMdMaYRmVqFecdT+YS0Y1P8gY6ss0Gss8aOnF3DBJWGJ/9uxlToJYSt Iskf/Ngli/nA6twrtqlX4PqF/9uX5QpAERj607WFkQ7ObvTNpZAyejlnTJPxR2yrb9d9mrrm4LHt 7LOvBn+R2GCJhztJ9ROE7yBNFNjwyUu63vPCc3wShFdxXqjKXiuOvlC87MCbfL6crZr1nRX//HDj Vj9OPYJkGm0vldthYiLXqEmDUTp7IhKoXgrM9Ks6jg== =uMUn -----END PGP SIGNATURE----- --------------ly91FhzTvqqnaaaUYBZhau5n-- From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:26:04 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:26:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250900.1548237 (Exim 4.92) (envelope-from ) id 1w0FpH-00074U-Kg; Wed, 11 Mar 2026 09:25:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250900.1548237; Wed, 11 Mar 2026 09:25:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0FpH-00074N-GP; Wed, 11 Mar 2026 09:25:59 +0000 Received: by outflank-mailman (input) for mailman id 1250900; Wed, 11 Mar 2026 09:25:57 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0FpF-00074B-LS for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:25:57 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4e42b940-1d2c-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 10:25:55 +0100 (CET) Received: from CH2PR04CA0030.namprd04.prod.outlook.com (2603:10b6:610:52::40) by LV3PR12MB9260.namprd12.prod.outlook.com (2603:10b6:408:1b4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 09:25:50 +0000 Received: from CH3PEPF00000010.namprd04.prod.outlook.com (2603:10b6:610:52:cafe::ca) by CH2PR04CA0030.outlook.office365.com (2603:10b6:610:52::40) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Wed, 11 Mar 2026 09:25:34 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CH3PEPF00000010.mail.protection.outlook.com (10.167.244.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 09:25:50 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 04:25:48 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4e42b940-1d2c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yOx4SZn4AatKtIlfHsnZPcb00TzI+P8uldrOpJ9AOlvd8FqBJfh3OB431YfZSpAX/89yzXl75NnmPPOcLffbofwWbuavqDHZG+CRiaszC4vNtaiGUqzCekJya1BFSa9uNQJsJDt8uM/4tJS5HOMnq19ir/otQLL2GeyOiDNQtOgEpUns6qXYt2WtOelDviARpYaa4LJ0r+Q/X6ykbKwuP0dS4jJSW90VwPbov1cQOQb0Uav5SIiUjO4l4niLDMfYITmply1oAYUf2wuwHqwCliObLqmho07/mKDqaBZjdGoPXjZcE8ej/GzbvCddRtJNbzn0irztCjbCUsi48ySc9A== 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=zLoPqqk2GbJd+TGmLW1ceGwAgHSMyplTDrP7Rk8/y5E=; b=e1Rd9NyYDFleyDFFRJPNee9cKdGsm1+u3k2fplEZ6IkTIs1q/rl9C2pU0cj2qVrPqeGW4pWnDjrUxbwKl39SyocKYDj3krUvHc4U6GDJjXGrIsPFnZRFSy2Qhdi+IDMbwIqP6mNSSv+6shzUsgZorX/QQZtDvNw8/8f1BB0M3EjvVo+IHc2MUfJSzxr25m6ZWIASFiREkQfSzCWkysY+nu57jikGWfqM8mklPTmUw3jFuRHmJtgvt2HBP2MyzLuYkPqlFCXiz2tj80LoY5x8wg0q1z3rmRFqB4bCnw/4gmb/XPepQMSX8hCBr8/0cI9natmHUb/bf0TyxEbNJb52oQ== 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=zLoPqqk2GbJd+TGmLW1ceGwAgHSMyplTDrP7Rk8/y5E=; b=UxEuOJ7bT7+vyIQ6OJ/1U7dNAT/ISDHs2fzBNYy3KpoM8EzIjVqqDw5NblK4Ku1+p3LoRuV/rShyKI8zlFKMwe5A5tnL/M7q0LeS5brFi1tlL5LiqO+/dWdWHyQDBD4f/ipK5+VjbX2rDcxwlNIi6/z5V5V5J2fJPmJ+jHJ6KGg= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 10:25:41 +0100 Message-ID: From: Alejandro Vallejo To: Jan Beulich CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> In-Reply-To: <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> 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: CH3PEPF00000010:EE_|LV3PR12MB9260:EE_ X-MS-Office365-Filtering-Correlation-Id: cc7edca8-cc75-4196-a885-08de7f502f53 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: 8zfur7QN5nECEbhWh7dW/az+PDaB9NABwK1nRl0zcqZw0Rg5w+IQN7YiCTeHcVXkV7wm8gw7Rxmi/vJGX4pSZwxQB+b7UTqch34bW+ZIV2NsvWGdagoB8S60FSIT2BMPwB+BQ8HqkrxAML4fJ26RZThkASF3GrzJy9/UcDU3PtyO6djSqA68S4aDN3I946IQRcFy2ypyokTOn3j37OatsA6PpSYO/XlkjPBKl5a616wBIcx9OUHhydu8Z1mvXqdaCaRL/DGm1mvH7ucBixTRDcUi8ChVZX94cQVvGpFRs489E9DRQUIBg7sUduhiRchJG6yoHedNeRayj11tXi6ayOUeLHPATxnvBTDQWowv7sI7XC2jvMqDKZ/HGXaZzrf/gFDnBe4b8OWCdGU88wM7ZzYLiehdKQq0dO0lHkUemF3oLbHvc9AHtM5/k5UeUp2HM6G9ppuMzr02MDWJprgQ2p8V57V8uwv0Tz9QZ2L308Jzp24l6nYEX5mKooPZP2fPQCNlSVUihpIaq0cPzsgHTEI0URfQLF1DB+M9IoSFuzUeMgad+ASt01wTWhC8iIa+VtORfjan9IVJjNmgzjOpGUXT2UfwawSTBmeEFuoSqBiXYfn9Lrw9+UngklKdQ1ftGXsL5Uw48u1yzuba9ceLNVvzGV6MltCJOSmu6G3Zlj/ZLzpKykpjWLvrkofGPtnt8KpDD9py1OfoaKhyUcSEIb9ATlN/7Um84f1CLWdmx/CNdmsKZxOsdWG+wwqb8URWTIrFrKUUZ66j509BCMI7vg== 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)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 2vWd5F5t4ewEj8tvFzBbUfVBaYO3eiF5vT54cc3QjAnRiS691cnWo8rvBOEhL2Wqg4VjVIx8OzmFBMEPe2cEJLXGuzOceJp3doTxQ6IZ/Ssch1XxkRjMUdbHSicelkeqD5O9jpm0Q7HOWiN+cnwO4QenjWsjDDH2jPximrlqcrrFbsL23AzSN5HaHuKmDEhkRIqJdd0yrQW0XJkB4qY+uTlzMLC1ZXVVdBga0mDWzicwcCtIMeEfh8V2En8L7sXRiTj8zGXisvM5+j9hEBJk37McYgODFRyfVP6fhn3TCGpKKoyC04nnGudf76PsYMmOF+DaVCUzEq8T6En0bP9+RNmpwQPU1y36M/HaGyojjR+s9EwJ+cJzTWnProiSl2XLKbFuB1XVIgsavTwq76DAFj6eIlLnGrgZLb/YZwUP1pWNdYzOt1ImT0YhaN2Zj84x X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 09:25:50.0774 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cc7edca8-cc75-4196-a885-08de7f502f53 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: CH3PEPF00000010.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR12MB9260 On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: > On 13.02.2026 12:42, Alejandro Vallejo wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -3832,69 +3832,47 @@ int hvm_descriptor_access_intercept(uint64_t exi= t_info, >> return X86EMUL_OKAY; >> } >> =20 >> -static bool cf_check is_cross_vendor( >> - const struct x86_emulate_state *state, const struct x86_emulate_ctx= t *ctxt) >> -{ >> - switch ( ctxt->opcode ) >> - { >> - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ >> - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ >> - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ >> - return true; >> - } >> - >> - return false; >> -} >> - >> void hvm_ud_intercept(struct cpu_user_regs *regs) >> { >> struct vcpu *cur =3D current; >> - bool should_emulate =3D >> - cur->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_vend= or; >> struct hvm_emulate_ctxt ctxt; >> + const struct segment_register *cs =3D &ctxt.seg_reg[x86_seg_cs]; >> + uint32_t walk =3D PFEC_insn_fetch; >> + unsigned long addr; >> + char sig[5]; /* ud2; .ascii "xen" */ >> =20 >> - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, = regs); >> + if ( !opt_hvm_fep ) >> + goto reinject; > > Is this possible at all, i.e. shouldn't there be ASSERT_UNREACHABLE() in > addition if already the check is kept? It isn't. v2 used to BUG_ON() at VMEXIT when !HVM_FEP and compile out this handler altogether, but Andrew was unhappy with it because he uses it occasionally = and it'd be more of a PITA to undo the removal or force a HVM_FEP-enabled hyper= visor for the #UD handler to be present at all. I have no strong views on the ASSERT. It's not expected to happen, but I do= n't expect the existing conditions to change either, and if they do that will w= arrant a change in the handler too.=20 If you want it I can add it, but if we're not killing the handler in releas= e I don't think it's very helpful to assert/bug_on. > >> - if ( opt_hvm_fep ) >> - { >> - const struct segment_register *cs =3D &ctxt.seg_reg[x86_seg_cs]= ; >> - uint32_t walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) >> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > Why is this initializer not retained? It is, it's just that the diff is terrible. An unfortunate side effect of t= he removal of the braces. The scope collapsing forces it on top of the functio= n, before the emulation context is initialised. It's set up in steps. walk is unconditionally initialised as isnsn_fetch, a= nd later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL =3D=3D = 3. See... > >> - unsigned long addr; >> - char sig[5]; /* ud2; .ascii "xen" */ >> - >> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >> - sizeof(sig), hvm_access_insn_fe= tch, >> - cs, &addr) && >> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >> - walk, NULL) =3D=3D HVMTRANS_ok= ay) && >> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) =3D=3D 0) ) >> - { >> - regs->rip +=3D sizeof(sig); >> - regs->eflags &=3D ~X86_EFLAGS_RF; >> + hvm_emulate_init_once(&ctxt, NULL, regs); >> =20 >> - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ >> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >> - regs->rip =3D (uint32_t)regs->rip; >> + if ( ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3 ) >> + walk |=3D PFEC_user_mode; ... here. >> =20 >> - add_taint(TAINT_HVM_FEP); >> + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >> + sizeof(sig), hvm_access_insn_fetch, >> + cs, &addr) && >> + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >> + walk, NULL) =3D=3D HVMTRANS_okay) = && >> + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) =3D=3D 0) ) >> + { >> + regs->rip +=3D sizeof(sig); >> + regs->eflags &=3D ~X86_EFLAGS_RF; >> =20 >> - should_emulate =3D true; >> - } >> - } >> + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ >> + if ( !(hvm_long_mode_active(cur) && cs->l) ) >> + regs->rip =3D (uint32_t)regs->rip; >> =20 >> - if ( !should_emulate ) >> - { >> - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); >> - return; >> + add_taint(TAINT_HVM_FEP); >> } >> + else >> + goto reinject; >> =20 >> switch ( hvm_emulate_one(&ctxt, VIO_no_completion) ) >> { >> case X86EMUL_UNHANDLEABLE: >> case X86EMUL_UNIMPLEMENTED: >> - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); >> - break; >> + goto reinject; > > How about placing the reinject label here, along with the two case one? > > Jan Sure. That works too. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:27:37 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:27:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250908.1548246 (Exim 4.92) (envelope-from ) id 1w0Fqp-0007hN-UZ; Wed, 11 Mar 2026 09:27:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250908.1548246; Wed, 11 Mar 2026 09:27:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Fqp-0007hE-QX; Wed, 11 Mar 2026 09:27:35 +0000 Received: by outflank-mailman (input) for mailman id 1250908; Wed, 11 Mar 2026 09:27:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Fqo-0007h2-HF for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:27:34 +0000 Received: from BL0PR03CU003.outbound.protection.outlook.com (mail-eastusazlp170120007.outbound.protection.outlook.com [2a01:111:f403:c101::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 87f1909d-1d2c-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 10:27:33 +0100 (CET) Received: from CH0PR03CA0227.namprd03.prod.outlook.com (2603:10b6:610:e7::22) by IA1PR12MB6041.namprd12.prod.outlook.com (2603:10b6:208:3d7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 09:27:28 +0000 Received: from CH3PEPF0000000C.namprd04.prod.outlook.com (2603:10b6:610:e7:cafe::71) by CH0PR03CA0227.outlook.office365.com (2603:10b6:610:e7::22) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Wed, 11 Mar 2026 09:27:22 +0000 Received: from satlexmb07.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.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 09:27:26 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 04:27:24 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 87f1909d-1d2c-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L8tIst6WlaYAb0lWAMMJDQc05DwDKFCP3vuEI7xCTRbTv0k/AQ9++zQDqNdI2iTE0ETFPTJZNWC1rw2jW+L4k5nNVdxVa5ApaOwz6IjjlV1KMLbJJ3Pvxwd6BTEBVWJSjOx6S3PjMFPsuxXNGIf/aqWAzQZp+M1nf4NwQ/HrSgKOWbvZoIqL32qrh1KACHCoGw3nUJidWkgels6GyLIPa7TmqAcHoi1Z3HFC0z+AUESa4BFyHLyJWFDxJbSG4b2nLN8sCauK2UR10U8w8gJ871ElMJnd1NtXD8VIbwC3aPzHHuzzWc+1df7UV//8DHhGGc2IW3A9NspilwYqEkmKUw== 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=PNrrOymFCnhDiqnrfwMeebp+A/+//ewqO1p99oDlPs4=; b=jLaLueIJeomi5Q3Pj9l2Y5tvTyug70xunrrmetEw2SpTE2hyr3HcN0lnqLElQT2mB93cIbQBd84YyQ/6gR2MuoZP1GalDar9WoBnmHnj0SKDI2mSiw/1fDaYP+YhBU1ulDzwlTcZuW5huy00hGOIAHi7HQ9+f5yXows6FTkv5+rP1Mwky4rXUUzTeL0iLnEUNzfpbdH1IfE4uQ9eL4WiKegc904w7DkTML5LHtrJHYubzy3bBe+lBtHIX3YpZzSDaAumRP5EA+GBFS/muo2lokM/Kj3N4g62AM/PhFevQDHARwOxuSRciPvYf5I1DUZytBz+uB0Artx6rHNMdL1LuQ== 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=PNrrOymFCnhDiqnrfwMeebp+A/+//ewqO1p99oDlPs4=; b=o2XkGPkz6t2MU0abAWveCSyD2yCooRMoH2jrHIuGWvj6Qm7ml0FTgNWCCWxoy9rTPv4Htt8/cAiN8CT8me9fYnUgvQfbcovMTUNo3fFgLIpRcmH56HQ5R6ubYj/nUOyjR0nfwUJzwiP8Xm+6Y2iz9lAjxTbMhQSSjhICGp80XAM= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 10:27:22 +0100 Message-ID: To: Jan Beulich CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie , Subject: Re: [PATCH v3 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-5-alejandro.garciavallejo@amd.com> In-Reply-To: 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: CH3PEPF0000000C:EE_|IA1PR12MB6041:EE_ X-MS-Office365-Filtering-Correlation-Id: 172a8972-44b0-425a-6952-08de7f506893 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700016|82310400026|22082099003|56012099003|18002099003|7053199007; X-Microsoft-Antispam-Message-Info: ajJ9u3A1Asb0AhIiHYd7S/fWWnGflSeFUiDTjGQm5pm5S0iVszOnpqcHq8sdFKEveFb6R5vtmpvdldbK7dqD7fE34P/J3UB0vGN26Pub8BjHPSAKmhEiXsGqvajPplFU5tGxfnRxPSZcTDn9lBkXz+p3zxIIK4onCY+cT5d9bzfZEa0jWbyOQLstDP/G2rR18gtcQlt5AKP+Bn6J8vwyhqePRMXxS64/yqChtDgzsha1AjlQIOvZnW3/+JiRnNguSckf2h5ozdnqw0C0yArEmMxTYq+b0wpxEjNpJUdjcL+s36d2/CAfBYk2DT6rarrlYOpAbw3Iqphf+PNzztB+3DCVKT6TKkIIPDJIbKpkjLTWBgnlSTa8pu6i/aoFHcFJAhsgBlWpLLKtjnmOXt0NeSNb+plAr5oe5XJHG5mK5lSnnHEqrBe07c9C4GqtvUaApVMbq8O+eqUJc5FRBw3iF81esoAzZVa8Sb8IC+gyNhHbtUVYjIs/+mK6bCP+/gXyQTeng8RV/VM3gDYA4FJ4mzcRH9gPMgllpeug/YAN51NabVdXs7DS4IqwLrX55/6fILERthChmJUE5EiYmp7S0335LyE8rloUtL0OBuLCMTHro85+xlJob7EcFgh5izl7MX9b+f97+ouZNcVKNA/ZuFPpebs/L7F7kL58GBKr+PS76RlOsnpUoYH9lhjS5ECp1toeHxpb0WgPHFZpTvl93CX6le/z54PLIot2now6BE2XvpdRDv2AQgXqXIoYqDd455pUuM0ZXYHRlH8aovT8sw== 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)(36860700016)(82310400026)(22082099003)(56012099003)(18002099003)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: h5xsG9CHu7E3Fl79BwdIxE89XoWP39oKwLDD2ix/p+b20jG2CIG0UABSEzsRkj3HAPx5O70t+slwpeXqrYagf591/QikyZ1oHpeBLyh3CdkSSEQ56CPPotGVilWgtflME4M+k7dVLkq0qYGx8fMjhycmWHQQbpNIoZtRenRQuvsz60YkDhNVViKei4sTwcAe5pUfpxY23oUcOgPLPTkbj7MKxDb5Q0gyYG8NFfbiTgldfuxNMkrg/+BRmhZtfLkj1cB0ZOVjUFf73SrUWf44suQPW3Ve+1VGpgOYYilzWZTEO5+Ewr/hqgsPOQMNcTPFQZWDvW0Ci+Axv5tni2Xwb4IRdh/zh1CnJmkztQUCPbA1XNN0WTDodKaavT+fXUDTVMjwgWn7/A0dQCkleaZNn9J4XYeDz6JTZcSoQQl/8M05ABCoMeDCwKjhsZoaarvI X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 09:27:26.1465 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 172a8972-44b0-425a-6952-08de7f506893 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: CH3PEPF0000000C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6041 On Wed Mar 11, 2026 at 9:46 AM CET, Jan Beulich wrote: > On 13.02.2026 12:42, Alejandro Vallejo wrote: >> @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struc= t hvm_hw_cpu *data) >> { >> struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; >> =20 >> + data->sysenter_cs =3D vmcb->sysenter_cs; >> + data->sysenter_esp =3D vmcb->sysenter_esp; >> + data->sysenter_eip =3D vmcb->sysenter_eip; >> data->shadow_gs =3D vmcb->kerngsbase; >> data->msr_lstar =3D vmcb->lstar; >> data->msr_star =3D vmcb->star; > > May I suggest to do writes by increasing address order? I.e. while this > already looks fine, ... > >> @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, str= uct hvm_hw_cpu *data) >> { >> struct vmcb_struct *vmcb =3D v->arch.hvm.svm.vmcb; >> =20 >> - vmcb->kerngsbase =3D data->shadow_gs; >> - vmcb->lstar =3D data->msr_lstar; >> - vmcb->star =3D data->msr_star; >> - vmcb->cstar =3D data->msr_cstar; >> - vmcb->sfmask =3D data->msr_syscall_mask; >> + vmcb->sysenter_cs =3D data->sysenter_cs; >> + vmcb->sysenter_esp =3D data->sysenter_esp; >> + vmcb->sysenter_eip =3D data->sysenter_eip; >> + vmcb->kerngsbase =3D data->shadow_gs; >> + vmcb->lstar =3D data->msr_lstar; >> + vmcb->star =3D data->msr_star; >> + vmcb->cstar =3D data->msr_cstar; >> + vmcb->sfmask =3D data->msr_syscall_mask; >> v->arch.hvm.guest_efer =3D data->msr_efer; >> svm_update_guest_efer(v); >> } > > ... your additions would want to move down here (and the other writes may > then want re-ordering as well). Preferably with that: Sure. > Acked-by: Jan Beulich Thanks. Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:30:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:30:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250919.1548253 (Exim 4.92) (envelope-from ) id 1w0Fu4-0000pJ-Ar; Wed, 11 Mar 2026 09:30:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250919.1548253; Wed, 11 Mar 2026 09: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 ) id 1w0Fu4-0000pC-8E; Wed, 11 Mar 2026 09:30:56 +0000 Received: by outflank-mailman (input) for mailman id 1250919; Wed, 11 Mar 2026 09:30:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Fu2-0000p6-Ql for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:30:54 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ffe58b4a-1d2c-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 10:30:53 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4853fd7b59aso18613675e9.2 for ; Wed, 11 Mar 2026 02: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-4854ad5416bsm30948735e9.1.2026.03.11.02.30.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 02:30:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ffe58b4a-1d2c-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773221453; x=1773826253; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=FtsqVf6QKhpBEQjy6xK9B7TwWQyycFUwXYMJkg6Me0A=; b=UPCWk73r8TbAodFO5hlhjcDDhQ6wjIIbWJZYtUw98x6Tz8IbOyntw8OQlWLhKiKpSq +X2ZIQKo2vLZWdcVRiTEuep2ajcSzFVUzr6WZUjJ9HxsUA5mc5zG7qxRYUGu8xvC1/N4 8fM3hHImOuIBdyCBf+sAUtRHRqaDQjLszpgyawiDWiCBOIgZLdRepIGnz0luvwzQ0bdU mh+yLVzNuMj6tXnGXy7Uo5U3cNLIQfVboeEJaZjHes0Ff+Bzpf3j7AemXQ0FZu4weUpi BV7/1oBfFA+aY+dzvGsG3egRun3K5LbE5Cid9RRP28Qbl00MTRUWmxN2ykgPKi0STNcZ BdDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773221453; x=1773826253; h=content-transfer-encoding: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; bh=FtsqVf6QKhpBEQjy6xK9B7TwWQyycFUwXYMJkg6Me0A=; b=nMevP+O8IhA1HupmKO+MBh4QQjuRtMylT2c1x/gMir1Oi1SUtUl8zuPa9wpsrkXund T8SY23+lL9+znMxLubToStz7u0ZItJGWCiEr49/lbkgEhI7zC2Hu7kOA5WDLGApvL4HS OwiYYK13qB5fx6TG+ggDqkEqnxARbVFwHhYRGSgaL1SiTp5fnymE3sk4G5bGw7t2+R15 6ZRuMqqrjfYtgFYkR/aKZtuYQu9eknx0u1neWz+aYnRyf7emUjwCejPzWnS5qDHf//cC 8qh2RNv458EmfXK1/T+jvbJQw+zWkvBueFHFc+Tnj3BkZBhL+RogFfIccYdh1b8/Reim lOWw== X-Forwarded-Encrypted: i=1; AJvYcCX/8mpr/KAu5KcdOwMIztkss7BM8vLFwwdNQmy1jWpm7rsWkdeFEOmmfqvC91friOaqgTFd5Gi4fl4=@lists.xenproject.org X-Gm-Message-State: AOJu0YwvzQow522nThFyTT2NEjoKWWr7O265IUsxzu9ANN3rBrEbofR6 13JNCNGLhvLx4UaX1pWrs6HlsmGWpb8UEhWQuYtUIKBZX6fBpneS2iXrmK1SilC2pQ== X-Gm-Gg: ATEYQzwJK7f24i8Xo4g1RyWq5AtAa0N4vfgaWTpXhzB2PL3XA2l+fvb2nl8qk9DgEnz 6q3DeGmSfdKIewtGepXL1yfZiRiPzloY15IQMefvnOnuLpnBRtK8G+ByQweL9DIz27iYMQBw490 kvd4oFHwM9E+6YUqhB0LDKyYvmOcnHFOmI5TucFlNc9SII3i0EcsZGYuNx9mDt2etOvJue6iYlP jqeXJyphvEepca+zekqk6l22FDq383MOBeQZfravCK77DQsm6VcMFMf0/Gos4ttIWDfdEVfShZR KbDrZq2QslGq+tsEQu9v+ttRuzLgAxJWJ5yDWYS/PPGynbSyjOFRBd18E3zAQ7qQBfMN/6xs2st BR4SfB195Kl9DAShw3Hs3mu9k31OCAqs3wc4XnufZtt1Nv4f5youvnUxthf3GTShFhV637PV77f pvcprST/GrhMuNozsa+7ztdmDXrR7rrUMuWyttNGPHAv4n5bhHkpVcv+MlkNlIihSNIoxeR6WOx sVhW5fiRc+nCNk= X-Received: by 2002:a05:600c:a404:b0:485:4bd1:4c64 with SMTP id 5b1f17b1804b1-4854bd14edamr22523395e9.31.1773221452944; Wed, 11 Mar 2026 02:30:52 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 10:30:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 10:25, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: >> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -3832,69 +3832,47 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, >>> return X86EMUL_OKAY; >>> } >>> >>> -static bool cf_check is_cross_vendor( >>> - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) >>> -{ >>> - switch ( ctxt->opcode ) >>> - { >>> - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ >>> - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ >>> - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ >>> - return true; >>> - } >>> - >>> - return false; >>> -} >>> - >>> void hvm_ud_intercept(struct cpu_user_regs *regs) >>> { >>> struct vcpu *cur = current; >>> - bool should_emulate = >>> - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; >>> struct hvm_emulate_ctxt ctxt; >>> + const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; >>> + uint32_t walk = PFEC_insn_fetch; >>> + unsigned long addr; >>> + char sig[5]; /* ud2; .ascii "xen" */ >>> >>> - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); >>> + if ( !opt_hvm_fep ) >>> + goto reinject; >> >> Is this possible at all, i.e. shouldn't there be ASSERT_UNREACHABLE() in >> addition if already the check is kept? > > It isn't. > > v2 used to BUG_ON() at VMEXIT when !HVM_FEP and compile out this handler > altogether, but Andrew was unhappy with it because he uses it occasionally and > it'd be more of a PITA to undo the removal or force a HVM_FEP-enabled hypervisor > for the #UD handler to be present at all. > > I have no strong views on the ASSERT. It's not expected to happen, but I don't > expect the existing conditions to change either, and if they do that will warrant > a change in the handler too. > > If you want it I can add it, but if we're not killing the handler in release I > don't think it's very helpful to assert/bug_on. I see two options: Drop the if() or add ASSERT_UNREACHABLE() to its body. >>> - if ( opt_hvm_fep ) >>> - { >>> - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; >>> - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) >>> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; >> >> Why is this initializer not retained? > > It is, it's just that the diff is terrible. An unfortunate side effect of the > removal of the braces. The scope collapsing forces it on top of the function, > before the emulation context is initialised. > > It's set up in steps. walk is unconditionally initialised as isnsn_fetch, and > later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL == 3. See... > >> >>> - unsigned long addr; >>> - char sig[5]; /* ud2; .ascii "xen" */ >>> - >>> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >>> - sizeof(sig), hvm_access_insn_fetch, >>> - cs, &addr) && >>> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >>> - walk, NULL) == HVMTRANS_okay) && >>> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) >>> - { >>> - regs->rip += sizeof(sig); >>> - regs->eflags &= ~X86_EFLAGS_RF; >>> + hvm_emulate_init_once(&ctxt, NULL, regs); >>> >>> - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ >>> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >>> - regs->rip = (uint32_t)regs->rip; >>> + if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) >>> + walk |= PFEC_user_mode; > > ... here. But that's the point of my question: Why did you split it? All you mean to do is re-indentation. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:47:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:47:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250933.1548263 (Exim 4.92) (envelope-from ) id 1w0G9f-0002ij-NT; Wed, 11 Mar 2026 09:47:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250933.1548263; Wed, 11 Mar 2026 09:47:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0G9f-0002ic-Jq; Wed, 11 Mar 2026 09:47:03 +0000 Received: by outflank-mailman (input) for mailman id 1250933; Wed, 11 Mar 2026 09:47:02 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0G9e-0002iW-1U for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:47:02 +0000 Received: from MW6PR02CU001.outbound.protection.outlook.com (mail-westus2azlp170120002.outbound.protection.outlook.com [2a01:111:f403:c007::2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3cc6c822-1d2f-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 10:46:56 +0100 (CET) Received: from PH7P220CA0037.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:32b::18) by PH7PR12MB8013.namprd12.prod.outlook.com (2603:10b6:510:27c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 09:46:49 +0000 Received: from CY4PEPF0000EE3A.namprd03.prod.outlook.com (2603:10b6:510:32b:cafe::5d) by PH7P220CA0037.outlook.office365.com (2603:10b6:510:32b::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 09:46:41 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE3A.mail.protection.outlook.com (10.167.242.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 09:46:49 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 04:46:47 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3cc6c822-1d2f-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h/+Vh5vxcPm3l8Yi9/0YorOu59+YBnYLadj3O5OnrML1pCTeiZjT2IcT2S5hTLEwgvolc96cbwe/oKrX5ImjG670aMEv20ogHXmnSw+ZADUaZzixmQg48w5/CcnrVTj/NcsZlVRMTBe2ZrcAKYROvVjVQkTxW3jLOqtdphKSWrR+9Sn7C7krI05cuXI/4oz/c3//HcfLmy7Py/RAfHCkIOtUTFjds9D4YpwvpAy7wH4XQS74073ZvG7LOYmNPhlfzDdFvPKAB72Yd+MUz5mAzY5PiIkCMWguQm6TnNPqMPO6V5eFaJ3AeRLychvdYGjdHvPMKnBY3uXTKGyC/nBK+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=ghnJIzHCBfPPb7PJGOHx3Jgoqqxk8PgvNWQy+vwhnPM=; b=R8YJ9cyZ5DdklpVUy3Y+g2Ke7+hZDgCkh6i6uQJtKsFTWCXKdUCoQj87D0oap4g9fHX9lBx6ikEwQrPMKreSUc3LCZcwcsQ0uDiQDy7i2VNKshXbDpf+rnADFvTf6M2w0+oemSNS5dhUWMfIBQk5hvvKGA8ntOwvTePDrSjwxWfAojsukvo2gBIoqdusCaosMo+Sa29aah8hARouCtPoy12BZGjBQpCZhXH+L/6OTidA3+M2aRZs9MahP+gZHRNAgK1mkj1dHLDcdkE9TsbgrhBsn0dHyyXOSxxJyDNd9kgb2Mjz9P6WmgTK45UrSQt/YG5iIStowpJ2w8gvEvVcOw== 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=ghnJIzHCBfPPb7PJGOHx3Jgoqqxk8PgvNWQy+vwhnPM=; b=AyuxDHYLQ4bEyhI6p47UgscLh5DhSEpPyT/goIGSa9cMSbrIuAu2VMYzzOFygxjQgnXFeGAQaEBC4qCNmZOSsyMyUoH6NtczPPbsOwCXvE46x0+TTpy+H1hj8Z+jVpRvNwdOlXKCGKTy/ynRPJwlNecDGjvMCgwQGYqdSpiGuD8= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 10:46:40 +0100 Message-ID: CC: Oleksii Kurochko , Community Manager , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , "Jason Andryuk" , Subject: Re: [PATCH v3 0/4] x86: Drop cross-vendor support From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <7973d3d1-8984-421f-88db-ca17ea3cb2ac@suse.com> In-Reply-To: <7973d3d1-8984-421f-88db-ca17ea3cb2ac@suse.com> 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: CY4PEPF0000EE3A:EE_|PH7PR12MB8013:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d0a625f-3357-47af-1697-08de7f531dd5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|22082099003|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: lh3WvbS/RPgecNaSYP7Vs8rWcnRHHIrQURA78j5L+ZmNqDJwOBgF34ld1TxHOzgIG8QSKyoB6G/jqAreTFMvx5fRZdCj/XR0ukKnt3VQnmc/wNUYuxoEgPyjeScqXwX3kBWv3NvFkvG/BA/1E3cRllczHgc15gtut6zrePFUVDH5p4WIPutsfAwzG4HsWI1RVL5hOkVt51QqbfjLIRGuEKS0A2OPpxQaehYClWEHnY55Nb+9Nr1ZtgS0UCelOwwd8oUQMzUFw/tMyTmxgRk6Fs8JlYdubmYyFq0B1QgV0FdLNJvwn4/vZggtKMd4WeZUIa4gLq58a+L6mnS0QOzJ197gjEln/eWRpMrhTquW4tU71o8yABbBxKfZxo+b5obnbR0KIJGLptM3LJ85wong3kDgCGAHJ8FI3tMeEIlK+4bomJtcQuCZG8llzJEiZT2XE2U32jltbTnEeL84Pa0WNRZ82JZRCXFG+PLc44dPxA4HNzMRTQ8J7xALUco3XRDblcp+Y4lXLefKeC1EBRvszUqo8AFuYoWjGC2zSRNJfz26/nA6W5Twyf5K+5+KyIKbfB+on8/XD0YgvQ1zwcSVM4loxaqldsmlVotXt/xnv54JBbBchIOgCLdau+7B0rZiEd74ionTZkWkHmxEp0DMjfrI3sgswI4iU8EY9e2gjMlUh4nMPpcHgZd/uMt5GwQ5YMY6omRn2N6f6mg7WylRFiA5+wxxMy0ENbSksXm21QeuK4pJUuS1ElWi0o6rMNLUBYq8xwNp9JKe9E12bjo6KQ== 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)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: bUUMAh1dH4u+Sb5EpNwFzxmR0mfHAJ36DEm+PQVWrqNzpgm7oToK3oD/qgSb19O5bIUtT4vDWUiQbxeZYkXiMV9xbXSLoIOhXtme4y4eyHh6QULNVJegrZdHXet6J8JJtreAVWZR8RtESXqbbaX9KPYQsORG6hHdKSkEKsu8xiICBOU6BMiYCEuvb0aVSsbnZOKyqrFXOA7nqqw1Kgixm1llEiwfzB9x/eSuHqB9g2o6mUE4BbWXcI8o3Odo0S1RDifRzTejN+GoOWh6OdGBUTdmpAezHrxhJevE894w4oPyrldKpmfW6EaljtkWh2gd665xToA+SOMJ6z2zEq6r7pOLYUT5LJ0THBWpElUawij/19BukHkC8CKj7T7v7NlQk0FP+nzr+BhA/N192n59f65Kq4yVrry3e/r0QNEVP55e/vNRooJKWLMKLKIdPD46 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 09:46:49.1815 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d0a625f-3357-47af-1697-08de7f531dd5 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: CY4PEPF0000EE3A.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB8013 On Wed Mar 11, 2026 at 9:54 AM CET, Jan Beulich wrote: > On 13.02.2026 12:42, Alejandro Vallejo wrote: >> Alejandro Vallejo (4): >> x86: Reject CPU policies with vendors other than the host's >> x86/hvm: Disable cross-vendor handling in #UD handler >> x86/hvm: Remove cross-vendor checks from MSR handlers. >> x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems > > With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,R= ET} > in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still al= low > its use by introspection? Whether to then also permit those with HVM_FEP= =3Dy > (but VM_EVENT=3Dn) would be a follow-on question. > > Jan I can force emulation of anything by writing an instruction to an xAPIC reg= ister followed by RET and then CALL-ing it that address. If we want a hypervisor capable of running such ridiculous cases the emulator must be complete. If = not, the question is what to do otherwise. Inject #UD? Crash the domain? Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 09:54:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 09:54:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250942.1548271 (Exim 4.92) (envelope-from ) id 1w0GHD-0004KP-Dc; Wed, 11 Mar 2026 09:54:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250942.1548271; Wed, 11 Mar 2026 09:54:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0GHD-0004KI-B1; Wed, 11 Mar 2026 09:54:51 +0000 Received: by outflank-mailman (input) for mailman id 1250942; Wed, 11 Mar 2026 09:54:50 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0GHB-0004KC-Sl for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 09:54:50 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 566cc743-1d30-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 10:54:47 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-485409ab264so5572585e9.1 for ; Wed, 11 Mar 2026 02:54:47 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854a18ddedsm40124975e9.0.2026.03.11.02.54.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 02:54:45 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 566cc743-1d30-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773222887; x=1773827687; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=k+RAOTjCwTLNedTNd0e/9yvXBzGGNZlJbi2KI22185o=; b=fVm/C5JLhU53g+B3dEIv7mFroL/Ys+AoMkcfS/MzuRCLNUZCuItQofvDufTsXX4k8e hEtRcAV2LQgz2ml/gq5GtezusVXRlztBFjdthitGX2J7dJgAalo7HudnUIq5fVK8x8wv CCZwV3KiRjbn8WIthTQiBuw2U3iTsxm76jfaBhNETEoVoeIvpTt22y9VPNoiMyd5yNia LAkuR7Mg97+XD0SYf7+NuBagEdSYSHE+fL8dSVG4cz7BZSlms5XQC74ABYHW5wBm4NgN /qhK7hYQqge3OrYNwfHA2iaif17nrfvh0mikxVAov5xm8Y6s5o5k6Uw8Rad3tN3QY2kj pV9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773222887; x=1773827687; h=content-transfer-encoding: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; bh=k+RAOTjCwTLNedTNd0e/9yvXBzGGNZlJbi2KI22185o=; b=DyVrZz/NLXgy1DYxEA8ZWwVBNoFr0MhD8MJ2BZKY0y1KS4IcoMUb9C4dwMPwJgOZTK 8R9IDit0Vt5aNqje7dFek3eEaQ+asUJukwtuLoiW0PQ4dkphkR6ulnP8sTrgBcrDIdKk 1hHke+haTblF1ZRBV0oIs6cU3QP6kN1BkMGZeFCuaxMHQW463Xu5CP3bhP0A8OwpoSbY KMCo/tC/ZH5e7VjCDGNU5AyQKymRzLcYWTpAWSbPUjopIa/Htx7OnYLUBa12L9TFxZbh I7uvWZ6LhHejZrgeiOYzDYyuvrNrmdohhW8T8n6OVmeAd7M9HQmJzLk7in3akINUVOHR KAQw== X-Forwarded-Encrypted: i=1; AJvYcCUdLr71MVzrgo7djn8AM84/GmbRnbJysnGTqxiN9uyvmysB4NkQkiG047mNQdATO5qD/fVq+iqZlYA=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywp6aTvxQFG9tY/9vGFhn5yxqjYf93HuSL7xhmS4Zz/XXdeEcFP TAlZXGGc/yz1M5V/eCL6FWZetK9xh1t8Y6rPvJ8xegzviA9VLRvfAsp2VBVi5t1r X-Gm-Gg: ATEYQzzG3h7QptOuoJqpHBS3LUhF0C92TXb3Qtxjk2TB9GDrcbDIHJhpL2llIwgF5iF mEWxoIkdnpCA31mKwA9ZXDx4P9FUeplBmEXNKGm3F86HnCZ6L4cFZPhwxbU8Uf0Zaig0pcbtgmz XiIYjkoifCYk3AjBa1jxBvDV5dMNk5SDm874Wltu/Ri51qh1RjS7dHVZs+7w4Hkrn5U/3KQdVUf Opr0+HAxSa/HVU/8MEW4U/QV8Hjc4BFlTBEJMAJHLyn5vvjNtSTwa0E4WXRfuFEe+KvXxhEt6sE D4pD0b9ujaCV1VM1G8jSxl4J1ND/m2CRwbmioywRXdZl3c24YldkDxmOhCAatYytT1TakmG+DeO /RitAZT6sMmSqJgEpkDlqv5UhWHwSldNsJmqaB2MNr3UXOdl4WqibB8OPrt7hoyqxAV8CtaOMHl 7Z8hUSddEBEUAEy+N4U0rIGXVjj0eBwGmsn7lEW6qn8JKQpohMaP56vtwFOoxQ9xHV1dfhdcg2V BY= X-Received: by 2002:a05:600c:a46:b0:47e:e59c:67c5 with SMTP id 5b1f17b1804b1-4854b25ab04mr25355385e9.8.1773222886218; Wed, 11 Mar 2026 02:54:46 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 10:54:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Oleksii Kurochko Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing To: Jan Beulich Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> Content-Language: en-US In-Reply-To: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/10/26 10:15 AM, Jan Beulich wrote: > On 06.03.2026 17:33, Oleksii Kurochko wrote: >> Some RISC-V platforms expose the SSTC extension, but its CSRs are not >> properly saved and restored by Xen. Using SSTC in Xen could therefore >> lead to unexpected behaviour. > And what's wrong with (or what gets in the way of) adding proper > saving/restoring? Also, wouldn't a guest use vstimecmp anyway? I.e. what > saving/restoring are you talking about here? > >> To avoid this in QEMU, disable SSTC by passing "sstc=off". On real >> hardware, OpenSBI does not provide a mechanism to disable SSTC via the >> DTS (riscv,isa or similar property), as it does not rely on that >> property to determine extension availability. Instead, it directly >> probes the CSR_STIMECMP register. >> >> Introduce struct trap_info together with the do_expected_trap() handler >> to safely probe CSRs. The helper csr_read_allowed() attempts to read a >> CSR while catching traps, allowing Xen to detect whether the register >> is accessible. This mechanism is used at boot to verify SSTC support and >> panic if the CSR is not available. >> >> The trap handling infrastructure may also be reused for other cases >> where controlled trap handling is required (e.g. probing instructions >> such as HLV*). > Hmm, won't you need a more generic way of dealing with traps anyway? See > Linux'es _ASM_EXTABLE(). See also comments further down. At the moment this approach works for me and I haven't had a need for more generic approach. I will look at _ASM_EXTABLE(). I haven't checked yet but I assume it will require some extra fixup code in trap handler what looks like over complication for the current case, at least. >> --- a/automation/scripts/qemu-smoke-riscv64.sh >> +++ b/automation/scripts/qemu-smoke-riscv64.sh >> @@ -7,7 +7,7 @@ rm -f smoke.serial >> >> export TEST_CMD="qemu-system-riscv64 \ >> -M virt,aia=aplic-imsic \ >> - -cpu rv64,svpbmt=on \ >> + -cpu rv64,svpbmt=on,sstc=off \ >> -smp 1 \ >> -nographic \ >> -m 2g \ > How does this fit with you panic()ing when SSTC isn't available (i.e. the > register cannot be read)? I must be missing something, likely a result of > me not being able to really understand the description. When SSTC isn't available my panic() won't occur and then will continue to be executed. Otherwise, when SSTC is enabled (it is enabled by QEMU by default) my panic will occur. >> --- a/xen/arch/riscv/cpufeature.c >> +++ b/xen/arch/riscv/cpufeature.c >> @@ -17,6 +17,8 @@ >> #include >> >> #include >> +#include >> +#include >> >> #ifdef CONFIG_ACPI >> # error "cpufeature.c functions should be updated to support ACPI" >> @@ -483,6 +485,7 @@ void __init riscv_fill_hwcap(void) >> unsigned int i; >> const size_t req_extns_amount = ARRAY_SIZE(required_extensions); >> bool all_extns_available = true; >> + struct trap_info trap; >> >> riscv_fill_hwcap_from_isa_string(); >> >> @@ -509,4 +512,9 @@ 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"); >> + >> + csr_read_allowed(CSR_STIMECMP, (unsigned long)&trap); > Please avoid such casts; see also below. > >> --- a/xen/arch/riscv/entry.S >> +++ b/xen/arch/riscv/entry.S >> @@ -99,3 +99,27 @@ restore_registers: >> >> sret >> END(handle_trap) >> + >> + /* >> + * We assume that the faulting instruction is 4 bytes long and blindly >> + * increment SEPC by 4. >> + * >> + * This should be safe because all places that may trigger this handler >> + * use ".option norvc" around the instruction that could cause the trap, >> + * or the instruction is not available in the RVC instruction set. >> + * >> + * do_expected_trap(a3, a4): >> + * a3 <- pointer to struct trap_info >> + * a4 <- temporary register >> + */ >> +FUNC(do_expected_trap) >> + csrr a4, CSR_SEPC >> + REG_S a4, RISCV_TRAP_SEPC(a3) >> + csrr a4, CSR_SCAUSE >> + REG_S a4, RISCV_TRAP_SCAUSE(a3) >> + >> + csrr a4, CSR_SEPC > Why read sepc a 2nd time? Because a4 was changed, so it should be re-read, but we can setup CSR_SEPC before a4 being changed. > Yet further, what's the point of storing the value > in the first place? The sole present user doesn't care. I needed that initially for debug. And also it would be useful for trap redirection for example, but it isn't a case now. So for now I can drop that. >> --- a/xen/arch/riscv/include/asm/csr.h >> +++ b/xen/arch/riscv/include/asm/csr.h >> @@ -9,6 +9,7 @@ >> #include >> #include >> #include >> +#include >> >> #ifndef __ASSEMBLER__ >> >> @@ -78,6 +79,37 @@ >> : "memory" ); \ >> }) >> >> +/* >> + * Some functions inside asm/system.h requires some of the macros above, >> + * so this header should be included after the macros above are introduced. >> + */ >> +#include >> + >> +#define csr_read_allowed(csr_num, trap) \ >> +({ \ >> + register unsigned long tinfo asm("a3") = (unsigned long)trap; \ > Why can't this variable be of the correct (pointer) type? This would then > at the same time serve as a compile-time check for the caller to have > passed an argument of the correct type. Good point it could be an option. >> + register unsigned long ttmp asm("a4"); \ >> + register unsigned long stvec = (unsigned long)&do_expected_trap; \ > Fiddling with stvec may be okay-ish very early during boot. NMIs, for > example, do exist in principle on RISC-V, aiui. There must be a way for them > to be dealt with by other than just M-mode. Do I understand correct that your concern is about that if NMIs will be handled in HS-mode that switching stvec in this way could be dangerous as do_expected_trap() doesn't know how to handle NMIs? If yes, then NMIs should be handled by M-mode as: Non-maskable interrupts (NMIs) are only used for hardware error conditions, and cause an immediate jump to an implementation-defined NMI vector running in M-mode regardless of the state of a hart’s interrupt enable bits and: The non-maskable interrupt is not made visible via the mip register as its presence is implicitly known when executing the NMI trap handler. So standard delegation registers like mideleg do not apply to NMIs because NMIs are not visible in the mip register. I haven't found in OpenSBI how they are explicitly handling NMIs, but it looks like if they happen in (H)S-mode or (V)U-mode then they will be just redirected to (H)S-mode or V(U)-mode: https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_trap.c#L361 And then do_expected_trap() will fail to handle them... Interesting that other hypervisors are using the similar approarch (with temporary updating of stvec) and they haven't faced such issue with NMIs yet... > >> + register unsigned long ret = 0; \ >> + unsigned long flags; \ >> + ((struct trap_info *)(trap))->scause = 0; \ > "trap" would better be of the correct type. Don't use casts like this, please. > > Further, wouldn't you better set the field to a guaranteed invalid value? 0 is > CAUSE_MISALIGNED_FETCH, after all. I don't see that such an invalid value exist for scause. I think we have to reserved a value from region 24-31 or 48-63 as they are designated for custom use. > >> + local_irq_save(flags); \ >> + asm volatile ( \ >> + ".option push\n" \ >> + ".option norvc\n" \ > Shouldn't this come later? Do you mean before where SSTC csr is really tried to be read ("csrr %[ret], %[csr]\n")? Does it really matter in such small inline assembler? > >> + "add %[ttmp], %[tinfo], zero\n" \ > Why "add", when you really mean "mv"? I think it could be "mv". > And why set ttmp in the first place, when > that's what do_expected_trap() writes to? To force the compiler to materialize tinfo in register a4 (ttmp) before the trap handler runs as handler will use a4 as temporary register. > Don't you really mean to specify "a4" > as a clobber? Good point. It makes sense. Likely it can updated to: ... mv a4, %[tinfo] ... : ... : ... : "memory", "a4" > >> + "csrrw %[stvec], " STR(CSR_STVEC) ", %[stvec]\n" \ > The assembler does understand "stvec" as an operand, doesn't it? I haven't tried... I'll check that. > >> + "csrr %[ret], %[csr]\n" \ >> + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ >> + ".option pop" \ >> + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ > tinfo isn't modified, is it? It is modified by handler. > >> + [ttmp] "+&r" (ttmp), [ret] "=&r" (ret) \ > ttmp isn't initialized (in C), so the compiler could legitimately complain > about the use of an uninitialized variable here (due to the use of + where > = is meant). ttmp is modified by handler too. > > Whereas for ret the situation is the other way around - you initialize the > variable, just to then tell the compiler that it can drop this > initialization, as - supposedly - the asm() always sets it (which it doesn't > when the csrr faults). It was done in that way as when csrr will lead to a fault, handler will jump over the csrr instruction and so ret won't be set at all. For that case it was set to 0. > >> + : [csr] "i" (csr_num) \ >> + : "memory" ); \ >> + local_irq_restore(flags); \ >> + ret; \ >> +}) > A macro of this name would better return an indicator of what it is checking, > rather than the CSR value (which the sole user of this macro doesn't even > care about). With the current one use case it doesn't care but generally I think that someone will want to use this macro just to get CSR value. I don't have a speicifc example but still it could be used in this way. > Ideally such would also be an inline function. I thought about that but I had difficulties with csr* instruction and their second operand which expects to have immediate. But if I will have inline function that csr_num will be in register. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 11 10:11:18 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 10:11:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250953.1548282 (Exim 4.92) (envelope-from ) id 1w0GX3-0007Cz-NM; Wed, 11 Mar 2026 10:11:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250953.1548282; Wed, 11 Mar 2026 10:11:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0GX3-0007Cs-IS; Wed, 11 Mar 2026 10:11:13 +0000 Received: by outflank-mailman (input) for mailman id 1250953; Wed, 11 Mar 2026 10:11:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0GX1-0007Cl-UN for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 10:11:11 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9fab059d-1d32-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 11:11:09 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4853aec185aso29201795e9.1 for ; Wed, 11 Mar 2026 03:11: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-4854b5e92d5sm40354145e9.1.2026.03.11.03.11.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 03:11:08 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9fab059d-1d32-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773223868; x=1773828668; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=8VSPL9pI0r/nB6HnC2XdlimUBaQh2F+tmXvni44X9HU=; b=GzJ/Mwc+ZZyI1ueebYXGMJNXNDOzyrJVMAhsAhOg5Jx93i74kArTq4K3mK+nYHcfQR EzBAGOwg9jhVVzdF9zKxVSuebrf260TE1Y3wBOjj0qi7USvzNmNMb5J5o4seH/BelT6u VEWO8rno+92TBIrzYvnLwk4/2qIoDEO0piDnGuWc1MafQc/j/K+VWavIXw2kf+L3uuNX JeUXSN3NcaHMJXfcbjK+TeUR25xal2ON5etTzyJd5CNONClhRBHhGskK5izBLB0ZLnht oCIRNbA6wZ1xmkFNfegZ6UE5q0LzsrvM+WKg4+r2DeaO1coW/K/Qd6pmLDP7KxviiLbP vUVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773223868; x=1773828668; h=content-transfer-encoding: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; bh=8VSPL9pI0r/nB6HnC2XdlimUBaQh2F+tmXvni44X9HU=; b=OYkUV7wGexw5uHQmYqX5TQ8mzLxxGLn+YGJxClnAtCgMli1Xzn1b2wTLc2YMuWb/Rz LEtIG047+wslEGFfV566UM4w2xC8QLeUaZlP8d0yn/U+mT/DOY868U7WDWCGza0Ce5P0 sLaS+6eoXgb2PXtrMGrx9Z6SBfS5+U8E4ZMK1S/eAWcCsUIdh9z/dqCTsbJmnvof2Smm acOC6oE9BzprUUKLqOcu09KbZ7z1+/rRP1qt/0nX8yoRS0uusuMjYpm8fDkXdMTuWpBS MC0MQjD86lWaX+H/2BKjVKSWFPKipEzWK1SeeXcrIsJWlceZNwh2fh1fTI3wG8kjrfju e4DA== X-Forwarded-Encrypted: i=1; AJvYcCX4yW37p+6OAN5GBeHEQKMnFGxQMveBSjpSQ2wn2mUGtEizcGeBeCky7wSg/a9KuWVD8W7GgOCYh/0=@lists.xenproject.org X-Gm-Message-State: AOJu0YwnQUi9L7D5WWnkyJAPQzU1WB+G8jpm8JWoAlmPawaEP5cFZgwP Q9XipdJtx9HbDfQT9HfhT8S9CTdocKMc+q0OhhGev7VDqsXpl2sPdF6xmZjlE3TyaQ== X-Gm-Gg: ATEYQzyylRrYGk/pi6di7kyBfq9BnJC7hqtjM1IcZxXH6rmn0xS+ljCSVuXKDw7rz0I 8Wknbzqq9ThXQm03qEoANKlM7r5xUe3TMyXOOFybxOs5Pnlfa6Ri9WVBoBnM/Of5axY5UvjGLYr YD4UcIDswLCnPUDMGcJtzyYUhgvZAGsLQIg4XHvT3ZDPwQ9qYM7TD2K2DSFw0g10FaOaE3ZIKGN bOphaaBOhrMXT7E7JQfFLV8wMtWBzj2FJTYCys4DCg4YR4d4prLh+Pg4XB/NqDdBQuv72zWkNlX 8SQgYeRbrrYYgYpv0jZjQaDNMw/HE05Xq2uDpWKZdfZffcFoDcS3YgGgTCoh4LA0apNEHV9/gZz X3KNBvY4hB19bCiaSfwne4nQyYeU/iw7zAd48Z6hE10yXOOju8Itv+voGBSBzGxCEaBp+TdiJJ1 J3HALuFjpeVyRUCTC9VHCjkbp0QTIafoQ7yuJs6Qmj2BA7QV8eRy23MG1t87MwTH2NWuZs3H24U nIvTt+TCwTLXag5lEknf4hChw== X-Received: by 2002:a05:600c:3511:b0:485:3dfc:57a with SMTP id 5b1f17b1804b1-4854b134942mr31551655e9.32.1773223868541; Wed, 11 Mar 2026 03:11:08 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 11:11:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/4] x86: Drop cross-vendor support To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <7973d3d1-8984-421f-88db-ca17ea3cb2ac@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 10:46, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 9:54 AM CET, Jan Beulich wrote: >> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>> Alejandro Vallejo (4): >>> x86: Reject CPU policies with vendors other than the host's >>> x86/hvm: Disable cross-vendor handling in #UD handler >>> x86/hvm: Remove cross-vendor checks from MSR handlers. >>> x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems >> >> With this, do we actually want to keep emulation of SYS{ENTER,EXIT,CALL,RET} >> in the insn emulator? Or at least gate that on e.g. VM_EVENT, to still allow >> its use by introspection? Whether to then also permit those with HVM_FEP=y >> (but VM_EVENT=n) would be a follow-on question. > > I can force emulation of anything by writing an instruction to an xAPIC register > followed by RET and then CALL-ing it that address. If we want a hypervisor > capable of running such ridiculous cases the emulator must be complete. Well, yes, hence the question. Or in other words: Do we consider completeness important for these insns? (There are others we don't currently support.) > If not, > the question is what to do otherwise. Inject #UD? Crash the domain? #UD is what I think we inject for anything the emulator can't handle. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 10:15:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 10:15:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250964.1548290 (Exim 4.92) (envelope-from ) id 1w0Gb9-0007ob-AT; Wed, 11 Mar 2026 10:15:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250964.1548290; Wed, 11 Mar 2026 10:15:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Gb9-0007oU-6X; Wed, 11 Mar 2026 10:15:27 +0000 Received: by outflank-mailman (input) for mailman id 1250964; Wed, 11 Mar 2026 10:15:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Gb8-0007oO-JM for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 10:15:26 +0000 Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp170120002.outbound.protection.outlook.com [2a01:111:f403:c001::2]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3801633d-1d33-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 11:15:25 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DS1PR03MB7967.namprd03.prod.outlook.com (2603:10b6:8:21a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 10:15:16 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9700.010; Wed, 11 Mar 2026 10:15:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3801633d-1d33-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=fpmjAZFGQ8nh6BrKPd9Wx3zZgllAPTLXvxylTCl77PHD9diK/RnKH6eDIlhEtPMmWoD20Y2MvjBbfljIZKArmSTEYHrJpr95fVs8yFEepY4HPhtTUPNUCxPcnGYRwPWBoRVym7P/3N9BamfGB5/CY7t7lAFY5tXQOtoM/v/kkEuioID5Rf2uEPDol97ljc0ym7JjOgb7ORBChycWYmjVFOIfIZ8MU0cawoC/C22Xidh/Xg5P53CYGyS4xGQg/KM4dp1YX9dM8y4Isz+SBKLZiO6YJ73RZYzMGls4vZmJhspDEYi8OxQEkEndXwbRbge/rtL6EkBQq7y/brtwHUy8PQ== 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=qLeHjcuf0axcx/3i4OcLup/yoCifknUICWtiIky+Nqk=; b=tAh2F7Cqpa+W7CZNOPZJ/HMDEaqCk9u5IcBX+ogogIdh3EsG1qVmP03xaHM7/rWpPmE/d55Jo1RWdJWkkhV36b4JexAxlPWeOlrEThXaCgf/5blPljm3WtCA/c5GVRl4a4DAiLHQEpGuhpSXrCpyRCor/Yd2EFAq/ypAD9I3ST8l3lXfblVJFHfhN5xlVkU9SKTjT9W1RvJclEpZDSgqkkVBRE/5T9HKIX93KtX+QVDjF0EPt+dG+U9cGLpCGz6yr1ubgmKAm5nZW7dI/MDN2Dtf1ITOtkKR11uAHfR/p6y8Xm7Q87MoSJ4jzuinAf9ai/m9fXpQLWrOJy+ucKi5hg== 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=qLeHjcuf0axcx/3i4OcLup/yoCifknUICWtiIky+Nqk=; b=Y98Swxy1Ci1d7hoVS43QpjVZjgN4HNmR4lKtHZ9j1HkVtiT6RiB0lc0zebOJt4Ya5huAKhDM3sLfynk1AJStrnGFRXoYfIHkaGcePjnj9OUcxfbC3FWWHf7WQXag1eC4f03OfUUN1xcrA3YbtLpl0sV0w7G/YiZsM6jypDZdwZM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Wed, 11 Mar 2026 11:15:18 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julian Vetter Cc: xen-devel@lists.xenproject.org, Jan Beulich , Andrew Cooper , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall Subject: Re: [PATCH v3 2/7] x86/msi: Define extended destination ID masks and IO-APIC RTE fields Message-ID: References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-2-julian.vetter@vates.tech> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260309123055.880050-2-julian.vetter@vates.tech> X-ClientProxiedBy: MR1P264CA0049.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::15) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DS1PR03MB7967:EE_ X-MS-Office365-Filtering-Correlation-Id: 3919a747-3908-462a-4603-08de7f571a89 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: JZ/EJy3AJRSdieos00qLtMviMbWALaet+/uaaRAtAx741tQF8dJRPw4ZDx214Oj9smcOhUShArvdjneJNLiUxSLwUE64Q6q5klX4HrJ79arKGTXJU7uQFaJQh8GNNbktJH3MoMTm86LeA9SN2FM1nfsrUo3zxlzlQWsWq1mut0Biz+njwPZjpE+EHLKy4IG49Q/pbonJg69s2P2bYkqwXX/6ynBCBtBV/7k9pMCAXxRx5y897rpSZ873IVA0QYAcAMsO3um4JdKYoskcSeIpsYdk6OGM8pLO1bR6iC336H6Zgf8PsVJNpLfK4qMn2einRiuMcjf4ok3nml/oEF9zRgpVEZH1KGoryFocakFg8q973sR7wH/L9THeyxmIKJleaz8h2IZ2js8rvzlGUkDu8QCHvkJlyNVoOIve43HMVPASJWIPAzrMwkBhCLeyE6lfjlS8GxPuTTXzkT+jaPqY68dAeKVS4KmZui2fdKLT9HGyrxt8uLjcbkaQlkU3gb2kLWvkcCkLxeroBiWDquSBGLadjy79S2qsAsTJMLuo4WsTeghpWVenfWV5Z0RzA62JU9dDYgpqSEtVmR5pk9NlGUEB99dpOfRS0uDMEthz4cS8AGtFZ6Dt7gk7PIzYp+nmIbxFkS1l1+uW+fepyuzupadblpkLBxKNbvZPiNoclzTSGgzGWjvHkbMA68XBfAoTuhLDJTS7IZ3fQQlHKy5PpE69F6S32P1M2EzV3TDvi3w= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MERlemtJQVFUZFoyeFdpaG95OFozdm5hY0VqOVR1b2k4SEFhUTFQWEd1M3Bq?= =?utf-8?B?OEpsQkJIaUJFc1paMXppQ05nTm9FNUhvQjdxQ3g0eHRrc1dqMjF0V2ZCTkd3?= =?utf-8?B?amZrcVFXTlBmbThZaVJDOFJ0UmdpM3orU0hSbE94MkdtYXpWSjhSYmY4R2hn?= =?utf-8?B?YmdLUm5hUVB6cko3aW5xWlpzTGRhQ2hLazdkSWhrMnl5c0paUWI3TEg5NnAw?= =?utf-8?B?bkMwMjJ2bnBwZm1mNWg0UTdLU2hRR0ZaQmpaeUxJM29Jb0VyRytEWkd0dEdw?= =?utf-8?B?R0tsamF5OTJSelRGMUFSa2dBaUN3dEhnNGUxOHdFa3RMZWk1ZUR3cWUyNTB1?= =?utf-8?B?aUZLdE1jR1hxWkF6dHJYbnNPdnlFTGlkNkJyNXQ1WnpJdDJrZ0xiWmRxSUc4?= =?utf-8?B?T0YyZFV6WHJlaE9nRXRPUDRDK3p1QXpsaWJWK3hEUmJjK2ROTDAxWEpLTGFj?= =?utf-8?B?QVJHU2Z4TWhuZW43dUZYcXlEeGg0M05sTkdUcHBQd1hSNmM2QVd6cUQzcFAw?= =?utf-8?B?bFFrWmZtTHhYUmwvTFE4MVRtaENCcEc1WGxYcEwzN09XM3hVSnNoSTVoNHVh?= =?utf-8?B?N3E1bU1UeUlLY1JYcEN3dThnOThnRVVrbklZYy9DZWMzQ2ROUmw5dDV3UUFy?= =?utf-8?B?K3dUWHJHYjlvbGtXNEwxdURCNHNyOTNXeEppN0pzazRkOUNzb0JGZlhiYVVS?= =?utf-8?B?UXgxeTBOa0lMcEdOUTJpQVZOLyt5VmIzb3g0VER0NnF5Y1JKWjFQUFhTZmJX?= =?utf-8?B?eWdDa2tsNURyNnllaHk4alhqbTdlM2o4eTB5UGF3VGJnWjByUUFlT00zSk5E?= =?utf-8?B?dEI1ZWlmRWtkM1NCRGJhcmVqclNrV1dMMi9wcW9uaDJrZ1M4clhEMVd1ZXJu?= =?utf-8?B?d1FhejVVemNDVDR5R1pncEp4M1h3aTlUT09HLzBLZlVWcFJiSGpVbmxTOFJw?= =?utf-8?B?U3dOa3I5YU4zQU1oZExQdjkvT2pzM0lERnJNM2ZZbkg1R3JUWUNuOG4vQlVq?= =?utf-8?B?d2VrMmo1RHM2aExNTGpEb040cmxRcDB4R0pvUmp2TE0yeCtPdXc1a2Z2SzA0?= =?utf-8?B?QnZ0STJ2L3ZDV0NpcGZCdXduVk5mbnA5Yk51UkJuc3d1TFQ1ekZCbWRTbXJM?= =?utf-8?B?cHJsWVVsME9ZRlpzU1h0RWttbTV2ak5GeEEyVmViT29HelNKN09jOUdBbzFj?= =?utf-8?B?UE1odlAweExnWW9wRlFxTmtoSElQdmJneXNEOUxyVjlRZklqQklHYWt1czE3?= =?utf-8?B?V1lyT1N6OWdxb1RYT3pDWjZEZWg0Q0w5OVJ1cmZUVGkxV1krbjJCTXN5YnlD?= =?utf-8?B?RjNaRE96TDllZC9uUlVqNGFaRUo1cGJsRE00a3YvZDhiYmZpYU9DSzJVZTUv?= =?utf-8?B?MjdrallDN3JnclpUdUkxOGdEZHB6dWY2d3lJdnU5UFNldUdlbkcvL21RTnpy?= =?utf-8?B?OEZ5VmFvOG1zZUpHRlhqOU1vNWNkTGgzMzMyUjBjQ0ZKNXVJQ2s3V3phbzc3?= =?utf-8?B?VFNkdmJKLzJDbmV6TXBLKzhQL0R4eldEY3Qyc0FTT2NCUXRVbjlka1E1NGo5?= =?utf-8?B?Q0VRWDd3SmhzQVozem5XaFlrbHFJMmZ2eDhZUVIwU0x4ZytDOHhzbi9KbkhK?= =?utf-8?B?dTllV1FQTEt2ZkNaSVFLZTlhYnlTVndVbzRVQjNCS2NEU2dQc3RoVGpDSjZP?= =?utf-8?B?dHlRcXcrT0t3c3lUbmYwcWVFbjhRcmprdFRrL0JzOEtjemF0dFhoc1hybE9E?= =?utf-8?B?RVNpUXJwZUVScmpjM3R5am04U3ZVWldwUlBDbjZvNXlYTk5tVE9pOHV2RStD?= =?utf-8?B?NmdlcXl4aTg3bWV4NzRKZENCMHV3SkVYRTFFVnlCRExQelFGOHNHNDJtWjJu?= =?utf-8?B?UkFmSm5RSUR4dGFIdnU1eE5lU0dIZnFyRkkxWUVPazBzcTAvbmo5Mi9tZXdw?= =?utf-8?B?SkhUb29nVUxFdUhrbDBMV1ZwSUhJOU92VXRGN2grbHVNYVpjUUxWbkowcVUr?= =?utf-8?B?SW5ZdmdzaGdIQU5QNVdmNmZ6WktYemlyVlNZT0JmaWgyRnNyQUF2dTQ0NjRp?= =?utf-8?B?elhIQkpOdUpIR3EwRjNtNms4cmM4T250OGdLT0NSRkUrZlhVeElnTitZVGxK?= =?utf-8?B?SWtYOUVmSVhERGVaVmxsL3NOS3pVMDB5TndBcGU5QnE0NGZkdmlKNTFnQks0?= =?utf-8?B?d1ZFSEFzQlhZck9WdGdNQ2dLUDRNZnNXZTZUdkYrencwS2h0aVU2c2JIeVBR?= =?utf-8?B?T1h6eUR3M3B4Ly83Y1hxRmNhS2xrZDRiOHhYM1BMWnBrbzJkL1hhaTFiN1Ru?= =?utf-8?B?R05TV3piaWtCeWYzZmNyZ3Z0Y01KVjFTaTMvTXhJSldON3duVnRDdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3919a747-3908-462a-4603-08de7f571a89 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 10:15:21.8450 (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: Y74oClRjEryLLRQIHfe4Mh/Eg+3C4xAfShQa3OQ1CymtQDLShIeZjKEhd+jIMxkz4ZWYGkjYAKwQMAK4n0kuLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS1PR03MB7967 On Mon, Mar 09, 2026 at 12:31:02PM +0000, Julian Vetter wrote: > x2APIC guests with more than 128 vCPUs need destination IDs beyond the I think this needs to be re-worded: "HVM guests with APIC IDs greater than 254 would be unable to use those IDs as the target of external interrupts due to the lack of emulated IOMMU. However there's an unofficial extension to the MSI messages format that re-use some reserved bits to expand the destination field from 8 to 15 bits." Or similar. > 8-bit range provided by the standard MSI address and IO-APIC RTE fields. > The Intel spec allows bits 11:5 of the MSI address and bits 55:49 of the > IO-APIC RTE to carry the high 7 bits of the destination ID when the > platform advertises support, expanding the range to 15 bits total. Hm, I'm really unsure the Intel spec allows for any of this. This is something that has been done on the side, re-using bits marked as reserved in the spec. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Mar 11 10:22:27 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 10:22:27 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250974.1548299 (Exim 4.92) (envelope-from ) id 1w0Ghh-00015I-VN; Wed, 11 Mar 2026 10:22:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250974.1548299; Wed, 11 Mar 2026 10: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 ) id 1w0Ghh-00015B-ST; Wed, 11 Mar 2026 10:22:13 +0000 Received: by outflank-mailman (input) for mailman id 1250974; Wed, 11 Mar 2026 10:22:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Ghg-000155-DC for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 10:22:12 +0000 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazlp170110009.outbound.protection.outlook.com [2a01:111:f403:c111::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 27533957-1d34-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 11:22:06 +0100 (CET) Received: from PH8P220CA0023.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:345::29) 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.20.9700.11; Wed, 11 Mar 2026 10:22:00 +0000 Received: from SA2PEPF000015C9.namprd03.prod.outlook.com (2603:10b6:510:345:cafe::a6) by PH8P220CA0023.outlook.office365.com (2603:10b6:510:345::29) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 10:21:51 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF000015C9.mail.protection.outlook.com (10.167.241.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 10:21:59 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 05:21:57 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 27533957-1d34-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VXEdklrnRd4sUqss9M3PN8MrQXFWE6qqnXjleYHmjsKWU6+IaKrSM0Oie4XOuL8pJi+M6govn/aWf3KpypukKctBnhuotPRjhErR6MXFt93wN+XXTAPsMSGS5A45bghaa/BeD7USuHt6M6GgBcxibh1nB+VgnLx4bQSCW4b9EbjmzMwaY1CewA7losLDHZUXQ5jo62YY44I6uv05p+IKYLaeUjWHMYXScuMpwc9L/nNpon+T2Gk/4Mq7tyzQu6lWSPSEEoMCeugVoMmBKKcT1UlB7jVG5KRFDBN9VqVwspjzDz9vfP0YVwGXXeZ3iNHc3ruv6jjpxHxspnuxDcuC/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=zZTB3cT2ASH/74OHAs4DUZkRTc5eEWFt1tnPBwff3Jw=; b=ItkKREbAaR0JyunTS/upadzsdumk7XgZUn/nswKKdAm7IWUbbI+guvBDNwft5SwCS2nIHDJ5HvYtjjJ8jIuFaFmQIwCtsvM6i/pwQAd2J71Gd5QyXMr5RL/7o8KTuiEQmPXcuHqQsWuM13b59ByybWO7QS2HO9fNQZTQHS7KNpQRINgNkPkcsX38R/dTgsaGNKo3MTBmq93UE6MYVj9kgDRWnxqZvVLcQSQfSOc+7uAMoxxM2stwCLsNNSNkFdX3nt9cFZfzO4bgmr6BmiCsIm3fy9w2AlbYh5CpFTiGNaSZ77ocmNGgG8tkHq1puAf9EZOVnoFcHe68WFSza27jvw== 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=zZTB3cT2ASH/74OHAs4DUZkRTc5eEWFt1tnPBwff3Jw=; b=MI6xaYzJ+wGatWBMEYcGqNn6wWzsAzjO5mLRkT0EDU/fqc7XbsUYuTeCEbU0hHIU6e6sfcmN1OONzMwGRnj+fwFqAzkBw06vyD5GXk1C01aeqeEJTJLQuTzO4d3t2hHUcPc/roxin6D6+CAULPhxnDzSAo5QDUWSoeET49dF+iE= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 11:21:56 +0100 Message-ID: CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler From: Alejandro Vallejo To: Jan Beulich X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF000015C9:EE_|MN0PR12MB6054:EE_ X-MS-Office365-Filtering-Correlation-Id: 5c92e5a5-2e2f-4032-932f-08de7f5807ba X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|82310400026|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: sqGV86/D8xf0tXLbsYYt0CV+cjqte7UD44HtVL5SmP5A3j7LA8izuUuZ/ksA5QB19KJQXwEQFRL5nLY1hnrokBpOoQsR33pixGcuMkceayOqQ70vu4ma1sFVcr+5jGbXFwWoNhqWRdtfOZbk59YXJcYrOJUPuE4w74ekTNx37qPJ209PbqGKLgPJ/Rfnd02pbeJ2s+Kj6ySoI/L2gAM1d7zO+UwWJfWx3eY7vkziMPad6NKRGEWdJpKZ02f781KcnI/81G7ISMe/XJNIED03ibj7WyyepOaYEFDbK5NLInp4R0FEiCaIBkTaZzoT7HwYRorEo3QY1YSnjTfuKtj3esLmSQa2d0iPW/880ntJShwLSXk9Mp62cnzFHz547+ztPnoP0sWg00leH2eJF/8UBMjcqTtaZqkpMyLjDuGGPpmTuWzxOSf4d/hFblzX6NOxOk5SQFGr3KPscowIVZjO73gMHadZ/JsHSq7lIXYEAC4w3JfVhnmI16c3MTfVpS2tD7UPt+apZ5nl6wd7iHUJy4mkcB8lDYK+M2ORDF8vZG+wXOOPb9Veosu8IiPIUGTw7B01e6PpvP0f2uhCEE6O1tNAyLBnRHCKvmLyAr56vIFFN4+lpqXrvhF9wHyV3LAjIiuCOiAZyn8F5tXKs67n/SpqrClU/QrdIunVgENlsv5kGTLlHyYd+hbD4IKlwW2oKQEFnu6vR/LTPdIzmIPqZnWQfCZroxIr7DYq9+IOc7T4qvUWT9jfuVlMtBrDyHZBp8a71+lP9KQ8dsAB7q4S3Q== 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)(1800799024)(82310400026)(376014)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: TEUPcQ/HxDkKwjAwm3c9i0HuXu0suNOo+KNDsGVt8W2tgtBmThTHPluaRPaqTZm8XlsJt1TcfMqzwZoGkdXlFMKgLtKOXMLKJyrMq/KKrj09BpNfQUBd6ad2jaKOVx+cLQjHql+CrfJtwEPjHPdGr4nosJBGbg3Pi2HE/4htoieLbxEa8+za+ZPtuwm3zA9ThHHQszR0Exi9CdP9mm0KHmUu6r8+504q52QTxwpziABSVrUsQ3ztg6+maWOWotzWB+/JiaEcvk7OVPnZtGR0TDx0wdxN3R16X/q2i110mtRwfQnHDAGgE6laBD1UiTrhFcQ41KWNomWA+zVtMf7HrKjP87ctF/59iix0H+6TTTtK7/JN1Sxr9q/xV4Qfez+VQKEK8YeyGG61mm/QgCkjOkhmEmj2WjmzN3aDK+Kp3W/6n0hfKNFUFKjcqMI2yiiL X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 10:21:59.6055 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5c92e5a5-2e2f-4032-932f-08de7f5807ba 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: SA2PEPF000015C9.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6054 On Wed Mar 11, 2026 at 10:30 AM CET, Jan Beulich wrote: > On 11.03.2026 10:25, Alejandro Vallejo wrote: >> On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: >>> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>>> --- a/xen/arch/x86/hvm/hvm.c >>>> +++ b/xen/arch/x86/hvm/hvm.c >>>> @@ -3832,69 +3832,47 @@ int hvm_descriptor_access_intercept(uint64_t e= xit_info, >>>> return X86EMUL_OKAY; >>>> } >>>> =20 >>>> -static bool cf_check is_cross_vendor( >>>> - const struct x86_emulate_state *state, const struct x86_emulate_c= txt *ctxt) >>>> -{ >>>> - switch ( ctxt->opcode ) >>>> - { >>>> - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ >>>> - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ >>>> - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ >>>> - return true; >>>> - } >>>> - >>>> - return false; >>>> -} >>>> - >>>> void hvm_ud_intercept(struct cpu_user_regs *regs) >>>> { >>>> struct vcpu *cur =3D current; >>>> - bool should_emulate =3D >>>> - cur->domain->arch.cpuid->x86_vendor !=3D boot_cpu_data.x86_ve= ndor; >>>> struct hvm_emulate_ctxt ctxt; >>>> + const struct segment_register *cs =3D &ctxt.seg_reg[x86_seg_cs]; >>>> + uint32_t walk =3D PFEC_insn_fetch; >>>> + unsigned long addr; >>>> + char sig[5]; /* ud2; .ascii "xen" */ >>>> =20 >>>> - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor= , regs); >>>> + if ( !opt_hvm_fep ) >>>> + goto reinject; >>> >>> Is this possible at all, i.e. shouldn't there be ASSERT_UNREACHABLE() i= n >>> addition if already the check is kept? >>=20 >> It isn't. >>=20 >> v2 used to BUG_ON() at VMEXIT when !HVM_FEP and compile out this handler >> altogether, but Andrew was unhappy with it because he uses it occasional= ly and >> it'd be more of a PITA to undo the removal or force a HVM_FEP-enabled hy= pervisor >> for the #UD handler to be present at all. >>=20 >> I have no strong views on the ASSERT. It's not expected to happen, but I= don't >> expect the existing conditions to change either, and if they do that wil= l warrant >> a change in the handler too.=20 >>=20 >> If you want it I can add it, but if we're not killing the handler in rel= ease I >> don't think it's very helpful to assert/bug_on. > > I see two options: Drop the if() or add ASSERT_UNREACHABLE() to its body. I'll go for that second option then. > >>>> - if ( opt_hvm_fep ) >>>> - { >>>> - const struct segment_register *cs =3D &ctxt.seg_reg[x86_seg_c= s]; >>>> - uint32_t walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) >>>> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>> >>> Why is this initializer not retained? >>=20 >> It is, it's just that the diff is terrible. An unfortunate side effect o= f the >> removal of the braces. The scope collapsing forces it on top of the func= tion, >> before the emulation context is initialised. >>=20 >> It's set up in steps. walk is unconditionally initialised as isnsn_fetch= , and >> later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL =3D= =3D 3. See... >>=20 >>> >>>> - unsigned long addr; >>>> - char sig[5]; /* ud2; .ascii "xen" */ >>>> - >>>> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >>>> - sizeof(sig), hvm_access_insn_= fetch, >>>> - cs, &addr) && >>>> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >>>> - walk, NULL) =3D=3D HVMTRANS_= okay) && >>>> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) =3D=3D 0) ) >>>> - { >>>> - regs->rip +=3D sizeof(sig); >>>> - regs->eflags &=3D ~X86_EFLAGS_RF; >>>> + hvm_emulate_init_once(&ctxt, NULL, regs); >>>> =20 >>>> - /* Zero the upper 32 bits of %rip if not in 64bit mode. *= / >>>> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >>>> - regs->rip =3D (uint32_t)regs->rip; >>>> + if ( ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3 ) >>>> + walk |=3D PFEC_user_mode; >>=20 >> ... here. > > But that's the point of my question: Why did you split it? All you mean t= o > do is re-indentation. Because I need to declare "walk" ahead of the statements. Thus this... uint32_t walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) ? PFEC_user_mode : 0) | PFEC_insn_fetch; must (by necessity) have the declaration placed on top before the emulator context initialisation. The options are... uint32_t walk; [... lines ...] walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) ? PFEC_user_mode : 0) | PFEC_insn_fetch; ... or... uint32_t walk =3D PFEC_insn_fetch; [... lines ...] if ( ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3 ) walk |=3D PFEC_user_mode; Line count remains at 3 in both cases, but in the former case there's a comparison, a ternary operator and an OR all adding cognitive load to the same statement. In the latter case there's an assignment in the 1st stateme= nt, an if+comparison in a separate line, and a separate OR in the final stateme= nt. It's just simpler to meantally parse because the complexity is evenly distributed. I can see how the current form was preferred to avoid a third line (and then a forth due to the required newline, doubling the total). But with the rearrangement that's no longer relevant. If you have a very strong preference for the prior form I could keep it, th= ough I do have a preference myself for the latter out of improved readability. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 10:54:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 10:54:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1250999.1548316 (Exim 4.92) (envelope-from ) id 1w0HCm-0005Bo-D3; Wed, 11 Mar 2026 10:54:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1250999.1548316; Wed, 11 Mar 2026 10:54:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HCm-0005Bh-8x; Wed, 11 Mar 2026 10:54:20 +0000 Received: by outflank-mailman (input) for mailman id 1250999; Wed, 11 Mar 2026 10:54:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HCl-0005Bb-64 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 10:54:19 +0000 Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [2a00:1450:4864:20::42a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a61a1051-1d38-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 11:54:17 +0100 (CET) Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-439ac15f35fso10390966f8f.0 for ; Wed, 11 Mar 2026 03:54:16 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439f81aca65sm6670892f8f.17.2026.03.11.03.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 03:54:15 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a61a1051-1d38-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773226456; x=1773831256; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=gwAyAPqxP5WCH8T6EQ/P0JblAV3dinBl+SEsGrTfcUU=; b=aoAjKajMDRMA8S9R1oEadxhIR9WcqsYA0SZkfa+VhUu7IxL5ToMxdsj5X8BxSczIWN AWiqvPaYE9eyBfvpTQSUh+QJ5LXUVjW+UpJWXLECq0H8dkSPttZGH5g9QIJ/veYM3Vod 3SPsV6O8gbC3GoX5c+0ffz5sSvr0ogs9BP7GWRtH0cHzBrEeQF7CZKzDHkBJb75CN4lk EuusahLagX6rW2yH3wvvM1ovPRq40g4v2j55oRx2duFlHGGulAG913AS44Sax4cIEnTn hoB/M/vnk4Lz3VP4kPMdEX6utP8+1rkRU79JoW1BmML25U/V9O/0VOXoqV6DrsUmIJ2Y VJ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773226456; x=1773831256; h=content-transfer-encoding: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; bh=gwAyAPqxP5WCH8T6EQ/P0JblAV3dinBl+SEsGrTfcUU=; b=PZwJf2d6IQ79xB9rHhcxFcZywS7HMX+leMEr8SVQr9XXqWPh1ncsyIm7Rrt3CbBnVy 1MpZojGzQXROrfpH+dgulZGuLWKgn4WgaijhjtaLd4rjNB5lCIKvujVUmuzKDC5YdLA+ aBPj63wON/iwKhqb4ql/Oqk6gGguOFF4Enl3HXB7EKRLAxI+vrywcgBv4PJa5NH+j9In N4bWDBYleLpNu83J6sI0+v3r92GZ/n9x82CXB8G1aP78HQZK6Wj0YvIRTbHOyjGvFRhp c7kICCdqjPmo1jLNsSimRSiEeLGm60pfxw20dl3mdqjeEno+C03ld67PkmdqF9iAsXH3 60Nw== X-Forwarded-Encrypted: i=1; AJvYcCViZz+pCc/hvJ54XMDjfE6sbU2dYA9wP6NTUB0/vH0FP6j4VZhHXjFxIkhVlK6BiVYWl4GcIMtITe0=@lists.xenproject.org X-Gm-Message-State: AOJu0YzvSobCmBlby1z2oE56K8cGwO/NT4qlmwRlCeGmwIq2MNbOjGBd Kc9uGFnRsFtErHoh4mrYTF1OBm2JsFXpH193XlrVLn+7cI/H4zcsj3KT X-Gm-Gg: ATEYQzxik7RTeulhZcEfDyxV6so5JIFSci+YVwdLkDo5dNVyTznDk01uomRxHaNLCKj z/aBEgOQlMVFrSrUQ7Qd5+j8zIIfy1cvTWXn9f/j5iopI1hvC6FLecRdh+7pY6rkUk1MzluV89z tysCQzgS1f/0mTAwAdjEYwa2gTEBgvZnhil5tHW9nZDHSTa3giMO75ezHtg3SAGL+skZYkupBQp bhUW38Eyw19AoxhEYpkx+ycTM8EtrsXEMgXCD7RN7u9rlcrsHPUb6U77XEgXUQLxFn2sTrTcpyE ImUKRxinUKuYHA+HeepJpISKZIzoSW70EkUZ9LQe7NOWRxTAM9cV9Mw3QXNE2KFJm3J1ZpMW+a7 xLtw+glE9HCihUEwS1WxLjBMNKJIxux/wlv6WhAFJT8Y4EAipymtP7mjfybE1X+SzT4tAvh6jp8 YBye/dAavhc93N0RuwbwIB9QnTqBLrOhgV0EPqi1TsToaoIqvbrsVEVUwbVX4uEGZOTp62zfXtn wk= X-Received: by 2002:a5d:5f93:0:b0:439:b057:cb12 with SMTP id ffacd0b85a97d-439f8205f60mr3856849f8f.22.1773226456060; Wed, 11 Mar 2026 03:54:16 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 11:54:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing From: Oleksii Kurochko To: Jan Beulich Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/11/26 10:54 AM, Oleksii Kurochko wrote: > On 3/10/26 10:15 AM, Jan Beulich wrote: >> On 06.03.2026 17:33, Oleksii Kurochko wrote: >>> Some RISC-V platforms expose the SSTC extension, but its CSRs are not >>> properly saved and restored by Xen. Using SSTC in Xen could therefore >>> lead to unexpected behaviour. >> And what's wrong with (or what gets in the way of) adding proper >> saving/restoring? Also, wouldn't a guest use vstimecmp anyway? I.e. what >> saving/restoring are you talking about here? >> >>> To avoid this in QEMU, disable SSTC by passing "sstc=off". On real >>> hardware, OpenSBI does not provide a mechanism to disable SSTC via the >>> DTS (riscv,isa or similar property), as it does not rely on that >>> property to determine extension availability. Instead, it directly >>> probes the CSR_STIMECMP register. >>> >>> Introduce struct trap_info together with the do_expected_trap() handler >>> to safely probe CSRs. The helper csr_read_allowed() attempts to read a >>> CSR while catching traps, allowing Xen to detect whether the register >>> is accessible. This mechanism is used at boot to verify SSTC support >>> and >>> panic if the CSR is not available. >>> >>> The trap handling infrastructure may also be reused for other cases >>> where controlled trap handling is required (e.g. probing instructions >>> such as HLV*). >> Hmm, won't you need a more generic way of dealing with traps anyway? See >> Linux'es _ASM_EXTABLE(). See also comments further down. > > At the moment this approach works for me and I haven't had a need for > more > generic approach. I will look at _ASM_EXTABLE(). I haven't checked yet > but > I assume it will require some extra fixup code in trap handler what looks > like over complication for the current case, at least. I checked _ASM_EXTABLE() implementation and so I will need basically provide only for now implementation of EX_TYPE_FIXUP what doesn't look too much and is comparable with the current suggested solution. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 11 10:58:28 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 10:58:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251010.1548326 (Exim 4.92) (envelope-from ) id 1w0HGk-0005sH-Vf; Wed, 11 Mar 2026 10:58:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251010.1548326; Wed, 11 Mar 2026 10: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 ) id 1w0HGk-0005sA-Rw; Wed, 11 Mar 2026 10:58:26 +0000 Received: by outflank-mailman (input) for mailman id 1251010; Wed, 11 Mar 2026 10:58:24 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HGi-0005s4-TZ for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 10:58:24 +0000 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [2a00:1450:4864:20::430]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 388611d6-1d39-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 11:58:22 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-439b9cf8cb5so9663335f8f.0 for ; Wed, 11 Mar 2026 03: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-439f81f13c3sm6599708f8f.25.2026.03.11.03.58.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 03:58:21 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 388611d6-1d39-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773226702; x=1773831502; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=4J5pUkRSyaUBU43apUgBScWFcUPwmMaVtMcIjcgu9RE=; b=W1qCKcpmCTtscorUEkB805EVHakx2SERWyNg7UldzVvuek/NDTwUVnHQb/auKcGLH/ ya7wuKZ9nTHPhpGq7wc1hSh7U9j9UmGTwYG/J5SfIHjKdlXDUrwBZqAxNVzs3O/QqdT6 +BQdLHRb9CBK0QNcZTsXxFu53Jq24lJxi45x+kZurKG+LoxPsmGoHkT8e2g4eRW/acf/ lzyUHaiL1YaZkJQb7DNRk9dCIR0iFlFoh40VqepTpHOkGFfMrAs6zJqKFbQOp/H2nt8D IcRXoOf4QIC/JGgG2AguEhNx9cqXf6hEsDqFrjwmuBNH23sLytxB/xw3unmaMDaA4QOt Rdzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773226702; x=1773831502; h=content-transfer-encoding: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; bh=4J5pUkRSyaUBU43apUgBScWFcUPwmMaVtMcIjcgu9RE=; b=LoWvsAtEDa3X+kSjJ7WDwua82FoNCift9R0hHi1JHuhCF245YenKJfhimmqNZXpBhr 0/v/uSfax8ydcSdyC+6BQegVxNrQbUuiMFc0nA1j2HSK9uRtxsfvTUFckEBCbIO/YWTm FsRQnsh+EyH1FgWUPcQBrHfDYSqeYKl29ReU59FLxiPhJ/Ftvg66AeDalePOUvZdLXhk ZQqlDQl9mY2ZbYFn+CQKD6CVpnEDo+vIH66lwulI08GNnY9IGu4SBZfLLNmme2peX3UU 2cSNJ7C8CIpCXTBtiFUkaXLpeu+dbpciAp1VhZT7OMJBAGZImRKVNYI4LYTy2WL+VbGv XUzQ== X-Forwarded-Encrypted: i=1; AJvYcCX4M/0vXl+/MNbxEAKKooJKw3+qYvJLVb49Y8qYVtlWAdAPChcJjDvlurSJLnTeqkKJT65PTfRwhkY=@lists.xenproject.org X-Gm-Message-State: AOJu0YyHG6pnMCCpCqhM5PKht6cAsE8hL8ZeXmqLNXilOYfuhkjqp2qc rDhUYEQtGefc+ABrQ0N8Yn3Z9uR0VkLUr7u/TqW/Rmvpopb/wm8R3hkHDYxlXx+lWw== X-Gm-Gg: ATEYQzwfM69On3t+6ed/cpbdZ6hSCWdRtQHygxhILyM++KPbySsFXtqvAYeeHsM2UXZ ZVwV81nKdtyyoicPJIMYfLoVEkl/c7zS2l89pFBm90RHY9ZcThNtSAlkUt558ECJLIZ0AKkQf4Y poSb+GxFti5X0Ml/MhloRWkV84PCwzfULIr9s/nX5mH9erN0ZbLY473N8kLEvWuMDlBr28/Jmxe dyEQA2NE2lJv3jMCzk3/ZO+GnP/9kr9Wal8Bn48z3Y4HpnYs3s6TziG1TLJHGCZcuiwp7s6Cfc+ VRXvNzvyHvzQ/bupRMwtD3gsfn3RWIdXvUVkaPjEAdai2WbiCJguC5esHFywz/ag2vgIl+iQ3sd scbZKuNpCYVbxrQwnEku4Sm7zj3jtC8MQCyT4TzJMX0jdUiH7nWSQHz6sxGgnBIr71bbjJs9JzN lEKYkJBonHMTQFVcCu0MnnS0gwedZx7xYiZq5jooKbSlGep/k62iSl0AxP7/gA+aU7PTwX6KFd8 /8igiNqcey/82Q= X-Received: by 2002:a05:6000:18a8:b0:439:c81f:b96d with SMTP id ffacd0b85a97d-439f8224ef8mr4107841f8f.51.1773226701890; Wed, 11 Mar 2026 03:58:21 -0700 (PDT) Message-ID: <2e471f54-1885-4615-8a23-c33ce683158f@suse.com> Date: Wed, 11 Mar 2026 11:58:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing To: Oleksii Kurochko Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11.03.2026 10:54, Oleksii Kurochko wrote: > On 3/10/26 10:15 AM, Jan Beulich wrote: >> On 06.03.2026 17:33, Oleksii Kurochko wrote: >>> --- a/automation/scripts/qemu-smoke-riscv64.sh >>> +++ b/automation/scripts/qemu-smoke-riscv64.sh >>> @@ -7,7 +7,7 @@ rm -f smoke.serial >>> >>> export TEST_CMD="qemu-system-riscv64 \ >>> -M virt,aia=aplic-imsic \ >>> - -cpu rv64,svpbmt=on \ >>> + -cpu rv64,svpbmt=on,sstc=off \ >>> -smp 1 \ >>> -nographic \ >>> -m 2g \ >> How does this fit with you panic()ing when SSTC isn't available (i.e. the >> register cannot be read)? I must be missing something, likely a result of >> me not being able to really understand the description. > > When SSTC isn't available my panic() won't occur and then will continue to > be executed. Otherwise, when SSTC is enabled (it is enabled by QEMU by default) > my panic will occur. Oh, I notice I misread the condition around the panic(), mainly because of the misleading / ambiguous message passed to it: "SSTC isn't supported\n" can mean unsupported by Xen or unsupported by the platform. Anyway, to me this is entirely bogus: Why would we panic() because there is a certain extension available? >>> --- a/xen/arch/riscv/include/asm/csr.h >>> +++ b/xen/arch/riscv/include/asm/csr.h >>> @@ -9,6 +9,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #ifndef __ASSEMBLER__ >>> >>> @@ -78,6 +79,37 @@ >>> : "memory" ); \ >>> }) >>> >>> +/* >>> + * Some functions inside asm/system.h requires some of the macros above, >>> + * so this header should be included after the macros above are introduced. >>> + */ >>> +#include >>> + >>> +#define csr_read_allowed(csr_num, trap) \ >>> +({ \ >>> + register unsigned long tinfo asm("a3") = (unsigned long)trap; \ >> Why can't this variable be of the correct (pointer) type? This would then >> at the same time serve as a compile-time check for the caller to have >> passed an argument of the correct type. > > Good point it could be an option. > >>> + register unsigned long ttmp asm("a4"); \ >>> + register unsigned long stvec = (unsigned long)&do_expected_trap; \ >> Fiddling with stvec may be okay-ish very early during boot. NMIs, for >> example, do exist in principle on RISC-V, aiui. There must be a way for them >> to be dealt with by other than just M-mode. > > Do I understand correct that your concern is about that if NMIs will be handled > in HS-mode that switching stvec in this way could be dangerous as do_expected_trap() > doesn't know how to handle NMIs? Yes. > If yes, then NMIs should be handled by M-mode as: > Non-maskable interrupts (NMIs) are only used for hardware error conditions, and > cause an immediate jump to an implementation-defined NMI vector running in M-mode > regardless of the state of a hart’s interrupt enable bits > and: > The non-maskable interrupt is not made visible via the mip register as its > presence is implicitly known when executing the NMI trap handler. > > So standard delegation registers like mideleg do not apply to NMIs because NMIs > are not visible in the mip register. > > I haven't found in OpenSBI how they are explicitly handling NMIs, but it looks > like if they happen in (H)S-mode or (V)U-mode then they will be just redirected > to (H)S-mode or V(U)-mode: > https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_trap.c#L361 > And then do_expected_trap() will fail to handle them... > > Interesting that other hypervisors are using the similar approarch (with temporary > updating of stvec) and they haven't faced such issue with NMIs yet... Well, NMIs may be rare to occur? And hence very unlikely to occur in this small a window? >>> + register unsigned long ret = 0; \ >>> + unsigned long flags; \ >>> + ((struct trap_info *)(trap))->scause = 0; \ >> "trap" would better be of the correct type. Don't use casts like this, please. >> >> Further, wouldn't you better set the field to a guaranteed invalid value? 0 is >> CAUSE_MISALIGNED_FETCH, after all. > > I don't see that such an invalid value exist for scause. I think we have to reserved > a value from region 24-31 or 48-63 as they are designated for custom use. Not sure that's possible. "Custom use" may mean "custom" from hw perspective. I was rather thinking of picking something pretty high in the reserved range, like (1 << (MXLEN-1)) - 1 or 1 << (MXLEN-2). >>> + local_irq_save(flags); \ >>> + asm volatile ( \ >>> + ".option push\n" \ >>> + ".option norvc\n" \ >> Shouldn't this come later? > > Do you mean before where SSTC csr is really tried to be read ("csrr %[ret], %[csr]\n")? Yes. > Does it really matter in such small inline assembler? Yes, if nothing else then to not raise questions. Plus (depending on the specific operands used), the ADD (MV) could e.g. be representable by a C insn. >> And why set ttmp in the first place, when >> that's what do_expected_trap() writes to? > > To force the compiler to materialize tinfo in register a4 (ttmp) before the > trap handler runs as handler will use a4 as temporary register. ??? I don't understand what you mean with "materialize". >>> + "csrr %[ret], %[csr]\n" \ >>> + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ >>> + ".option pop" \ >>> + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ >> tinfo isn't modified, is it? > > It is modified by handler. Where? It's only used as the address of the two stores. >>> + [ttmp] "+&r" (ttmp), [ret] "=&r" (ret) \ >> ttmp isn't initialized (in C), so the compiler could legitimately complain >> about the use of an uninitialized variable here (due to the use of + where >> = is meant). > > ttmp is modified by handler too. Of course, but just to repeat - you mean "=&r" there. >> Whereas for ret the situation is the other way around - you initialize the >> variable, just to then tell the compiler that it can drop this >> initialization, as - supposedly - the asm() always sets it (which it doesn't >> when the csrr faults). > > It was done in that way as when csrr will lead to a fault, handler will jump > over the csrr instruction and so ret won't be set at all. For that case it was > set to 0. And again - this is meaningless if the constraint is "=&r". >>> + : [csr] "i" (csr_num) \ >>> + : "memory" ); \ >>> + local_irq_restore(flags); \ >>> + ret; \ >>> +}) >> A macro of this name would better return an indicator of what it is checking, >> rather than the CSR value (which the sole user of this macro doesn't even >> care about). > > With the current one use case it doesn't care but generally I think that someone > will want to use this macro just to get CSR value. I don't have a speicifc example > but still it could be used in this way. Well, if you want to keep it doing so, make the name match what it does (and in particular what it returns). >> Ideally such would also be an inline function. > > I thought about that but I had difficulties with csr* instruction and their second > operand which expects to have immediate. But if I will have inline function that > csr_num will be in register. Only if the function wouldn't be inlined, I expect? Which hence you may need to force, by using always_inline. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 11:06:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 11:06:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251021.1548334 (Exim 4.92) (envelope-from ) id 1w0HOk-0007To-NI; Wed, 11 Mar 2026 11:06:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251021.1548334; Wed, 11 Mar 2026 11: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 ) id 1w0HOk-0007Th-K7; Wed, 11 Mar 2026 11:06:42 +0000 Received: by outflank-mailman (input) for mailman id 1251021; Wed, 11 Mar 2026 11:06:42 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0HOj-0007Tb-VD for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 11:06:41 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 60a3ca31-1d3a-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 12:06:39 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so32414375e9.2 for ; Wed, 11 Mar 2026 04:06: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-4854b66dedfsm45501465e9.12.2026.03.11.04.06.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 04:06:37 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60a3ca31-1d3a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773227199; x=1773831999; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=THWX4dw5nHbItcNRFe55nzEA85XRDepCbjCrxbTfMaE=; b=K1wpU7N4SChaJjavzN9OGVmCiZa6aKqJH+YM0eBNXZ9LKxiHFNWy7/hiMeVeGqt98b /xd4FzDPnZj8Ar+WXXPSLUsc/tmbD+9iQUm6zwaBDg20VTT/x3JACjDCjWiMmAHJhhJO 1WgM/P7pz/X0jxW7iEHfwPl+KPXfjwoYgggijQEAd+xkOieqd9VkaF4eTvNMZKb693qf EjWiWK0wAJzPtZsX7RAnMWY1DSgtxiCmH36Bh2xI2OIV85xYgAfio0OjYoOqBJcwovx5 eL5KfOplcusbHJk8o8om8qslPhkLeIBl1QEkPcN1BWKPmi6IO1DDHreNi99hhhYCPzkR cVmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773227199; x=1773831999; h=content-transfer-encoding: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; bh=THWX4dw5nHbItcNRFe55nzEA85XRDepCbjCrxbTfMaE=; b=dB4y8vf0u9+IINE5dERNN94cBftKRF2IcUrd+g5QGMkpNglaE0Kygs91RanpOYfSox 5kIG7TGTjVegtfH97u3OLB94rPS6Hv0dsueG5qd8ByzIPapZGMHveo90TD4BxOcouSU+ pQfF5Zfhtg2TRCuXfqK18MwLo7okIkfLvA6heoAQNHXKnfEsi2N0NpadiyoGX4sq3EiG VdqCeD9r3Op49t/LGemrbA47DKozJNz4ZtiN7c8lPNWU8wTFEuFczGpU7iFj6wbuuiz+ 0FyJy8LXeErNYd9+2bstP+LAR7cKvi755EU7TpuD3KBVrqmiEgAt4rechHDjTmOkQKxX QUTQ== X-Forwarded-Encrypted: i=1; AJvYcCVrHkdKBS8EytQ5Cq7bnSBWyDZfJ0yc5Ldau1Sx0q69GwcoIjT9fON5U80pkh7VzgOIVlQmg5jX20U=@lists.xenproject.org X-Gm-Message-State: AOJu0YzvTbuvARkYefij5jhoQ/Y8+MrIwDYSG8RLnV7NV7MPQ9cnJbJx RkyVSgzBvqFb2KuDmHaKtn76SuNKrmtnSCkzeA1CNYZk77lxztl0kpmZ7FERHFtM0g== X-Gm-Gg: ATEYQzyetMfFEVRh7eP/SOk7De2vekkNVPbDX/nA5Mpi4oMu1O2E2ECnk20Wu2qbHGS Mb0iJRehPH8gAV8mb6aPDWBXQh70Mxal9iggVeq/mZZCFM7SUzgU2AWjI8pvHzXX8zHXPO4oHse Sn4Jpv0Wyf9LBitmMHX6UgQ6f/am26VGXuTGSMVElECC0AA+Lt/yjzt8TG30tu0HR5WKr9kg+C/ qCxSUmNYcV6qiQp5aShTw+jO2vsnwN3FIOJMh8OrGSvrrAs+eVicEGhKcD0Mh9ej+4Vu7Iqqz72 DMQvjZj6RhoeyiWpCRvW8+jkiKhXJc5mF5j+CPzVohFxNUrPiVKxqAXCvuGd77FZAlcX06b2R7H hHDVYJK5QK8KcPI00RTF8CcsTvLMhewR/NQMR6L9TT/zQkuEov1H2LeIhNF5BYVS01xyiq44nsW 5r8e8rVemSiAlFgORNt5CHNzNknLb1GuozqMMDUzqG7CysFs2TKtAc4d9EYrLXAQRnh7sK04atg s26sFnuYZtME0w= X-Received: by 2002:a05:600c:45c3:b0:485:3473:d4a1 with SMTP id 5b1f17b1804b1-4854b13e63emr36476885e9.34.1773227198440; Wed, 11 Mar 2026 04:06:38 -0700 (PDT) Message-ID: <66926b3b-82e0-4595-b54f-e73cef396ea2@suse.com> Date: Wed, 11 Mar 2026 12:06:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 11:21, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 10:30 AM CET, Jan Beulich wrote: >> On 11.03.2026 10:25, Alejandro Vallejo wrote: >>> On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: >>>> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>>>> - if ( opt_hvm_fep ) >>>>> - { >>>>> - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; >>>>> - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) >>>>> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>>> >>>> Why is this initializer not retained? >>> >>> It is, it's just that the diff is terrible. An unfortunate side effect of the >>> removal of the braces. The scope collapsing forces it on top of the function, >>> before the emulation context is initialised. >>> >>> It's set up in steps. walk is unconditionally initialised as isnsn_fetch, and >>> later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL == 3. See... >>> >>>> >>>>> - unsigned long addr; >>>>> - char sig[5]; /* ud2; .ascii "xen" */ >>>>> - >>>>> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >>>>> - sizeof(sig), hvm_access_insn_fetch, >>>>> - cs, &addr) && >>>>> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >>>>> - walk, NULL) == HVMTRANS_okay) && >>>>> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) >>>>> - { >>>>> - regs->rip += sizeof(sig); >>>>> - regs->eflags &= ~X86_EFLAGS_RF; >>>>> + hvm_emulate_init_once(&ctxt, NULL, regs); >>>>> >>>>> - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ >>>>> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >>>>> - regs->rip = (uint32_t)regs->rip; >>>>> + if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) >>>>> + walk |= PFEC_user_mode; >>> >>> ... here. >> >> But that's the point of my question: Why did you split it? All you mean to >> do is re-indentation. > > Because I need to declare "walk" ahead of the statements. Thus this... > > uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > must (by necessity) have the declaration placed on top before the emulator > context initialisation. The options are... > > uint32_t walk; > [... lines ...] > walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > ... or... > > uint32_t walk = PFEC_insn_fetch; > [... lines ...] > if ( ctxt.seg_reg[x86_seg_ss].dpl == 3 ) > walk |= PFEC_user_mode; > > Line count remains at 3 in both cases, but in the former case there's a > comparison, a ternary operator and an OR all adding cognitive load to the > same statement. In the latter case there's an assignment in the 1st statement, > an if+comparison in a separate line, and a separate OR in the final statement. > It's just simpler to meantally parse because the complexity is evenly > distributed. > > I can see how the current form was preferred to avoid a third line (and > then a forth due to the required newline, doubling the total). But with the > rearrangement that's no longer relevant. > > If you have a very strong preference for the prior form I could keep it, though > I do have a preference myself for the latter out of improved readability. Strong preference or not - readability is subjective. I prefer the present form, where the variable obtains it final value right away. More generally, with subjective aspects it may often be better to leave mechanical changes (here: re-indentation) as purely mechanical. Things are different with objective aspects, like style violations which of course can (and imo preferably should) be corrected on such occasions. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 11:38:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 11:38:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251043.1548342 (Exim 4.92) (envelope-from ) id 1w0Htg-0002z1-2h; Wed, 11 Mar 2026 11:38:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251043.1548342; Wed, 11 Mar 2026 11:38:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Htf-0002yu-Vv; Wed, 11 Mar 2026 11:38:39 +0000 Received: by outflank-mailman (input) for mailman id 1251043; Wed, 11 Mar 2026 11:38:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Hte-0002ym-38 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 11:38:38 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id d732a5f6-1d3e-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 12:38:36 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4853c3c2fe7so20510725e9.0 for ; Wed, 11 Mar 2026 04:38:36 -0700 (PDT) Received: from [192.168.1.6] (user-109-243-67-101.play-internet.pl. [109.243.67.101]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854b0dcf2asm25150185e9.8.2026.03.11.04.38.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 04:38:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d732a5f6-1d3e-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773229116; x=1773833916; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=jTMhN/XBLRhbVc49obxdvF8PZceTAcH/NBbJ45h94Rc=; b=TZc2pQtc8SXI8Q6iN3Ov0BqoImT+gjx8lwmF84NgRHlzLqP3C62sUz0De8Z/8dE+7q RVmuo2RemGg/olpAnyHRZHlV9NvluPDTpE8j+pwglXMIWN+4rxmvKukM4I3dpu6s5bbH TRIyGAk2OODTfFOPh46zdjkZphF7q/Y/xTiWwdtNGCkviQlrs5CF5s45OfQtWJMmmyph 4+sPJl/AUYegREVHq0OlQyeaCVl1mwTNvxse6XPV0yEqtFTK4j9J49sjPHb0UGEzSWnz CgRI43tv+i3VA5PDp1uj/BfzOVDU4kw5f+E3vMFoNbnZ/I0j0e9H0SY649hIau04THBs o6iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773229116; x=1773833916; h=content-transfer-encoding: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; bh=jTMhN/XBLRhbVc49obxdvF8PZceTAcH/NBbJ45h94Rc=; b=bVKL8vWstJUi6ucPscAm3koAIPuk3F3CF1iRykVH9Z19BKtqcFvRZwoOz+Z4W6U6Rh Za7OpFaBm24oOdC17eNrr3/cWTWlV66rZa7FirJ6JZrFpgZ4pu/ESwiJPA8IEhCiIat6 Tn7EbtAetwe4Snj1EoYKGCw76IMiSzFKnKjpSAnyXu65fyD1QYjGTK1P8rlbmGBN5mFa LTNEKitljbxdzdH5Uw67/Fm8Shl7iZpuT6WHqfVYPyaSoczvlx5JRzEH4eGC0oeASPSe 8B3a94UXD2ybeXoWWnY64FAABFBZNFExJ8JW36PKIKESJsS4AeMtNHpr9GcBkeKlhejg lG2w== X-Forwarded-Encrypted: i=1; AJvYcCVSm5GZiyDh2uKGv8sY7Dwf4SumlbvQIkSIgQn6uEyUDYTA+5pJRQTa3RW31exFPwEV976E8yfXqjE=@lists.xenproject.org X-Gm-Message-State: AOJu0YxpYgH9Kb9NusfjRCcblVdBfuuItpgKK29WN7x5tdER1dNA2Mio qWY1TgE7g1v90mIm2VuSXV1qE/TMf8e691Wgbxq5T3ckSlap6OH/0PiG X-Gm-Gg: ATEYQzxmvNFA43iUMrnCmFsIfM23STcMMWoawN7kKtFcm0egEc+urQrrZCMvU3aydTo a4Xzq32WcnFqHWsVJWtp4yY5fpZ0rLtefwnCPeLVDk1QA3vX8+CfpKemZyv00Nj8zMEQJ/G4F6b Nsvl+ecygbm5ce6xscGFec4Fqx9ZZh0mjYZym1pje0FDFCUEj/F8Ymoai/2tu/XiacygGJx+Sgg puole6LyXVBn4yvSo7xABaguRARQbtwWnc1Ao6z+tGks7FKipGa31NA3tkpNN8AI1BYADhS3UjD IfWtds9LcKTxR+5u4Ua9xrGmzBBQuGYzt43aHj2kVpWjcMxcxeU67Qb9cjV15Y+SixJOf3C+NeS AMB5Fj4i1NNx6SZZrGh6QPF0dXo91A9Qn1gVMGz4UMGMQ5eTBmenKJY3gxZ4UnqmCAby318168A ng9V0YwhWFR4n3yvc4R400yA47oTtSF/4eoXE6OocXe6KQrcqad3e7hMCgOLI1lFkKn6hQl9x7i tY= X-Received: by 2002:a05:600c:8710:b0:485:3f72:3230 with SMTP id 5b1f17b1804b1-4854b0d2917mr35612335e9.15.1773229115406; Wed, 11 Mar 2026 04:38:35 -0700 (PDT) Message-ID: <87eb8fb1-aa50-436c-8e2e-050981af4d1b@gmail.com> Date: Wed, 11 Mar 2026 12:38:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing To: Jan Beulich Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> <2e471f54-1885-4615-8a23-c33ce683158f@suse.com> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <2e471f54-1885-4615-8a23-c33ce683158f@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/11/26 11:58 AM, Jan Beulich wrote: > On 11.03.2026 10:54, Oleksii Kurochko wrote: >> On 3/10/26 10:15 AM, Jan Beulich wrote: >>> On 06.03.2026 17:33, Oleksii Kurochko wrote: >>>> --- a/automation/scripts/qemu-smoke-riscv64.sh >>>> +++ b/automation/scripts/qemu-smoke-riscv64.sh >>>> @@ -7,7 +7,7 @@ rm -f smoke.serial >>>> >>>> export TEST_CMD="qemu-system-riscv64 \ >>>> -M virt,aia=aplic-imsic \ >>>> - -cpu rv64,svpbmt=on \ >>>> + -cpu rv64,svpbmt=on,sstc=off \ >>>> -smp 1 \ >>>> -nographic \ >>>> -m 2g \ >>> How does this fit with you panic()ing when SSTC isn't available (i.e. the >>> register cannot be read)? I must be missing something, likely a result of >>> me not being able to really understand the description. >> When SSTC isn't available my panic() won't occur and then will continue to >> be executed. Otherwise, when SSTC is enabled (it is enabled by QEMU by default) >> my panic will occur. > Oh, I notice I misread the condition around the panic(), mainly because of > the misleading / ambiguous message passed to it: "SSTC isn't supported\n" > can mean unsupported by Xen or unsupported by the platform. > > Anyway, to me this is entirely bogus: Why would we panic() because there is > a certain extension available? It is bogus because then we need also add support of SSTC for a guest what isn't done now thereby if it is detected that SSTC is available that it is dangerous to continue about full support (guest part) of it. I thought about the case to let Xen use SSTC and just don't tell Linux that SSTC is available by dropping from riscv,isa property the mentioning of SSTC, so then Linux will still continue to use SBI set timer call to Xen and the will just safely reprogram (if it is needed) a timer using SSTC instructions. But if to do in this way still nothing will prevent a guest to test if SSTC is available by reading CSR_STIMECMP and nothing will prevent to access CSR_VSTIMECMP by guest what could also lead to some misleading behavior. Likely we could set henvcfg.STCE to zero and it will forbid guest to access SSTC registers but I am not sure that we really want such behavior when Xen is using SSTC to setup a timer, but guest isn't allowed. It seems it will be better just support SSTC extension fully and not to support it only for now. > >>>> --- a/xen/arch/riscv/include/asm/csr.h >>>> +++ b/xen/arch/riscv/include/asm/csr.h >>>> @@ -9,6 +9,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> >>>> #ifndef __ASSEMBLER__ >>>> >>>> @@ -78,6 +79,37 @@ >>>> : "memory" ); \ >>>> }) >>>> >>>> +/* >>>> + * Some functions inside asm/system.h requires some of the macros above, >>>> + * so this header should be included after the macros above are introduced. >>>> + */ >>>> +#include >>>> + >>>> +#define csr_read_allowed(csr_num, trap) \ >>>> +({ \ >>>> + register unsigned long tinfo asm("a3") = (unsigned long)trap; \ >>> Why can't this variable be of the correct (pointer) type? This would then >>> at the same time serve as a compile-time check for the caller to have >>> passed an argument of the correct type. >> Good point it could be an option. >> >>>> + register unsigned long ttmp asm("a4"); \ >>>> + register unsigned long stvec = (unsigned long)&do_expected_trap; \ >>> Fiddling with stvec may be okay-ish very early during boot. NMIs, for >>> example, do exist in principle on RISC-V, aiui. There must be a way for them >>> to be dealt with by other than just M-mode. >> Do I understand correct that your concern is about that if NMIs will be handled >> in HS-mode that switching stvec in this way could be dangerous as do_expected_trap() >> doesn't know how to handle NMIs? > Yes. > >> If yes, then NMIs should be handled by M-mode as: >> Non-maskable interrupts (NMIs) are only used for hardware error conditions, and >> cause an immediate jump to an implementation-defined NMI vector running in M-mode >> regardless of the state of a hart’s interrupt enable bits >> and: >> The non-maskable interrupt is not made visible via the mip register as its >> presence is implicitly known when executing the NMI trap handler. >> >> So standard delegation registers like mideleg do not apply to NMIs because NMIs >> are not visible in the mip register. >> >> I haven't found in OpenSBI how they are explicitly handling NMIs, but it looks >> like if they happen in (H)S-mode or (V)U-mode then they will be just redirected >> to (H)S-mode or V(U)-mode: >> https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_trap.c#L361 >> And then do_expected_trap() will fail to handle them... >> >> Interesting that other hypervisors are using the similar approarch (with temporary >> updating of stvec) and they haven't faced such issue with NMIs yet... > Well, NMIs may be rare to occur? And hence very unlikely to occur in this small > a window? It is still sound risky and ASM_EXTABLE approach sounds more safe particular in this case. > >>>> + register unsigned long ret = 0; \ >>>> + unsigned long flags; \ >>>> + ((struct trap_info *)(trap))->scause = 0; \ >>> "trap" would better be of the correct type. Don't use casts like this, please. >>> >>> Further, wouldn't you better set the field to a guaranteed invalid value? 0 is >>> CAUSE_MISALIGNED_FETCH, after all. >> I don't see that such an invalid value exist for scause. I think we have to reserved >> a value from region 24-31 or 48-63 as they are designated for custom use. > Not sure that's possible. "Custom use" may mean "custom" from hw perspective. > I was rather thinking of picking something pretty high in the reserved range, > like (1 << (MXLEN-1)) - 1 or 1 << (MXLEN-2). Agree, it could be an option. > >>>> + local_irq_save(flags); \ >>>> + asm volatile ( \ >>>> + ".option push\n" \ >>>> + ".option norvc\n" \ >>> Shouldn't this come later? >> Do you mean before where SSTC csr is really tried to be read ("csrr %[ret], %[csr]\n")? > Yes. > >> Does it really matter in such small inline assembler? > Yes, if nothing else then to not raise questions. Plus (depending on the > specific operands used), the ADD (MV) could e.g. be representable by a C insn. > >>> And why set ttmp in the first place, when >>> that's what do_expected_trap() writes to? >> To force the compiler to materialize tinfo in register a4 (ttmp) before the >> trap handler runs as handler will use a4 as temporary register. > ??? I don't understand what you mean with "materialize". Mean forcing the compiler to load the variable into the specific hardware register (a4) before the potentially trapping instruction executes, so the trap handler can safely use that register. > >>>> + "csrr %[ret], %[csr]\n" \ >>>> + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ >>>> + ".option pop" \ >>>> + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ >>> tinfo isn't modified, is it? >> It is modified by handler. > Where? It's only used as the address of the two stores. There are to updates of tinfo in the do_expected_trap(): FUNC(do_expected_trap) ... REG_S a4, RISCV_TRAP_SEPC(a3) ... REG_S a4, RISCV_TRAP_SCAUSE(a3) ... END(do_expected_trap) > >>>> + [ttmp] "+&r" (ttmp), [ret] "=&r" (ret) \ >>> ttmp isn't initialized (in C), so the compiler could legitimately complain >>> about the use of an uninitialized variable here (due to the use of + where >>> = is meant). >> ttmp is modified by handler too. > Of course, but just to repeat - you mean "=&r" there. > >>> Whereas for ret the situation is the other way around - you initialize the >>> variable, just to then tell the compiler that it can drop this >>> initialization, as - supposedly - the asm() always sets it (which it doesn't >>> when the csrr faults). >> It was done in that way as when csrr will lead to a fault, handler will jump >> over the csrr instruction and so ret won't be set at all. For that case it was >> set to 0. > And again - this is meaningless if the constraint is "=&r". Make sense... > >>>> + : [csr] "i" (csr_num) \ >>>> + : "memory" ); \ >>>> + local_irq_restore(flags); \ >>>> + ret; \ >>>> +}) >>> A macro of this name would better return an indicator of what it is checking, >>> rather than the CSR value (which the sole user of this macro doesn't even >>> care about). >> With the current one use case it doesn't care but generally I think that someone >> will want to use this macro just to get CSR value. I don't have a speicifc example >> but still it could be used in this way. > Well, if you want to keep it doing so, make the name match what it does (and > in particular what it returns). > >>> Ideally such would also be an inline function. >> I thought about that but I had difficulties with csr* instruction and their second >> operand which expects to have immediate. But if I will have inline function that >> csr_num will be in register. > Only if the function wouldn't be inlined, I expect? Which hence you may need > to force, by using always_inline. It could work. Thanks. ~ Oleksii From xen-devel-bounces@lists.xenproject.org Wed Mar 11 12:41:11 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 12:41:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251082.1548361 (Exim 4.92) (envelope-from ) id 1w0Irw-0002mp-KO; Wed, 11 Mar 2026 12:40:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251082.1548361; Wed, 11 Mar 2026 12:40:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Irw-0002mi-Gl; Wed, 11 Mar 2026 12:40:56 +0000 Received: by outflank-mailman (input) for mailman id 1251082; Wed, 11 Mar 2026 12:40:55 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Irv-0002mc-Hg for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 12:40:55 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8aad7e35-1d47-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 13:40:53 +0100 (CET) Received: from PH7P221CA0071.NAMP221.PROD.OUTLOOK.COM (2603:10b6:510:328::24) by MW6PR12MB7085.namprd12.prod.outlook.com (2603:10b6:303:238::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.12; Wed, 11 Mar 2026 12:40:47 +0000 Received: from CY4PEPF0000EE37.namprd05.prod.outlook.com (2603:10b6:510:328:cafe::ec) by PH7P221CA0071.outlook.office365.com (2603:10b6:510:328::24) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 12:40:47 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE37.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 12:40:46 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 07:40:45 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8aad7e35-1d47-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AuCMEP9XpWU3ctKIjFlHgv8tUHBD2D577Y0Lf5B/eh1aMV5ERR8mBIWsOpeGvpcpD5CWZiwU3VWaRDyduuuDeVo57M7b1wiEw5J1FmpDmwj/qqGox8g0jPw0elVQ9SvEbCxpFEXzQoLdAEXSFhtK2UKVtit9LYfpDejJ/jjVtfWBhuVMle+fWcXrGtUtShC7PoG4fsC/GeRwrUztoM11J90Q4+dx4p8+i5Cy79XJey97GoMNJBMI3zaSjGbAt34fWi1wZMnO0s+d69nz0LARpB4SqtvJPbQNyj9hMzKua803g975jjNgAVsc+6K0vPosjTSja+qFFVMR3taSTECgOQ== 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=VkIQXLNOHmFB9zDorOhqVCMM0hyznygcYm0FFlY59vk=; b=o0yK55K08Ag2vHYZGVT4sALGePyTTg6pv7ZSuFdzePPwtPXcPq4xzO5jdpNur+xXCKJrki18HPRodbMaDsbAOW33+y8ZHJHstjPzrAM8VLjoEq2XWLhKZgXO0AUryaA1Vu3p1B7eEkDhf0jIDWbYwcb+7c+7kdfbjF9O+b7oaZ463C2lG3T2xTYAOiKs7Q3UwtJa/CX3M10jISccsrh9T/FSKdkkO6eJVnKv5sbbJEyHmSsN8wPoLov/2Pt2iEtYzE9NB8koXtAJ6JfPsXGMh9XVreA6A7QWFexB9GEihTwzy2QxDh9Fi1A21+ltkBvZaaGgyL/JTXTghZIlOD4O+w== 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=VkIQXLNOHmFB9zDorOhqVCMM0hyznygcYm0FFlY59vk=; b=RglvFu5sGsbTJ7/mFcFJqNt2aVc32yIe06JbTCfe2gdALxv5NU4GUp2/+SPOh5Jk8Cz77K5yYWzvlLlOAJ6L2IU46SEwQ++u8mwn+WfM065dmhuEkcioD7x/GOp96FGeNeyHabf63915JppZhQFGGt9JItEQmfh4eF1jhD7hFKU= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 13:40:44 +0100 Message-ID: To: Jan Beulich CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Subject: Re: [PATCH v3 2/4] x86/hvm: Disable cross-vendor handling in #UD handler From: Alejandro Vallejo X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-3-alejandro.garciavallejo@amd.com> <813d3fc9-170a-4f25-872a-3688946c236d@suse.com> <66926b3b-82e0-4595-b54f-e73cef396ea2@suse.com> In-Reply-To: <66926b3b-82e0-4595-b54f-e73cef396ea2@suse.com> 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: CY4PEPF0000EE37:EE_|MW6PR12MB7085:EE_ X-MS-Office365-Filtering-Correlation-Id: 4d679ad1-7eb7-46d1-93a0-08de7f6b6b3b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|376014|1800799024|82310400026|18002099003|56012099003|22082099003; X-Microsoft-Antispam-Message-Info: EplUtRIzctCE5VNr1hhQBufyXtpzmVnHlRFB5UFfM19puqbegZp+EBYYex0tWNt0W+WwNsrC4CINi2zyvnsGfBIfL/htcMQ88UTcqwKQMFiAbATJl4BZU3RDCV+g1h/+ZvAJvBPufiu2Il1j2GIIGpjWcsSDjsj/tusSbaGKiI/vRwfaqcERbKf1qQe6DynltjU+Oi9S4m50CVjSA5nFrO6NBmoWUYGgyFSUD5FClLhH0qCZGpWf3K1xwa5ngS51DFWt2Cbz6xo6F73YSNwc7jhDOxN4/HHiUeoBSwyfgOxQwp0o8d1Mo2HB0QJOPQTDP8ReDWUkOtIdEf1I05Z1TO16d2AMqa2Ks5sS4XkDdCQBWSFtZ+MSTnmLLouetMyRCoc/KZWDCJnnzahTD3z2ka+A2qS1leVqzBK1ljOypwrX1h7qtyrwvMthJ2OzAcl2sRoxD8oamS8uWyHA+jNTbWid6zchLIYqDLrJ7oApT1z9tuOUbXlrq/PmT8K0f4M8xbOYVDeSfDd+mhLyhyNfwD9kJKMC4X2LleUF5QCqnBT8pkE4NpRONSuzg0sRShk7efjDURPtsLhYu33j4pxrruh7S4P448DKZ38f9y1eGmBmjMQjgHQ3UlrI2+7Krm2hzYA5NeFH8lMnu37qT4obDxnKTnK4qwmgEb2F0yo14UYcbP6noAB9TuITA0m6BcQqM/6N8f6kM3aMjbmmYUAKnWcITUcNHeKVF0n1oTLtDZr8rFzgaOeqLA0bsh5BvsO7L3tVf9OxN5ZkZnL6IPVhlw== 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)(376014)(1800799024)(82310400026)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 6CFXoKZQ6Wa2G3HrgAt8Tb420P09OoE1X8ffJ9lSEMtQ5mGnD2y/NFgKSuGb0bIp/NxcB8kkeP5pqh1ZiO5uEBBFS03diDjUDYUf8eX+j9ebn2qgH2Vhfk/4o1HKxqxcgxLcPArzQPipyMJY41wJGnvP2+A3wDCt0UvZ5+u6VPkma/oIfmLfQr9BjQP/qXUJeyQUviVqFN7ldko9BzJhPlzYQrjHT4+b7FGfhcjcFSCrNUH8VXNNTLy6rEG7z6cD5tHt2jyMFRDOkfBhH7jiYO+2d93aKHt7cIXU6yrPFEaMIg88MkO8yeFJ3QBGDaX3VkCnmC6FuqEvCRbjZfZxtdrecdP0epLNzIZNK7HVzK1FyCSKfBC58LPJ+jYP6wC1iBx44FrY9n6tZ5AcTqcwHOA0p7UyyIphfLKy+mmC/nmRzhAxx2UMw2jPrwR0ept/ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 12:40:46.9603 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4d679ad1-7eb7-46d1-93a0-08de7f6b6b3b 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: CY4PEPF0000EE37.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB7085 On Wed Mar 11, 2026 at 12:06 PM CET, Jan Beulich wrote: > On 11.03.2026 11:21, Alejandro Vallejo wrote: >> On Wed Mar 11, 2026 at 10:30 AM CET, Jan Beulich wrote: >>> On 11.03.2026 10:25, Alejandro Vallejo wrote: >>>> On Wed Mar 11, 2026 at 9:35 AM CET, Jan Beulich wrote: >>>>> On 13.02.2026 12:42, Alejandro Vallejo wrote: >>>>>> - if ( opt_hvm_fep ) >>>>>> - { >>>>>> - const struct segment_register *cs =3D &ctxt.seg_reg[x86_seg= _cs]; >>>>>> - uint32_t walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) >>>>>> - ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>>>> >>>>> Why is this initializer not retained? >>>> >>>> It is, it's just that the diff is terrible. An unfortunate side effect= of the >>>> removal of the braces. The scope collapsing forces it on top of the fu= nction, >>>> before the emulation context is initialised. >>>> >>>> It's set up in steps. walk is unconditionally initialised as isnsn_fet= ch, and >>>> later (after emulate_init_once()), OR'd with PFEC_user_mode for DPL = =3D=3D 3. See... >>>> >>>>> >>>>>> - unsigned long addr; >>>>>> - char sig[5]; /* ud2; .ascii "xen" */ >>>>>> - >>>>>> - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, >>>>>> - sizeof(sig), hvm_access_ins= n_fetch, >>>>>> - cs, &addr) && >>>>>> - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), >>>>>> - walk, NULL) =3D=3D HVMTRAN= S_okay) && >>>>>> - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) =3D=3D 0) ) >>>>>> - { >>>>>> - regs->rip +=3D sizeof(sig); >>>>>> - regs->eflags &=3D ~X86_EFLAGS_RF; >>>>>> + hvm_emulate_init_once(&ctxt, NULL, regs); >>>>>> =20 >>>>>> - /* Zero the upper 32 bits of %rip if not in 64bit mode.= */ >>>>>> - if ( !(hvm_long_mode_active(cur) && cs->l) ) >>>>>> - regs->rip =3D (uint32_t)regs->rip; >>>>>> + if ( ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3 ) >>>>>> + walk |=3D PFEC_user_mode; >>>> >>>> ... here. >>> >>> But that's the point of my question: Why did you split it? All you mean= to >>> do is re-indentation. >>=20 >> Because I need to declare "walk" ahead of the statements. Thus this... >>=20 >> uint32_t walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) >> ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>=20 >> must (by necessity) have the declaration placed on top before the emulat= or >> context initialisation. The options are... >>=20 >> uint32_t walk; >> [... lines ...] >> walk =3D ((ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3) >> ? PFEC_user_mode : 0) | PFEC_insn_fetch; >>=20 >> ... or... >>=20 >> uint32_t walk =3D PFEC_insn_fetch; >> [... lines ...] >> if ( ctxt.seg_reg[x86_seg_ss].dpl =3D=3D 3 ) >> walk |=3D PFEC_user_mode; >>=20 >> Line count remains at 3 in both cases, but in the former case there's a >> comparison, a ternary operator and an OR all adding cognitive load to th= e >> same statement. In the latter case there's an assignment in the 1st stat= ement, >> an if+comparison in a separate line, and a separate OR in the final stat= ement. >> It's just simpler to meantally parse because the complexity is evenly >> distributed. >>=20 >> I can see how the current form was preferred to avoid a third line (and >> then a forth due to the required newline, doubling the total). But with = the >> rearrangement that's no longer relevant. >>=20 >> If you have a very strong preference for the prior form I could keep it,= though >> I do have a preference myself for the latter out of improved readability= . > > Strong preference or not - readability is subjective. I prefer the presen= t > form, where the variable obtains it final value right away. More generall= y, > with subjective aspects it may often be better to leave mechanical change= s > (here: re-indentation) as purely mechanical. Things are different with > objective aspects, like style violations which of course can (and imo > preferably should) be corrected on such occasions. Ack Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 12:44:07 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 12:44:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251090.1548369 (Exim 4.92) (envelope-from ) id 1w0Iv0-0003Hn-0G; Wed, 11 Mar 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 1251090.1548369; Wed, 11 Mar 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 ) id 1w0Iuz-0003Hg-To; Wed, 11 Mar 2026 12:44:05 +0000 Received: by outflank-mailman (input) for mailman id 1251090; Wed, 11 Mar 2026 12:44:04 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Iuy-0003Ha-TJ for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 12:44:04 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f91415a5-1d47-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 13:43:59 +0100 (CET) Received: from PH8P223CA0018.NAMP223.PROD.OUTLOOK.COM (2603:10b6:510:2db::28) by SA5PPF7D510B798.namprd12.prod.outlook.com (2603:10b6:80f:fc04::8d0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.10; Wed, 11 Mar 2026 12:43:52 +0000 Received: from CY4PEPF0000EE30.namprd05.prod.outlook.com (2603:10b6:510:2db:cafe::82) by PH8P223CA0018.outlook.office365.com (2603:10b6:510:2db::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 12:43:51 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by CY4PEPF0000EE30.mail.protection.outlook.com (10.167.242.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 12:43:51 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 07:43:49 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f91415a5-1d47-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Wn3I7U1/urEkvk3hnqSAyvbIoe+zTfaqoFQlWhvwYwKNYj+gjGdFkTMUtxv3vtK8Z9b/6AWcUqokEmynz8KHqTBRh6PSJwq7JKAPxXDv8ybM+cR7U5lJNlENS/Gbj1AZ1CnYKVeml5X3Tz26s2nv1t6Lez7CdGezPfwtXTe7Mvif4w6HYNvddiVu2ihUa6N0ZvlqqFYx0Vz/eUfKffhvnvTdmZOyxF3UwXUfBLOGyL81LmHLPkvb3M7YZMctdUxhEYmg9R3eBh2CY8omkte++wxQNIe02h0/3vPM2jqloda8GO56L72OWGWP7Wmjezan5PLiFWDlqh64XoGc0MHkpA== 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=EG8cZI98ZOM0QjlQOmrqhILQJn7/3KTuPiOq/eLp4m8=; b=p1BK2UrC8FSO4ONjUeHYQDqKgilrY0GLRYYGD1j8l0GoizsLWBl2UDT4Lmy3rMfYDuTeBQH3OUt1j3R/JyXMkvKId+Rcw2T+N9llN/797hPGI+Y5VC/3v8Bg4E6ykagWS1eskOMLyic/J2YC1p37KPgF34t3B8s6SzxWRLVKSsu0oSuAr79EOugDNlsj7KBsHstqqGB2LuL3bqhbl97DK7TJajznsi3onGr/juWJ27HIBvQnpeI8Vt64SsKcxL0JoRV6rwhIuUMHoq4xrr+7zZ10qCXYapv7cxULW8Wh8c19f1LVtZw1KRE36BcCxJctPhmNUuiC66bYP+SGGZkbvA== 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=EG8cZI98ZOM0QjlQOmrqhILQJn7/3KTuPiOq/eLp4m8=; b=BI9un+tZxaJCTPgjb/F4yhXkVSkLWcE8tPxOJczRp8C2W4GdQqs+LDDg43Hnuf9LynPaVAcgzwgJI6XjYSVSGawMc8z/dlJMo8R/NeMLvmJcveeDMvvvIGtGlqgwOWVUA+DlQ0q9q0bN9cYwFQZhHmHXnSer2ZMqlrm0S663YH4= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 13:43:48 +0100 Message-ID: Subject: Re: [PATCH v3 1/4] x86: Reject CPU policies with vendors other than the host's From: Alejandro Vallejo To: Jan Beulich CC: Oleksii Kurochko , Community Manager , Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , X-Mailer: aerc 0.20.1 References: <20260213114232.42996-1-alejandro.garciavallejo@amd.com> <20260213114232.42996-2-alejandro.garciavallejo@amd.com> <8ba61374-f05e-45d9-b1b2-0140edbb34a6@suse.com> In-Reply-To: <8ba61374-f05e-45d9-b1b2-0140edbb34a6@suse.com> 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: CY4PEPF0000EE30:EE_|SA5PPF7D510B798:EE_ X-MS-Office365-Filtering-Correlation-Id: c4063f4b-cc07-4e68-f80d-08de7f6bd90e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|82310400026|376014|1800799024|36860700016|22082099003|56012099003|18002099003|13003099007; X-Microsoft-Antispam-Message-Info: Qdsv4Me/1AxVxO0sZ0IOydAJdoUeJeaPbWC045b7C1yQhbU247F0v11WGD0qrtuW8BUCi9e8oe+yZL6VJDQEeL/OTOJ0KwPodf6pvBvhfmJg7WBp1vFl5JqSWZt3PXm6zhhcM2uyHDhmQkzEXuBtARVUBfeEw/Q6mmLr3oKa9PEsKCFnBI0uYV1FIhS6cp+mQ4PeI1cGM55/v2vSbl30u7HAu5hoqXkMZNdlqJZHdS3IZQYYOUjllOqDjZAv9m9CwL3N4VHM5XotLQXW44b0txU2qDDAY3GX2kkNC3pQSwrRAnjc1xgMN/hcayRhnP/ekO1+Wx2vSVcwU032AMg//frnOWcPYMfSan2Z8lDGXNaycU0zOBvA/dHy1BeYnWt8MF8hCtO19iMirIucZZmC64pfeoTBCs9S5PYh+4HmgtWE12baxLeJ0FeHrC40pcrVu479Ul4PeYEczB340ttbyTNSVzFs8UpDWWUCAV77KF/aPvZh4ytKEPv0oiXvTVBI+YU0yljYqpmthrGC0xn5FvnUcjFqcAExC595KxiioAKaLUhn7tYkOmmrw5FpFEzYY11PC/KljBIB3142vWr5m88Zqt8trysAlMetwgc2NstAFEJw6dGSMfVurs13uBnkT+x/VYoz6KTXEJukp5YWxQqppNH8Zyk6suYljZPum746ZfnKifPk3JRs2WQGA1oJ1B+7G5qPHgCNLEzJCZ6n3I/rIk4O61/ZDGwqcoc/Ldw= 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)(376014)(1800799024)(36860700016)(22082099003)(56012099003)(18002099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: RX/FnzcBSKbmZV/YSMsYrZ98NcXaHqn40PVT8jDTAP+a4C2VMGKyYta1Z1QGHcfUP06htAqKrIhy1GqWb+pf//pWVdDmbZ/fYffbsW6oL9TAqeSxRVAGSLcg+27d4GsEc/aoTcbLETex//QsLhTGodlgKhEd8APa1kRdgf+aem12stNP+UNbgtBOvHKDq/lXLC0JyuDY3CunJ3PtkApvJ8Bx56ebDM+qc3wvz1/+gAWP5hl6EPT5UBKh6R5NJrbfv4cwwW/5l2eTC8860nu6eCI2yXLHNWi1bWJXq0mgFdNAKz0h2iD3EkTqI6DXId4xhKObQIGJmVvZC/YUA/QFECH88/lp0hfCoQIbt2MfG7+LiMfWporWYgWwFCdJb/W4bBoOsPt/C3h9EIxJjrEYow0UU77fO/T+m7gW69I6BuuXpfe0HA8M1o13305v7L0N X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 12:43:51.2185 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c4063f4b-cc07-4e68-f80d-08de7f6bd90e 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: CY4PEPF0000EE30.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA5PPF7D510B798 On Wed Mar 11, 2026 at 9:26 AM CET, Jan Beulich wrote: > On 13.02.2026 12:42, Alejandro Vallejo wrote: >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -22,6 +22,11 @@ The format is based on [Keep a Changelog](https://kee= pachangelog.com/en/1.0.0/) >> - Xenoprofile support. Oprofile themselves removed support for Xen = in 2014 >> prior to the version 1.0 release, and there has been no developmen= t since >> before then in Xen. >> + - Domains can no longer run on a CPU vendor if they were initially l= aunched >> + on a different CPU vendor. This affects live migrations and save/r= estore >> + workflows accross mixed-vendor hosts. Cross-vendor emulation has a= lways >> + been unreliable, but since 2017 with the advent of speculation sec= urity it >> + became unsustainably so. > > While the code adjustment looks okay to me, the wording is a little odd. = What is > "run on a CPU vendor"? How about "Domains can no longer run on a system w= ith CPUs > of a vendor different from the one they were initially launched on"? > > Also, nit: "across". Sure Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 12:54:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 12:54:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251110.1548378 (Exim 4.92) (envelope-from ) id 1w0J5L-0004wZ-Rx; Wed, 11 Mar 2026 12:54:47 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251110.1548378; Wed, 11 Mar 2026 12: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 ) id 1w0J5L-0004wS-Ox; Wed, 11 Mar 2026 12:54:47 +0000 Received: by outflank-mailman (input) for mailman id 1251110; Wed, 11 Mar 2026 12:54:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0J5K-0004wM-AU for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 12:54:46 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7a19ce25-1d49-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 13:54:44 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-4853e1ce427so36785325e9.3 for ; Wed, 11 Mar 2026 05:54: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 5b1f17b1804b1-4854b66e3f8sm48934515e9.14.2026.03.11.05.54.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 05:54:43 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7a19ce25-1d49-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773233684; x=1773838484; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=U5ulGpwPGUeubOHrOFQJRstkDUZXs/VLi5V3Py6WIZE=; b=F3qfc0fW60rB261Eoyhmuqpk72nv9zDAMcqPqeO013RRZ71vOMcYVM2fe0gzbv06R3 t3e3o37knb/gFfBUvZv04QlwEWaQDIE25YgK05ZiBNnqWGmkr39a0r5N3GANTNnOzELW PuAluxIufCGx1rmTXvLxH2jnx+yT1OBjPb4KLU7n+nJWBL2rYwHJ/QrFlSFatw8dvJBd iGEfZ0GX9iSwiuLeQSZRjMcxWeiNBU2yFtRLeBSlwfx1JxROYMyqpqogQL/pRSGmrfOj eu5j6HzG+zK21VK5wz1ZRVblH8XPXRSZk7RMiHxkg0SIZe9IJLa0/Ks+flv33fgJvJP6 hPrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773233684; x=1773838484; h=content-transfer-encoding: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; bh=U5ulGpwPGUeubOHrOFQJRstkDUZXs/VLi5V3Py6WIZE=; b=ead6s4OmnB+0KJJ/GnBh0VjuH+LZ2TesWBvbq7+g1dgUGSwuP6SF7Zv9V7jCVy5Ujq wuq8vvWHaSvTJ9J8Cp3BUeFthIiQUmAPJWK2BZg1/+3e7SFdR4MDR9Pr31IGeYSOvvKX /2lZmnH4aQrBwBmI1L9mHIjXy75zfH50xdKUKEDEWD2eXa2fV1V3X63uOKIapkoWi1Zu RxPEqsf1LuZbkKv/qNAd88fACPWRYCaUGHtFN3qjBbm0H3IQLtHpdtbdp8l16vR4FvfS hImyV9GAJjpRcAIkU6o8mOd2HR+gA0lII7CiTyYoUuYaas173U3XXEMLByhDy7S97L6W Kobw== X-Forwarded-Encrypted: i=1; AJvYcCVvZg5Fj4qCBY56/veGoX0koqPgMDld/tes/4yX9CN42nS4m/AuMmyWo/OppMIbDUm/2EC6btE2854=@lists.xenproject.org X-Gm-Message-State: AOJu0YzwHP0lJopixWsXiWnsHrTBb7s5lvE2b4nPK+gMhFZiKKN9hNVm MkQz8ctItkWKCPe8qJe6ZjCtwIYfoyb/HBHlSye6s7u45sdAOv9FOaxrrXbb/fDt7w== X-Gm-Gg: ATEYQzyrFvqUn6zFYBKDRNILGrWWgPtjdUW/LF4LjRDF4cqxl5Lu7EvzoFosfvyJFia XiBp7ramOB+5mXmwyumyARGHaphhB3WegjacP9BRbn08E25D5qUXrKt8HimhsECno//An1O7wG3 uP970NAkK7HA2ugWcwZkABudXEpKrpGE97VSMe9B3E9nqyl1ONrTnVSLGdHWPO72GYq15nPyKXs PNn1DAjMS0FSV/JAhw+w+nsZ/Zh184nw0TRcYAdUfC1cUruXZw+tLndJ7Qe9h93wkOqjevR5zCZ dBgPlaURGyBZ1fkng7B362s7zf++3JXcrvJ9GDqm3a1vfq5NOkO8nhTizeWJfo88NPK9SIffoXP RaXQEWmOSN0BHRz8X+Op/j8akYYsMBXvrKRB+mgZz+wYGz4eCvpEV6GSBRm4PGP3AkUwKIEsBqH Genb+WoZMfrovNIltJSoD2AMYqRjjnXJo7+PDK007jwNOo0yMmVm8GqT2S7UveMQoLAEU+ZjBpi Bssd5NXKM11MJE= X-Received: by 2002:a05:600c:4693:b0:485:481c:e7bb with SMTP id 5b1f17b1804b1-4854b1009d9mr37946765e9.20.1773233683850; Wed, 11 Mar 2026 05:54:43 -0700 (PDT) Message-ID: <66a4763e-6d98-4919-b3d5-350c4d23fc32@suse.com> Date: Wed, 11 Mar 2026 13:54:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 14/14] xen/riscv: Disable SSTC extension and add trap-based CSR probing To: Oleksii Kurochko Cc: Romain Caritey , Doug Goldstein , Stefano Stabellini , Alistair Francis , Connor Davis , xen-devel@lists.xenproject.org References: <9ff93ad1-0151-4f37-a6c2-f7dd4197ca84@suse.com> <2e471f54-1885-4615-8a23-c33ce683158f@suse.com> <87eb8fb1-aa50-436c-8e2e-050981af4d1b@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <87eb8fb1-aa50-436c-8e2e-050981af4d1b@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 12:38, Oleksii Kurochko wrote: > On 3/11/26 11:58 AM, Jan Beulich wrote: >> On 11.03.2026 10:54, Oleksii Kurochko wrote: >>> On 3/10/26 10:15 AM, Jan Beulich wrote: >>>> On 06.03.2026 17:33, Oleksii Kurochko wrote: >>>>> --- a/automation/scripts/qemu-smoke-riscv64.sh >>>>> +++ b/automation/scripts/qemu-smoke-riscv64.sh >>>>> @@ -7,7 +7,7 @@ rm -f smoke.serial >>>>> >>>>> export TEST_CMD="qemu-system-riscv64 \ >>>>> -M virt,aia=aplic-imsic \ >>>>> - -cpu rv64,svpbmt=on \ >>>>> + -cpu rv64,svpbmt=on,sstc=off \ >>>>> -smp 1 \ >>>>> -nographic \ >>>>> -m 2g \ >>>> How does this fit with you panic()ing when SSTC isn't available (i.e. the >>>> register cannot be read)? I must be missing something, likely a result of >>>> me not being able to really understand the description. >>> When SSTC isn't available my panic() won't occur and then will continue to >>> be executed. Otherwise, when SSTC is enabled (it is enabled by QEMU by default) >>> my panic will occur. >> Oh, I notice I misread the condition around the panic(), mainly because of >> the misleading / ambiguous message passed to it: "SSTC isn't supported\n" >> can mean unsupported by Xen or unsupported by the platform. >> >> Anyway, to me this is entirely bogus: Why would we panic() because there is >> a certain extension available? > > It is bogus because then we need also add support of SSTC for a guest what isn't > done now thereby if it is detected that SSTC is available that it is dangerous > to continue about full support (guest part) of it. > > I thought about the case to let Xen use SSTC and just don't tell Linux that SSTC > is available by dropping from riscv,isa property the mentioning of SSTC, so then > Linux will still continue to use SBI set timer call to Xen and the will just > safely reprogram (if it is needed) a timer using SSTC instructions. But if to do > in this way still nothing will prevent a guest to test if SSTC is available by > reading CSR_STIMECMP and nothing will prevent to access CSR_VSTIMECMP by guest > what could also lead to some misleading behavior. > Likely we could set henvcfg.STCE to zero and it will forbid guest to access SSTC > registers but I am not sure that we really want such behavior when Xen is using > SSTC to setup a timer, but guest isn't allowed. I don't see what's wrong with Xen using an extension that isn't made available to guests. > It seems it will be better just > support SSTC extension fully and not to support it only for now. If at all, an ack for such from me would be pretty reluctantly given. >>>>> + register unsigned long ret = 0; \ >>>>> + unsigned long flags; \ >>>>> + ((struct trap_info *)(trap))->scause = 0; \ >>>> "trap" would better be of the correct type. Don't use casts like this, please. >>>> >>>> Further, wouldn't you better set the field to a guaranteed invalid value? 0 is >>>> CAUSE_MISALIGNED_FETCH, after all. >>> I don't see that such an invalid value exist for scause. I think we have to reserved >>> a value from region 24-31 or 48-63 as they are designated for custom use. >> Not sure that's possible. "Custom use" may mean "custom" from hw perspective. >> I was rather thinking of picking something pretty high in the reserved range, >> like (1 << (MXLEN-1)) - 1 or 1 << (MXLEN-2). > > Agree, it could be an option. > >> >>>>> + local_irq_save(flags); \ >>>>> + asm volatile ( \ >>>>> + ".option push\n" \ >>>>> + ".option norvc\n" \ >>>> Shouldn't this come later? >>> Do you mean before where SSTC csr is really tried to be read ("csrr %[ret], %[csr]\n")? >> Yes. >> >>> Does it really matter in such small inline assembler? >> Yes, if nothing else then to not raise questions. Plus (depending on the >> specific operands used), the ADD (MV) could e.g. be representable by a C insn. >> >>>> And why set ttmp in the first place, when >>>> that's what do_expected_trap() writes to? >>> To force the compiler to materialize tinfo in register a4 (ttmp) before the >>> trap handler runs as handler will use a4 as temporary register. >> ??? I don't understand what you mean with "materialize". > > Mean forcing the compiler to load the variable into the specific hardware > register (a4) before the potentially trapping instruction executes, so the > trap handler can safely use that register. I fear there's some misunderstanding on inline assembly here. An output-only variable doesn't need "pre-loading". But anyway, all of this is gong to be moot here (but potentially relevant elsewhere in the future) when this becomes a mere clobber. >>>>> + "csrr %[ret], %[csr]\n" \ >>>>> + "csrw " STR(CSR_STVEC) ", %[stvec]\n" \ >>>>> + ".option pop" \ >>>>> + : [stvec] "+&r" (stvec), [tinfo] "+&r" (tinfo), \ >>>> tinfo isn't modified, is it? >>> It is modified by handler. >> Where? It's only used as the address of the two stores. > > There are to updates of tinfo in the do_expected_trap(): > > FUNC(do_expected_trap) > ... > REG_S a4, RISCV_TRAP_SEPC(a3) > ... > REG_S a4, RISCV_TRAP_SCAUSE(a3) > ... > END(do_expected_trap) a3 is used there twice, yes, but neither use modifies the register. If the first use modified it, the 2nd use would be broken. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:10:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:10:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251147.1548387 (Exim 4.92) (envelope-from ) id 1w0KGI-0005s5-0B; Wed, 11 Mar 2026 14:10:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251147.1548387; Wed, 11 Mar 2026 14:10:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KGH-0005ry-T9; Wed, 11 Mar 2026 14:10:09 +0000 Received: by outflank-mailman (input) for mailman id 1251147; Wed, 11 Mar 2026 14:10:09 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KGG-0004uP-Q9 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:10:08 +0000 Received: from SA9PR02CU001.outbound.protection.outlook.com (mail-southcentralusazlp170130001.outbound.protection.outlook.com [2a01:111:f403:c10c::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 00b9ee66-1d54-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 15:10:06 +0100 (CET) Received: from BN9PR03CA0526.namprd03.prod.outlook.com (2603:10b6:408:131::21) by DS0PR12MB6560.namprd12.prod.outlook.com (2603:10b6:8:d0::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 14:09:58 +0000 Received: from BL02EPF0002992A.namprd02.prod.outlook.com (2603:10b6:408:131:cafe::3e) by BN9PR03CA0526.outlook.office365.com (2603:10b6:408:131::21) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 14:09:57 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by BL02EPF0002992A.mail.protection.outlook.com (10.167.249.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:09:57 +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.17; Wed, 11 Mar 2026 09:09:56 -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.17; Wed, 11 Mar 2026 07:09:56 -0700 Received: from [172.22.194.138] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 11 Mar 2026 09:09:55 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 00b9ee66-1d54-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xHSB9k28sB7kUHz4QI13a+wqhdHaQdN+uJd3uXfo1wRZ1Ea0p6wCPjR4LUUXM9LbmiYzghENDXdop8LsnlEM50FOrYsm9W6Ubav+9z7LKfqCDz6pnFJDRs9gta64/R7wtz5wgHiBeHboPvcEJk0X4ExKGdaYzJ24ijdQppJsUxfkc3w0aRZZSuWzvQtosDDs4hkckd5vMqJE0dahi401Mk5vQhp6zDX0JwZi9zV9tUOAxU7jthtxLhSa8rxqiwVzn32SleNqIqYonOaFLc7kFnHZ6VHZ5+mN5gHj2c50AQVF80FV8kabDdNw3OcutUkkokoKKAedPAByukNQrvgp7g== 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=F4YOctJBCJL3jsVpHCrS9Gm56uQh0xSYflxixPkOSk0=; b=s51oPup+ET5DtgpUeZyIuhOQ4/fUpsAetxFhZ1KhxSacthz26RbbKsnS/gY5LDJ81FPkxdRj6CkrfXKdFkGArgurcvJcdV4I7TUWK4Huz1vCEMene41Sje6ndSWNIzSdZ8tuuZCY0cZN1IglcaxEPrh6kosxrms6OCxb2uIgSVKGCkdlHboSPIPY5iEEI/6Dkc+BYUxrhUHFbc75DV8ylQFm02tR7yF71uMmt95dBps8BbUrki0dxLqAglKLHXGjVkt/4vdZdYfRwY7GeUVQDSKt3hG9RQMttzJKz7k5pjFeBPhtnsKk5PSNhn8zU76BWXnVXDvq6U6o8M/SPcPZvw== 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=F4YOctJBCJL3jsVpHCrS9Gm56uQh0xSYflxixPkOSk0=; b=AU6uvStSt5BblpzqCx/zMevi9PksCnesTpynOqm/Xy52tcEtoQsk3yC8NaMWwb7dgCveXn4AHDBsfSg527NVaUNKcyLgnIGz9g6IxqrSuSip8fPceuZMttOyA2WKSfpHqQReqN+SV81PaICFAgshAWvTt1c3cJcdpyHWf004J00= 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: <8ccde8eb-d8a4-411c-bd6e-9c3fcea1150f@amd.com> Date: Wed, 11 Mar 2026 10:09:54 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: fix unmapped access trapping on GICv2 hardware To: "Orzel, Michal" , , Stefano Stabellini , Julien Grall CC: Bertrand Marquis , Volodymyr Babchuk References: <20260205190128.38716-1-stewart.hildebrand@amd.com> <1e8f9976-b0b6-47b1-88c0-690d4f1589ce@amd.com> Content-Language: en-US From: Stewart Hildebrand In-Reply-To: <1e8f9976-b0b6-47b1-88c0-690d4f1589ce@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0002992A:EE_|DS0PR12MB6560:EE_ X-MS-Office365-Filtering-Correlation-Id: 8486a416-9bba-4eeb-1342-08de7f77e01c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: O+2s6PO9jtD8zTXDjTw0EEXZFIfVtSV8cvM3SmCkm4gLz5evPPc9bf+i1aOMFwbm4uxijQQcuWd693ipFDyvCTvbOrE8YODnBlso/WvcEj8PJ+DmRYlaomx09pEMy7hGhTsFUIcx1BuBFkcYUZDAQi5itLW21KAp0veu+wa6pfOUMb5XCa7uob4kdX3aFdkR8FSdvYkJrVuHtkGKIpG9H6hIo1uYerkcVQplMYPxarP8wcVf+h733iQcDHD82SKQVO8WAEf5K2KPnV5zHuaWWMLPaqQ7V+OJGmnshV7PfwwZAAVBUuyhvq+1qWn8N/YAkiFDuaKyKIrPiNjR86QVhDT6wNURnZf5Nn1UHo8QMLonCcHaVYq69wzjNbjTD09joebf9T8t5ej13MJ0GCGBzRxE0KGPdtttcdikdOJ7mwwdJx16/u7Kb8KsvugQRpsW0652NK2YPoZEdwybGJD7rmfaeHH7OohMmWO/PCqiYNF9TF7HEQQHQ8BConh1OrUB+B9reBit2sUXJM6hVYwwpCw2k0xCut3DROjRMIYjlxP7y1kAeyCw531tMC0oXSkOQHi+eLoWp7u4VSfKkdpyFCAo4jDyr2CzQjG4K8IxjuJBSCONQzk3V1CluflzR0qqQgodoca/7iqSkLzJdvFrHL5+FU8ADGDtwlesYfhfVzEVt1cSEgX+RCWO3T3fovlXGuPKCeLTxdokrEg9rd9BCiUeSUYq5tfexQLFnOI9mYDAK7BzIHtJHU3J8T4moarM8S+509w0rG+mTs3UVQgGfQ== 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)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: KzNDEO56otrvHbRZr8cnb7bbJoYUaf3lvxyaqKvA6GDXyNSptOmPFC/uXINRT1Xv4bP9MN+KNarr9ITDcurq9vWX4tCueU9fjoGDNCUZ8Ovjxx2HMKhgZQ06x9A4AUQnBdUhgObLRbjU5G9b6SOt4cIYexLimps0RGg0V+4lxOkYUcR52k7P0uSJ8ejWrZZ6hhEwSz5tE5TrZ7vJI7LZTLAjyZeYDX1Uu4ccmq6JqsRt/fOxJTSOfNkRuqqF2d6HZS0vistLRj6EGjgnGaJpvmjF67TKVm39gbHZAYeNpFdMvU+ws/3nhTPDRiI55Ose5+U2QU+hh8KXmTUhqg4obaxx/IaFTIZl3veTuuJLDi63O6X6orcq5JrGP46XSUuAFv4TK756l6HN81R9utvQXx27d/YdPuqXB9fLAHFMn25dBsYSgmt1XYYsGEG6lzK2 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:09:57.0517 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8486a416-9bba-4eeb-1342-08de7f77e01c 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: BL02EPF0002992A.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6560 On 2/18/26 12:16, Orzel, Michal wrote: > > > On 18/02/2026 15:21, Stewart Hildebrand wrote: >> Gentle ping. > Sorry, I'm quite busy these days. > >> >> To be clear, domU interrupts with vGICv2 are currently broken when >> XEN_DOMCTL_CDF_trap_unmapped_accesses is not set. >> >> On 2/5/26 14:01, Stewart Hildebrand wrote: >>> Since 4dbcb0653621, the vGICv2 CPU interface is mapped in a deferred >>> manner. On domains with XEN_DOMCTL_CDF_trap_unmapped_accesses unset on >>> GICv2 hardware, the vGICv2 CPU interface fails to be mapped. A visible >>> symptom is that a domU gets stuck at: >>> >>> [ 0.177983] smp: Bringing up secondary CPUs ... >>> >>> Move the 2nd check_p2m earlier so it's prioritized over try_handle_mmio. >>> >>> Fixes: 980aff4e8fcd ("xen/arm: Add way to disable traps on accesses to unmapped addresses") >>> Signed-off-by: Stewart Hildebrand > I investigated whether the reordering is safe and it looks ok: > Reviewed-by: Michal Orzel Thanks! Is there any other feedback? Is this ready for commit? From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:10:59 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:10:59 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251153.1548396 (Exim 4.92) (envelope-from ) id 1w0KH5-0006HX-9J; Wed, 11 Mar 2026 14:10:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251153.1548396; Wed, 11 Mar 2026 14:10:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KH5-0006HQ-65; Wed, 11 Mar 2026 14:10:59 +0000 Received: by outflank-mailman (input) for mailman id 1251153; Wed, 11 Mar 2026 14:10:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KH3-0006HK-VS for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:10:57 +0000 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [2a00:1450:4864:20::434]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 1c4dd145-1d54-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:10:51 +0100 (CET) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-439c944bb62so5477193f8f.3 for ; Wed, 11 Mar 2026 07:10: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-439f820a2f1sm6922475f8f.30.2026.03.11.07.10.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 07:10:50 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1c4dd145-1d54-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773238251; x=1773843051; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=jBjKyQK+QtIz3+tlMNJQwtl6c0fxdaVvvsMhigp5ihQ=; b=RV+C9BqT+QebWJI57ojyhZDh7U2UqN2Sd5DtrsCfJrBOqDFA44izFoLIubR0F2fEbx D7828hEsCP8bWcty4opsw9VcshJSwuMfgjUwccmTsGJjRATxuZIBrljXfP739iwqy1/b 3UlkRd0tMY1cvaYPhFY7GPf2DcsRUENKN/G1akC4C8/Z0Xna9zal0yW/la7NRUoBzjXA Vy1/tHZR57+YlsdW4SLVp75MLYVIPVwAdnCPKky7f97EBwq4QpJhInqj5Fln0oH6SBt+ iA/KSfZsTJglQSZZuVqhFeoHgxBpI7MP2Nvz72zgDmJFeN6cocenMXVICDkbbKRXnaLc hDYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773238251; x=1773843051; h=content-transfer-encoding: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; bh=jBjKyQK+QtIz3+tlMNJQwtl6c0fxdaVvvsMhigp5ihQ=; b=K7GZE5NquHkD8QNhihHOLpJ4KF1TrokMBUlf9bEL7iYJNzNI5vt+z5HOCs2NvOE5J9 gni2svaOBmwqsAxqc+mmgViGmOQRv/ow1XwIncg7Trl4nqVjTYaRefYQfr+zrgaeh2sM LdsB7yi/k6YL8un9l7tN2uEBL2lfGB0iKBnkPpU40L0F1kenheS+AXDb0iZPrsYHouQV JQfx7q0L+Bfi8zTLq2wPlJGZvdGajOS+FMLeZIPZDA8sc4nuTd9w78xQM+lj9142HUcz sWu9L2dEf64mKH95VMuNARbxwfcDTJTl2jtFEXL73LbdBpgceWVQfUw8cI5+MZ8GYX9l WKCA== X-Gm-Message-State: AOJu0YyIrsLCAxbZlkL4Rh7nz7YAyNJwX30sclj96+nuUL82rlLqQkEq qsMp1GArR8NOqnnSoV2kZu3VG5HxOMg6rq34gWeTd/k3hZ/Z4m79l8AWW2ZVqP9G4w== X-Gm-Gg: ATEYQzyoC39HfKRw10gRFelE/CVRLYrFWsUHkt1DLUk+0LJW6cPnfgO8FgOyQ4k8AuF A/BAb/gvPSOGkcdxtm9L6Lwde1gXu48g5vFYVB97UxrDT+HyKOZtpCRXIyZB2PYh54PfcTY9+GX 7BKgtPcbYNxaZsdxzMHPKKeRv6mMZAdTJtgKfcNOvxTgpph0YGBBJc0BcdvA57oYrs1sdGwZ2yi 9rBVxQ4aldYUH/IubLb3agS0DlBRb+Gi7O49ysZlLCqltqDfuSK+ugtxBdoEREtgAesQM/9h54s +FZ9BxqM/C++ftMq1nfw4XokHns1Iz8fRQn2oAwTj/edwiG7yUJr1dfW2/b/XvtAdumyLPcUde8 9de7vufCQnqQ1lVXP9lwXnN61em5HwDJ7NN9GL0sJN64LRhAWhkT8+J2Ah774j+pQM5eFuoaU+M x7InCIPv8CCM6jEqwmGf4LgBb2KHRcoROBJzu7aobJEd7JA0idUWfsiRAfxHrWgByN+Ckk8+wkO rbE6OGdMMgYuCo= X-Received: by 2002:a05:6000:2913:b0:439:b3d2:3768 with SMTP id ffacd0b85a97d-439f81c8cc0mr5545785f8f.21.1773238250940; Wed, 11 Mar 2026 07:10:50 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 15:10:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] core-parking: shrink core_parking_cpunum[] From: Jan Beulich To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Julien Grall , Stefano Stabellini , Anthony PERARD , Michal Orzel References: <29922662-8b95-4a69-9401-11480df59cdf@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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10.03.2026 10:20, Jan Beulich wrote: > On 10.03.2026 10:07, Roger Pau Monné wrote: >> You possibly want to adjust the subject, instead of shrink I would use >> "dynamically allocate" or similar. > > I've changed it, albeit the goal really is the shrinking. And it's only now that I notice that I committed the patch with its old title, sorry. I failed to properly propagate the adjustment. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:27:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:27:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251170.1548406 (Exim 4.92) (envelope-from ) id 1w0KX9-00087N-Es; Wed, 11 Mar 2026 14:27:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251170.1548406; Wed, 11 Mar 2026 14:27:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KX9-00087G-Ay; Wed, 11 Mar 2026 14:27:35 +0000 Received: by outflank-mailman (input) for mailman id 1251170; Wed, 11 Mar 2026 14:27:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KX7-00087A-P6 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:27:33 +0000 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c107::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6fa6765c-1d56-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:27:31 +0100 (CET) Received: from SN7PR18CA0028.namprd18.prod.outlook.com (2603:10b6:806:f3::11) by IA4PR12MB9787.namprd12.prod.outlook.com (2603:10b6:208:54d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 14:27:25 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:f3:cafe::bd) by SN7PR18CA0028.outlook.office365.com (2603:10b6:806:f3::11) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 14:27:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:27:24 +0000 Received: from xcbagarciav01.xilinx.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.17; Wed, 11 Mar 2026 09:27:22 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6fa6765c-1d56-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=asou78lM4f7GfT9vCJ7pDT2IZmTwaOZ4288Qw/HrI40fgr8i9emYWTFv5N7acciymhCozWwjpSkTJbwPc/qsOGs8EpbRRvCyANvYwX7Lgqh240H1wmROKZvSyU9Ha6q6P8Ez4K3kIGBOjE1gUYDqxfeEeeHu6ROlivEOiHF7YYkqLUdJoEXbEafjC7/9p3xOihtz2LkvG0+sRG36R5mejwblu8T4/+fSwmkj6AluQ+w5l6Z5eB8TopmaUDtm/AbzSPVWPy5Ouq5KJfNmygJn4J+XSqBBD2AYuETfNYaT+u92gpwHw/tKaWhYIQJYFRfgJHgsiEqYqpTM2yk0IkZzEg== 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=rX85h1Hwc8oqInc2hnINB1xhgtpkPVwSbXpHMzhPg3I=; b=DIzvZYmMJMx+6RqGSLoQmmUoEfJ8soVUC4iceCS9iaN5m1umdYqmBnMmQOqa2kw3MEMdxD7wUQlyrczKsQGbGnKSSaOqHPUxQd5WkT3swOxDkbvSw0Gm0qb+JbXAF/OKrnLzLQCQ8KUYq9OyyXyJ+XzlNobUmbBQVxw19W66yMLTjBNwYYhHcV4Yh69MDnOEvUtp3CBBuThFLEgnWf2kSIBBNU0Fo6oXvPit7fSutLyDrSy9DHjCQmF6ID1nRLYnnykiyXI6NTJNN5T0hTn7aeNYifJqGCublJWYp4eBX04vffZZhmEHt2X8218+poQ9d75JCUPCJLEaIe6s9w/FxA== 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=rX85h1Hwc8oqInc2hnINB1xhgtpkPVwSbXpHMzhPg3I=; b=Na4zcyltr74ruaBij/ZOEKdLYs8XcmC36iR/hhaJbjY6U7vZBBQL7vcZh481dzLyc3D/ZYjpkNG2qXzqAhc82Ow6RAeHqGH8tlMTtQUFroUdKVzLeHPR2Ys+NOAwlhYkY8xLkbS7NZv7PIMj3Ix9pQ/o7M/ehEfo4C9Tg1KJw04= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , "Jason Andryuk" Subject: [PATCH v4 0/4] x86: Drop cross-vendor support Date: Wed, 11 Mar 2026 15:27:03 +0100 Message-ID: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: SA2PEPF0000150B:EE_|IA4PR12MB9787:EE_ X-MS-Office365-Filtering-Correlation-Id: 21fd5987-e9e2-4883-b2d4-08de7f7a50b4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|1800799024|376014|82310400026|13003099007|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: VaBGWPmJUjXglkNEQXMs6H5QRDFb/PbrWizRY+8V+omFt7A4Rd2puJ4uYFbGRkaTOxvB0H1+ICVjrOZptKSIE+hXCMxE1eJYTy/2u/Z8GQMyVsGlLseIvT+hU/sBfA/sRM9evXONP5i8SuAHKIZWC4yw0hZdZCb9RpWeD5EA81f1USyKCPlrEBSpNpootC17OOdBDWrG7pyi0J6LOGX0uVyhAo58ZobKC7JyWyAf0DUBSwhN/I3aqZ2BQgjgQxK5xQtvCy9oQFKwmzkAKitNdjL2zbPQINcHS9rir6RVnO2NoIBMJdvEmr95OT9u4ABuNN6W7v3VpsLFeVryyvC9aJTDQjrNMwz//jYuuuT65dHuNIT42obEd1Exdz3mQaHHGqWo61Kmhq2w5qtbWUqWHRz+z6gERzSifqj5J0OL57whcBXHhLUtjPUl6nxI30sWYDayAerMuVkWGHiOcx8XnjkPE2en/u9fNMmM9RTR/hhoC6O47H+ardr64nUwi0cXOsbhcEN93OsMdOAR1hq+HscoLuWIMEB4eVXU/h0MZwkQqRoaZFjCQKspxb13FaSuiFdK32MVJXMZaw9Q9vI6KOY8PapFJGT07A8Ilnav4tSSY/wCyE2GCOJZ801rd/nVgN+XKVOPCU/vmaQySBGySe24VfZB/dMIdGtOe9rK3MDZtrJtdM2/2LpAtzSVi2J8gW6sRO1FSSJlu2r5oJ0p3WEOYJdKt0Ckdt6aKBlt7EXQs8Y2fD7Qn1D5fXLNhR4Ln0y7mG07la66uJbLYHRkOK8Xn3a7Q0Srb5QrqeLnALY= 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)(1800799024)(376014)(82310400026)(13003099007)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 6lLTd0OS17ue2O07i1G9Ty+wncOXkJJ6KhR6V3G49vtEs2TYFRsNWxSdUlEakNK5VZvZvNU/9V1Zy8/SIGK7n35RDGx38uTftnY4WiDkm2tpgT0H5Uzyc2XU1jKLkfP5kQ1KMJV22LhXrkRC3VQMfaGhXkkgDKcxt0BySpSdvVCvxOHI61cQTKiy1kHYSLfpsQOqwAA/j4wBpFdykg5zVcGWMHIinxeYkofT6LEKbbSZjc7oOkcd+yKxz8DLkTjmukZvjDIrlnsTmFaZ5YdPAvkfeXb4qxL8So5ywUGn24rJoYZhFptMRM5Vq+HDKG2VFwJjKAOZSzXjilYPxs/kF/sWTs3X9Z6BGFYqV4cH07yPKNPrATctmOX4DMiPL3sDxT4f9RISkcs5aa+Em7FfYks9MxsKymo9tuC+l20koKA/nF0r9tmc6Wmo1kYjedBp X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:27:24.9314 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 21fd5987-e9e2-4883-b2d4-08de7f7a50b4 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: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA4PR12MB9787 Hi, Only patches 1 and 2 missing acks. v1: https://lore.kernel.org/xen-devel/20260122164943.20691-1-alejandro.garciavallejo@amd.com/ v2: https://lore.kernel.org/xen-devel/20260205170923.38425-1-alejandro.garciavallejo@amd.com/ v3: https://lore.kernel.org/xen-devel/20260213114232.42996-1-alejandro.garciavallejo@amd.com/ pipeline (green): https://gitlab.com/xen-project/people/agvallejo/xen/-/pipelines/2378378894 Cheers, Alejandro Alejandro Vallejo (4): x86: Reject CPU policies with vendors other than the host's x86/hvm: Disable cross-vendor handling in #UD handler x86/hvm: Remove cross-vendor checks from MSR handlers. x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems CHANGELOG.md | 5 ++ tools/tests/cpu-policy/test-cpu-policy.c | 27 +++++++++ xen/arch/x86/hvm/hvm.c | 73 +++++++++--------------- xen/arch/x86/hvm/svm/svm.c | 45 +++++++-------- xen/arch/x86/hvm/svm/vmcb.c | 3 + xen/arch/x86/hvm/vmx/vmx.c | 3 +- xen/arch/x86/include/asm/hvm/svm-types.h | 10 ---- xen/arch/x86/lib/cpu-policy/policy.c | 5 +- xen/arch/x86/msr.c | 8 +-- 9 files changed, 91 insertions(+), 88 deletions(-) base-commit: bfb33fa6d4eb4110cd7dd47ec71d2e550739e126 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:27:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:27:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251171.1548414 (Exim 4.92) (envelope-from ) id 1w0KXA-0008KR-KT; Wed, 11 Mar 2026 14:27:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251171.1548414; Wed, 11 Mar 2026 14:27:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXA-0008KI-HU; Wed, 11 Mar 2026 14:27:36 +0000 Received: by outflank-mailman (input) for mailman id 1251171; Wed, 11 Mar 2026 14:27:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KX9-00087A-G6 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:27:35 +0000 Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazlp170110003.outbound.protection.outlook.com [2a01:111:f403:c10d::3]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 716ee96f-1d56-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:27:34 +0100 (CET) Received: from SN7PR18CA0008.namprd18.prod.outlook.com (2603:10b6:806:f3::32) by DS0PR12MB6437.namprd12.prod.outlook.com (2603:10b6:8:cb::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 14:27:28 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:f3:cafe::5c) by SN7PR18CA0008.outlook.office365.com (2603:10b6:806:f3::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.27 via Frontend Transport; Wed, 11 Mar 2026 14:27:28 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:27:27 +0000 Received: from xcbagarciav01.xilinx.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.17; Wed, 11 Mar 2026 09:27:25 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 716ee96f-1d56-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wO1VSRZQxNiG3dKFQJ0Y12kyqCUDIT33gpnT4vlm60Y7vYXbbhADDo+bT2eZ8bkv/gmN7JyNppbxW9atrgBtdq1n0CWyhOCc536aEj6SoEpuPisXQWHNzy1+kxg7b30ne1MYL5CVuWN2jBbaqutaY+vzIVfssdzlnfYWII9sq8Oxp3BOFBY1wDeNsHFognJhdAU4Ro9nlJpHe9lD/pbwE/qlepeHvTLAObjN4VeCHY7U4b7Kgy2LqIUOQgQFeCv81ts+ztOMDMDitGoVoIPbiznmdHehkgM/wepIJ2oIPC5W0+M4BjCvWwjDI21/K0fmPWeLl1PxPtHwmNlyf1uwuQ== 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=F9MIEfn09tg7aPNeCKXTNnjlwWiDP/C9u8yiYjGcYfU=; b=R9HpJPRloPHphkMOEeZViEYeadn4WjtHSJaY/oE52TZ77QHnt8uLw2b4/P20XI5A2nZUmV31twVQu+aHiHmClxPUxj0qyeDaARXDdVnKFt4RcccR36nYAdrzd02lnlW3co1SDZcWBTM7jHOMbE4xuw0dBnU1cFHcqbwbZpzcVTE5z8S17TxSi2jB2UZaEBK0/JnRuid5ltWhWu/QtbOSdui7a0++BtwM1SAahkV6JINHINPQ/mrBPng7n8xSl4pbcZX/zNCGQM52QqaXf5ozOmEP2AAbNSiyBxKCHJPPTR6XG7O67S6b2Z/guFu0agXlBsdYhhVGRMWydW7/CocsCw== 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=F9MIEfn09tg7aPNeCKXTNnjlwWiDP/C9u8yiYjGcYfU=; b=DjNe1fap8LsWv1BF1m+RImUlVEhtgk1j3EhdWK19h3xQiSWChWVNG8S3TV54tEpvmqhpBXIMVH+zlWUcvnu3pdI3XoJUWM052rQ1GPCRiRgNRXyoWdSKAXPWTmLFN5xBROwPtTpc/BpyPCIpVBnvxIjWTvhJZFByoRBhFiln+Kk= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH v4 2/4] x86/hvm: Disable cross-vendor handling in #UD handler Date: Wed, 11 Mar 2026 15:27:05 +0100 Message-ID: <20260311142711.16754-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: SA2PEPF0000150B:EE_|DS0PR12MB6437:EE_ X-MS-Office365-Filtering-Correlation-Id: 9e412c67-49c2-480c-4039-08de7f7a5287 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: +BQHOIlJa7UaHE8e4PpkK5BzL/P1XGTVYKqjQq7lCGMD/Vt7qN5FYqsebOyPJaBFBGC6RVDfZYtVUtRTL1HLgwxECsunjO/c38EXmxV2PlvW/zNtCpg/mH36Es5pq9glDWkuuDve07RpefKuBqhDjl/yfuc21JwWhtm8P8pT5hTMygeyOGnDpn91AAYvxTWho9zPTgR7q9b0A18w2n3ci6lI6y8Hcem80Mw1leoHLGGhiDHgg1fW4UgEvyX2OAPePeiN6MhB0hOk7wMj2m9n7KFW7gByWzP2q0jEWP4WJiJeb8ZNYMELlvd/tHgAq3Si9+V60KCR+/dfSDLAbDxt7KMAioesq8eDcKPYHbmeS/cnkewQgIAvnO1laaEjXQvZKyGyD7gphZHirGBUBwO1CxVUC+LYHH3NnM/0NaC1FACfnSS+6qy6ZZNxCaF5siIXw6ybIdAD96jB1bj/Jiva9XFDTQQ8ycsFOBF6lWkimKiWxEeXNz68kQjprQ4HYkKTSeAFFI/qz6nHxDl7X/pFRo0qSelYe2AQnXm1jY2FtksUigKkRxVQXsfHuPwPFBKr+lf5Z0qYNES/dCAjzENB9Zq2GFjQvhvXhgcuAOkNTYQApqXrPfNbZ697lK96d+vD9BSZ7tqUd3pS4CEUsi2e1Z6Vv3nD97lTuR5RRvpeeh/tILsQT5gdRL6WPwBAHxTt2kfr6dvGxECl/aKM7+g56aA+W6kD31pEjp+5UmRvhLa8qcZ6JFQS9QW1gbKcz+dxsWduTFIuVqubWltzP7zWnw== 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)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ERXY193S6l0R1QhseYNZ0VDAwgWEBWzBS7NWBL+YKGdycS3mZnGi4iOHgz2JWdYefc3oP9wKRBbY4VLkYGuvrO6v6phnN7dHD8chRKIzIz4TpYIJ+byKKYL+jk91KFHBWEd8NZZLciV8bvtHq8isZlxZLoCOECzTfXBnX3AosSN0cP75rJc/0thBm34sApoFH9kSw37ovJqSssgmmTb3Npul0hh903KHAQPC/QgmWrTRPSoM5Ao8Jij43vGfpn3MuF78XgwtZfh1mNYmY2ruqYsZvvCCF4p7eyicjEXJ42s+bJ34tNPUc/yL4mlHylc4MBB15xjBx9o392DOjAOzAF+ev9zEFkwG0roNv3drMAlpo1vHprNBsFLqdxEmMZAlywlVQgH1djGhjy0VP+hXhRjhVDr1B7PpKg1LKSs2fq53TFC7vMtAfQnu6y4R0vFv X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:27:27.9893 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e412c67-49c2-480c-4039-08de7f7a5287 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: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB6437 Remove cross-vendor support now that VMs can no longer have a different vendor than the host. While at it, refactor the function to exit early and skip initialising the emulation context when FEP is not enabled. No functional change intended. Signed-off-by: Alejandro Vallejo --- v4: * Reverted refactor of the `walk` variable assignment * Added ASSERT_UNREACHABLE() to the !hvm_fep path. * Moved the `reinject` label to the UNIMPLEMENTED case in the emulator result handler. --- xen/arch/x86/hvm/hvm.c | 73 +++++++++++++++----------------------- xen/arch/x86/hvm/svm/svm.c | 3 +- xen/arch/x86/hvm/vmx/vmx.c | 3 +- 3 files changed, 30 insertions(+), 49 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4d37a93c57a..4280acfc074 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3832,67 +3832,50 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, return X86EMUL_OKAY; } -static bool cf_check is_cross_vendor( - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) -{ - switch ( ctxt->opcode ) - { - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ - return true; - } - - return false; -} - void hvm_ud_intercept(struct cpu_user_regs *regs) { struct vcpu *cur = current; - bool should_emulate = - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; struct hvm_emulate_ctxt ctxt; + const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; + uint32_t walk; + unsigned long addr; + char sig[5]; /* ud2; .ascii "xen" */ - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); - - if ( opt_hvm_fep ) + if ( !opt_hvm_fep ) { - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) - ? PFEC_user_mode : 0) | PFEC_insn_fetch; - unsigned long addr; - char sig[5]; /* ud2; .ascii "xen" */ - - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, - sizeof(sig), hvm_access_insn_fetch, - cs, &addr) && - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), - walk, NULL) == HVMTRANS_okay) && - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) - { - regs->rip += sizeof(sig); - regs->eflags &= ~X86_EFLAGS_RF; - - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ - if ( !(hvm_long_mode_active(cur) && cs->l) ) - regs->rip = (uint32_t)regs->rip; + ASSERT_UNREACHABLE(); + goto reinject; + } - add_taint(TAINT_HVM_FEP); + hvm_emulate_init_once(&ctxt, NULL, regs); - should_emulate = true; - } - } + walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) + ? PFEC_user_mode : 0) | PFEC_insn_fetch; - if ( !should_emulate ) + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, + sizeof(sig), hvm_access_insn_fetch, + cs, &addr) && + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), + walk, NULL) == HVMTRANS_okay) && + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) { - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); - return; + regs->rip += sizeof(sig); + regs->eflags &= ~X86_EFLAGS_RF; + + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ + if ( !(hvm_long_mode_active(cur) && cs->l) ) + regs->rip = (uint32_t)regs->rip; + + add_taint(TAINT_HVM_FEP); } + else + goto reinject; switch ( hvm_emulate_one(&ctxt, VIO_no_completion) ) { case X86EMUL_UNHANDLEABLE: case X86EMUL_UNIMPLEMENTED: + reinject: hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); break; case X86EMUL_EXCEPTION: diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 243c41fb13a..20591c4a44f 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; u32 bitmap = vmcb_get_exception_intercepts(vmcb); - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) bitmap |= (1U << X86_EXC_UD); else bitmap &= ~(1U << X86_EXC_UD); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 82c55f49aea..eda99e268d1 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -803,8 +803,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; int rc = 0; - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD); else v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:27:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:27:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251172.1548423 (Exim 4.92) (envelope-from ) id 1w0KXB-000073-W1; Wed, 11 Mar 2026 14:27:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251172.1548423; Wed, 11 Mar 2026 14:27:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXB-00006w-Sp; Wed, 11 Mar 2026 14:27:37 +0000 Received: by outflank-mailman (input) for mailman id 1251172; Wed, 11 Mar 2026 14:27:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXA-00087A-Vd for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:27:36 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7163c7cc-1d56-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:27:36 +0100 (CET) Received: from SN7PR18CA0001.namprd18.prod.outlook.com (2603:10b6:806:f3::15) by MN2PR12MB4109.namprd12.prod.outlook.com (2603:10b6:208:1d9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.4; Wed, 11 Mar 2026 14:27:27 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:f3:cafe::a4) by SN7PR18CA0001.outlook.office365.com (2603:10b6:806:f3::15) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 14:26:54 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:27:26 +0000 Received: from xcbagarciav01.xilinx.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.17; Wed, 11 Mar 2026 09:27:24 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7163c7cc-1d56-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DDgl4UencWUze2cMf+q9tdLeEE284uV5j0+TBDbOCRbbOIZTrKCotMTdGkAD/Ys7Yo5Z8ZHBHvJ0vcZiodNUzQ8fd0wgK1Zu0P8z4hgrmGVUxJZluQF6RGsjWbY6/HvaY+1/Nm54tsejcM66EXn9QH75zDdulMOLjZnrI6a0wATSPWILHk7XogjD7cdM+0d77ENvii1CGoqCLBjfwH7yUYz9XTIQBqLlZPzHr0eDyil5AOZ0XQjzK4isjF6/Hvgo9Lml070rLhO9fN9DEJZTkkPj9x1a5BI3iiex3BQj7v/HpHbOxXfdUA+jBEMfgpVAzlJlUP1ZUjgsbumCTU+u5A== 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=q+p7cae+ArZ+PDM9loA7Pfn9Yv4gwr3gdHU7guinMic=; b=AxoXF82wcKEQVLP9sB/SambvAJz8oL9Ji9UVAmPzG+gQV3FiAnf6pw6JGxNiEOOwlqpD0+AtD/3jT8bEJ4oqMhCKCY1/KT41Cwsy5HOuru/yRZO+44reBEG34MJo0s0cxQRW7QJkyH+Dtd76MbX3zoYX1PLVL36MuUYOMD0+BANd9MBIctiBBbiTHW9CG/qe42HIAGhvZC723fvxO8L4hQFfQ3bceGs+ftyQeEsPyqmtrVzowQIMpqvg+3jac2OnLNx8MEpos6ggddo1CwsRDYoqLbv4lu5wadvadPTDV0DtGKD3zjLw+LYvwS/BLrjob8S58NWEnaQNW549XLjZpA== 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=q+p7cae+ArZ+PDM9loA7Pfn9Yv4gwr3gdHU7guinMic=; b=I+U0KKTpjTNbKaCpXwA3wlWmpIthhA0EUXt93d+eU5lHiJtOfAJT/hmC9gGbIEyJk5d8FZ1sZXNDKN/l1tviNCuEnKxT/Irr6fyrpSgDIHA4Pgvra1MzfwxPub7XaGRkmj1NL4ccerbUVWJGG+2TU6fga8zVepbISOX++iJ8kW8= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD Subject: [PATCH v4 1/4] x86: Reject CPU policies with vendors other than the host's Date: Wed, 11 Mar 2026 15:27:04 +0100 Message-ID: <20260311142711.16754-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: SA2PEPF0000150B:EE_|MN2PR12MB4109:EE_ X-MS-Office365-Filtering-Correlation-Id: f880a7ec-97e3-4ee1-41e0-08de7f7a5163 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|36860700016|82310400026|13003099007|18002099003|56012099003|22082099003; X-Microsoft-Antispam-Message-Info: wJApQdifNk8zsKCNq/h+1aA2HVsUrjjM2V+L2Eh6tQD9LKqkKf70Y1Pjb/e8aZpWqQOqQlS5Jn+wmtr+poilXQO+l/Ob5/M22pdilaeF2oNAyzFeHUGrxtI3qTzbBza1F8afANsz5CERmxfBEXVucb2Z2ihllyHF41a4RZA4GKJXQePC3PxwnMVv21tjjYIvleIOxDAFCjKZAUuKco2jKO/SCGhDydZ2xkOWBLBupJvYZD9tM7qEwR0O6djUuu5t+L17wWpbIliKc9HzMtFPjSV6pgXjMJitNYd9+Ka6G23ba5nYPMSJuA1J0XBr2xZ546Xn8K5gtGF8aULWIi4D3dqEHKcUBMFrvjVG9PxXg33XPsudAj7ZneVYnZLKND5kvPRhQ4fAETSjnZk25icUm3dj6X5CXZ1fiDLDGpbOX4YkNwlkXUwXB65sC7pHYAgJ9bVuP7bW9HVIdY0KB7au6EwwhxODSh1NFt6y6+NNOM+dH4DzuvNr059g2NzgkEMYYncPH7i1+TySSGe36vl5laja3pkqWjOsfo5wpR7ldKeVFBRwRbuu4qYTpiZYYB3QffSRDfYuINrf/sFJgDxPl5yklVNw5Xc6u26MM4DNf2UNm8wevlE1qqliW85/s0dgc/3MsFWFc0khGArCg16Nr+TePM99jzpgv1PY5XNgKcv4vpY7KYBzC+SZDv4sWPwKcwLLuB53ZC3YhGJjHctZrR8RI1pmnQWYYG8dz2anty8= 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)(376014)(36860700016)(82310400026)(13003099007)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ch4FZZGHTnrcFCr55X6O2I02GZSmIBAXqn3DyA8zmDO67p5uFRpxW4KYwu0LP3OsZuVESekYmq1jxqsTA1QDM7VDOZLjsHKc+gaLrfiWR1CyxxVkiyW7kgywFhFyyF2Y/GAg/Rc2MbykVkGZAr8S/LyqUKLvfZH8FRFJrLryHUvyLAkOFrH+hA5kfFBZJZG5PR+F+wXIRN0pNCL88hSN+7nsF30KJCxp7vikZbxWaeA5sBbp++N3E/buc09Hqz4kfG++9kgV98mZNwMTuVfvmN7C+9+IiIahrHwktXEAXOYxtrcn62s09jq2U+IodrbTY9Y74oU3C7xFXN/rH+Cc4fsXV4SkwRR7WKQHZqbQ3/Difkukp/9U0QALJxUMLbAsbaRQrNKqYQ9mUqcjssfcS2IRwZKlTl4PpAWV1ix7bTmFBQ4KBGgoSu/o8LAdXIPO X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:27:26.0768 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f880a7ec-97e3-4ee1-41e0-08de7f7a5163 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: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4109 While in principle it's possible to have a vendor virtualising another, this is fairly tricky in practice and comes with the world's supply of security issues. Reject any CPU policy with vendors not matching the host's. Signed-off-by: Alejandro Vallejo --- v4: * Adjusted CHANGELOG --- CHANGELOG.md | 5 +++++ tools/tests/cpu-policy/test-cpu-policy.c | 27 ++++++++++++++++++++++++ xen/arch/x86/lib/cpu-policy/policy.c | 5 ++++- 3 files changed, 36 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c191e504aba..90ba5da69e4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 prior to the version 1.0 release, and there has been no development since before then in Xen. + - Domains can no longer run on a system with CPUs of a vendor different from + the one they were initially launched on. This affects live migrations and + save/restore workflows across mixed-vendor hosts. Cross-vendor emulation + has always been unreliable, but since 2017 with the advent of speculation + security it became unsustainably so. - Removed xenpm tool on non-x86 platforms as it doesn't actually provide anything useful outside of x86. diff --git a/tools/tests/cpu-policy/test-cpu-policy.c b/tools/tests/cpu-policy/test-cpu-policy.c index 301df2c0028..88a9a26e8f1 100644 --- a/tools/tests/cpu-policy/test-cpu-policy.c +++ b/tools/tests/cpu-policy/test-cpu-policy.c @@ -586,6 +586,19 @@ static void test_is_compatible_success(void) .platform_info.cpuid_faulting = true, }, }, + { + .name = "Host CPU vendor == Guest CPU vendor (both unknown)", + .host = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .guest = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + }, }; struct cpu_policy_errors no_errors = INIT_CPU_POLICY_ERRORS; @@ -629,6 +642,20 @@ static void test_is_compatible_failure(void) }, .e = { -1, -1, 0xce }, }, + { + .name = "Host CPU vendor != Guest CPU vendor (both unknown)", + .host = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .guest = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 2, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .e = { 0, -1, -1 }, + }, }; printf("Testing policy compatibility failure:\n"); diff --git a/xen/arch/x86/lib/cpu-policy/policy.c b/xen/arch/x86/lib/cpu-policy/policy.c index f033d22785b..f991b1f3a96 100644 --- a/xen/arch/x86/lib/cpu-policy/policy.c +++ b/xen/arch/x86/lib/cpu-policy/policy.c @@ -15,7 +15,10 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host, #define FAIL_MSR(m) \ do { e.msr = (m); goto out; } while ( 0 ) - if ( guest->basic.max_leaf > host->basic.max_leaf ) + if ( (guest->basic.vendor_ebx != host->basic.vendor_ebx) || + (guest->basic.vendor_ecx != host->basic.vendor_ecx) || + (guest->basic.vendor_edx != host->basic.vendor_edx) || + (guest->basic.max_leaf > host->basic.max_leaf) ) FAIL_CPUID(0, NA); if ( guest->feat.max_subleaf > host->feat.max_subleaf ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:27:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:27:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251173.1548432 (Exim 4.92) (envelope-from ) id 1w0KXG-0000P8-7L; Wed, 11 Mar 2026 14:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251173.1548432; Wed, 11 Mar 2026 14:27:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXG-0000Oz-3M; Wed, 11 Mar 2026 14:27:42 +0000 Received: by outflank-mailman (input) for mailman id 1251173; Wed, 11 Mar 2026 14:27:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXF-0000Ns-Dw for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:27:41 +0000 Received: from PH8PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170120001.outbound.protection.outlook.com [2a01:111:f403:c107::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 74afc3c2-1d56-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 15:27:38 +0100 (CET) Received: from SN7PR18CA0002.namprd18.prod.outlook.com (2603:10b6:806:f3::25) by PH0PR12MB7839.namprd12.prod.outlook.com (2603:10b6:510:286::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.23; Wed, 11 Mar 2026 14:27:28 +0000 Received: from SA2PEPF0000150B.namprd04.prod.outlook.com (2603:10b6:806:f3:cafe::75) by SN7PR18CA0002.outlook.office365.com (2603:10b6:806:f3::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Wed, 11 Mar 2026 14:27:20 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF0000150B.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:27:28 +0000 Received: from xcbagarciav01.xilinx.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.17; Wed, 11 Mar 2026 09:27:26 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 74afc3c2-1d56-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hktbEHC8uoz/N1wwmwgCUkxURNtUHzDe9DbTnku7tD/pI3o9zto4kE+bhe6SzhY9TUz6rH0+BSJQ9D/Kbxe+I6QhgwG2Ezwwdt8X/9IYiSmOd25/8OdXWv2JZgh3jbRI0vr+C/yDONgsgBE5joX3QO5nIGz6XdjsL+vo1DVnAMETfaEaAofuLrBHMkjYLKfLJhU6xexxD7AClJo6qTixyZyTCDu/BN5/9hE7SF6rPjurjgdJTBX0/wMlPN9+radXFpHvL7dKR2Lb9yyWMowlNxsKgpFDd2lZGF+R6L56q5aWbMwhSD7Ig95nvHYNAjsBRZCGXjbfsIe4xUtZ5AcKMA== 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=PdWkxG9i7l3rW3T6Rp/jnTpeGEs/5PuOgfzAZHWlwfs=; b=wWpC6IMqtUL1hMTPj6Ysm7M2BXxJ/EXXeTqrCzRsQ1IustJdjTfpaT4FLkRElA3awrvtOYQjQNn1aT2UJm26/a9IVdA9p6cyITW9/C4YjJJiJhtnbWfH+PhTS0fPGu+D4mZOJJiK4eLxM5Bp2f9RNY9JXwnVdb4r6598qPb6wE2VGJArhftQGy7U3AZ6I5ESn883idRYbf35vK1ocVxVWYtQOAF6aFxU3IDd0zpRqHpTmtpxzDrKnEEvgOfR21pM3RvfDf3toJdTTaTmYhnMVE9ggq567kSQqfe/PTN0Okq4oD7IotSn0jTdy82IoiMM2zaN1rNdMAfNtBMz2OnkEQ== 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=PdWkxG9i7l3rW3T6Rp/jnTpeGEs/5PuOgfzAZHWlwfs=; b=ayNpLI6vguhwi4JepUf4YGkvEpE+N7PJPNtdtXHFsMITs4gNoUbP8JFNLORetEFqZcuBF2sTL9VLriMHJQ3uX2USzb/gH7u65qt1lozWTVzTH03Pp1qbYdSmFF+1Lzj4M/oxOKeQN0IJpvWZT2m96lWe05pgltjhkDFO2M8q+6c= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v4 3/4] x86/hvm: Remove cross-vendor checks from MSR handlers. Date: Wed, 11 Mar 2026 15:27:06 +0100 Message-ID: <20260311142711.16754-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: SA2PEPF0000150B:EE_|PH0PR12MB7839:EE_ X-MS-Office365-Filtering-Correlation-Id: 0da0f76e-ac80-4421-b574-08de7f7a52e1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|82310400026|376014|18002099003|22082099003|56012099003; X-Microsoft-Antispam-Message-Info: zT5lDCDbMtFPdumg1Hnp2G/t/dSK62HbvoyxPkX7i7twBUuU9W+TavWTnbiCcMaG8H24ecEbB4adSX/chzx9kfPb8X7+gM2fhKXNsdBTEhmHfmn6A0humXKxMg+kR4SSKJIfVh6GEkwbztgA/Iz65lqP+Vzf6O1WeOpqqJJcib/XKEpxu/o7nCtFdD9FG6x2P8PkCNdR1Kp41HLRPV0jEPg1jX3OACG/3c5sd+ieUUEj+Xy1Bb23Vs6nIj0Z2Om/NPcCWYTFGREzqsbgfVS+ZtNzaXFabA2B4P6P1GJUv/fu2LXm7ikXyLmvjMkIOzLrbkpBV+NJZoVskwNjSB8+TvXeG6IqBAV51Xlds6FLVhNPw3khFKTnWa48xWXT4MWZ06B1c3QCZyfNIIy/G0MsNaQEkhWsPxsqwkOe80tp9GDaSjq8YkKP4IlOYRPkS6tcYBoBtN4RtlVTt3e8Qqp28GgHKyXt/XRza+dnNJu+/XA8FFKY4TMSGj06e0RhrIazZuDliN5ZGUyl/yapfTnq4DTkAZ4UOjrCUBDFwtorAi+lOJdL7mdiCJwA/wuSMxlI/hYs1nD4GyQoSvxCjN3PsCCKEROVN+OheCyESKXLL7ePxN0HOwNP+CsEaB3Z0i2gM+A4weYM8cZrGLn195dlRwiNfCQLGw9ddaHeNapDU9abwToaaiQuVGyR73qNcM84CDlzz1ileBpN9mITdN1sod9xyKpwNMKnB11QSp9+VLMtgVQ4BlmIHo+X4q39glOt76JUksMUAALTk/ZwzQ2S/g== 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)(82310400026)(376014)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: uBpz632AZlrE6ixwiH//fdJEBCjBO91PTo2FthfRCYYDRVZGLGdhb1QrHQ/yA13T5qZ1Tu6IS7MMq7Ovfox1Gc/E3/cJbquQWYoz7g09UeRz7t2vs/zYF2QYvHGb23EpLltdhSnbdj9OqyFrPuqQnNSTdnCn2gPSej2GpvoDy6FUD16GPXTmzXVAnsI2UWhVDx7q8ymN9LCKdPzuJiUUYH3DLQ/UxWWVz8Xl0UauxVsB4E0Z+xB5WnUM2j/9Edn/AIOtuE7IqBuF6qMJCA9OXbBwFNxRfZwEBiOqkRdhN2degdGkSYUDTZ10IsOpjQuH4BI12d2iAI+3jxmJdSb6tFjxvsUH6Gf2RKfSeNIwTl73gMEmEddQlFWif2YyQO5T+6l1FxsAS9GRelmYns1iCx5ivKOKNsA1WYYAqA1uZN/vR4xSbc++R3Fm/BdYj2za X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:27:28.5829 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0da0f76e-ac80-4421-b574-08de7f7a52e1 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: SA2PEPF0000150B.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7839 Not a functional change now that cross-vendor guests are not launchable. Signed-off-by: Alejandro Vallejo Reviewed-by: Teddy Astie Acked-by: Jan Beulich --- xen/arch/x86/msr.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 6a97be59d52..d10891dcfc8 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) break; case MSR_IA32_PLATFORM_ID: - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || - !(boot_cpu_data.vendor & X86_VENDOR_INTEL) ) + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL ) goto gp_fault; + rdmsrl(MSR_IA32_PLATFORM_ID, *val); break; @@ -189,9 +189,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) * from Xen's last microcode load, which can be forwarded straight to * the guest. */ - if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || - !(boot_cpu_data.vendor & - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || + if ( !(boot_cpu_data.vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) goto gp_fault; break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:27:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:27:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251174.1548437 (Exim 4.92) (envelope-from ) id 1w0KXG-0000Se-IG; Wed, 11 Mar 2026 14:27:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251174.1548437; Wed, 11 Mar 2026 14:27:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXG-0000SV-DP; Wed, 11 Mar 2026 14:27:42 +0000 Received: by outflank-mailman (input) for mailman id 1251174; Wed, 11 Mar 2026 14:27:41 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KXF-00087A-IK for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:27:41 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 74fe7e07-1d56-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:27:40 +0100 (CET) Received: from SN6PR01CA0019.prod.exchangelabs.com (2603:10b6:805:b6::32) by DS5PPF7671D5CC0.namprd12.prod.outlook.com (2603:10b6:f:fc00::653) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 14:27:31 +0000 Received: from SA2PEPF00001504.namprd04.prod.outlook.com (2603:10b6:805:b6:cafe::9d) by SN6PR01CA0019.outlook.office365.com (2603:10b6:805:b6::32) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Wed, 11 Mar 2026 14:27:32 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00001504.mail.protection.outlook.com (10.167.242.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:27:29 +0000 Received: from xcbagarciav01.xilinx.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.17; Wed, 11 Mar 2026 09:27:28 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 74fe7e07-1d56-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=OiALSE0opl9WwFMCqLVbZ60EUexnCAn5tuj40GE5X8HRXr6GZZGrAeUsC2ZxO7SzMpBSKlifnIEfRJyStqPK+Rp4o/yEzO2VCkbt2tGTQ7x/EdLRYZCS6HDXw79pzrAm2sQyRSD7C6802CgUkSULutmKqKJ8Y0ScK2Odl6gSGGBRy8QWzQ8dYFYf+SUbZp55MVmaZM4qBQCSZwgdDJfWK606prD8xEaeZceYWJ3DomupoF/qQX29+gI/VR8oBPYYoAhrAcWrSZ2zBXHQjDvYw13XYp/wnytwp5BqCgzKHcWjV5GuNoVOS/jNP5AZuZydWmPtzcvgbXPUBLXgBFD3sg== 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=8W73DiBPopGYeUkDwKpXuXzVBpLkZfDD8f6yj9F+Ki0=; b=YNzBCB+xO7pgSKRjk1z503yrLrsL4FtoMK32v0opB2M9xLGMgDf/CVG3Mbl5eQgntlTu0EOS1FCwzSre5d6D6yyJNuijWKagUUuDvfvAtgSZRCiHlZtNvlqgrquK7RRHVY0NhPF4E5iEvyHT75Vb5Ti8VFJFnh/PdLI3i3vNSMmeQOpfl04aCq6DP433Hevx8+49OdZbsYLov038nC02iadfyJ5g+gfYFfmUe7CnZycErk+4l2zJyISdqZGX3APGCKtmmNM9lIW/fI/ZuM9CaV9PzMKfj4BDRfrLX9kj9P3LS+hZg6TFuE5M818vNryMmjigXpjHZtqnSNAg6xNJyw== 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=8W73DiBPopGYeUkDwKpXuXzVBpLkZfDD8f6yj9F+Ki0=; b=V0tLMG77XvG4cLMqcCqwOyTasCm+BiBK8JxbkXAXAeHan8sKywOCdDblmIx2fRSw6Pdmu/gHJVcqiZ8oOxGkKoQE0ZeZTM4TF1tvBDSUh8edGY5R5AzHROAqOBJliOwMO9Xw0jSmXnHpLKD1BZtoHaqKKN6hO1PWUAnyxYaILio= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v4 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems Date: Wed, 11 Mar 2026 15:27:07 +0100 Message-ID: <20260311142711.16754-5-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: SA2PEPF00001504:EE_|DS5PPF7671D5CC0:EE_ X-MS-Office365-Filtering-Correlation-Id: 705db63f-e539-4104-2cfb-08de7f7a53a1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|36860700016|1800799024|22082099003|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: 1DhZdn/myvZJVnlG1+LCDn0arq1AGYBDMwlnilVEqnuWhfzGwmZA7DheTQ+HkEPAJb1FDCcRUHWMv42qAhDcY8K4PvScGv7qA+CV/ONP3Y7BOu8zC0dJMGRSxZb0O8uO+TSHyKypiPr/aw+SL+jVQybGCefF1nKyuj2vmThBhSv3tjizt2yXXSwYA0BUcd7Yx1va0huNumqOkxdvEqbeCh5rAfC57W7NBXYgcimbtuiiGJka2eRD+lHCkZ43ddgmgCZtWKpuo5KcBuOV4BY9qGn+7JWuD2BoQBbIJCiSwOpKwuZ0L/c+T42AF7CGPwsWaWXvDHcdPCBoaWLj0AzfNQyIUezRMa0YrQSjkl0WbugKMlMieDvGxRhtNdrK73dqKSHDl/ljJIBg3uOzc6Q+MmsQLx4QfY3TyA3b/BhAqG4CfFbyBFOTVSbQ4ob+4PrYnIZIHufu0YdAxbRXZ5mWiCoTcnnR8LdCY2NgT48w2Y/M35JAGGkegoi7NWkzgSJ+Bfb3GoKdIxY/VaQiwxkjLrSI9uHWgJBJ1EtJG4IYfxMLUgqXR0iondjKRkCuVHYaCxEWO2Ay8ghjy0NV4NXTJvBW2BgZGgPuiJ71a9MakQ9ZC8DYgeZ9hsO4H6FeXX57xYm8aOO2UvzEhYLyZNck/tMaepRtaqYYs+ppuYTdJRJXR1VYWAiJylrv5f7kiJybDOsUXSB7TsfD/pXVRu1Fkm7O8xae4jNBJ5XspuYxJT6DxmW7E2JiJK0KDSqLpRDf 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)(36860700016)(1800799024)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: jZ9XR+zdEwk3k3pcXYcCJOV17NbUvV6CKbq0McyhOSza8g673J4kbhtnTlBB/MVxtRQFWRgFqYvh6mRWMiSnl7N7f93xCpNRbldX1EftDIzGgmYf6fOJzBuP4CUJ/4fFZdiaOYViOjoTTIzPH4A/pL6MWIawABcBdUE41h4h6/OJDZQnSkYF5i9esBwxt4vm2vhpJ3a1m5xmbknRN4RwbvsFuaobDsVoTNCQkOx85XQTOxqwK/6lI3wa3o9+YSRrX8YLJZNDQ+8bBEZ0akXXKVPtivYYRR9SbaMjDx1FRdmLkNY2j6YMROFhfYbRnQVlD6H9445PBBDMVbK1IsLSTy7hiUcnHvJ7qXUCxeWvRggeceUS2GfyWWy8y19lN/eFjxyjBqb2xg0FoXGJQREUJdxMVwpDsRSb8Yf1BKQT3G2kveebhNQWZVXS/de8n7Zz X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:27:29.8343 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 705db63f-e539-4104-2cfb-08de7f7a53a1 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: SA2PEPF00001504.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPF7671D5CC0 With cross-vendor support gone, it's no longer needed. AMD CPUs ignore the top 32 bits of the SYSENTER/SYSEXIT MSRs, which is not how this emulation worked due to the need for cross-vendor support. Any AMD VMs storing state in the top 32bits of the SEP MSRs will lose it. It's very unlikely to affect any production VM because having 64bit width just isn't how real AMD CPUs behave. Signed-off-by: Alejandro Vallejo Reviewed-by: Teddy Astie Acked-by: Jan Beulich --- v4: * Sorted assignments to the vmcb struct by dst address. --- xen/arch/x86/hvm/svm/svm.c | 42 +++++++++++------------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ 3 files changed, 22 insertions(+), 33 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 20591c4a44f..076d57e4847 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs; - c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp; - c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip; - if ( vmcb->event_inj.v && hvm_event_needs_reinjection(vmcb->event_inj.type, vmcb->event_inj.vector) ) @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); - /* Load sysenter MSRs into both VMCB save area and VCPU fields. */ - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs; - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp; - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip; - if ( paging_mode_hap(v->domain) ) { vmcb_set_np(vmcb, true); @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + data->sysenter_cs = vmcb->sysenter_cs; + data->sysenter_esp = vmcb->sysenter_esp; + data->sysenter_eip = vmcb->sysenter_eip; data->shadow_gs = vmcb->kerngsbase; data->msr_lstar = vmcb->lstar; data->msr_star = vmcb->star; @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - vmcb->kerngsbase = data->shadow_gs; - vmcb->lstar = data->msr_lstar; - vmcb->star = data->msr_star; - vmcb->cstar = data->msr_cstar; - vmcb->sfmask = data->msr_syscall_mask; + vmcb->lstar = data->msr_lstar; + vmcb->star = data->msr_star; + vmcb->cstar = data->msr_cstar; + vmcb->sfmask = data->msr_syscall_mask; + vmcb->kerngsbase = data->shadow_gs; + vmcb->sysenter_cs = data->sysenter_cs; + vmcb->sysenter_esp = data->sysenter_esp; + vmcb->sysenter_eip = data->sysenter_eip; v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -1734,12 +1731,9 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { - /* - * Sync not needed while the cross-vendor logic is in unilateral effect. case MSR_IA32_SYSENTER_CS: case MSR_IA32_SYSENTER_ESP: case MSR_IA32_SYSENTER_EIP: - */ case MSR_STAR: case MSR_LSTAR: case MSR_CSTAR: @@ -1754,13 +1748,15 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_CS: - *msr_content = v->arch.hvm.svm.guest_sysenter_cs; + *msr_content = vmcb->sysenter_cs; break; + case MSR_IA32_SYSENTER_ESP: - *msr_content = v->arch.hvm.svm.guest_sysenter_esp; + *msr_content = vmcb->sysenter_esp; break; + case MSR_IA32_SYSENTER_EIP: - *msr_content = v->arch.hvm.svm.guest_sysenter_eip; + *msr_content = vmcb->sysenter_eip; break; case MSR_STAR: @@ -1954,11 +1950,11 @@ static int cf_check svm_msr_write_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_ESP: - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content; + vmcb->sysenter_esp = msr_content; break; case MSR_IA32_SYSENTER_EIP: - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content; + vmcb->sysenter_eip = msr_content; break; case MSR_LSTAR: @@ -1984,7 +1980,7 @@ static int cf_check svm_msr_write_intercept( break; case MSR_IA32_SYSENTER_CS: - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content; + vmcb->sysenter_cs = msr_content; break; case MSR_STAR: diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index e583ef8548c..76fcaf15c2b 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v) svm_disable_intercept_for_msr(v, MSR_LSTAR); svm_disable_intercept_for_msr(v, MSR_STAR); svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP); vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm); vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap); diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h index 051b235d8f6..aaee91b4b61 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -27,16 +27,6 @@ struct svm_vcpu { /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */ uint8_t cached_insn_len; /* Zero if no cached instruction. */ - - /* - * Upper four bytes are undefined in the VMCB, therefore we can't use the - * fields in the VMCB. Write a 64bit value and then read a 64bit value is - * fine unless there's a VMRUN/VMEXIT in between which clears the upper - * four bytes. - */ - uint64_t guest_sysenter_cs; - uint64_t guest_sysenter_esp; - uint64_t guest_sysenter_eip; }; struct nestedsvm { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:29:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:29:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251212.1548450 (Exim 4.92) (envelope-from ) id 1w0KYV-0002BX-3u; Wed, 11 Mar 2026 14:28:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251212.1548450; Wed, 11 Mar 2026 14:28:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KYV-0002BP-0S; Wed, 11 Mar 2026 14:28:59 +0000 Received: by outflank-mailman (input) for mailman id 1251212; Wed, 11 Mar 2026 14:28:58 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KYU-0002BH-Ad for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:28:58 +0000 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp17011000f.outbound.protection.outlook.com [2a01:111:f403:c100::f]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a2930dc0-1d56-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 15:28:56 +0100 (CET) Received: from SA9PR13CA0173.namprd13.prod.outlook.com (2603:10b6:806:28::28) by MN0PR12MB6053.namprd12.prod.outlook.com (2603:10b6:208:3cf::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Wed, 11 Mar 2026 14:28:50 +0000 Received: from SA2PEPF00001508.namprd04.prod.outlook.com (2603:10b6:806:28:cafe::58) by SA9PR13CA0173.outlook.office365.com (2603:10b6:806:28::28) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.22 via Frontend Transport; Wed, 11 Mar 2026 14:28:48 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by SA2PEPF00001508.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.20.9678.18 via Frontend Transport; Wed, 11 Mar 2026 14:28:48 +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.17; Wed, 11 Mar 2026 09:28:47 -0500 Received: from [10.71.194.215] (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Wed, 11 Mar 2026 09:28:46 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2930dc0-1d56-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=l8qgotWeY4JcGfaWTWkqNpf0tPh9GWygkuU0Y5fp4jcItiNM0lhISiDydHrMpQHmj/3MKDcioH+AIN7VHwcXtr1AU/Jm2rBGpBnY6LOOeL7mFk5DgcZd9VolB8zSfXn6w8Y1on0v2H/IdmEP3kmwnEdNRgyo31/A0CXEXdvhTtFbW3+UuT5UTcDsIpy4DqD+msuzYc47Wtoybx3PJhvllD6+BA/HcXxZMdIGW6H9ypjNoaCJwj+U3STxxQYZdswLxdv7/SjSaDiJt8LpouSfacZmPboygBmNvW5cxlP1Lz26Gb3rCdhlN0wWFA3xkUJHIpAu/bq8vGmsi+21MvAF5Q== 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=h2r0/8ej73WI0PEnvNExoigrPoI3S4hHyeVt31lA25I=; b=E10sITTDsFYcRe1UWhcyZTcNxVi3I5JFBi0yVGRoCZX1rw6DY+T+QHMMxZYW9zqIWUUB1gB7oJG4I6w2l97Inv8BUgZ5OONY3ucl6xUO+9EWvJarNtTNLCsrD39+ZEf36G01vPh2Cz3LbXQ+KqYNg8sqpxQtIv0niRK1tyT3BPdbcy0MULz/racnZ3CiK0AKi9RxA7L5jiFDEbCEhYdaARC/e/RWWER4SBvZRkDx8GOHVQG81+Oxjhko71qoGaVMrTqfcu3gYgVFIzBCh5HYNqBejLPnQvqHdIJohrXYm+EADUVwLq432zPlniL5xNh0PrDJiA4BDiPxggLgdJfdmQ== 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=h2r0/8ej73WI0PEnvNExoigrPoI3S4hHyeVt31lA25I=; b=5hb1Gdps4PCLXD6kh0GFcm8oTxiECEUcOkP9U9vgQU4gQ1fYN/q2ooHDBC5gnuOlz3MxMUArmE5pvNe0z7MEoGygpkGSr6nvpfIjfiFwJGmZmBcEPIA87EoTjQXC5cYbDDOJDDpoU3jiOYSKLpqC8zscYJEDjqrOIn4O5fLVEiU= 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: Date: Wed, 11 Mar 2026 15:28:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: fix unmapped access trapping on GICv2 hardware To: Stewart Hildebrand , , Stefano Stabellini , Julien Grall CC: Bertrand Marquis , Volodymyr Babchuk References: <20260205190128.38716-1-stewart.hildebrand@amd.com> <1e8f9976-b0b6-47b1-88c0-690d4f1589ce@amd.com> <8ccde8eb-d8a4-411c-bd6e-9c3fcea1150f@amd.com> From: "Orzel, Michal" Content-Language: en-US In-Reply-To: <8ccde8eb-d8a4-411c-bd6e-9c3fcea1150f@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00001508:EE_|MN0PR12MB6053:EE_ X-MS-Office365-Filtering-Correlation-Id: 59e88267-9d35-4736-1cdb-08de7f7a8262 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|36860700016|82310400026|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: gzOod23MWwk/NllvNAIr5qa+/Wv6smM5H299p0Zql1OhCcQ5MhcWwj2tQxDQp2ump7TYFw2+PpHOFvnSL88uRceq6agKgFNu+LIvns1CCyYmZJJ3Nd5h7ftC2LXP49ERo8xw0Ak3x3OJVu3ke7vTXRZyxplalYpCSOvW0emeSomiNRxllaVPy1vbYCDuIC3E2f+y7x6FO94D04WnKVhk/nYlmf2KnWrkunEc6k5+nSej6OwMw7xsVuOxxZhTyL4xn+P7NSnl0nCGJ91KnDT6XtxntCoJbyagisLj7g8lFIKwCtdTxBH7dwWb5/MNkz9/g+eWaOXbNmTyAUhAe0woqcFV/mEPWqUvO21GG0s69lkmF1QD0OGMIAzgMX/fXxspGodls38rx6ZRqpo4UVbgJvVDNkVdCDdMgQgMI0PIplBUAuhx0SgRAlW5us7WQ1BlP38BgWHo1wofCK+2uqiS3veEbjvPdz4kjXoZlhgb3I1gqRYlDfkmMANaHeIJwPs8lj1GA1w4rNvp0RJ9dEiuq0GQAkMg9/X9VLcl/eztCjA5x0x317WxTRPVl9+C15OH9rvYBKoA2pUOimvBFj4tI0c8nHvAVf0D1Jg41p1nC+2Dc88gQgX057+HWvvQpritoqQaOQMBbUn8e9/RJjqqDJqA37JFAWyNgCRpKSycxpgak/Wg4PavP9BxUuWP+y5Gli7VEDyD3WxwoPIfbT14vs0/A53sxh2NngDpUSglwpI1lGpihp6gFGZthbUy49oxOwCTpZWXw16PrYg2/9uUPg== 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)(36860700016)(82310400026)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: QkvT2UDnJ+Sh3D9iCfOKp+St4uGW6ExeFNcdokG6+hOCiQN8TNo3+SEkWQ5M0H0A2tzG4mhCwMF+rqvyULlPHju0KNEyTOXUInFfLpn0FPu+IgbeDDlo986VfQEq8FpNKqScCB/+HEQfjWoXwyfoyIOm/yJx5beJ8SX0mFrpoYkACpw7fHhSYw5lTl1W8Jgl5NajTumskydnbvIgcdK27pVMD4OZc20izv4+zyVkz++7eHgeIkUuVWEYsCcLJaMozWfDtn/CqA88PAv9RKQRlLpxybkC4/41gowKFqHK5LMn7kLJluE5nYvmORDOjyJOVnqTDepSSd7Lfr1zefKzM6R86MfPBSuahGzrKOJeNpFsS2CFcDIsO3UT/jH9eM7WGajjHFZkloxHzU2K0yCXZAqctPROfdOlw1Ok3NPImQreozZY4cTMNwYdqRCZjnHV X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 14:28:48.3079 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 59e88267-9d35-4736-1cdb-08de7f7a8262 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: SA2PEPF00001508.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6053 On 11/03/2026 15:09, Stewart Hildebrand wrote: > On 2/18/26 12:16, Orzel, Michal wrote: >> >> >> On 18/02/2026 15:21, Stewart Hildebrand wrote: >>> Gentle ping. >> Sorry, I'm quite busy these days. >> >>> >>> To be clear, domU interrupts with vGICv2 are currently broken when >>> XEN_DOMCTL_CDF_trap_unmapped_accesses is not set. >>> >>> On 2/5/26 14:01, Stewart Hildebrand wrote: >>>> Since 4dbcb0653621, the vGICv2 CPU interface is mapped in a deferred >>>> manner. On domains with XEN_DOMCTL_CDF_trap_unmapped_accesses unset on >>>> GICv2 hardware, the vGICv2 CPU interface fails to be mapped. A visible >>>> symptom is that a domU gets stuck at: >>>> >>>> [ 0.177983] smp: Bringing up secondary CPUs ... >>>> >>>> Move the 2nd check_p2m earlier so it's prioritized over try_handle_mmio. >>>> >>>> Fixes: 980aff4e8fcd ("xen/arm: Add way to disable traps on accesses to unmapped addresses") >>>> Signed-off-by: Stewart Hildebrand >> I investigated whether the reordering is safe and it looks ok: >> Reviewed-by: Michal Orzel > > Thanks! Is there any other feedback? Is this ready for commit? It's ready, will commit tomorrow. ~Michal From xen-devel-bounces@lists.xenproject.org Wed Mar 11 14:52:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 14:52:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251236.1548458 (Exim 4.92) (envelope-from ) id 1w0KvN-0006Wj-R7; Wed, 11 Mar 2026 14:52:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251236.1548458; Wed, 11 Mar 2026 14: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 ) id 1w0KvN-0006Wc-OE; Wed, 11 Mar 2026 14:52:37 +0000 Received: by outflank-mailman (input) for mailman id 1251236; Wed, 11 Mar 2026 14:52:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0KvM-0006WG-Ni for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:52:36 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f01e6085-1d59-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 15:52:34 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4852f8ac7e9so55466315e9.1 for ; Wed, 11 Mar 2026 07:52: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 ffacd0b85a97d-439f821d095sm7684845f8f.32.2026.03.11.07.52.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 07:52:33 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f01e6085-1d59-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773240754; x=1773845554; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=0Z3ddnBTQh3monl3uUxBvm4jJ2tkt4UDLSJQeB/4uVs=; b=LOceYgvFQJLNXFSkU4nYVNZlQ+BYIjChb4MjtkT3ozeEb+RLY62FtSfthFB0Kf4d9t qjAIgOOsmAmD5oVW1sWthLzgcXQRVFQioRwKGZHB2JFgwL4OD5j5dv7az1lS9MwXXhV+ Fd8lo+I2y7PRxz5lLVqikGDB4EixX2cD0U0dcfZuq66zSBFfDpG6vTcQI9AIdvm15Xiz JUctNbuCjQuTfo4nJEOmQFKNq2oyDJ9hme+4Da6MhXUvD2t0jjBqqBicP9H+LRIhEmVx +HQJZwAbsLqCwE5mhrdxY6NTyzhba1AO6HdpXjeYxAYM+aF1/agln6K5u3r5ekYycORw mkdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773240754; x=1773845554; h=content-transfer-encoding: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; bh=0Z3ddnBTQh3monl3uUxBvm4jJ2tkt4UDLSJQeB/4uVs=; b=I/m9Fj8oqCqGyVRGd/6BEal6/ttECXZDp/NN2NY0owLaZvktCQsCCU3yb4mwY85ThW WAqBMVHGUdUSFmvG8UwlFIE15wEDYAzvzQmT8I1MoZacyjXH+Gw4Z0GNOGdYht9i7fOU 6c96uasDSGxEZM0knBbQ39Qdy7trzVnMZ5zn7bt5BFHI0R4YwkiYyS3MmY0tG0v19Dr/ +sJurKylEPzyyvcJjpcsQ1OnCu0LDZQUqzO68sEDKaTMUm6cKuZJmX0j88QriCOpt8N1 z0JuFXGJuw/zrNGyQB1T2JBDuJQ8JpsyN5QiDKFYvjwBwjuReGNptH+qvMbMrJreAnbX fI0Q== X-Forwarded-Encrypted: i=1; AJvYcCXn9bBk4lloLr0CkfrNRC/+oa/h0QRUpVHLR0gUZIRSS1guh+OTmwMF2SvgH6c39JoJxnsDNI4ZvlQ=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy+y6vMcXo0CXa0Lpt7V5XAu294PWZJrLuLn+kBj+HwfO4d80aK IoUoW7T4kdjCjsHkT0+Bkn51f80M6GQVq7OdLp8Owg6N2kFSpDo0iJbWWUoID8AzeQ== X-Gm-Gg: ATEYQzwFFd0caRmWWAp+yLK3JxrLxlCyMQaRINpWr+A0lwxbU0zr0rTmktFlctIn88w hs1zw+3YBFKOkR9lsywul77u5gbVKgzVCOUEHqbDCf5AOb0QprRiONbQMo/uThICjkOkzE8KUoZ zvJH1OGxaMLnbiWmCVj6IfDRT/+R/EhKEJElpDHfGJ+49IH+oUoB7ya8Tg//uuLzWV2RTN8UVGx EiVU9pvzJ3Rvjto5ZCNCvgvKhV0VegwsGAKINRmNUYeotDr5QXyz4/ZWMRXc7nJkoRAl9v+namf Qy4u2MbghdFzZ4e1WKExpTHZOj4gADBS0hoR/QiUnt/qCobmOSwKYwTUmb0wsh/A/Hh56DcqAfF TaqYgh6ATIxLlWrVAcHx8962WDFi1wrafr5ou/NZzfPP/d+QkmuF14zaAgWAsUo7VEK6GW7u2Qo 4ECJgInlgCtthQX2Ls1qpnemDelLwL/Y88tcG+NSJBQGYp82fDYxZ5fe4zoXP1nvko+Q9bMCYau s3XoKKXfnuRbPI= X-Received: by 2002:a05:600c:c163:b0:485:33ad:3c9f with SMTP id 5b1f17b1804b1-4854b145656mr44551755e9.25.1773240753795; Wed, 11 Mar 2026 07:52:33 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 15:52:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/4] x86: Reject CPU policies with vendors other than the host's To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , xen-devel@lists.xenproject.org References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-2-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260311142711.16754-2-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 15:27, Alejandro Vallejo wrote: > While in principle it's possible to have a vendor virtualising another, > this is fairly tricky in practice and comes with the world's supply of > security issues. > > Reject any CPU policy with vendors not matching the host's. > > Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Wed Mar 11 15:00:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 15:00:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251252.1548469 (Exim 4.92) (envelope-from ) id 1w0L2T-0007Lf-Ir; Wed, 11 Mar 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 1251252.1548469; Wed, 11 Mar 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 ) id 1w0L2T-0007LY-FF; Wed, 11 Mar 2026 14:59:57 +0000 Received: by outflank-mailman (input) for mailman id 1251252; Wed, 11 Mar 2026 14:59:56 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0L2S-0007LS-RI for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 14:59:56 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f65f2a3a-1d5a-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 15:59:54 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4853fd7b59aso21159235e9.2 for ; Wed, 11 Mar 2026 07:59: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-48541b6f6b7sm202625995e9.9.2026.03.11.07.59.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 07:59:53 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f65f2a3a-1d5a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773241194; x=1773845994; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=qgx4FhloQI16wj6SD7UudbddpkdRbcgUSx8DPO4fSDs=; b=BH5OPGUURir5LkSUKLtOyCsk/Q/adGbCRdX7jMj65CWiBwXL5zPtaLdklXX6H8EtxE ejyuE+i9w2ybWeywA83Jows+M+5VsaqXR+v1z0CC2wJTAdFlUY/kG/B+w0Otc1HNGVYf wDH0U5z+FxNU19quvTzpc5kTYPvRACBnqsY/jEd7DpK16vNdoOzXJ/VW5ZUPJq7XB8jO MbzwuQqsPlPN8NdkYgQFNg8eC6w9O6NsW7mcxCq9ejNyOdOnk2OvUkxa9P0djvhYQbEv +HxfyeTJHxxW2Ne0YSwMg7MYpJMRhXY3MyFRkYMNuc7Pk8uDZJHSGKVeY+QwXOpPNSlP qHxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773241194; x=1773845994; h=content-transfer-encoding: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; bh=qgx4FhloQI16wj6SD7UudbddpkdRbcgUSx8DPO4fSDs=; b=b8WUDxlBmHzwnGS25wIbSR+WDoxeYiobmr9qq4EHeHW7oce54MKuR7d9dBZvq5JxT4 ltBmwoPknlU0cXZ5u5ZZocTW+F247YGTsUHgeApf6MU3MWGvmjgJiMuZTwvhUB7xk8H3 i97F1WdE8OG8LTiXBr17Iw7lBL9jB2KgTksi5/pf0URmrONcoPasFxmZKrzVagVqXdUo KpAhkwjtOzbMOgxDk6Hsxd1appug4YEGzlajvigpSdFuU/jOkYtvaPLgIqh7BkOy3Ov7 X6R+Icu4tLxAdQ4laRJLqt6jDpoiIWf2B64/hoEIRRC8Uqsugx7t2jKTDyyTkpX9m84c Wxhg== X-Forwarded-Encrypted: i=1; AJvYcCW3RzGi4nMmk46OMmWQS1AVbNlTZWhAqiIWJx6KheNeeJDsvxbYoV/H8Q96j893cPTWI1a0W/UVgOc=@lists.xenproject.org X-Gm-Message-State: AOJu0YwmGJPeA/P78Oa9GWVIsAytllRgX7x1BfHIdyDlsaiA6AWuDhlo teh1yBGoBwq7rdrKWUeoH7wL6T4ZsDKU2IcdrwMtXMXtF/HmesUuJTuc0v6qD5A67w== X-Gm-Gg: ATEYQzzAGtr8NSkXGam4v+sWuW7X9BnM/tNCR1dR+LAcpj9FysEEH1ynOkZ52aPSwaE 7nVPp1MXdVculGgJfprGL1T5XTh39uwH76BroU6vU2zdt1lcWhLaYgAJ04slklwscgC2DGosAef cN6h14NN8mdGzEUv2EiS21YJsWRArwd9UaU1THXArTZv+UOnrp0jmI0z9vTlr1aJZlTme8g2dVv SLB4dsS01JN7JGZuUJmZSXSzv4ThcPU2ICupADHeaQ5FNYv53ZwmI2n9dDNCtF1RrU6ynbtzKtE 69Bjf+/n45ZTj3EuqeagzvQiUwbYDeId2nyno/DxVGJ/f3S7xs47kn3+APgvYBc06UUfZbhOk2z cJynzTkGvlZwzgs3XA/gMFwo5q637JtGDKP97GDowPK4vAfIaFwDxyIXdunbiYsiLYF4oJPinY5 3YIrVbowBlWol08jbe/Ex7eep3cITCa4tpkkbWgQOG8r1+Rqx9R9UFu3ERM3f7znZjzdf2mzR9q wJfJQLLaRYz2GQ= X-Received: by 2002:a05:600c:8b38:b0:485:3fc8:de9c with SMTP id 5b1f17b1804b1-4854b0be1b5mr49753765e9.12.1773241193656; Wed, 11 Mar 2026 07:59:53 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 15:59:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-3-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260311142711.16754-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 15:27, Alejandro Vallejo wrote: > Remove cross-vendor support now that VMs can no longer have a different > vendor than the host. > > While at it, refactor the function to exit early and skip initialising > the emulation context when FEP is not enabled. > > No functional change intended. > > Signed-off-by: Alejandro Vallejo > --- > v4: > * Reverted refactor of the `walk` variable assignment "Revert" as in "move it even farther away from the original". As said, you want re-indentation, so please do just that, nothing else that isn't explicitly justified (like the moving of hvm_emulate_init_once() is). With this put back in its original shape (can do while committing, I suppose): Reviewed-by: Jan Beulich > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3832,67 +3832,50 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, > return X86EMUL_OKAY; > } > > -static bool cf_check is_cross_vendor( > - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) > -{ > - switch ( ctxt->opcode ) > - { > - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ > - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ > - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ > - return true; > - } > - > - return false; > -} > - > void hvm_ud_intercept(struct cpu_user_regs *regs) > { > struct vcpu *cur = current; > - bool should_emulate = > - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; > struct hvm_emulate_ctxt ctxt; > + const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; > + uint32_t walk; > + unsigned long addr; > + char sig[5]; /* ud2; .ascii "xen" */ > > - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); > - > - if ( opt_hvm_fep ) > + if ( !opt_hvm_fep ) > { > - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; > - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > - ? PFEC_user_mode : 0) | PFEC_insn_fetch; > - unsigned long addr; > - char sig[5]; /* ud2; .ascii "xen" */ > - > - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > - sizeof(sig), hvm_access_insn_fetch, > - cs, &addr) && > - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > - walk, NULL) == HVMTRANS_okay) && > - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > - { > - regs->rip += sizeof(sig); > - regs->eflags &= ~X86_EFLAGS_RF; > - > - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > - if ( !(hvm_long_mode_active(cur) && cs->l) ) > - regs->rip = (uint32_t)regs->rip; > + ASSERT_UNREACHABLE(); > + goto reinject; > + } > > - add_taint(TAINT_HVM_FEP); > + hvm_emulate_init_once(&ctxt, NULL, regs); > > - should_emulate = true; > - } > - } > + walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > + ? PFEC_user_mode : 0) | PFEC_insn_fetch; > > - if ( !should_emulate ) > + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > + sizeof(sig), hvm_access_insn_fetch, > + cs, &addr) && > + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > + walk, NULL) == HVMTRANS_okay) && > + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > { > - hvm_inject_hw_exception(X86_EXC_UD, X86_EVENT_NO_EC); > - return; > + regs->rip += sizeof(sig); > + regs->eflags &= ~X86_EFLAGS_RF; > + > + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > + if ( !(hvm_long_mode_active(cur) && cs->l) ) > + regs->rip = (uint32_t)regs->rip; > + > + add_taint(TAINT_HVM_FEP); > } > + else > + goto reinject; > > switch ( hvm_emulate_one(&ctxt, VIO_no_completion) ) > { > case X86EMUL_UNHANDLEABLE: > case X86EMUL_UNIMPLEMENTED: > + reinject: I'm inclined to suggest to indent this the same as the case labels. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 15:27:34 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 15:27:34 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251276.1548480 (Exim 4.92) (envelope-from ) id 1w0LSv-0002wH-Ir; Wed, 11 Mar 2026 15:27:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251276.1548480; Wed, 11 Mar 2026 15:27:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0LSv-0002wA-Fn; Wed, 11 Mar 2026 15:27:17 +0000 Received: by outflank-mailman (input) for mailman id 1251276; Wed, 11 Mar 2026 15:27:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0LSu-0002w4-2F for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 15:27:16 +0000 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [2a00:1450:4864:20::42b]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c7c30de0-1d5e-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 16:27:14 +0100 (CET) Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-439af7d77f0so13951f8f.0 for ; Wed, 11 Mar 2026 08:27: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-439f8223dc2sm7656888f8f.38.2026.03.11.08.27.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 08:27:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: c7c30de0-1d5e-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773242834; x=1773847634; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TBnN2Dumri8XGwoA7NBPI1PL+2jwWyiT4+WfYmUV3Yo=; b=bujf7qvTb9gRybh2hfjInKYWL/PnAHpPuZwjuHQkwxeeAKGo1ys/YY6rS2ooylTf3a 3Ymyodbh4+lADaA3rRBHwTpZFrbbDZIMZqOZ8PkjcT+0sf4y3uBu4EnI6BleoFCgOV0G DtikvMA0Qsgm0psVpimwno/JShsBaGfiJLiYwVmainv9PeW5My/6xsXz68TCii5hmvEe k5QP4UKs8VUPi1RiMMY/wOkCu18p3IYXbJWJmRg8Cb7Tlfj9oN+JmDti+XODgET9b1Mn L5rrXU0Zxi2d1kFaK1eILWiWQxgS3tn8EnUd5HBLwut9sXwozebacKbqvzaYGByQ7Qf1 XwPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773242834; x=1773847634; h=content-transfer-encoding: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; bh=TBnN2Dumri8XGwoA7NBPI1PL+2jwWyiT4+WfYmUV3Yo=; b=KTiH+1IOhLOj4vujZ/dtRiCajzzY4FXthMvDJQMqJ10x+zpj+1wbNDNtm3RmEug3lN l7IbS2n2fSepDWmSPGxMslI2tRyPBkqMh19MRKrtTU5qVJthLwvp5kZasuMJUVoNQ55/ Q7IyoR0pi+KEkazQbQOLrov7R9h9pUuh7Iv4cCoHqt0Kj2wZ6oSdvYoRUyIf4hQqHWF8 K3QvKMNyFQuuY1ND2NZTpRuLdfzZXt+CFjaCR6qtaOmkfFl/I8VS/PAu8gc0W7h8K0v8 AsQoZQiLe7uS3ylU4ER0a6X4suMyYgyDOBZyyUNygjuBPr6rOScF+VmRfCgp+B7XgoOu XRAQ== X-Forwarded-Encrypted: i=1; AJvYcCXNw/wG5PE9Fc4QjoaFfzGuPVbGhb4497YExG2tFib0E55axENo7tkykGhkKUa2aRUsTgZcYquu3Vk=@lists.xenproject.org X-Gm-Message-State: AOJu0YyeF54UkaEgazkWt7sLbPPzoLhAi4Ck3E9JTaLdEOZn2q06UjfI CA5Od7U8d8MhUDyhsKoSa/1JVg5mIu1B1JzNnOAppBqoZZQUcdW0kraYnmNNe7liyw== X-Gm-Gg: ATEYQzyR5A9m2QYSUf2DOD69Ujg1wvePOTOlSLzyB6POSfYUWJV2ImoYfvYyQRSC7jz 5VVjsDB0uxsXhg8wwvJB5+m/F8MRCqbOxQvaLpkYT6M3+CWK78IrZ+q5LfAdVq+Ywiy3XJVKiYR Db86vssrSNB+5R4vs32uDPWpGbktj0Om8X9TUZpKvqFeGVtsvGipuqjaTw97XxjRRytO82mjFY2 7CH0EHVgoa+BaVBvwyfnjwtxkqOuYhphTzX75tw/9c4qYQzCcj3pPEkhRa5oHzgBa6pJPYf5E8F sK0io5Xv53UyAAPo19dFqta4ze/bPnBpSZxihX1yEgHPVMaMx2stkVgc/himAkw9aob8B5RCN2i 3CMT14J0k1WJg8IBEG1KJ2JoPsgeeB9abqXYps1fsIlXPgVCQidPvPUUxN7+rbwvdQHqV+Wj+lX spizkJ/xzuLQKEQ1Cg6c2iAwLsHmhIKxMttYw0ZiNLmAR+WPA8FApUomp79vHEyjwrbcOCVNaUA cbsryS99l/0YcY= X-Received: by 2002:a05:6000:2283:b0:439:ae2a:755e with SMTP id ffacd0b85a97d-439f82017a2mr5884569f8f.23.1773242833530; Wed, 11 Mar 2026 08:27:13 -0700 (PDT) Message-ID: <1e371e65-ca79-42a0-93f9-804f73084033@suse.com> Date: Wed, 11 Mar 2026 16:27:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/7] x86/hvm: Support extended destination IDs in virtual MSI and IO-APIC To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-3-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-3-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > Use the newly defined masks to extract the full 15-bit destination ID > from guest MSI addresses and IO-APIC RTEs. In hvm_inject_msi() combine > the standard bits [19:12] with the extended bits [11:5] of the MSI > address into a 15-bit destination ID for LAPIC delivery. Increase the > dest parameter of vmsi_deliver() and hvm_girq_dest_2_vcpu_id() from > uint8_t to uint32_t. In vmsi_deliver_pirq() extract the full destination > from gflags via XEN_DOMCTL_VMSI_X86_FULL_DEST(). In msi_gflags() pack > the extended bits from the MSI address into the new > XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK field of gflags. In > vioapic_deliver() read the combined 15-bit destination using the > VIOAPIC_RTE_DEST() macro. Extend ioapic_check() to check for extended > destination bits set in a domain that does not advertise > XEN_HVM_CPUID_EXT_DEST_ID and refuse to restore the IO-APIC state, > preventing silent interrupt misrouting after live migration. This is pretty hard to read without being split in a few paragraphs. > --- a/xen/arch/x86/hvm/irq.c > +++ b/xen/arch/x86/hvm/irq.c > @@ -374,7 +374,16 @@ 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 (8 bits). > + * Extended MSI destination address bits 11:5 (7 more bits). > + * > + * As XEN_HVM_CPUID_EXT_DEST_ID is advertised, the guest may use bits 11:5 > + * for high destination ID bits, expanding to 15 bits total. Guests unaware > + * of this feature set these bits to 0, so this is backwards-compatible. How do you know? Like for the IO-APIC RTE bits, there is (and cannot be) anything enforcing this. Hence for a guest to use this feature, it needs to have a way to opt in. > + */ > + uint32_t dest = (MASK_EXTR(tmp, MSI_ADDR_EXT_DEST_ID_MASK) << MSI_ADDR_DEST_ID_BITS) | Nit: This line looks too long now. Here as well as ... > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -411,7 +411,9 @@ static void ioapic_inj_irq( > > static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) > { > - uint16_t dest = vioapic->redirtbl[pin].fields.dest_id; > + uint32_t dest = ((uint32_t)vioapic->redirtbl[pin].fields.ext_dest_id << > + VIOAPIC_RTE_DEST_ID_UPPER_BITS) | > + vioapic->redirtbl[pin].fields.dest_id; ... e.g. here a macro or inline function doing the conversion would likely help readability quite a bit. > @@ -618,6 +620,21 @@ static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h > e->fields.reserved[0] || e->fields.reserved[1] || > e->fields.reserved[2] || e->fields.reserved2 ) > return -EINVAL; > + > + /* > + * An RTE in the saved state has ext_dest_id bits set. Check that > + * the destination Xen has extended destination ID support enabled, > + * otherwise interrupt routing to APIC IDs > 255 would be broken > + * after restore. > + */ > + if ( e->fields.ext_dest_id && !d->arch.hvm.ext_dest_id_enabled ) This won't build, as the ext_dest_id_enabled field appears only in patch 6. But yes, that looks to be the opt-in mechanism I mentioned above. > @@ -659,7 +676,7 @@ static int cf_check ioapic_load(struct domain *d, hvm_domain_context_t *h) > return 0; > } > > -HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, NULL, ioapic_load, 1, > +HVM_REGISTER_SAVE_RESTORE(IOAPIC, ioapic_save, ioapic_check, ioapic_load, 1, > HVMSR_PER_DOM); As per the comment there, this belongs in the earlier patch. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 15:30:35 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 15:30:35 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251287.1548489 (Exim 4.92) (envelope-from ) id 1w0LW6-0004XD-4F; Wed, 11 Mar 2026 15:30:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251287.1548489; Wed, 11 Mar 2026 15:30:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0LW6-0004X6-19; Wed, 11 Mar 2026 15:30:34 +0000 Received: by outflank-mailman (input) for mailman id 1251287; Wed, 11 Mar 2026 15:30:32 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0LW4-0004Wu-94 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 15:30:32 +0000 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [2a00:1450:4864:20::333]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3d100a5e-1d5f-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 16:30:31 +0100 (CET) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-482f454be5bso12787045e9.0 for ; Wed, 11 Mar 2026 08:30: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-4854b66e3f8sm57716385e9.14.2026.03.11.08.30.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 08:30:29 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3d100a5e-1d5f-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773243030; x=1773847830; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TnBjGglOCM2+cTSoF662KVFUlDTC7/gd10+p2p4fWmU=; b=XZntlPKsF/eM+Bb/8fvGADM/1RUmpCIZn68QN4g+fIuVf6+f3yIIc6BHOizVQ/7GBl ZxBtDo4pCHRfGc0mlnAbB7CUzcVZZPWPWk15aMkNI3l2gGC6RzXOYgQ7JzKkNh89W9uu 2zdJpkz4zYTw4NmeMw9K3NBI3OSJhrz+n6L/S12g25gqxt5Qbhr/+cfHAOVDoArMaWmv HUuC9v4t5zqbprRPFEBo5lp16RcC42KUCdcmazFlnP56H8BMi8u3ZAy0SySpucfdPlH4 3JEyXnGKpTC/4K1Qu/jq1nh5D2a+Gl/K6lVovSf8/etmX3a47/kXn4Ghb7zGsk6T1heQ Ndiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773243030; x=1773847830; h=content-transfer-encoding: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; bh=TnBjGglOCM2+cTSoF662KVFUlDTC7/gd10+p2p4fWmU=; b=Zk42vaxlWMKwQAqu/+EUfhcJnXiIR1YUwKaTi4+CfrMPfM2ZtRII57UqG3se48dEtz LTkzCZ8e7JnZvTi0q0HakJUYg++e8vsZCXm+b5yXcK646FSE51E51jarS7UicHrIiSEu IlUtIa1ITWqaWrpqUP+AYLoEt74CktuiXtc5uyCnY5fIWuf6LlIyg+t+0u9bPviE+/S8 /k5k/IXYpDnCkXMMobjSGgPo1t2oVnbb6v7sp3RK+PpshrE5i4omr0p/ML5FfI9bdWVr WuA8/KJuaTB9qjv7+o6KHL9cAzhI6vwHbGSYh5g7AGxOw3Ztrfh5jngAxiqv8Gcm00bP OPDg== X-Forwarded-Encrypted: i=1; AJvYcCWwKiO8Fl8tN4I8BBKYws2ek8tb8xGfZfZSlVw0vXcXf645GIH4RmnB5u2POgc1p4cfsqoCc5gWnxI=@lists.xenproject.org X-Gm-Message-State: AOJu0YxwRh3ZYOhC0yxR1L/6Gy1JZM52kaOkspfnlqJPZjbLUTxkBENE jUS27an5JoVrgTfO1TXxkvl4gPU58nhoyfASuOBgqpb75xY3IPxYAoBnjuHvnXKbVIkup9CMQgA w3+A= X-Gm-Gg: ATEYQzxfGB8DFWAMMG2BJIGgRELIMBro6BhXJydKV8EkxZ7UT5XzR6HaOfzsI4y+/ma rGzuAAGE2BzLbQUKsHcJ6NkVQq7rvrNyajRhyHdwhMncB8xUSei5i9jGrBs9EsBkAyyPXBiVh13 tFiV/uaCmIXLS/Z2OkiCL00Zhg3IIljgIn+Md00modzRPIfT/Pt8VzO2yDrUn9jGWskjt+Z0w7Y F3dQN5QqkStA+Sv1eBHat/tuvZMWyUJ6+HjIuflObtGpsY8ZKe4DH7O8WEXQuL7C0dM7JDfcfad bQ+Td7RyxU5G25EtVdOGb69fZ3ED8TOF3EJ56Tw+mb2t7kwZi/JuJnBvavAppqndTVazK/x780i iP9qV5H+iWTOUhPJx40eaMYX8TCv2KTWUQnXvuDS5YJeXDjPYYZxfdg481oqSlJrq7tztFKdv5m VyhdmsBatTYHpBbO5Lo02pXZMP8BJYXyV6w6JJh8CMh6gjScf4AT0l6QvfjWgYt1Y3Nm5VAjszZ bZioDYtqTnwaF1hhNkYcVV3IA== X-Received: by 2002:a05:600d:8497:10b0:485:482e:f6c6 with SMTP id 5b1f17b1804b1-4854f523a8dmr1026395e9.0.1773243030353; Wed, 11 Mar 2026 08:30:30 -0700 (PDT) Message-ID: Date: Wed, 11 Mar 2026 16:30:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/7] x86/passthrough: Use extended destination ID in PT MSI bind/unbind To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-4-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-4-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > In pt_irq_create_bind() and _hvm_dpci_msi_eoi() replace the bare > MASK_EXTR(..., XEN_DOMCTL_VMSI_X86_DEST_ID_MASK) calls with > XEN_DOMCTL_VMSI_X86_FULL_DEST() so that the high 7 destination ID bits > stored in XEN_DOMCTL_VMSI_X86_EXT_DEST_ID_MASK are included when > computing the target vCPU for MSI passthrough IRQs. Increase the local > dest and delivery_mode variables to uint32_t to match. Why exactly would the latter also need widening? > --- a/xen/drivers/passthrough/x86/hvm.c > +++ b/xen/drivers/passthrough/x86/hvm.c > @@ -281,7 +281,7 @@ int pt_irq_create_bind( > { > case PT_IRQ_TYPE_MSI: > { > - uint8_t dest, delivery_mode; > + uint32_t dest, delivery_mode; Please prefer here (for dest) ... > @@ -807,8 +806,7 @@ static int cf_check _hvm_dpci_msi_eoi( > if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) && > (pirq_dpci->gmsi.gvec == vector) ) > { > - unsigned int dest = MASK_EXTR(pirq_dpci->gmsi.gflags, > - XEN_DOMCTL_VMSI_X86_DEST_ID_MASK); > + unsigned int dest = XEN_DOMCTL_VMSI_X86_FULL_DEST(pirq_dpci->gmsi.gflags); ... the type you found already being in use here. See ./CODING_STYLE as to the use of fixed-width types. Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 16:04:52 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 16:04:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251313.1548497 (Exim 4.92) (envelope-from ) id 1w0M3B-0000me-Gt; Wed, 11 Mar 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 1251313.1548497; Wed, 11 Mar 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 ) id 1w0M3B-0000mX-EC; Wed, 11 Mar 2026 16:04:45 +0000 Received: by outflank-mailman (input) for mailman id 1251313; Wed, 11 Mar 2026 16:04:45 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0M3A-0000mR-VE for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 16:04:45 +0000 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [2a00:1450:4864:20::32e]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 03ec7219-1d64-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 17:04:42 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48538c5956bso912385e9.0 for ; Wed, 11 Mar 2026 09:04: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-4854b0ea7easm44901275e9.5.2026.03.11.09.04.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 09:04:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 03ec7219-1d64-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773245082; x=1773849882; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=TT/SgzB7mUw3EoSGp78Tjf3cOUEGaf5p5hMLQXHI3Es=; b=TJ4vO90VppXFLrYmJTq6sd2VQ8nx2zAiIcJnHmcQEmlu0xQQ3z+bfgK7pd0MXTv5sf o3LXlK81siLvfmxw2AMzh5+MWmEHG4cAukHoVgdE/+8HwqRexFMYZwFGz0w32TiVsVtu 73+b1Kr5eAdV/6MjTrjNIaMLyvSb76GC/YQUKRH+RUzQ+64doYF/rhOPoidkUUCQFT6d tKoljiWzNxfiyY/LfDu2VnuOK6gOx4D0oEBhZdpYzcVb8Vrg2+cDqGU2Aqr0gTHjpDSL 2LWmdVE/7XiWBwWZmpACGOEFdoz+vtjPBwwRo18uaOg8nphe+dSiIw6oHf7sj+AAKJO+ ehPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773245082; x=1773849882; h=content-transfer-encoding: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; bh=TT/SgzB7mUw3EoSGp78Tjf3cOUEGaf5p5hMLQXHI3Es=; b=w8tXiVuLFH0BoSWQM7Oi7S58BfQMNqhZFNTJakrKdxNZHYmQ49E7PRc+FIoR2Eyxfv 1euLRDwLx6MROCxzRrhzjn5LyygSS7BMmHbuHI//9aeS0GzN3ZXUbVkQsvKTu2b/rHtT hQwzOYCDw8qQkPU7ceAwwSL2lfoaWO3YNPz+i/WvouTqkjnHi15yv1Au8sa3ewZLmsso EKdY+ZoO8KHpLbNdS++E62kmt8nMJoEwRlv+R4jl1Yngmg5VKyvIBAXbNbPp6UnXA2MI j14TRLSjfDkVSoYSBYRCKdmVBAWS/wuM2hmC6rkgPBaXpGeZdcTIaA0Z+GIXmrHg8Mow WnCg== X-Forwarded-Encrypted: i=1; AJvYcCUNlltCcG1sBPMyNh5HzTT0zlTstg3wjWNdTNPuWQz3UdDJEb7GC/ZRRjRlBbNGX6dlhnpUsO/uTTg=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyr+yafC5QIwzD5hz3HX1X3qSUsqeufumi1ExXK/3LjfCHEIfBL AGJlAbuoBH6C50hciX3HHTQgO1cLR9So1DltHPRSTPtMHW7vAQHVUOmFemgTe3rg4w== X-Gm-Gg: ATEYQzxDciCr5iRv8ISNs2O6ZqaAomlHmqvbiZbVCuQe+gk+FXYdub23Nk87LDD2ukd 7r1087A1tgPhvNibiJnltWkzAfwMJERE9nc/9rhFB89OAvt1DqJldHKi4PEti1A9UlI+ZWKOwzN I0b0wXTSWBOBZJNV3J0TMwhgRXq+hU7PCn6IekL7OEPqqKVHdbf3Zmx3fUlak3gGOcDgeaXPvjF I9075ahmp6Bp03k6c9SmckcWTr/I+zddwAtoGn3LrSoMiX70SAjIxtWkpwy+L7k9AiajJ0xwtNm nr6a9D8DGm3GotBFqXwEQePU5rjg+bmWhzfuKgH6qPSRYziNbEA3I4i93+NMGHMERpHE4RyNEGe dahBrf0AD8y5TDNKxEh8/GFZEUALfTbSphI0fYmaNDEAJNZbvKtBPq8z8gPlCqjaxlOBrwKqFmt iZegoeaYIt2I/pYkfnUwaCkZC/RD2eOE46J1TpRp/XxgfN7we2+kCN4sr5c0+xmvCBKtX2dBG3J faUg496r0wYbKM= X-Received: by 2002:a05:600c:310b:b0:46e:59bd:f7e2 with SMTP id 5b1f17b1804b1-4854f590efamr2030355e9.11.1773245081852; Wed, 11 Mar 2026 09:04:41 -0700 (PDT) Message-ID: <55a65f8d-40df-4841-8e76-200c82f397c5@suse.com> Date: Wed, 11 Mar 2026 17:04:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/7] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM ops To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-5-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-5-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > @@ -607,6 +631,83 @@ 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; > + struct xen_domctl_bind_pt_irq bind = { > + .machine_irq = data->machine_irq, > + .irq_type = PT_IRQ_TYPE_MSI, > + }; > + int irq; > + > + rc = -EINVAL; > + if ( data->pad0 || data->pad1 ) > + break; > + > + if ( data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED ) > + break; > + > + irq = domain_pirq_to_irq(d, bind.machine_irq); > + > + rc = -EPERM; > + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) > + break; > + > + bind.u.msi.gvec = data->gvec; > + bind.u.msi.gflags = > + msi_addr_to_gflags(data->addr, data->data, > + !(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED)); > + bind.u.msi.gtable = data->gtable; > + > + rc = -ESRCH; > + if ( is_iommu_enabled(d) ) > + { > + pcidevs_lock(); > + rc = pt_irq_create_bind(d, &bind); > + pcidevs_unlock(); I understand the same locking is used at the other call site, but it's as questionable there as it is here. We should try hard to avoid use of this global lock when something lighter-weight would do. > + } > + if ( rc < 0 ) > + printk(XENLOG_G_ERR > + "pt_irq_create_bind failed (%ld) for dom%d\n", > + rc, d->domain_id); %pd please in new code. Also this message needs to be distinguishable from that in arch_do_domctl(). > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -444,6 +444,28 @@ 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; > + /* IN - guest vector */ > + uint8_t gvec; > + uint8_t pad0; > + uint16_t pad1; > + /* IN - MSI data (vector, delivery, trigger) */ > + uint32_t data; > + /* IN - flags */ > + uint32_t flags; > +#define XEN_DMOP_MSI_FLAG_UNMASKED (1u << 0) > + /* IN - MSI address (0xfeexxxxx, includes ext dest) */ The address given is x86-specific, while the header is arch-generic. (If this was to be an x86-only interface, ... > + uint64_aligned_t addr; ... this also wouldn't need to be a 64-bit address, for example.) > + /* IN - MSI-X table base GFN, 0 for MSI */ > + uint64_aligned_t gtable; > +}; Commentary throughout also leaves unclear which of the fields are actually meaningful for XEN_DMOP_unbind_pt_msi_irq. In a new interface, the unused fields would want checking to be zero. Yet better may be to have unbind have its own, much smaller structure. > +typedef struct xen_dm_op_bind_pt_msi_irq xen_dm_op_bind_pt_msi_irq_t; Is this typedef actually needed anywhere? Clearly ... > @@ -468,6 +490,7 @@ struct xen_dm_op { > xen_dm_op_relocate_memory_t relocate_memory; > xen_dm_op_pin_memory_cacheattr_t pin_memory_cacheattr; > xen_dm_op_nr_vcpus_t nr_vcpus; > + xen_dm_op_bind_pt_msi_irq_t bind_pt_msi_irq; ... the plain struct can be used e.g. here. Imo we should stop cluttering the namespace with typedef-s which aren't actually needed. (A case where they are needed is when a guest handle needs defining for the type.) > --- a/xen/include/xlat.lst > +++ b/xen/include/xlat.lst > @@ -107,6 +107,7 @@ > ? dm_op_map_mem_type_to_ioreq_server hvm/dm_op.h > ? dm_op_modified_memory hvm/dm_op.h > ? dm_op_nr_vcpus hvm/dm_op.h > +? dm_op_bind_pt_msi_irq hvm/dm_op.h > ? dm_op_pin_memory_cacheattr hvm/dm_op.h > ? dm_op_relocate_memory hvm/dm_op.h > ? dm_op_remote_shutdown hvm/dm_op.h I'm curious: How did you determine the insertion point? Jan From xen-devel-bounces@lists.xenproject.org Wed Mar 11 16:45:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 16:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251342.1548523 (Exim 4.92) (envelope-from ) id 1w0Mgd-0005tE-Ix; Wed, 11 Mar 2026 16:45:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251342.1548523; Wed, 11 Mar 2026 16: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 ) id 1w0Mgd-0005t6-Dq; Wed, 11 Mar 2026 16:45:31 +0000 Received: by outflank-mailman (input) for mailman id 1251342; Wed, 11 Mar 2026 16:45:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Mgc-0005sz-BL for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 16:45:30 +0000 Received: from mail132-19.atl131.mandrillapp.com (mail132-19.atl131.mandrillapp.com [198.2.132.19]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b2353a73-1d69-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 17:45:23 +0100 (CET) Received: from pmta09.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail132-19.atl131.mandrillapp.com (Mailchimp) with ESMTP id 4fWGns1qR4z38C for ; Wed, 11 Mar 2026 16:45:21 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id 91755ee142c24cf09d14820a48502e98; Wed, 11 Mar 2026 16:45:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b2353a73-1d69-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1773247521; x=1773517521; bh=sF4mymys6HAdkw0w5HfIbDG7JT5KWKQV9kEANluIkKo=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=M4SXMsT4bI7OMHpjo6LlMptingu/us1dYII8J6C73OlHhtcIsUJ8McFoo3u02yPtZ U1rBnznU53xx3xmaiCuN5FFFXLfbyW3FNX+uNNSyJgX86AHEaTxiuAwDazqqRUGW1U q3OzHVngsTFJ4ShODeUJq+ZFDeIEZQg9ybitwqKgSSjjgPaQ/++ae//PLH/eAdhb97 d1IKfOBhrJoGLco7gNEIm+sFchGMpd/hM4hs1RMbMT08/xWLS+A+BUtb2Sb8DVDLOO MBH0T1SnpNMwg1bp62EAwPlsExVjIPhgXmm/b1ew+J2QdOEHX0TnM1mxX6ofLdlp2O 0nYPW8EEs6TMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1773247521; x=1773508021; i=anthony.perard@vates.tech; bh=sF4mymys6HAdkw0w5HfIbDG7JT5KWKQV9kEANluIkKo=; h=From:Subject:To:Cc:Message-Id:References:In-Reply-To:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=qWbqT8GoBdfavENknNPEKsyiiDPye6BhIAUmwJXI3qtc9Mbn1S9BnJkRDZV7pghV9 M+TQqB8scXcgKvc39HWKdMo5JrQ3eyELwR7Pwm/kN/wAk3C1yI7wE28y0ewAzeZ/YN cigWWSP2BqWWq8gFfYDM4ZHfaItDBBSyXfVDq/ThjAo+UP54cgv8qKJjQRYUZ9869u 31ZtQKH+Y6MowrMvafKfl/ehpvLMmp4WvO1ForSa7cvl1h96McipczlO+rZRtmtoTI ORYN1wxIewkCOLtRgOenOT3TQCYSrd1n3YeF0uVNksIVU3IxyTtmza5mwqoH+Xt/Di hiDpvUNUZlF1Q== From: "Anthony PERARD" Subject: =?utf-8?Q?Re:=20[PATCH=20v8=202/2]=20xenpm:=20Add=20get-core-temp=20subcommand?= X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1773247520247 To: "Jan Beulich" , "Teddy Astie" Cc: "Oleksii Kurochko" , "Community Manager" , xen-devel@lists.xenproject.org Message-Id: References: <7380cf63-e9ac-4df9-9633-c26f9de0027a@suse.com> <4c18413b-6296-4a30-bbec-561f7b802cbc@vates.tech> In-Reply-To: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.91755ee142c24cf09d14820a48502e98?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20260311:md Date: Wed, 11 Mar 2026 16:45:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 03, 2026 at 12:54:28PM +0100, Jan Beulich wrote: > On 03.03.2026 11:50, Teddy Astie wrote: > > Le 02/03/2026 =C3=A0 17:52, Jan Beulich a =C3=A9crit=C2=A0: > >> On 27.02.2026 18:00, Teddy Astie wrote: > >>> + printf("No data\n"); > >>> + exit(ENODATA); > >> > >> In how far is using errno values as arguments to exit() a useful thing= ? (I > >> think you had it like this before, and I merely forgot to ask.) Yes, I= can > >> see the tool using a number of exit(EINVAL), but I don't understand th= ose > >> either. This way you can't even document easily what particular exit c= odes > >> mean, as the errno values may vary across OSes. > >> > > > > I reused the exit(...) pattern used in xenpm, but I'm also fine by > > returning simpler errors (like exit(1) or exit(EXIT_FAILURE)). > > Anthony, can you please suggest which one better fits the toolstack as a > whole? There isn't really one, but `exit(EXIT_FAILURE)` would be more explicit. -- Anthony Perard | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech From xen-devel-bounces@lists.xenproject.org Wed Mar 11 17:02:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 17:02:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251360.1548531 (Exim 4.92) (envelope-from ) id 1w0Mx8-0000D7-RX; Wed, 11 Mar 2026 17:02:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251360.1548531; Wed, 11 Mar 2026 17:02:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Mx8-0000D0-OF; Wed, 11 Mar 2026 17:02:34 +0000 Received: by outflank-mailman (input) for mailman id 1251360; Wed, 11 Mar 2026 17:02:33 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Mx7-0000Cu-CA for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 17:02:33 +0000 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 1659b7d5-1d6c-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 18:02:30 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 343704433C; Wed, 11 Mar 2026 17:02:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD869C4CEF7; Wed, 11 Mar 2026 17:02:27 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1659b7d5-1d6c-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773248548; bh=qbQHUZHFrMSl9GZ0M449xWT2lv88BuJUsOUnExNCyK4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=auYcSsapz8p65gnvMN/VpGSca+m0V47rs2fNjRxHOGbcOF7khTzKCshNZHWFukUEa bnXC+yfrXbKqbLhu68q0yQfhAyMWSCXNXNIBAKRaLjxFgWqWGJAvlEHVE71SrnEki3 dKD9hbUZKlFZq0UVuNyj0aL4WApKHEHlTf0M8Ea7qH5r5ypeguDSCVP7fDO8XFkDzz KqLzUOMWPsO+YrDPq38kiCFHjNbZq9K/tQnyESpkcZj3YnLHqDfmRejiAWwWhB2AUQ D64NsEu8EfPzJunss4O8z5+fy5ezEJbruvUviqIng0ygosw3JnId/51TdCe9FKqRYj 4x+0E9RndXZcA== Date: Wed, 11 Mar 2026 12:02:26 -0500 From: Bjorn Helgaas To: fengchengwen Cc: Jeremy Linton , Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Ajit Khaparde , Wei Huang , Andy Gospodarek , Somnath Kotur , wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org, Wathsala Vithanage Subject: Re: [PATCH v5 2/2] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Message-ID: <20260311170226.GA930029@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef9b529-839b-4cf0-a294-5b68fe8aa768@huawei.com> On Wed, Mar 11, 2026 at 11:00:02AM +0800, fengchengwen wrote: > On 3/11/2026 6:09 AM, Bjorn Helgaas wrote: > > On Tue, Mar 10, 2026 at 10:58:49AM -0500, Jeremy Linton wrote: > >> On 3/9/26 10:20 PM, Chengwen Feng wrote: > >>> pcie_tph_get_cpu_st() is broken on ARM64: > >>> 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. > >>> cpu_uid should be the ACPI Processor UID [1]. > >>> 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via > >>> cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, > >>> generated and managed by kernel (e.g., [0,255] for a system with 256 > >>> logical CPU cores). > >>> 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the > >>> MADT table, and this UID may not match the kernel's logical CPU ID. > >>> When this occurs, the mismatch results in the wrong CPU steer-tag. > >>> 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID > >>> so the mismatch is not seen. > > > >>> int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, > >>> - unsigned int cpu_uid, u16 *tag) > >>> + unsigned int cpu, u16 *tag) > >>> { > >>> #ifdef CONFIG_ACPI > >>> + u32 cpu_uid = acpi_get_cpu_acpi_id(cpu); > > > > From AI review (gemini/gemini-3.1-pro-preview): > > > > Does this code need to validate that `cpu` is within bounds before > > using it? Before this change, the `cpu_uid` parameter was passed > > opaquely to the ACPI firmware via `tph_invoke_dsm()`, which would > > gracefully handle invalid values. > > > > Now, `cpu` is treated as a logical CPU index and passed to > > `acpi_get_cpu_acpi_id(cpu)`. On architectures like arm64 and riscv, > > `acpi_get_cpu_acpi_id()` uses `cpu` directly as an array index > > (`&cpu_madt_gicc[cpu]` and `&cpu_madt_rintc[cpu]`). On x86, it uses > > `per_cpu(x86_cpu_to_acpiid, cpu)`. > > > > If a caller passes an out-of-bounds `cpu` index (for example, if an > > IRQ affinity mask is empty and `cpumask_first()` returns > > `nr_cpu_ids`, or if userspace passes an arbitrary ID via > > `mlx5_st_alloc_index()`), this will result in an out-of-bounds > > memory read. > > > > Consider adding a bounds check: > > > > if (cpu >= nr_cpu_ids) > > return -EINVAL; > > > > I agree that this is an issue, and I think implementations of > > acpi_get_cpu_acpi_id() should validate their inputs. > > > > I don't know if there's a value that can never be a valid ACPI CPU UID > > and could be used as an error value from acpi_get_cpu_acpi_id(). I do > > see a few mentions of a ~0 value meaning "all processors" (ACPI r6.6, > > sec 5.2.12.13). > > I only have the ACPI Specification Version 6.5, so I will use v6.5 > as an example. https://uefi.org/sites/default/files/resources/ACPI_Spec_6.6.pdf > int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) { > if (cpu >= nr_cpu_ids) > return -EINVAL; > *uid = xxx; > return 0; > } This looks good to me. > Another issue: This commit also provides an implementation for the > x86 platform. However, further code analysis revealed a potential > problem in the implementation: > > The acpi_get_cpu_acpi_id() retrieves uid from x86_cpu_to_acpiid in > SMP, and x86_cpu_to_acpiid is set through the call chain: > acpi_parse_lapic() -> topology_register_apic() -> > topo_register_apic() -> topo_set_cpuids() -> x86_cpu_to_acpiid. It > appears to retrieve the "ACPI Processor UID" from ACPI Section > 5.2.12.2, but the problem is that this field is only one byte in > length, which may cause issues in huge-core systems. > > Therefore, I suggest re-implementing the acpi_get_cpu_uid function > for the x86 platform. Either I provide a default implementation > (shown below), or x86 guys contribute to the implementation: > > s64 acpi_get_cpu_uid(unsigned int cpu) { > if (cpu >= nr_cpu_ids) > return -EINVAL; > return cpu; > } I don't think this is your problem to solve, so don't worry about it. If you implement acpi_get_cpu_uid() to return the same values as cpu_acpi_id(), it's up to the x86 folks to deal with any one-byte ID issues. Bjorn From xen-devel-bounces@lists.xenproject.org Wed Mar 11 17:59:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 17:59:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251421.1548558 (Exim 4.92) (envelope-from ) id 1w0NpW-0006bx-00; Wed, 11 Mar 2026 17:58:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251421.1548558; Wed, 11 Mar 2026 17:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0NpV-0006bq-SN; Wed, 11 Mar 2026 17:58:45 +0000 Received: by outflank-mailman (input) for mailman id 1251421; Wed, 11 Mar 2026 17:58:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0NpT-0006bk-NY for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 17:58:43 +0000 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [2a00:1450:4864:20::32d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f0c32813-1d73-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 18:58:42 +0100 (CET) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4853aec185aso995265e9.1 for ; Wed, 11 Mar 2026 10:58:42 -0700 (PDT) Received: from localhost.localdomain (host-92-22-18-152.as13285.net. [92.22.18.152]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48541aa73dasm466222415e9.2.2026.03.11.10.58.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 10:58:40 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f0c32813-1d73-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1773251922; x=1773856722; 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; bh=LlBmTgWfgO6kHetj1uAczCboAc6JSzkfGfAETvDden4=; b=BKPVCyZx/qjgmYu7vT7nd1CgNuWjnuBQmNcal/sYhJgZug+M1NFfx25YQukjzemjZj ocy80Fpw6VxloLKU6ihrYCowCHlr8xtdiMBhj/qmKnllt2wv/iS+rikstUrIaEi7uZIv NDXj2NCRDdQrhnzOXEXODiPEepOZHeLhMaAlQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773251922; x=1773856722; 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; bh=LlBmTgWfgO6kHetj1uAczCboAc6JSzkfGfAETvDden4=; b=U9I3E+e/wuKO9QouaTHfKrn/kJRLSN4ZktULpoRStpnFQy+bYlskVJPe1ov/VKnDn5 VJRTCAw6scA+/8tsmkXra3xLyv/P1JyRm0B3HAb1iuqX4q8Z9p6PBh1D3wj8yEtk5D3f U1j34MGwyZ3T3L7PhzC+A26wUrY1tzgWaSYbo/WlEziowfbOmYS0Blm7XqtA/GZz3MgR WOvS/noOAmMUvI21tc7hyeMlLKmUNXSypGsa9IE+GxWn0RZreEYCWkmwVbu51SxWvFzo kRJcYoMkOcT92q/jlSyaoXE9v5CkRmhbdn+KWlZiS61Y03UyL9oxhB9vtuhZ36w0G2Qr jvQA== X-Gm-Message-State: AOJu0YwAZ0FCUBAKUI+MRoH70MJ3yEaIUzgdvGSdFUwKBp/9jL8ibJyZ Ck2hCditeajw2l73+GtfaIrV0pFOD2D4DiaftL+qP+A8jDiP1gzUhIqLrSJWd4PM4muCuivE1Sg yIKud X-Gm-Gg: ATEYQzzDlqSUDr71xmDF8ZMYsPIdSBYmVs5t/xtiJSm6JcEMVrgK98RKCly433rKYgV nCOgzpTnCB6pDNZIIAxeC4II44hz/vB7jiKrMHFwog17nV93eeUHJvITpzg/RbfTqSA7FA/htrI xNNXvNPVv/LJjaoe2bv8zlSa2CiqkF5mmlE+xwAqMqaq79bnQGcfvV++BUaVpYHSaXbKZ7MPcOB 1ZTyJkadVX/Z8gxQmgwLK/ItdXqT/HwQPTx5olzMgLm2tN4q0o4gCAmjec5sot1MRJNsR9KDWhy X02N2rIu4uuAjr50cap3vUXDpWHtlHkyVILEnDMcSbc/aS0m6KofXnRpGC1W9SkcZbzkAA3mh9h S/jIYYTRW1WL5AZOCz1qXw+UG0cRi2rHL27jlhrxefxCpETX6ihzXWIKkDqTdhRBg4j1kT622Fi /+2FmZ1aBOztr5cIJCe4IA150nSk+RtUGOWRZE/HAlTBOJKzADblE84xn7z/QnjxuBUYyu82Q= X-Received: by 2002:a05:600c:8b0a:b0:480:4a8f:2d5c with SMTP id 5b1f17b1804b1-4854b129f91mr57653585e9.29.1773251921378; Wed, 11 Mar 2026 10:58:41 -0700 (PDT) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v4.1 13/14] x86: Clamp bits in eflags more aggressively Date: Wed, 11 Mar 2026 17:58:38 +0000 Message-Id: <20260311175838.573925-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260227231636.3955109-14-andrew.cooper3@citrix.com> References: <20260227231636.3955109-14-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In FRED mode, ERET is stricter than IRET about flags. Notably this means: * The vm86 bit (bit 17) and IOPL (bits 12,13) must be clear. * The sticky-1 reserved bit (bit 2) must be set, so dom0_construct() needs to set X86_EFLAGS_MBS in order for a PV dom0 to start. * All other reserved bits must be clear. Xen has been overly lax with reserved bit handling. Adjust arch_set_info_guest*() and hypercall_iret() which consume flags to clamp the reserved bits for all guest types. This is a minor ABI change, but by the same argument as commit 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"); the reserved bits would get clamped like this naturally by hardware when the vCPU is run. The handling of vm86 is also different. Guests under 32bit Xen really could use vm86 mode, but Long Mode disallows vm86 mode and IRET simply ignores the bit. Xen's behaviour for a PV32 guest trying to use vm86 mode under a 64bit Xen is to arrange to deliver #GP at the target of the IRET, rather than to fail the IRET itself. However there's no filter filtering in arch_set_info_guest() itself, and it can't arrange to queue a #GP at the target, so do the next best thing and fail the hypercall. This is not expected to create an issue for PV guests, as the result of such an arch_set_info_guest() previously would be to run supposedly Real Mode code as Protected Mode code. This allows PV guests to start when Xen is using FRED mode. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné v4.1: * Adjust VM handling. * Rewrite commit message. v3: * Rewrite the commit message. v2: * New It turns out that it's simply ignored by IRET in Long Mode (i.e. clearing it commit 0e47f92b0725 ("x86: force EFLAGS.IF on when exiting to PV guests") wasn't actually necessary) but ERETU does care. --- xen/arch/x86/domain.c | 24 ++++++++++++++++++++++-- xen/arch/x86/hvm/domain.c | 4 ++-- xen/arch/x86/include/asm/x86-defns.h | 7 +++++++ xen/arch/x86/pv/dom0_build.c | 2 +- xen/arch/x86/pv/iret.c | 8 +++++--- 5 files changed, 37 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 868c26036dd9..4664264b2f5d 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1193,6 +1193,14 @@ int arch_set_info_guest( if ( !__addr_ok(c.nat->ldt_base) ) return -EINVAL; + + /* + * IRET in Long Mode discards EFLAGS.VM, but in FRED mode ERET + * cares that it is zero. + * + * Guests can't see FRED, so emulate IRET behaviour. + */ + c.nat->user_regs.rflags &= ~X86_EFLAGS_VM; } #ifdef CONFIG_COMPAT else @@ -1205,6 +1213,18 @@ int arch_set_info_guest( for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ ) fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs); + + /* + * Under 32bit Xen, PV guests could really use vm86 mode. Under + * 64bit Xen, vm86 mode can't be entered even by PV32 guests. + * + * For backwards compatibility, compat HYPERCALL_iret will arrange + * to deliver #GP at the target of the IRET rather than to fail + * the IRET itself, but we can't arrange for the same behaviour + * here. Reject the hypercall as the next best option. + */ + if ( c.cmp->user_regs.eflags & X86_EFLAGS_VM ) + return -EINVAL; } #endif @@ -1244,7 +1264,7 @@ int arch_set_info_guest( v->arch.user_regs.rax = c.nat->user_regs.rax; v->arch.user_regs.rip = c.nat->user_regs.rip; v->arch.user_regs.cs = c.nat->user_regs.cs; - v->arch.user_regs.rflags = c.nat->user_regs.rflags; + v->arch.user_regs.rflags = (c.nat->user_regs.rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.user_regs.rsp = c.nat->user_regs.rsp; v->arch.user_regs.ss = c.nat->user_regs.ss; v->arch.pv.es = c.nat->user_regs.es; @@ -1268,7 +1288,7 @@ int arch_set_info_guest( v->arch.user_regs.eax = c.cmp->user_regs.eax; v->arch.user_regs.eip = c.cmp->user_regs.eip; v->arch.user_regs.cs = c.cmp->user_regs.cs; - v->arch.user_regs.eflags = c.cmp->user_regs.eflags; + v->arch.user_regs.eflags = (c.cmp->user_regs.eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.user_regs.esp = c.cmp->user_regs.esp; v->arch.user_regs.ss = c.cmp->user_regs.ss; v->arch.pv.es = c.cmp->user_regs.es; diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c index 155d61db13f8..a0e811ea47a0 100644 --- a/xen/arch/x86/hvm/domain.c +++ b/xen/arch/x86/hvm/domain.c @@ -194,7 +194,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) uregs->rsi = regs->esi; uregs->rdi = regs->edi; uregs->rip = regs->eip; - uregs->rflags = regs->eflags; + uregs->rflags = (regs->eflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.hvm.guest_cr[0] = regs->cr0; v->arch.hvm.guest_cr[3] = regs->cr3; @@ -245,7 +245,7 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx) uregs->rsi = regs->rsi; uregs->rdi = regs->rdi; uregs->rip = regs->rip; - uregs->rflags = regs->rflags; + uregs->rflags = (regs->rflags & X86_EFLAGS_ALL) | X86_EFLAGS_MBS; v->arch.hvm.guest_cr[0] = regs->cr0; v->arch.hvm.guest_cr[3] = regs->cr3; diff --git a/xen/arch/x86/include/asm/x86-defns.h b/xen/arch/x86/include/asm/x86-defns.h index 0a0ba83de786..edeb0b4ff95a 100644 --- a/xen/arch/x86/include/asm/x86-defns.h +++ b/xen/arch/x86/include/asm/x86-defns.h @@ -27,6 +27,13 @@ (X86_EFLAGS_CF | X86_EFLAGS_PF | X86_EFLAGS_AF | \ X86_EFLAGS_ZF | X86_EFLAGS_SF | X86_EFLAGS_OF) +#define X86_EFLAGS_ALL \ + (X86_EFLAGS_ARITH_MASK | X86_EFLAGS_TF | X86_EFLAGS_IF | \ + X86_EFLAGS_DF | X86_EFLAGS_OF | X86_EFLAGS_IOPL | \ + X86_EFLAGS_NT | X86_EFLAGS_RF | X86_EFLAGS_VM | \ + X86_EFLAGS_AC | X86_EFLAGS_VIF | X86_EFLAGS_VIP | \ + X86_EFLAGS_ID) + /* * Intel CPU flags in CR0 */ diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_build.c index 9a11a0a16b4e..075a3646c2a3 100644 --- a/xen/arch/x86/pv/dom0_build.c +++ b/xen/arch/x86/pv/dom0_build.c @@ -1024,7 +1024,7 @@ static int __init dom0_construct(const struct boot_domain *bd) regs->rip = parms.virt_entry; regs->rsp = vstack_end; regs->rsi = vstartinfo_start; - regs->eflags = X86_EFLAGS_IF; + regs->eflags = X86_EFLAGS_IF | X86_EFLAGS_MBS; /* * We don't call arch_set_info_guest(), so some initialisation needs doing diff --git a/xen/arch/x86/pv/iret.c b/xen/arch/x86/pv/iret.c index d3a1fb2c685b..39ce316b8d91 100644 --- a/xen/arch/x86/pv/iret.c +++ b/xen/arch/x86/pv/iret.c @@ -80,8 +80,9 @@ long do_iret(void) regs->rip = iret_saved.rip; regs->cs = iret_saved.cs | 3; /* force guest privilege */ - regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM)) - | X86_EFLAGS_IF); + regs->rflags = ((iret_saved.rflags & X86_EFLAGS_ALL & + ~(X86_EFLAGS_IOPL | X86_EFLAGS_VM)) | + X86_EFLAGS_IF | X86_EFLAGS_MBS); regs->rsp = iret_saved.rsp; regs->ss = iret_saved.ss | 3; /* force guest privilege */ @@ -143,7 +144,8 @@ int compat_iret(void) if ( VM_ASSIST(v->domain, architectural_iopl) ) v->arch.pv.iopl = eflags & X86_EFLAGS_IOPL; - regs->eflags = (eflags & ~X86_EFLAGS_IOPL) | X86_EFLAGS_IF; + regs->eflags = ((eflags & X86_EFLAGS_ALL & ~X86_EFLAGS_IOPL) | + X86_EFLAGS_IF | X86_EFLAGS_MBS); if ( unlikely(eflags & X86_EFLAGS_VM) ) { -- 2.39.5 From xen-devel-bounces@lists.xenproject.org Wed Mar 11 18:01:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 18:01:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251431.1548565 (Exim 4.92) (envelope-from ) id 1w0NsX-0008Al-Bs; Wed, 11 Mar 2026 18:01:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251431.1548565; Wed, 11 Mar 2026 18:01:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0NsX-0008Ae-9F; Wed, 11 Mar 2026 18:01:53 +0000 Received: by outflank-mailman (input) for mailman id 1251431; Wed, 11 Mar 2026 18:01:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0NsW-0008AN-0S for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 18:01:52 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5ffeb0bc-1d74-11f1-b164-2bf370ae4941; Wed, 11 Mar 2026 19:01:50 +0100 (CET) Received: from MN2PR20CA0044.namprd20.prod.outlook.com (2603:10b6:208:235::13) by BN7PPF02710D35B.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6c4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.3; Wed, 11 Mar 2026 18:01:46 +0000 Received: from BN3PEPF0000B36D.namprd21.prod.outlook.com (2603:10b6:208:235:cafe::53) by MN2PR20CA0044.outlook.office365.com (2603:10b6:208:235::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.26 via Frontend Transport; Wed, 11 Mar 2026 18:01:37 +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.20.9723.1 via Frontend Transport; Wed, 11 Mar 2026 18:01:46 +0000 Received: from localhost (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.17; Wed, 11 Mar 2026 13:01:30 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5ffeb0bc-1d74-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dr0Gs0qu45yXBUBSglHv44/qGOTa4orggIm+FWKGK/wSAJDfDrNI+yjsaFXXyetWfqjmQJkv+Dep2zecy6DOPUsx76PJIObV3PMcrCkp1B+Q74GcVPwVgxOJYYzMHtwekrKNKNLniw0VRip3mHiL+Aau0RcrwCiZj2OQauUEAeANapP2awFGwoTlolaoMjK8avWxNaLsrXoAaa2GyPdHFdcBEN6v1nHpEGgvjjoYGOdUhnt1yhba5BCQLz2S90hTpJxnNWpfsjIWueE9uO9G9Lhp20JMECSMDFGSUavb7im2JE7jPxAr/iQDoVtrKNzXB//mjGmV4wqhxhjiGg2nqA== 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=okI4fiejMMls0M1i0caJ90L2TUXisxMbRuJCnUtSXu0=; b=LzBMxnmKdhOjx8TAf5ir/Y7b0c6fcj1hvm2gitgDumInzF5AUEkbqd2cNp/1XL/kQiq65ac7LCwZtDMrZdoSWeWDeiZKm0lbihhxDRgPRYjHZAffzTvbzfucQxx2z1rlZTuVeB52GVbfFGksiUwyZ/PZn2Mv4ITfPND+SKrY7CJkkFtyZpP/rnLHayYsKtvQflofc8NA26h32/I00IAoA/yKSgsBoLf65f+vOhr+MiNoKeczO9AeHcSxGk9Gv4M/Mdr8LFauzDWUePiBdcIwQfi9w8l7nmgQOikRpJOvD++lTbRcvPTUrzuMz3SjMCcj8RRYYvkRhEelHXAx9il0og== 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=okI4fiejMMls0M1i0caJ90L2TUXisxMbRuJCnUtSXu0=; b=YKoxCDeOE0hKbzkKAZRvtyqcaNFYQSWJ+QmcD0UUunhJTS9jVOfR/sNvDTxLQE37LTGUn/i28bj9KTLt31xYUbORyP0+VnsxJKfB0ywub1+YXmOKGFry7lzSZI88vSxk4NwqyNXzc17ELa4JPgyYsUpULt5inbOg3KFKx0O8RN0= 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 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Mar 2026 19:01:25 +0100 Message-ID: Subject: Re: [PATCH v4 2/4] x86/hvm: Disable cross-vendor handling in #UD handler From: Alejandro Vallejo To: Jan Beulich CC: Andrew Cooper , =?utf-8?q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , X-Mailer: aerc 0.20.1 References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-3-alejandro.garciavallejo@amd.com> In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN3PEPF0000B36D:EE_|BN7PPF02710D35B:EE_ X-MS-Office365-Filtering-Correlation-Id: c27c5355-b116-492d-541d-08de7f98428a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|36860700016|1800799024|82310400026|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: dif0zl2YGVvK6wZyWvmVhDB9iKip7jWMizMsPLNd024X0dguZikDqAfvvAF0zujWCAXzN4ipe/ghNQ6WtzNVPpT8lI+xk3t8i4mXLqkpsPAbWwYUvAm5CtTIJut9tM8DH2n8rjSJ59rVlrD3t0aGCT3jOFXI8l7f3Ur/G4BvJJ89/7h2bVV0SEpdk0stl9p0GfvNL4I9ydxnjOSe71tM++GuNL5gsqNQE6/ldwwU108MvvO5kVVZKuTf7ThILe6yZIn3mJTwNxy6CHrr4SgGKcE9sGun/YuG99n2F2fr6/9bOYNmKmJbMPNe/26HOs2iZnNTR/+nHmHGrt2eM/BJRNjj14UwrEY/ciiIFA2ilw1eAiaipU2S485iWTlonFwOJ4HbaU282ZdRyDQdqO/8V2BAMp4Uvj7xy42jeVC4m8ZxHKOiau6COgHUDfpntQIW1SgbTWAmH0XF+OOKKa/gYiNlvrcobZHhQj1THK1E1IF8RvgO/GWLd6/1gHdvR0ErIvb6SjMKTgKji8x4JcWJ0DhWiJXWZ0LuI5UbT33gHJ6j6TigKTnXidYaTy9O/e1m0hpNKtIueShhn3dXdJWtqVAqBfUcdP+z1aQYO78oliLBRNMqogPwljT/osXxSmQsQAcK5batfpm+h608JoqDqrEMa5FGzGqAmsmgvvmS6GQ7y8oJ7vHaOZ/GfUHqMvOnW5kB8DtKLxlmyPsKF1HRywVQWfHGvDDT5R3KpY6df3Mm73SxUmuMeDIu07K6F9pv65oXAJ1NeOiSDHxea2OCRA== 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)(82310400026)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: wNWa4ehWMaSZchkpkLR6YA5PdR59cWUPrRX25vgl3StS/T1kFc7tLSQTDnXeZ9b5X0X1H/Hg3FzO6CcBXrI11PBXCl8tNikSBJLuu8BvuunZyLJs5PoLoRrr0ic2OiMamhphys29h4ABqS4iRJAY9WgVnpIScCQbPmt/J1zt//O+FodXjxsOQctXlq84uzMucaQuBGndgAW+9c8BR4maTtYMhlRsCJjf4REofyIk/u8lAyLzTa3VitPNkOrjWdp1Qn5S39RNd0iBAO/vN+K0OmgUCq5HJfMQ7Wfdx4enNaNojtuOT3htRBp5aM29GzyGCJUJbywPsikxMY+Y6xu1dKsGRv980bPyeFCTpObNzjvHgx5UP7D3CZR0xZ1iwNFj6z38ndz3brC7hSleYDkxZVP4Fpwr+UsXuFjsWuJfMuxtk/Xi8Qh2n4sDS9yV8AIN X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 18:01:46.0743 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c27c5355-b116-492d-541d-08de7f98428a 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: BN7PPF02710D35B On Wed Mar 11, 2026 at 3:59 PM CET, Jan Beulich wrote: > On 11.03.2026 15:27, Alejandro Vallejo wrote: >> Remove cross-vendor support now that VMs can no longer have a different >> vendor than the host. >>=20 >> While at it, refactor the function to exit early and skip initialising >> the emulation context when FEP is not enabled. >>=20 >> No functional change intended. >>=20 >> Signed-off-by: Alejandro Vallejo >> --- >> v4: >> * Reverted refactor of the `walk` variable assignment > > "Revert" as in "move it even farther away from the original". Revert as in not split the assignment and restore the orignal syntax _of th= e assignment_, which was the main focus of the prior discussion. It's hardly my intention to add unrequested changes, but I can't address th= at which isn't explicitly requested. > As said, you want re-indentation, This is an ambiguous piece of advice. Of what? That can mean moving the prior logic back to its original location= and crate a minimal diff (1) or simply collapsing the indentation of the block = (2). (1) can't be done with hvm context initialiser moving after the early exit, which I explicitly mentioned in the commit message I wanted to do. (2) can't happen because declarations and statements cannot be mixed (thoug= h I really wish we dropped that rule). There's a third option of keeping a silly { ... } around just for indentati= on purposes, but that's worse than either of the other 2 options. Maybe there's a fourth code arrangement in your head that does all this in = a way you find less intrusive and I just don't see it. If so, feel free to se= nd a patch I can review. It'll be faster for the both of us. Or tell me precis= ely what's at fault here. If it's the diff, I'll go for option (1) above. I don't care enough about i= t to argue. > so please do just that, nothing else that isn't > explicitly justified (like the moving of hvm_emulate_init_once() is). I'm not sure if you're fine with that motion because it's in the commit mes= sage or not because it's a refactor that shouldn't be in the patch. This stateme= nt can be read either way. > With > this put back in its original shape (can do while committing, I suppose): > Reviewed-by: Jan Beulich I don't think it's very obvious what you mean to do on commit, so it wouldn= 't be appropriate to agree to your adjustments, seeing how I just don't know what= they are. I'm happy to send a v4.5 on this particular patch with whatever else n= eeds modifying. Or a full v5 even. Or review whatever you wish to send as a v4.5= of this patch. Your pick. >> + reinject: > > I'm inclined to suggest to indent this the same as the case labels. I didn't notice the extra statement in CODING_STYLE for labels inside switc= hes. I tend to do that myself, but thought it wasn't in Xen's style. Sounds good then. Cheers, Alejandro From xen-devel-bounces@lists.xenproject.org Wed Mar 11 18:48:44 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 18:48:44 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251477.1548576 (Exim 4.92) (envelope-from ) id 1w0Obm-0004nI-NP; Wed, 11 Mar 2026 18:48:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251477.1548576; Wed, 11 Mar 2026 18: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 ) id 1w0Obm-0004nB-JS; Wed, 11 Mar 2026 18:48:38 +0000 Received: by outflank-mailman (input) for mailman id 1251477; Wed, 11 Mar 2026 18:48:37 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Obl-0004n5-3G for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 18:48:37 +0000 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazlp17011000f.outbound.protection.outlook.com [2a01:111:f403:c100::f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e5e39128-1d7a-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 19:48:31 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7926.namprd03.prod.outlook.com (2603:10b6:806:432::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.12; Wed, 11 Mar 2026 18:48:21 +0000 Received: from CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37]) by CH8PR03MB8275.namprd03.prod.outlook.com ([fe80::a70d:dc32:bba8:ce37%6]) with mapi id 15.20.9700.010; Wed, 11 Mar 2026 18:48:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: e5e39128-1d7a-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=iW6QCKyQPPl4wDwxqNkDR/tUqdnSfKa/mxraQ0uAYsllS4jTpDUph5uvHQixSdcHcU7X7EaotqeMm6f8x4kJgKOq+PcC3nIxJKfTYpk/JrJ3dI61a4aocfm09b8vwdMw4/KivuRlBafXIJf70sTRP7FT9YdrNpBl/77368SsKqh9QJs8+HHvxfiePhuX4Vl5efmbghJIdf4OUxPklSypoSouBz9EDlumdtxR9sUNmV4JshJ+4PezwpIfpHVHg4d16DkRoG3jGNPtiSea9LjXT6nGfroENDS6toNaAGztC6XYuXd2aIyLEWZtlmQTPr9zrd0moiC/dpQeQD2i82Skiw== 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=6NGDs+BRyn7XweAWMRpwVKPpBX19IbRMJ8dz2ljzaz4=; b=psMPgWnzyHD6hIWQiyhyt/nDG5JZuSW47mEtUKZbwzkJ/p+WPpgbs+k+PDjChmEErn6rQvyMg2iEPNhJFa6ca0kOBomy/jG5r49ZVRG+ORQQ7sSm9Zy/QGGd6+3L32/qSSO2Zkn9x4QZtzg3DsYWbGhnG890UJpOHNSbyMmW/gLU+dNMVzOg6BcQ7HPN3zfD+HeAuL41DOc/vKAPK2lGod84Eunst7oGA/UcVVIFH/NjKgdNgNA6VhQjA5Id5sj5I8Zh5e88yakcLUiRt/4Leq6IUsDM/7NuWJcNiDyAWv/x4dG+tQ8Xep2Q/tBnsKJAAbNe2DXva6JmduFoeocneA== 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=6NGDs+BRyn7XweAWMRpwVKPpBX19IbRMJ8dz2ljzaz4=; b=BCF7W1L+s1Z3VK3PT8VGH7Wc/Z/wjbbLU59H7Uy5OAeqLN08ILqAfsTEKiaJgOJUXN9W7oBHhEQ82oJ7Ki2zfyvZ+CoPGrg4WZvP9z75yDIOIa2L9Ah7/DpoTjP53UfbwQhJXCsnz/FmPlrFuN39/Z5Wcy62ddxt1YlWt2fRBEc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <3a4359c6-ac49-4920-be28-c71cf911ff9c@citrix.com> Date: Wed, 11 Mar 2026 18:48:20 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk Subject: Re: [PATCH v4 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-3-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260311142711.16754-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0416.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::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_|SA6PR03MB7926:EE_ X-MS-Office365-Filtering-Correlation-Id: 7b4289ff-560d-485c-daa1-08de7f9ec66e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: oFA2M7iYkuM1Z4c4Z2OmgFZVfOzB87SvVO3zLYyjtlMjq6wYhgujtOuSke3yGrR6nYOm9xpnZ6Fvi2JvkPwIHWUDSroQm3oZ8AYnWKB+CE0bGZ0gJPHN0BtxFRfmIzP6jduB7e88bBj2nhwT6ELhlUXRoC5lT/nTRPlkeT+gbOVumFvio2d86gMRthYXivaXKoa8lwwEE+C6JDPVIN9p0blNF9BGh6NLHv+F80/tbrW8sEKoBWw0O6Lmg5Wq4tP8SDE36mXMS7Uog2aEHm2ENwysPCjWKGvSu+QIsfGCihwcltefURmqkYiix4pZGVYvuGTggAi4x6vkM6U9Gx3oI61MpeJ1FCE91Hqchln95xJYbPoi8JywpbPcsUf3sbzOQTaOSicGGB5WbiFWc0+V0IIBvprmZZb9RWTZykUuDLqcfc6J6kcWeDicRjuNoP1sVWJUaS1k9YGvDuHzdQ9PK1M8JezI2Gs6joDvoGPigJrrihwBgJ8jPOgV3F+F/ozq+xYntuXbEdMl8iWlZKD1cie2svjyDrUFcuEo0hG5eWzKapNjA94/NIlJsHfxkMktDLHPiY1BB8Ly3rzII9/WRqw0sMvRq5s3gPmDCxmUA0PrKIMkTCJsqjFJ9UkdTVGiwn0Bj96PbMucY3enWS2i0aF4t1uf1o24eXAV4bqHQkfKlNMsJ+qfmVJwOcT6zMZOymp0Aa5Ehfsle4kgbfBgFMzSKstGXml87UDnqldI6PI= 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)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEs3ZCtrMTQydGpQaDNraHlkbGVITzR4aEhIM3JiNTB1c3ltQ3Y4V0Y4Tllq?= =?utf-8?B?SlVhVzgwWkRIMFNndTcraXpLWFJ2V2kzaXlZeXVXZUJ6MTBQcW1rTGlQbWc2?= =?utf-8?B?d1g5b2Q5ZDBCZTM1bjU3TFc1QjhudUExNkRPd1ZKZkkyeHhjbzJPZVF3eGtS?= =?utf-8?B?TDYvNHhKR2JvVUZlYVVvMDVjd3pWQW1xaStHcHBUOEdjTWZlcng1dGduRjdt?= =?utf-8?B?NXhYNkVISkJxMCt3ZWg0MnFsREE4c0tqdHJRT0xBODhuTDhVb1N1aWxSSjVN?= =?utf-8?B?eHQ4TjJVVFB0YnFTbVJiMUJXUHp2MnI2SEU5bjVYSG1ZUXhRZ016eGpRNFZ1?= =?utf-8?B?a1FlR0JZOTN1WGhSdndxTjd4RnNIZ2U3MStXSHV3TGtzZjk0aklITTB6ZEpL?= =?utf-8?B?S2NpaTg2SEF5MXRISGJ4WmdxWGRVTGdJM0hldi80dDNrWlRxWUZDZVEveUVC?= =?utf-8?B?K3o3UjFsdFNIdkRteTZ0ZkIzdVhGM3JsMEtzR1VYTS9XRXRjd2wwWUdLb1VB?= =?utf-8?B?cnFOTWZiV3NrSGN6LzkyYnVubi9PYzY3cE01UVhORFVPb0dpbTFJTysxMW8z?= =?utf-8?B?eXZSREJGd3AzQXNXVXV3bUE3d2pxY3FDRHpNK3VmbkZBekJyR2dBYXZrRWZN?= =?utf-8?B?dzZESzBYektaa01TMVBFeEc0cjVYYXpNVkFiTXlpWlY3eUJ4bVNxSTRRbmhJ?= =?utf-8?B?TnZ0UTBaS3M2OGZSRFJFWjZrWVdoRnBYSW9KZnRRRCtsSkwrNXpKL3JJcEc3?= =?utf-8?B?bFAvTld1dzY1UlJ4dnMxc0ozM1d3ZVQwMGY3VGZFcjJYcXN4M2ZRdzFDTW91?= =?utf-8?B?d2l1UWVyNWVhM3I0QWlBdWJQUUhKLzAxS0J6WkRPc0xwYk9mMTlTdXFKL3U5?= =?utf-8?B?OVVPZlNCMUNybXRyaDZNc2VwN1hXajRGSXpxZVFsWHdFaWJFVGNPMzc1YkMw?= =?utf-8?B?V3dDUjdnVzZ5aGlkTDFmcWl6aFVWRUk3OSt6SjRxbGhPd0pxZWJEcktlZGJK?= =?utf-8?B?N2hXSHF6Wng4UDBmOGZvUEZDTG41aUZZN2IvR3FYNXgyOWMrOFhuUWdnR2NT?= =?utf-8?B?dWNBc1puWldESnk2SGFHdXpsNTdwaXlWMU1tRE1zbVZYWFNrVE1HVUQ4eXMx?= =?utf-8?B?REZtcUxtdUU4NnppelA5dlk2MzFlczJiWk5waTh6Z0FZQTk2Z3RHcXU2eURF?= =?utf-8?B?UlNMMG9xOFZLNGVRRUEyNkhSakVjdElRajVUTWpPZUpKRHM5dzlLbllnNEVZ?= =?utf-8?B?SVJiODlrN2lqQTluYmIyOUMzcDh1YWtERVNFT3oxNERzeFViVzdQcFBPbUQ4?= =?utf-8?B?MmVFTUw1RndaMlhHTFNQdW5QV3VkeXpNeDBTdlVKUDJxbnIrSHB0U3lQTnFX?= =?utf-8?B?dUROMGl6V2VzRmMzNVhXblRSN0ViK0Y5WjJ0Qk01OUJiWVNVejdBa25aWjFW?= =?utf-8?B?TEV3WnNQQ1M2WWtiM05Gdy9OQUdhaFZhNHpxd3F5SG1yeERWaGVzQXFsRVRw?= =?utf-8?B?L0lKdHZTbmhyMnZXV0lhZy9sTE53QzIySVBzZlNWL0s2S3lOVlJvNE9oM1JT?= =?utf-8?B?clBua29RZy92TGxRc1Y1TGxvU3NKZEFncElkS20rZXJHdnRwSGZyRFVlZWY2?= =?utf-8?B?NEFpQnVkWUI0Nm05L2VsTUt2cnpSdVU3R2JVUXd4U1g0UnlXOE9Cc09kMTNV?= =?utf-8?B?QzMwREE5aDlMQStjVXMvQ1B0ZjM0M09pZGRXdXFIdmo2ZXpHT3NOTG5ic2pO?= =?utf-8?B?am9OV0tPcnY0NnVsTG9PNnFzc1BUV0RvVnFNYVJWc084UlFDSE9qaFYrOE1U?= =?utf-8?B?ay9XNkp3WFlybWJQeFlTaE9ValVYQTh2ek1yeXpQZ0RsMExtcVFRTWVJWUUx?= =?utf-8?B?NzM0WHB4Q00wSDUyMFV1ZmJXU2ViaXhQYU9wSGJ4VmZuT1FZSEhGUzgxZWJj?= =?utf-8?B?a1luKzF0bGxjT3F5aGhpa0JHNkVJSTRGOXVLWUowWHJOaFVocWNOS1NlaVky?= =?utf-8?B?bW1qQytiZzNtTERUWDJwVVltMDRtWis0Q2F1TkQ1ZnYwNlBOYy8xeHpsQmQx?= =?utf-8?B?WG1RUmZIL2RDU0ZldktJczZjREZXWHQzTU9GVktZRGhKL0hzL1NvQUxvb1ov?= =?utf-8?B?TXZsZE9mTHFPUUY1TFJaNGE1ME45MjJuT3FELzhlY1ZEZzdwV2NGWkR4ajlx?= =?utf-8?B?MG5SdWsyVklvcmQ3VnFENC8ydWVSeVIxY0hqbklJWVZYRGhnVnc5YVlVNmFm?= =?utf-8?B?SldlS3FrOXF0cUt6R2xPaHpPbTB0U2plYm5lYjhEZC9tQS9GWGdxYlZlMVdq?= =?utf-8?B?dmkvVE05SmJIZEg4OGp2eTcvZTJoTiszV1NmSTRXemNzbmdRRzBnZz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4289ff-560d-485c-daa1-08de7f9ec66e X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 18:48:24.4716 (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: pBRKDWPn5pM3fgNaI2xjM5DKXvanragcR873aYVYavNggl5MDfCAQFx1qu9bpm53drDiW8bVvct7Ngs+GjdgddJAHlDSaSEgFvvI2npE4ac= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7926 On 11/03/2026 2:27 pm, Alejandro Vallejo wrote: > Remove cross-vendor support now that VMs can no longer have a different > vendor than the host. > > While at it, refactor the function to exit early and skip initialising > the emulation context when FEP is not enabled. These two things are at odds.  Two patches please. The first which strips out is_cross_vendor() and initialises should_emulate to false, to be this patch in conjunction with the changes for the UD intercept. Then a subsequent patch to rearrange hvm_ud_intercept() to DCE some more in the !FEP case, which is no-functional-change. In fact, I've got half a mind to suggest 3 patches, with the middle patch being a strict un-indent of the the current "if ( FEP )" clause.  I think that will make a very a surprisingly legible patch 3. The result will be much more coherent for future archaeologists to follow. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Mar 11 18:54:47 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 11 Mar 2026 18:54:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251490.1548584 (Exim 4.92) (envelope-from ) id 1w0Ohe-0006P0-Ee; Wed, 11 Mar 2026 18:54:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251490.1548584; Wed, 11 Mar 2026 18:54:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Ohe-0006Ot-Bu; Wed, 11 Mar 2026 18:54:42 +0000 Received: by outflank-mailman (input) for mailman id 1251490; Wed, 11 Mar 2026 18:54:41 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0Ohd-0006Ol-66 for xen-devel@lists.xenproject.org; Wed, 11 Mar 2026 18:54:41 +0000 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azlp170100009.outbound.protection.outlook.com [2a01:111:f403:c107::9]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bfbbdc6c-1d7b-11f1-9ccf-f158ae23cfc8; Wed, 11 Mar 2026 19:54:39 +0100 (CET) Received: from CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) by SA6PR03MB7926.namprd03.prod.outlook.com (2603:10b6:806:432::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.12; Wed, 11 Mar 2026 18:54: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%6]) with mapi id 15.20.9700.010; Wed, 11 Mar 2026 18:54:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bfbbdc6c-1d7b-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Gukzsx572hw2WV7mm2OPjjq//cbq6aOXnXEZuR91hEsg1tHCg3g0Ussh4RQQs2awuiwm9iJOjFRmNBZCSSOwTyN6bNyblI1BbwwO2gnDJsq6PpbGBhqeQxgNoRXXcjLdgdGbBVCliP/pKKOk8785sCnV8bl1mPQ2+4oYXPxNHUJzpMUUxgDb/SDY7UYhUQ1UkUZ2TeoaKPHWOK9lB541oWphFDHlmMNWjUZvMXCsEBmP3YCC0jmet/7GjXPAHUJRDFPZQop9dKmsKRvx7f9PzEiIw30+LfiQ7E3D+0bB53kNtDKVJ4ESXau0Q4dS3Ma+3zJILH+RUE8SFuSQl9ja6g== 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=rjJi2ByH8oxh/HkmazPoTciK0z2uwOsP+ggzCjCvvsE=; b=isBIf7Jhr26bkQlMoyAemBFoYA5RMy+PPFWpoOh45rKHzq2pCu/gEXYzirCsCYoY8LJgmk8hqpm9Gy5zeZ4/N6WfuZ6Fi3HJrqIgxlIOHADg+dzbECku/M08JIJKJeZrKT2xARIo2AFlKR9Y1zO0KMMqvMZtQ0HUAs1Dy8JSXNk1m2Y1V4X1iAQPmRhWjGi00R9O9IBvsKnQ+0xUfnkENDrA2iu2fZoPHsdtj5WHA6SgRItNVmE4zaq46XfWV8R/E/eiCrzucM/0PLDieen46r6XS6lOY3yd/71pvfSqpivIr9+vo+VYC7Mdyi1RZnu9Gpd+CsocJ6E60Htu41isFw== 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=rjJi2ByH8oxh/HkmazPoTciK0z2uwOsP+ggzCjCvvsE=; b=0pm/XQnJrt7IxJIKMeIuBXqnMMFBxNOaMGcw67UA4UrceJ1Ct2NgtYH5m+zBSgijukHRKnqRcIvy3tcDmGmEWN3C5lSxoZC3uRvCI3i1hh0kOp1hR1T+PwDlR2/FRpi58n4MJck2uiCbR6rnVArW7mer3w+QAKjFMQZBu9R7uj4= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Message-ID: <22bbe514-b1d5-4928-a35c-c5c61f26602f@citrix.com> Date: Wed, 11 Mar 2026 18:54:28 +0000 User-Agent: Mozilla Thunderbird Cc: Andrew Cooper , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: Re: [PATCH v4 4/4] x86/svm: Drop emulation of Intel's SYSENTER behaviour on AMD systems To: Alejandro Vallejo , xen-devel@lists.xenproject.org References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-5-alejandro.garciavallejo@amd.com> Content-Language: en-GB From: Andrew Cooper In-Reply-To: <20260311142711.16754-5-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: PA7P264CA0432.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:37d::29) To CH8PR03MB8275.namprd03.prod.outlook.com (2603:10b6:610:2b9::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH8PR03MB8275:EE_|SA6PR03MB7926:EE_ X-MS-Office365-Filtering-Correlation-Id: ebefb891-084b-4e6d-26bd-08de7f9fa254 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 6oqaxYBlv33ndgItnr6ecyisnE9ysIRNciNvhw+ss7EXdI9dwICHmfBpB490Gc9dkCdNFz71OqEC93Dw/+CYrT9GKnKCOUJs8S5WBRWGg0IczgKohj9sk0dY/60bWOfFtxDBjB7O+1S+YVfaRUa96lrD6I8WQ/itcNxx8s1YxtHtUR0Q78degD7Qj+Rzg1dKvynWJJocvpFkzQJ+cXZWE5IgZ9TYj+zdmpcErP3Q5kf1NmGM29SZGFhfZBTivTfpP/6pXflnMquQOppJ10bHs/yqqqmVXxizX66EP/DKlhe9tyTLhtHhOy5O8KWgo9JN0RS1t+5TCaKmVb7Jet3xCOOq8BEpNjyGGtUWeHZYWHdchj0H/jKFn9ptlSAXqoRICbdES8oCuEvI2oXgO+/bZsXebVQb3oKgfEwz8aproqc34UVdG4AGT7SPs58Zi90iqja9JxZg8DflNUyMlgmgeJ4lGYVUAU1UOwbevtugpXT2HjhC82oIBhC8CMzsHXAOfNbNDgMKG8Kw4En/v33N66dQ0rVi6fotwm8+Nf3kQIIacXp64WPDDcg+q0bQ27UjkTAFBnd78qJKgjT2q5x97LeQUGCz12Kt13s/y1K/wCjvn4iGPCNI9brjbEfYeQK+51inqgMzAqmoaPSpd+qcy4QZ0+IW5vYwbtKGkjOmtD5/N1tkAEJuIfqf6LEHqBdudIUOpCr3Jy9vB4f++l1Zt0ttFJpj4PJ+HpSmER6LCSY= 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)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dzJheHd5M1U3NE9OUHoxc0Y3SlI3ejFUak9hbjBaQUxjS1hMRmVLcFlURnhh?= =?utf-8?B?RmFrR3diNXI1elZhU1Bsc2dLWURlYWIxdS9YdUJhTjBiaE9oalBubFZoVUp4?= =?utf-8?B?NjlOR1RVVzI3SUFWOXdueGlKSkJhUkIwSGlWSjVCYlVMR3RMRXpheUFwZTI4?= =?utf-8?B?cThZbFZrdTV3RnVZdVpGeHNScVU1TkZyUDYzaEI0Z2N4VmViVEtkZ3c1Vzhr?= =?utf-8?B?WGZjNGN6TDNIcjNQOExwSm54ZWVGWTRGMEM1WURMdS9aSDFNV2ZJbGRqOHJz?= =?utf-8?B?SnEvaWxaMHpaT3dhOWlyb0VNeURWbWZjdDFJU2wxbXJyTFNIVE5jMkxuUmFO?= =?utf-8?B?Um9BQmR3cmZJcG1oNUxneEdQL21hcmhsLzZ4LzJqdE1wKzVNRlVvUlJkM3Mx?= =?utf-8?B?YzFVNjNSSWIrUzhWQlBkRlY1MnRqRWg5eVBnYzRyWW1nN3Y0akJpWXhHUGVU?= =?utf-8?B?UkROdDdEL1RtcjAvZ2c3NXJvNW9CVTVrQm92WjBGS3JGNnNvTHUvb2w5bXNu?= =?utf-8?B?OVdDaFBwbyt6VWc2TGV2SzA5cnJkQlhlelM4ajdXcFlqVkZQZTRPcURFejBI?= =?utf-8?B?emdpMDdXdk5jVDNMdzROcG1vZjcrN2dGSit5bWtWTW0zdXNBM2h4S2RuWVRY?= =?utf-8?B?aXplRDhMa3RWc3pDeGZ6K2FCUnNjU3JXeWRNK0tSdC9QUDI3clBhTUV1WDlK?= =?utf-8?B?Qm1rS29KQS9SdHdkUklPeDM3TEg4OE53Nno4Vk5JZVc5enBJSnN6U3NvS1A5?= =?utf-8?B?MkFQZlU2MWI2N04xei9RNUJ5Y2d1ZG1vWlllcVVlSjlUMGRHQXRzcGxUZSt1?= =?utf-8?B?OTI3MlFYZEo5ZThIcTFiOFNZd0JndUo2L0QyRytCWkJiMmZSbm9XbnRrOWEw?= =?utf-8?B?VDdncXJ0U0dlYktqWm53ZlNsd0p6WmpwdnYxajlxR2RWb3FlUDdBVmVHeitR?= =?utf-8?B?N0o2NHRJc3ozbjFPV2w2VjRWRm1yRWNsYStCc0VRb3JKMjZMVVFIS2ZSNm84?= =?utf-8?B?OVRQYzZ0NUNPRVpuVkllV0JFNldpK3JwczRoeHZxdHVQbUdMVnJXL3NvZHY4?= =?utf-8?B?d2ZJTEloUXVyZWQvZWxERTdTVUF6R3JHMU96Mm1SOFE2RWhHSWM0MDdxOUZs?= =?utf-8?B?U3o3cFRmWnI3ZDhybllGUUp3TTRZZ0hmcGJ4bzV5Wk5nK1FmQ09ybml5UHVq?= =?utf-8?B?cUh5U0JPOUc0STJJRUp2UERhdjBKUUNFbUk3Wm1BY21valhKays4V2Nzamd3?= =?utf-8?B?NEF3SXNZVzl1eVd6am05Ymg5T2EvZTlrdzYvbEhrOVJMMmJMc3hWVGk2OTJr?= =?utf-8?B?NGViQVFNTmlYQnNLWFE3WFhGNkx0LzFzdklFQXg4eHpLbGZPN1VNNHJWK2N5?= =?utf-8?B?OGI1YzBIT0JHS0tIYWJ5TDhnaXZzRmpydW1zMklvb2J4NUFvaXpibjZRWWFn?= =?utf-8?B?dXRvMmpnNGY1UkhFbms2UFBOa2pDelROOXdQVTNRUjNhZ3Q4Q2xRNTBrOVln?= =?utf-8?B?YUw2WHFuMkpjRTMya1ltYWd2dHhpUXBQTHFXMlUzUEFIUk90WERpNjg2QTRK?= =?utf-8?B?OGpxU09vdllYSG1ySEFvNi9JUHJLVmV6QjF4L0wzMmE3MkxWdDhYWTZiM1dr?= =?utf-8?B?d3lDazFTWGpKRnJ3dHptRjJzc0s4VkZQNUtiQjRYWlRCdXpZQ0drRThOcjAr?= =?utf-8?B?OWZ0WXJnTk9RUjFFMXhjQmtURHN1M25PdXlWQWU3RmhHZWJlQkd2NHplQ2cz?= =?utf-8?B?dmdNVFdFZ2lMdTJEbytVWm5rcExJRmZtYUNyQ2pVZmlpU1hEN1JWV1l0ZVR2?= =?utf-8?B?eEt0SUJUVFhOZ1JNNW5WZS80ME8xZ0t3YXRZMHArK285dnNxODhWNHpwNHRH?= =?utf-8?B?dXVsS1JqUjVtWkdHVXEzMmRrdnZEZHZENE9KcGpmRXBHTVJHWVp0OEg5ZXFV?= =?utf-8?B?R2dRVkZFK0ZXNmdSZk54QW9nSW42NUR3TnR4SHF2eXl6TVgwbTZRajlSdXdO?= =?utf-8?B?L3VyVXhkakpEUEtHMWt0UkRaRGI1ZFpNWGcydkdjL3Vmc0kxWGp4WmJFcUli?= =?utf-8?B?dkowNG44VzZEK2NrSmhVdlh2SzJ5R0c4QUhQVHVGejc5SGp1TStwM3ZvM2xH?= =?utf-8?B?YnMrOE1rdk0vc2kxRmtpcGk3c3dsU25ieWF1NkVsMUNWQzRkYmhiaDYxQTc3?= =?utf-8?B?NWVNQ0ZBTnRxWGpHQzhYUkorWWlJYUZSdFRnMW1Vd0lNTjRwdkhEb0FDWnVn?= =?utf-8?B?T0h5ZzBlODNhR3MzTkdEbW1BTjVsa3NMQkRrMmtjRlhPbnQ4c2w4SUxaaitt?= =?utf-8?B?bnRlK3ptV3hFNE5rWWFvZkthZVBZUVZOTm9CazEvdWdocVdxbkVaUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebefb891-084b-4e6d-26bd-08de7f9fa254 X-MS-Exchange-CrossTenant-AuthSource: CH8PR03MB8275.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2026 18:54:33.3856 (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: OJ69ce2deqm9TVOZjK591IpSHFudGLkmtN5v2PYTdS3iDLKbNOlc0tbJG9gDyE7rE21Z0LHjzFdyQg3xrSMtSPIS5lCqema7PSI7e3qE9m4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA6PR03MB7926 In the subject, you need to say "SYSENTER MSR behaviour". To counter it getting even longer, the "on AMD systems" is reductant with the "x86/svm" prefix and can be dropped. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Mar 12 06:58:02 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 06:58:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251714.1548599 (Exim 4.92) (envelope-from ) id 1w0ZzN-0002Xb-0q; Thu, 12 Mar 2026 06:57:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251714.1548599; Thu, 12 Mar 2026 06:57:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0ZzM-0002XT-SH; Thu, 12 Mar 2026 06:57:44 +0000 Received: by outflank-mailman (input) for mailman id 1251714; Thu, 12 Mar 2026 06:57:44 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0ZzM-0002XN-2J for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 06:57:44 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id bfcb0dd5-1de0-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 07:57:36 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4853f2826f7so5422925e9.1 for ; Wed, 11 Mar 2026 23:57: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-439fe19aec5sm5513192f8f.4.2026.03.11.23.57.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Mar 2026 23:57:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: bfcb0dd5-1de0-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773298655; x=1773903455; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=4JY9BJ/9d+xdQsZgGB46qGlBtAWUT1DQpKWqvJ5veII=; b=S6cj5je2C1HRdv6gqCUhczAWvBck+iECUVaYYm82OdvHLXWSR7HkfPATOGGRE/zrit cbulWD2G1L0v/a5l9vLoUyF4FdujovZw9ez2p54aQRSLUBYFgGYLkLsJHMqFVbLgW0yx 01D1Hl2zeEd3IP95zqF27oIqBSig49ENPrYNJGQ0b8dfSNJ0BY7TibZjAAmPtyK9M7YJ OtzSdmYA/TxHtFJwE5TTuDGrH/3n6XUWpbnCHq54wOnIGPLBewmZkXg+sSB2lKdZBXoC CsC7CtWeoHb+z7iDNdVCu0hNc5eO+xnSUo+x7zFAiElHUjP22WktoGrDTGaWYloZl6LM b6dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773298655; x=1773903455; h=content-transfer-encoding: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; bh=4JY9BJ/9d+xdQsZgGB46qGlBtAWUT1DQpKWqvJ5veII=; b=vUxAFG0VtE0Lepx2gi+gqv6f3AaZSQ+qEtHQ8K4uV4mOyXbShxMQ72bikyJxMkx/j4 kN3nXRm2W6mzSiVwKDDb7r3FnUTmDmL13UGC92tPogbpbqXY42bwMvkj7hWU8gpPzC7/ gRWo69/QNgfBYkf7tOS7GXOagasa4o+ome093EpPtd0pcfqcD4zQgv3cFLYW9FnzotKc cnTQ/WGnHa6xqMCN/R10SQcbpSxnQCnuxjyQxH+W8u107iLYIBgNMN2rl98KwOyQHoLI uGSpt1PUbuUe59CikAep8mNFnISg1N6Ht9sA4FQgmtLmiXDxhXZZ8u3vAayrDL2GUy7u nvvA== X-Forwarded-Encrypted: i=1; AJvYcCWi8vxpLb8gMTvBuUtksjHbA9ABncPfex/us9cjJMGuk6R75WTuXAJn42cBf0FX4XNcxViaPMBy7T4=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywt9X0g+mRj1qqsLMyZJ7gSEpEpe2gqqqChFfCevXodQkgcpia9 KojaKFJuihMmSfL8IuaTfo+0Il196sjSDdppSmnGzN8Yq1pw1wSmix3sf41qee4qnA== X-Gm-Gg: ATEYQzz708B/jM6UTNM6HkmNRMJPYZDBI2QuarsLc0EjD4bntOQIYIzfqygK0QXiKWo 6/I+XGprIuqf9Bta8cS9SIEpitsA2/TFXI7bUZKJ32mZ3Lzq0nq888g6skcEsytWQLV9CazyrDx Y4VFgSDsAcRgbm9GCEqNHD/P5ag20XJae2ysBnMbRd+0R9knHakl4nyrOR2C5xyv4N+8cALfLX/ WFUM5Y7urfVwokA45GGtxGRSs/G4Xxpjhl4wu4Ne4XURNjEavOf+CHylFtlNNzmhQ3Ce9ibqP2e 3qVAkAcuFwGa2vdAaIDTMnid5ejLJIea1YXrNhl5rlFfwc1YgHVcvLN5gqa6pyCCWqihYDN3tce 9tkTEeogPbXKSK8c8atpzmM2OCABkavO5xwNuPPy+v+fw4wWyWHLw+G+ek45Yd/+ftnrKd9K+gt 6EsgtolVBk9m2xX3I23gXdbaXHJHdgp9NQzHab7ePha9w1JdTG7i8u/ue2Ji1Mmu6ZMPm2z/2+x m3LcmfiS3wnIYJZ+jffp447ZQ== X-Received: by 2002:a05:600c:3b16:b0:485:4535:73d with SMTP id 5b1f17b1804b1-4854b0a4920mr92305895e9.2.1773298654758; Wed, 11 Mar 2026 23:57:34 -0700 (PDT) Message-ID: <536b659b-1eb8-4bc7-980b-35c1ad6922d0@suse.com> Date: Thu, 12 Mar 2026 07:57:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/4] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260311142711.16754-1-alejandro.garciavallejo@amd.com> <20260311142711.16754-3-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 19:01, Alejandro Vallejo wrote: > On Wed Mar 11, 2026 at 3:59 PM CET, Jan Beulich wrote: >> On 11.03.2026 15:27, Alejandro Vallejo wrote: >>> Remove cross-vendor support now that VMs can no longer have a different >>> vendor than the host. >>> >>> While at it, refactor the function to exit early and skip initialising >>> the emulation context when FEP is not enabled. >>> >>> No functional change intended. >>> >>> Signed-off-by: Alejandro Vallejo >>> --- >>> v4: >>> * Reverted refactor of the `walk` variable assignment >> >> "Revert" as in "move it even farther away from the original". > > Revert as in not split the assignment and restore the orignal syntax _of the > assignment_, which was the main focus of the prior discussion. > > It's hardly my intention to add unrequested changes, but I can't address that > which isn't explicitly requested. > >> As said, you want re-indentation, > > This is an ambiguous piece of advice. > > Of what? That can mean moving the prior logic back to its original location and > crate a minimal diff (1) or simply collapsing the indentation of the block (2). > > (1) can't be done with hvm context initialiser moving after the early exit, > which I explicitly mentioned in the commit message I wanted to do. > > (2) can't happen because declarations and statements cannot be mixed (though I > really wish we dropped that rule). > > There's a third option of keeping a silly { ... } around just for indentation > purposes, but that's worse than either of the other 2 options. > > Maybe there's a fourth code arrangement in your head that does all this in a > way you find less intrusive and I just don't see it. If so, feel free to send > a patch I can review. It'll be faster for the both of us. Or tell me precisely > what's at fault here. > > If it's the diff, I'll go for option (1) above. I don't care enough about it to > argue. > >> so please do just that, nothing else that isn't >> explicitly justified (like the moving of hvm_emulate_init_once() is). > > I'm not sure if you're fine with that motion because it's in the commit message > or not because it's a refactor that shouldn't be in the patch. This statement > can be read either way. You justify that movement in the description, and I agree with that justification. >> With >> this put back in its original shape (can do while committing, I suppose): >> Reviewed-by: Jan Beulich > > I don't think it's very obvious what you mean to do on commit, so it wouldn't be > appropriate to agree to your adjustments, seeing how I just don't know what they > are. I'm happy to send a v4.5 on this particular patch with whatever else needs > modifying. Or a full v5 even. Or review whatever you wish to send as a v4.5 of > this patch. The variable had an initializer, and mere re-indentation wants to keep it so. (There's no question that declarations may need to move, for the result to still compile.) Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 07:23:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 07:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251725.1548612 (Exim 4.92) (envelope-from ) id 1w0aON-0006Mc-W4; Thu, 12 Mar 2026 07:23:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251725.1548612; Thu, 12 Mar 2026 07:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aON-0006LO-QX; Thu, 12 Mar 2026 07:23:35 +0000 Received: by outflank-mailman (input) for mailman id 1251725; Thu, 12 Mar 2026 07:23:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aOM-0006Jf-LN for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 07:23:34 +0000 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5e0c6a8d-1de4-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 08:23:32 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.140]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4fWf8m0KGKzcb2t; Thu, 12 Mar 2026 15:18:00 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 059382025F; Thu, 12 Mar 2026 15:23:28 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 15:23:26 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5e0c6a8d-1de4-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=jAGDg23Jh/R/fMlBCmfhZTnUH5xG89AkPnX8VI3PuSc=; b=RZuHUqv6BgF0qFidhU7XyV96mfaXB8HmU+gF/dxnCky1vEzSjWha4fDbKoycbuQDQvVxDdSvD F3ZRjdtTrzq0aMjyOfLURpFQuaD9wO3MVCZ6p1jSi4feVktW9fyKpxdOUQJLnFp1kyELp/UmvPE wMvodw5e+OYblCFU1fhzvXk= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v6 2/3] x86: Implement acpi_get_cpu_uid() Date: Thu, 12 Mar 2026 15:23:15 +0800 Message-ID: <20260312072316.4806-3-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260312072316.4806-1-fengchengwen@huawei.com> References: <20260312072316.4806-1-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemk500009.china.huawei.com (7.202.194.94) Add acpi_get_cpu_uid() implementation for x86, replacing the existing cpu_acpi_id() function. This completes the unified ACPI Processor UID retrieval interface across all ACPI-enabled architectures. Cc: stable@vger.kernel.org Signed-off-by: Chengwen Feng --- arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 1 - arch/x86/kernel/cpu/common.c | 15 +++++++++++++++ arch/x86/xen/enlighten_hvm.c | 5 +++-- include/linux/acpi.h | 2 -- 5 files changed, 18 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h index ad235dda1ded..57a0786dfd75 100644 --- a/arch/x86/include/asm/cpu.h +++ b/arch/x86/include/asm/cpu.h @@ -11,7 +11,6 @@ #ifndef CONFIG_SMP #define cpu_physical_id(cpu) boot_cpu_physical_apicid -#define cpu_acpi_id(cpu) 0 #endif /* CONFIG_SMP */ #ifdef CONFIG_HOTPLUG_CPU diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 84951572ab81..05d1d479b4cf 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -130,7 +130,6 @@ __visible void smp_call_function_interrupt(struct pt_regs *regs); __visible void smp_call_function_single_interrupt(struct pt_regs *r); #define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu) -#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu) /* * This function is needed by all SMP systems. It must _always_ be valid diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 1c3261cae40c..3081557542c7 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include @@ -57,6 +58,7 @@ #include #include #include +#include #include #include #include @@ -2643,3 +2645,16 @@ void __init arch_cpu_finalize_init(void) */ mem_encrypt_init(); } + +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) +{ + if (cpu >= nr_cpu_ids) + return -EINVAL; +#ifndef CONFIG_SMP + *uid = 0; +#else + *uid = per_cpu(x86_cpu_to_acpiid, cpu); +#endif + return 0; +} +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c index fe57ff85d004..2f9fa27e5a3c 100644 --- a/arch/x86/xen/enlighten_hvm.c +++ b/arch/x86/xen/enlighten_hvm.c @@ -151,6 +151,7 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs) static int xen_cpu_up_prepare_hvm(unsigned int cpu) { + u32 cpu_uid; int rc = 0; /* @@ -161,8 +162,8 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu) */ xen_uninit_lock_cpu(cpu); - if (cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) - per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu); + if (acpi_get_cpu_uid(cpu, &cpu_uid) == 0) + per_cpu(xen_vcpu_id, cpu) = cpu_uid; else per_cpu(xen_vcpu_id, cpu) = cpu; xen_vcpu_setup(cpu); diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 035094a55f18..90a1fdcb7eb9 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -324,7 +324,6 @@ int acpi_unmap_cpu(int cpu); acpi_handle acpi_get_processor_handle(int cpu); -#ifndef CONFIG_X86 /* * acpi_get_cpu_uid() - Get ACPI Processor UID of a specified CPU from MADT table * @cpu: Logical CPU number (0-based) @@ -335,7 +334,6 @@ acpi_handle acpi_get_processor_handle(int cpu); * -ENODEV if the ACPI Processor UID for the specified CPU is not found. */ int acpi_get_cpu_uid(unsigned int cpu, u32 *uid); -#endif #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 07:23:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 07:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251727.1548631 (Exim 4.92) (envelope-from ) id 1w0aOP-0006nC-Ib; Thu, 12 Mar 2026 07:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251727.1548631; Thu, 12 Mar 2026 07:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aOP-0006mO-DF; Thu, 12 Mar 2026 07:23:37 +0000 Received: by outflank-mailman (input) for mailman id 1251727; Thu, 12 Mar 2026 07:23:36 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aOO-0006YM-Q0 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 07:23:36 +0000 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 5d3dc5cd-1de4-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 08:23:32 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4fWf9M0psyzRhQX; Thu, 12 Mar 2026 15:18:31 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 2D2B54056E; Thu, 12 Mar 2026 15:23:26 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 15:23:24 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d3dc5cd-1de4-11f1-9ccf-f158ae23cfc8 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=emV69WpU1M2zFss/hf94/6FIT7KCIgFkUPlPK9LbC5k=; b=j8tTia/xDFsmamQXC4xERo2SqnVDUL5uyF8l36854lADwIwF8uhGv4gi8EgWOIh1KVcCupZhN oo4UTdGEKneHxRKIcfRSdW19zQBfFIRRgZ5doELv/oYNecFkKbM+rJz6ds/oxOya5CDwjZ0tsSF 8V2T+RPOx1IMmKLnvqLMiz0= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v6 1/3] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86 Date: Thu, 12 Mar 2026 15:23:14 +0800 Message-ID: <20260312072316.4806-2-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260312072316.4806-1-fengchengwen@huawei.com> References: <20260312072316.4806-1-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemk500009.china.huawei.com (7.202.194.94) To unify the CPU ACPI ID retrieval interface across architectures, rename the existing get_acpi_id_for_cpu() function to acpi_get_cpu_uid() on arm64/riscv/loongarch platforms. This is a pure rename with no functional change, preparing for a consistent ACPI Processor UID retrieval interface across all ACPI-enabled platforms. Note: Move the ARM64-specific get_cpu_for_acpi_id() implementation to arch/arm64/kernel/acpi_numa.c to fix compilation errors from circular header dependencies introduced by the rename. Cc: stable@vger.kernel.org Signed-off-by: Chengwen Feng Reviewed-by: Jonathan Cameron --- arch/arm64/include/asm/acpi.h | 16 +--------- arch/arm64/kernel/acpi.c | 16 ++++++++++ arch/arm64/kernel/acpi_numa.c | 15 ++++++++++ arch/loongarch/include/asm/acpi.h | 5 ---- arch/loongarch/kernel/acpi.c | 9 ++++++ arch/riscv/include/asm/acpi.h | 4 --- arch/riscv/kernel/acpi.c | 16 ++++++++++ arch/riscv/kernel/acpi_numa.c | 8 +++-- drivers/acpi/pptt.c | 47 +++++++++++++++++++++--------- drivers/acpi/riscv/rhct.c | 7 ++++- drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++-- include/linux/acpi.h | 13 +++++++++ 12 files changed, 120 insertions(+), 42 deletions(-) diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index c07a58b96329..106a08556cbf 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -114,22 +114,8 @@ static inline bool acpi_has_cpu_in_madt(void) } struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu); -static inline u32 get_acpi_id_for_cpu(unsigned int cpu) -{ - return acpi_cpu_get_madt_gicc(cpu)->uid; -} - -static inline int get_cpu_for_acpi_id(u32 uid) -{ - int cpu; - - for (cpu = 0; cpu < nr_cpu_ids; cpu++) - if (acpi_cpu_get_madt_gicc(cpu) && - uid == get_acpi_id_for_cpu(cpu)) - return cpu; - return -EINVAL; -} +int get_cpu_for_acpi_id(u32 uid); static inline void arch_fix_phys_package_id(int num, u32 slot) { } void __init acpi_init_cpus(void); diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index af90128cfed5..984a11788265 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -458,3 +458,19 @@ int acpi_unmap_cpu(int cpu) } EXPORT_SYMBOL(acpi_unmap_cpu); #endif /* CONFIG_ACPI_HOTPLUG_CPU */ + +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) +{ + struct acpi_madt_generic_interrupt *gicc; + + if (cpu >= nr_cpu_ids) + return -EINVAL; + + gicc = acpi_cpu_get_madt_gicc(cpu); + if (gicc == NULL) + return -ENODEV; + + *uid = gicc->uid; + return 0; +} +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c index 2465f291c7e1..56e2e486e49b 100644 --- a/arch/arm64/kernel/acpi_numa.c +++ b/arch/arm64/kernel/acpi_numa.c @@ -34,6 +34,21 @@ int __init acpi_numa_get_nid(unsigned int cpu) return acpi_early_node_map[cpu]; } +int get_cpu_for_acpi_id(u32 uid) +{ + u32 cpu_uid; + int cpu; + int ret; + + for (cpu = 0; cpu < nr_cpu_ids; cpu++) { + ret = acpi_get_cpu_uid(cpu, &cpu_uid); + if (ret == 0 && uid == cpu_uid) + return cpu; + } + + return -EINVAL; +} + static int __init acpi_parse_gicc_pxm(union acpi_subtable_headers *header, const unsigned long end) { diff --git a/arch/loongarch/include/asm/acpi.h b/arch/loongarch/include/asm/acpi.h index 7376840fa9f7..eda9d4d0a493 100644 --- a/arch/loongarch/include/asm/acpi.h +++ b/arch/loongarch/include/asm/acpi.h @@ -40,11 +40,6 @@ extern struct acpi_madt_core_pic acpi_core_pic[MAX_CORE_PIC]; extern int __init parse_acpi_topology(void); -static inline u32 get_acpi_id_for_cpu(unsigned int cpu) -{ - return acpi_core_pic[cpu_logical_map(cpu)].processor_id; -} - #endif /* !CONFIG_ACPI */ #define ACPI_TABLE_UPGRADE_MAX_PHYS ARCH_LOW_ADDRESS_LIMIT diff --git a/arch/loongarch/kernel/acpi.c b/arch/loongarch/kernel/acpi.c index 1367ca759468..058f0dbe8e8f 100644 --- a/arch/loongarch/kernel/acpi.c +++ b/arch/loongarch/kernel/acpi.c @@ -385,3 +385,12 @@ int acpi_unmap_cpu(int cpu) EXPORT_SYMBOL(acpi_unmap_cpu); #endif /* CONFIG_ACPI_HOTPLUG_CPU */ + +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) +{ + if (cpu >= nr_cpu_ids) + return -EINVAL; + *uid = acpi_core_pic[cpu_logical_map(cpu)].processor_id; + return 0; +} +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h index 6e13695120bc..26ab37c171bc 100644 --- a/arch/riscv/include/asm/acpi.h +++ b/arch/riscv/include/asm/acpi.h @@ -61,10 +61,6 @@ static inline void arch_fix_phys_package_id(int num, u32 slot) { } void acpi_init_rintc_map(void); struct acpi_madt_rintc *acpi_cpu_get_madt_rintc(int cpu); -static inline u32 get_acpi_id_for_cpu(int cpu) -{ - return acpi_cpu_get_madt_rintc(cpu)->uid; -} int acpi_get_riscv_isa(struct acpi_table_header *table, unsigned int cpu, const char **isa); diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c index 71698ee11621..bde810d02c4f 100644 --- a/arch/riscv/kernel/acpi.c +++ b/arch/riscv/kernel/acpi.c @@ -337,3 +337,19 @@ int raw_pci_write(unsigned int domain, unsigned int bus, } #endif /* CONFIG_PCI */ + +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) +{ + struct acpi_madt_rintc *rintc; + + if (cpu >= nr_cpu_ids) + return -EINVAL; + + rintc = acpi_cpu_get_madt_rintc(cpu); + if (rintc == NULL) + return -ENODEV; + + *uid = rintc->uid; + return 0; +} +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); diff --git a/arch/riscv/kernel/acpi_numa.c b/arch/riscv/kernel/acpi_numa.c index 130769e3a99c..cd8adc9857e3 100644 --- a/arch/riscv/kernel/acpi_numa.c +++ b/arch/riscv/kernel/acpi_numa.c @@ -37,11 +37,15 @@ static int __init acpi_numa_get_nid(unsigned int cpu) static inline int get_cpu_for_acpi_id(u32 uid) { + u32 cpu_uid; int cpu; + int ret; - for (cpu = 0; cpu < nr_cpu_ids; cpu++) - if (uid == get_acpi_id_for_cpu(cpu)) + for (cpu = 0; cpu < nr_cpu_ids; cpu++) { + ret = acpi_get_cpu_uid(cpu, &cpu_uid); + if (ret == 0 && uid == cpu_uid) return cpu; + } return -EINVAL; } diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index de5f8c018333..d034a217e85b 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -459,11 +459,14 @@ static void cache_setup_acpi_cpu(struct acpi_table_header *table, { struct acpi_pptt_cache *found_cache; struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu); - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; struct cacheinfo *this_leaf; unsigned int index = 0; struct acpi_pptt_processor *cpu_node = NULL; + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + return; + while (index < get_cpu_cacheinfo(cpu)->num_leaves) { this_leaf = this_cpu_ci->info_list + index; found_cache = acpi_find_cache_node(table, acpi_cpu_id, @@ -546,7 +549,10 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table, unsigned int cpu, int level, int flag) { struct acpi_pptt_processor *cpu_node; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; + + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + return -ENOENT; cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (cpu_node) { @@ -614,18 +620,22 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) * * Check the node representing a CPU for a given flag. * - * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found or - * the table revision isn't new enough. + * Return: -ENOENT if can't get CPU's ACPI Processor UID, the PPTT doesn't + * exist, the CPU cannot be found or the table revision isn't new + * enough. * 1, any passed flag set * 0, flag unset */ static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag) { struct acpi_table_header *table; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; struct acpi_pptt_processor *cpu_node = NULL; int ret = -ENOENT; + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + return -ENOENT; + table = acpi_get_pptt(); if (!table) return -ENOENT; @@ -651,7 +661,8 @@ static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag) * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0 * indicating we didn't find any cache levels. * - * Return: -ENOENT if no PPTT table or no PPTT processor struct found. + * Return: -ENOENT if no PPTT table, can't get CPU's ACPI Process UID or no PPTT + * processor struct found. * 0 on success. */ int acpi_get_cache_info(unsigned int cpu, unsigned int *levels, @@ -671,7 +682,8 @@ int acpi_get_cache_info(unsigned int cpu, unsigned int *levels, pr_debug("Cache Setup: find cache levels for CPU=%d\n", cpu); - acpi_cpu_id = get_acpi_id_for_cpu(cpu); + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id)) + return -ENOENT; cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node) return -ENOENT; @@ -780,8 +792,9 @@ int find_acpi_cpu_topology_package(unsigned int cpu) * It may not exist in single CPU systems. In simple multi-CPU systems, * it may be equal to the package topology level. * - * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found - * or there is no toplogy level above the CPU.. + * Return: -ENOENT if the PPTT doesn't exist, can't get CPU's ACPI + * Processor UID, the CPU cannot be found or there is no toplogy level + * above the CPU. * Otherwise returns a value which represents the package for this CPU. */ @@ -797,7 +810,8 @@ int find_acpi_cpu_topology_cluster(unsigned int cpu) if (!table) return -ENOENT; - acpi_cpu_id = get_acpi_id_for_cpu(cpu); + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + return -ENOENT; cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node || !cpu_node->parent) return -ENOENT; @@ -872,7 +886,8 @@ static void acpi_pptt_get_child_cpus(struct acpi_table_header *table_hdr, cpumask_clear(cpus); for_each_possible_cpu(cpu) { - acpi_id = get_acpi_id_for_cpu(cpu); + if (acpi_get_cpu_uid(cpu, &acpi_id) != 0) + continue; cpu_node = acpi_find_processor_node(table_hdr, acpi_id); while (cpu_node) { @@ -966,10 +981,13 @@ int find_acpi_cache_level_from_id(u32 cache_id) for_each_possible_cpu(cpu) { bool empty; int level = 1; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; struct acpi_pptt_cache *cache; struct acpi_pptt_processor *cpu_node; + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + continue; + cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node) continue; @@ -1030,10 +1048,13 @@ int acpi_pptt_get_cpumask_from_cache_id(u32 cache_id, cpumask_t *cpus) for_each_possible_cpu(cpu) { bool empty; int level = 1; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; struct acpi_pptt_cache *cache; struct acpi_pptt_processor *cpu_node; + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) != 0) + continue; + cpu_node = acpi_find_processor_node(table, acpi_cpu_id); if (!cpu_node) continue; diff --git a/drivers/acpi/riscv/rhct.c b/drivers/acpi/riscv/rhct.c index caa2c16e1697..8f3f38c64a88 100644 --- a/drivers/acpi/riscv/rhct.c +++ b/drivers/acpi/riscv/rhct.c @@ -44,10 +44,15 @@ int acpi_get_riscv_isa(struct acpi_table_header *table, unsigned int cpu, const struct acpi_rhct_isa_string *isa_node; struct acpi_table_rhct *rhct; u32 *hart_info_node_offset; - u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu); + u32 acpi_cpu_id; + int ret; BUG_ON(acpi_disabled); + ret = acpi_get_cpu_uid(cpu, &acpi_cpu_id); + if (ret != 0) + return ret; + if (!table) { rhct = acpi_get_rhct(); if (!rhct) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index 34430b68f602..ed72c3d1f796 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1107,15 +1107,17 @@ static int arm_cspmu_acpi_get_cpus(struct arm_cspmu *cspmu) { struct acpi_apmt_node *apmt_node; int affinity_flag; + u32 cpu_uid; int cpu; + int ret; apmt_node = arm_cspmu_apmt_node(cspmu->dev); affinity_flag = apmt_node->flags & ACPI_APMT_FLAGS_AFFINITY; if (affinity_flag == ACPI_APMT_FLAGS_AFFINITY_PROC) { for_each_possible_cpu(cpu) { - if (apmt_node->proc_affinity == - get_acpi_id_for_cpu(cpu)) { + ret = acpi_get_cpu_uid(cpu, &cpu_uid); + if (ret == 0 && apmt_node->proc_affinity == cpu_uid) { cpumask_set_cpu(cpu, &cspmu->associated_cpus); break; } diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 4d2f0bed7a06..035094a55f18 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -324,6 +324,19 @@ int acpi_unmap_cpu(int cpu); acpi_handle acpi_get_processor_handle(int cpu); +#ifndef CONFIG_X86 +/* + * acpi_get_cpu_uid() - Get ACPI Processor UID of a specified CPU from MADT table + * @cpu: Logical CPU number (0-based) + * @uid: Pointer to store the ACPI Processor UID (valid only on successful return) + * + * Return: 0 on successful retrieval (the ACPI Processor ID is stored in *uid); + * -EINVAL if the CPU number is invalid or out of range; + * -ENODEV if the ACPI Processor UID for the specified CPU is not found. + */ +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid); +#endif + #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr); #endif -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 07:23:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 07:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251724.1548608 (Exim 4.92) (envelope-from ) id 1w0aON-0006K2-Mt; Thu, 12 Mar 2026 07:23:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251724.1548608; Thu, 12 Mar 2026 07:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aON-0006Jv-Jw; Thu, 12 Mar 2026 07:23:35 +0000 Received: by outflank-mailman (input) for mailman id 1251724; Thu, 12 Mar 2026 07:23:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aOL-0006Jf-P7 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 07:23:34 +0000 Received: from canpmsgout08.his.huawei.com (canpmsgout08.his.huawei.com [113.46.200.223]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5d323081-1de4-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 08:23:30 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout08.his.huawei.com (SkyGuard) with ESMTPS id 4fWf9H3SBhzmV6N; Thu, 12 Mar 2026 15:18:27 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id 462344056C; Thu, 12 Mar 2026 15:23:24 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 15:23:22 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5d323081-1de4-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=JWR3I9L7KX8a3aClE88ycMtETglowguHrLZMRqWv8Io=; b=rBBmv+LpmD6banh43JS0edaS84dH116/qBok6pLAmwhWmT+MsH/WPIcqF7IxzQwINsFJ6zh0d mJIuJoBHbaPglNXiO3Pr3di3NekDdj/t9i9N3QwQMRBtfQLE/3NhfvwJKUgbM+kmEdJgVXGgKaE 7uxc8NBOtepchaLqk9hHm94= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v6 0/3] Fix get cpu steer-tag fail on ARM64 platform Date: Thu, 12 Mar 2026 15:23:13 +0800 Message-ID: <20260312072316.4806-1-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemk500009.china.huawei.com (7.202.194.94) This patchset fixes the failure of CPU steer tag retrieval on ARM64 platforms. The series is structured as follows: 1. First commit: Mechanical rename of the ACPI Processor UID retrieval interface (no functional changes) to align naming conventions across architectures; 2. Second commit: Implement acpi_get_cpu_uid() for the x86 platform to complete the unified ACPI Processor UID interface across all ACPI-enabled architectures; 3. Third commit: Implement the core fix for the CPU steer tag retrieval logic on ARM64 (the root cause of the retrieval failure). The renaming and x86 implementation lay the groundwork for the unified ACPI interface required by the ARM64 steer tag fix, ensuring consistent CPU UID retrieval across architectures before addressing the functional bug. --- Changes in v6: - Rename existing get_acpi_id_for_cpu() to acpi_get_cpu_uid() - Split x86's modify as one commit Changes in v5: - Refine commit-log of commit 2/2 - Replace cpu_acpi_id() by acpi_get_cpu_acpi_id() on x86 Changes in v4: - Split the rename into a separate commit. Changes in v3: - Rename existing get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() other than add one new API. Changes in v2: - Add ECN _DSM reference doc name and its URL. - Separate implement acpi_get_cpu_acpi_id() in each arch which supports ACPI. - Refine commit-log. Chengwen Feng (2): ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_acpi_id() on non-x86 PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Chengwen Feng (3): ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86 x86: Implement acpi_get_cpu_uid() PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Documentation/PCI/tph.rst | 4 +-- arch/arm64/include/asm/acpi.h | 16 +--------- arch/arm64/kernel/acpi.c | 16 ++++++++++ arch/arm64/kernel/acpi_numa.c | 15 ++++++++++ arch/loongarch/include/asm/acpi.h | 5 ---- arch/loongarch/kernel/acpi.c | 9 ++++++ arch/riscv/include/asm/acpi.h | 4 --- arch/riscv/kernel/acpi.c | 16 ++++++++++ arch/riscv/kernel/acpi_numa.c | 8 +++-- arch/x86/include/asm/cpu.h | 1 - arch/x86/include/asm/smp.h | 1 - arch/x86/kernel/cpu/common.c | 15 ++++++++++ arch/x86/xen/enlighten_hvm.c | 5 ++-- drivers/acpi/pptt.c | 47 +++++++++++++++++++++--------- drivers/acpi/riscv/rhct.c | 7 ++++- drivers/pci/tph.c | 16 ++++++---- drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++-- include/linux/acpi.h | 11 +++++++ include/linux/pci-tph.h | 4 +-- 19 files changed, 151 insertions(+), 55 deletions(-) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 07:23:39 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 07:23:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251726.1548625 (Exim 4.92) (envelope-from ) id 1w0aOP-0006kR-8J; Thu, 12 Mar 2026 07:23:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251726.1548625; Thu, 12 Mar 2026 07:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aOP-0006kI-5a; Thu, 12 Mar 2026 07:23:37 +0000 Received: by outflank-mailman (input) for mailman id 1251726; Thu, 12 Mar 2026 07:23:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0aON-0006Jf-DG for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 07:23:35 +0000 Received: from canpmsgout03.his.huawei.com (canpmsgout03.his.huawei.com [113.46.200.218]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5effe969-1de4-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 08:23:33 +0100 (CET) Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout03.his.huawei.com (SkyGuard) with ESMTPS id 4fWf9453GZzpTJc; Thu, 12 Mar 2026 15:18:16 +0800 (CST) Received: from kwepemk500009.china.huawei.com (unknown [7.202.194.94]) by mail.maildlp.com (Postfix) with ESMTPS id CAD7B40567; Thu, 12 Mar 2026 15:23:29 +0800 (CST) Received: from localhost.localdomain (10.50.163.32) by kwepemk500009.china.huawei.com (7.202.194.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 15:23:27 +0800 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5effe969-1de4-11f1-b164-2bf370ae4941 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=yK49JnkLKpYBZOqDDiJ5tuFkHdnhSIg09tqBvQIMd28=; b=kKHyA/oBTEDBLkGyt6IF5Mfl/9NSCdKjuLiy/HF08xBMphI4nGy1HFAwxMG51XNjBjkBo5mE1 yjJ8Kunab1b6+Q35VPZpdNjHq9uHYBsa/8T6vWVzXsQpo9LPA6UF2V4Yh93oUHRXBNRvgd2kM7T N9D++v+eloU19GgyjqKPnrA= From: Chengwen Feng To: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" CC: Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Wei Huang , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: [PATCH v6 3/3] PCI/TPH: Fix get cpu steer-tag fail on ARM64 platform Date: Thu, 12 Mar 2026 15:23:16 +0800 Message-ID: <20260312072316.4806-4-fengchengwen@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20260312072316.4806-1-fengchengwen@huawei.com> References: <20260312072316.4806-1-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.50.163.32] X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemk500009.china.huawei.com (7.202.194.94) pcie_tph_get_cpu_st() is broken on ARM64: 1. pcie_tph_get_cpu_st() passes cpu_uid to the PCI ACPI DSM method. cpu_uid should be the ACPI Processor UID [1]. 2. In BNXT, pcie_tph_get_cpu_st() is passed a cpu_uid obtained via cpumask_first(irq->cpu_mask) - the logical CPU ID of a CPU core, generated and managed by kernel (e.g., [0,255] for a system with 256 logical CPU cores). 3. On ARM64 platforms, ACPI assigns Processor UID to cores listed in the MADT table, and this UID may not match the kernel's logical CPU ID. When this occurs, the mismatch results in the wrong CPU steer-tag. 4. On AMD x86 the logical CPU ID is identical to the ACPI Processor UID so the mismatch is not seen. Resolution: 1. Use acpi_get_cpu_uid() in pcie_tph_get_cpu_st() to translate from logical CPU ID to ACPI Processor UID needed for the DSM call. 2. Rename pcie_tpu_get_cpu_st() parameter from cpu_uid to cpu to reflect that it is a logical CPU_ID. [1] According to ECN_TPH-ST_Revision_20200924 (https://members.pcisig.com/wg/PCI-SIG/document/15470), the input is defined as: "If the target is a processor, then this field represents the ACPI Processor UID of the processor as specified in the MADT. If the target is a processor container, then this field represents the ACPI Processor UID of the processor container as specified in the PPTT." Fixes: d2e8a34876ce ("PCI/TPH: Add Steering Tag support") Cc: stable@vger.kernel.org Signed-off-by: Chengwen Feng Reviewed-by: Jonathan Cameron --- Documentation/PCI/tph.rst | 4 ++-- drivers/pci/tph.c | 16 +++++++++++----- include/linux/pci-tph.h | 4 ++-- 3 files changed, 15 insertions(+), 9 deletions(-) diff --git a/Documentation/PCI/tph.rst b/Documentation/PCI/tph.rst index e8993be64fd6..b6cf22b9bd90 100644 --- a/Documentation/PCI/tph.rst +++ b/Documentation/PCI/tph.rst @@ -79,10 +79,10 @@ To retrieve a Steering Tag for a target memory associated with a specific CPU, use the following function:: int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type type, - unsigned int cpu_uid, u16 *tag); + unsigned int cpu, u16 *tag); The `type` argument is used to specify the memory type, either volatile -or persistent, of the target memory. The `cpu_uid` argument specifies the +or persistent, of the target memory. The `cpu` argument specifies the CPU where the memory is associated to. After the ST value is retrieved, the device driver can use the following diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c index ca4f97be7538..b67c9ad14bda 100644 --- a/drivers/pci/tph.c +++ b/drivers/pci/tph.c @@ -236,21 +236,27 @@ static int write_tag_to_st_table(struct pci_dev *pdev, int index, u16 tag) * with a specific CPU * @pdev: PCI device * @mem_type: target memory type (volatile or persistent RAM) - * @cpu_uid: associated CPU id + * @cpu: associated CPU id * @tag: Steering Tag to be returned * * Return the Steering Tag for a target memory that is associated with a - * specific CPU as indicated by cpu_uid. + * specific CPU as indicated by cpu. * * Return: 0 if success, otherwise negative value (-errno) */ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag) + unsigned int cpu, u16 *tag) { #ifdef CONFIG_ACPI struct pci_dev *rp; acpi_handle rp_acpi_handle; union st_info info; + u32 cpu_uid; + int ret; + + ret = acpi_get_cpu_uid(cpu, &cpu_uid); + if (ret != 0) + return ret; rp = pcie_find_root_port(pdev); if (!rp || !rp->bus || !rp->bus->bridge) @@ -265,9 +271,9 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type, *tag = tph_extract_tag(mem_type, pdev->tph_req_type, &info); - pci_dbg(pdev, "get steering tag: mem_type=%s, cpu_uid=%d, tag=%#04x\n", + pci_dbg(pdev, "get steering tag: mem_type=%s, cpu=%d, tag=%#04x\n", (mem_type == TPH_MEM_TYPE_VM) ? "volatile" : "persistent", - cpu_uid, *tag); + cpu, *tag); return 0; #else diff --git a/include/linux/pci-tph.h b/include/linux/pci-tph.h index ba28140ce670..be68cd17f2f8 100644 --- a/include/linux/pci-tph.h +++ b/include/linux/pci-tph.h @@ -25,7 +25,7 @@ int pcie_tph_set_st_entry(struct pci_dev *pdev, unsigned int index, u16 tag); int pcie_tph_get_cpu_st(struct pci_dev *dev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag); + unsigned int cpu, u16 *tag); void pcie_disable_tph(struct pci_dev *pdev); int pcie_enable_tph(struct pci_dev *pdev, int mode); u16 pcie_tph_get_st_table_size(struct pci_dev *pdev); @@ -36,7 +36,7 @@ static inline int pcie_tph_set_st_entry(struct pci_dev *pdev, { return -EINVAL; } static inline int pcie_tph_get_cpu_st(struct pci_dev *dev, enum tph_mem_type mem_type, - unsigned int cpu_uid, u16 *tag) + unsigned int cpu, u16 *tag) { return -EINVAL; } static inline void pcie_disable_tph(struct pci_dev *pdev) { } static inline int pcie_enable_tph(struct pci_dev *pdev, int mode) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 08:02:46 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 08:02:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251777.1548644 (Exim 4.92) (envelope-from ) id 1w0b01-0005Rs-Eu; Thu, 12 Mar 2026 08:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251777.1548644; Thu, 12 Mar 2026 08:02:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0b01-0005Rl-BK; Thu, 12 Mar 2026 08:02:29 +0000 Received: by outflank-mailman (input) for mailman id 1251777; Thu, 12 Mar 2026 08:02:28 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0azz-0005Rf-U8 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 08:02:28 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id cec9ec4d-1de9-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 09:02:26 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by SA2PR03MB5740.namprd03.prod.outlook.com (2603:10b6:806:11b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.27; Thu, 12 Mar 2026 08:02:00 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 08:02:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cec9ec4d-1de9-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=dLpfT80wsMpI2ZkKgRCGaaiSG9IpJLTj9+EPDz5GjsnHdzdU4hmJyMQIAO9efT1eUyloLYz/PDV6b6Zieweakj/Gj3029GA3lDFcadlodIYU9FrKzTqQIksDctcOB1W58Mi8xIUm98B+VFltBxA9mt4X85ANEJAsKwfH9Iz0Yhh7sw/gcIhQTj3D8XRuw6yfoWCShxO98XGNByvigyW+WvGM1Oa8cuQCGlNh/55VwlD5zTabYyAymfyJEOu0+YMWoTqMyfHvx2mhFuyfKFXPxdYvYMraZ7U4aGdV6H5zjmxQlazWFIXZjYnD+cCxshWbUhxbkWDegn2qduyIa9RkGg== 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=08wODLFuN4N6BksfeVKCpF7yEiF0rthYfncaPcd8r/w=; b=AacP6j9ATZxRSxe4EGn8sHFGdlCZ4dhcwt/f2SP9dl12K6t6hyQJkO/0GtSxXjxhFd7N3wasOhuEeon19V6svqmq/m5k4aBpp3eUAdvzIQZ7vfCgmYX4dm4uojr6zxRXUwsn62feZpWVSrecldHGkOJ/Hq45VuicXdLJK2gv5eAj2e3ORj7/FneeImVAMwvFFdL9O0dUZHIG1de/ghB9oAIcc1FKDl6h3BCO05HEo8Gp09RzLMqYX6x1ohVC4kQ+S0DSQLGeREhX8+4npTv1TCn0XdZKJNkDXJQnOTlhr9VMUUk/5p5gB1aCN1UgnIPtcsTKb3Qaf81JMQDcMaVPDA== 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=08wODLFuN4N6BksfeVKCpF7yEiF0rthYfncaPcd8r/w=; b=hCALmE5chMDT9dbJ5A3mM5U2kFiqyxxedMZNP8bQ1rnU6PgzqtfCgULvOlD5ZV6AQ3IyVQDS28Yfu2pAUXKCSi4/3yZ7k2supk0kT8jHIbGWjk6aYSE7K83u3Yp8yfePV9Yn1FcyvSdumF7Ch1/N7jhGb6qgUFrklEcKHAa2pDY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Anthony PERARD , =?UTF-8?q?Edwin=20T=C3=B6r=C3=B6k?= Subject: [PATCH] tests/pdx: fix overflow from conversion from page index to address on 32bit Date: Thu, 12 Mar 2026 09:02:06 +0100 Message-ID: <20260312080206.52648-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: BL0PR01CA0028.prod.exchangelabs.com (2603:10b6:208:71::41) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|SA2PR03MB5740:EE_ X-MS-Office365-Filtering-Correlation-Id: 6d00d893-a9ed-453b-b9bf-08de800db042 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: ut6IWUVzfrnAqUBKihHviQMvFSTogokElQPvBSb39za9g2rKrF5ongS2gaY2OWFkcvW/AemHWc/TK9R470dzE/W4AZCms5XBezYdoh7oBZ1Y8ryKc43/RY+sU3DiMUAUTu/otLR1+O9CmBXztvquiPGq7gR0gysUF7Rfs/owGzliIis8r+sm4u0YoJvD26+OfslHjuP/PPf2AfuxY/oMD5HctfucMSJGHUYbOXKVfKxQLRAoIxKyGQ7KFQYJHIJy3ZBt8DxsdvHPJ4BWHyuNLQIaUy8CZvruYZ2kY8AoB67+cvIw/MxgF0cq6Vvnv7/3gkQg1n4N6iLAsbAC1yfki3IndwjMsHZ/Q7lkc1J92Cxo89ZgUeNXkqqF/KWSDoRs/sT1LjIyIEx9JXhFK0SGk3k9Uk7EzYbW0rzYDjtNnZazaM6n+QaaWYbK8stprgiDD9k82zbqSgRCOp2J/EBn+6AxICLtMH470VFW+a+E0m/lRFtxK8XrysfX4auM3xJQnPcN76xFjKpl7xFHrcvQAbMQyBmbSRIMyyD99AYNEftMH96cgTO94Vngh1YVYQ3u+zBmjuHtKyXga2pnG7PYdx4g3aFfy/LzXOz/zdCkKt1KaHsDR60MSEAoidc52vbyPYnF/VyTWhhfBqaBgszvmntG1oCJXzCoaI+pAtWxWRN5y99HHRwjQtWDxQ99NSsu0/DWj5N93gvaF9lAVZqqmzWYR5Xkt14NOYTmELdYhwM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dldOUHFOWmJDcmhuZWk4SDdwZUpySFB5WUtoVW5HSjVsWlF4ZTVVdnorWEpj?= =?utf-8?B?bTBqL1hPS0xmNHBLZUYrLzF5KzBzRjNwNStSWm9YNGVVelI4b2lWRzRXeWVx?= =?utf-8?B?WkgvbC93MWI3UU1GTzRmZjBZWlJIUzV2WkhhWGR1TGRFcW1GcjZzSFNuUjBI?= =?utf-8?B?cUpBNzJQRW9sbnU5VUVuSTBIdGx5TkxlSDRCZnF6ZzJFSDlZbmxFaFphVGtM?= =?utf-8?B?TG8xVnh0cVAycVFTYW4xcEs1Ry9oRDZOTTBkM2RkS3I1QURrZU4wTDdOWDVQ?= =?utf-8?B?ZEtadUE2TFhXMks0NGtlMFJJbEt6S0JoS0gvWHhPT29PSjZXQ21neGRnaVpr?= =?utf-8?B?SzgyK21YNHJzVXZ6cWZ6dDJ1ek51SHY0d0lhQllDVXFTYlprdkhCZEdlY3BE?= =?utf-8?B?SGo1R0pLOTZNQ2pmOFdhcFZMZi9RNThwTGozeXFmTkhqVG1hSWJ3cGplbEZV?= =?utf-8?B?cXJEb09iY2QwR2ZGMFFSek9XVkJmMTlJTGZyUUluY0tVOFhReWtVVTlpTEFF?= =?utf-8?B?SitNREZXMFZpTG9IMjQzU2FSd2FrTE9wbDF1TWM2UjZLZTg2NXRDOVRUV3NU?= =?utf-8?B?dnBraFdtZDlKdUI1cjlyMkIzeGsxeDNNOHVNUTR2TXB2VkNNalRaVGJnbEdq?= =?utf-8?B?ZmYwZFdWVS9FalUvYUN5ZUJZbjRyOVNWeEpZWVhvRnZQR3hHajdTV2wvbFNt?= =?utf-8?B?bU5ZTmE4TmR6cVZaZ041NkRSS0Y5SzM5UkRRRlZRSS8rVCs2blhzRTZ5T2h5?= =?utf-8?B?bDlhL0N0VnFVU3NiYnBGb2kwRDZZYW5TbTdYdlRDVy83THVEYXIvYW82Zy9h?= =?utf-8?B?WFY3ZGtyWGZnZEJ0MWlxYjBIQXU2Zk9YVUFsUytqY01FQ2ZrbE5ZUnUyUU9R?= =?utf-8?B?aVZENFpLdkd3b1BjMzExSkxPVDFiTWNkcEZnVWJmWmhkSmJldVhjbU44SDFW?= =?utf-8?B?YUpWN1d1cW8xSk9kWnNPbUtjd1ZiT3o3dEZrSGVOeHI2cytUa0w0c1IxMzVq?= =?utf-8?B?b0g5bEI4T2NNWk5Pd01qWEVWOVhPOC9TcUU4UXdhSGMvTHEwaFMzcVYzOUlw?= =?utf-8?B?eThSdDExZG10ZFVUb3JvL3hhTlBYRlpuZWxhYS9JTGpET256Q083M3RVbDlW?= =?utf-8?B?bTNTc1ZIbGlzRW1zOG90emdHMG5wdG13UmpFWG1RdXBvRjlmbDFkSXFndlF2?= =?utf-8?B?QUJJRHh3dVhNYkF0d1RWUUlxSThvVVVnaFlHdGFLTStjb3NOcTFvZVVMSjU3?= =?utf-8?B?K0UxVDV6ejZWMGY5a2FGWEJTd1o0RTFpb1BnbTkrRStSQlpCMFpIaVA0Vm9I?= =?utf-8?B?MVRLU00yMWZpSzVRM2JQaUxCVE40d1VobkNyRnlCcjRMTSsvRFc2bDhBcnR5?= =?utf-8?B?bVpJQktVc1FHQmYzemFFU2JBdm9abGhBNDhhckpmSnhhOHpNU0MzUzNud2x3?= =?utf-8?B?ZGhnUUZlTlRWNkp5a0pkcUZFaWpONVRXV1JaRFcwMTZMTmJwMnM4QnBYek5j?= =?utf-8?B?aVlXZW5nQ0VDNjBDZG81aldjZ2I0NGoybktWaUMzbWdad0VUY29CZVkvd1VM?= =?utf-8?B?aEg5S3MvWkJXWWM5MEJqT21HZkp6U2g0eTJ5SUlxbDF4T2dGb1l2TTh0S0Mz?= =?utf-8?B?S1pqYW1HbCs3dVhadEJyR0xhQmozbXY5aHdmcmpKSEk2dDdDRUxNL3hnZllB?= =?utf-8?B?MWN2cjhJbUFiR2p5Y1I3MGFtazN6bTFpemdnZyt2Y3ZOZXgrSW12dHhPQ2RX?= =?utf-8?B?V0NmWnBNd0x5aGZxYWxzZTdSSWt6a3Vod1RTb3Z3d0pIbDQyYVBldzJ5V2Fz?= =?utf-8?B?UWNzMEtTOEVPUVg5amVobFBWeDdSM2t4ZUF3aEhsS0VzMzk3RGFZb2h3T0RK?= =?utf-8?B?Y0h2eDhuREc1SW9GbE4wVFY5NkMvYUFEOXB4VDk4aC9tWFNvdENTZ1lOMDVK?= =?utf-8?B?K3UvYnFubkJuakRPQWJnREZVcjA2TG56NDExdTZNdU8vSkRSYjhHTU4zN3lR?= =?utf-8?B?blFIVFRVTG1oM216bXFjRkMvMkVvdTdZZmU1MkZqNThpbWlOaUhZc1ZqKytI?= =?utf-8?B?R0Y4SjBWMmJ6VGJNMXdLSEdBRGJIbEY1TVRLQ25XeHVrNEwwWk5ZOSs4R2xW?= =?utf-8?B?Y3ppK250NDgyRWhHUlFCWldwbjZkMyt4c0REcW5vajNOYXlPZ1ZIRUJodHpj?= =?utf-8?B?UjI4R2hRYmlMM0tYVXNEbXV6TXFBOFFyS3g4UkpNc2hCUUtONzNsWjVMbXA0?= =?utf-8?B?VjlwaGZkbzlvaEZGOVI1ak1FTXFzelF5WHQ2VStrTGFwa2lDTWs5TEVTbGk0?= =?utf-8?B?SXU4RHhhMDdwdmNQWWgxM2paNmdlVnBDWXBjOFFzZFU2eE5Db3VxUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d00d893-a9ed-453b-b9bf-08de800db042 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 08:02:21.5591 (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: 02uOy07mhEVpvdZV0NO+Mj0yIH9xYsWERO2iFHZhO7sShrfSlIVTGN3PWZN7EBi5fL9aEsmwT0mNfKscY8IcYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR03MB5740 When building the PDX test harness as a 32bit executable the page shifts done on unsigned long types can overflow. Instead use pfn_to_paddr(), which casts the values to paddr_t previous to doing the shift. Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests") Reported-by: Edwin Török Signed-off-by: Roger Pau Monné --- tools/tests/pdx/test-pdx.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index eefd54c76815..066bd3e7e569 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -208,8 +208,8 @@ int main(int argc, char **argv) if ( !tests[i].ranges[j].start && !tests[i].ranges[j].end ) break; - pfn_pdx_add_region(tests[i].ranges[j].start << PAGE_SHIFT, - size << PAGE_SHIFT); + pfn_pdx_add_region(pfn_to_paddr(tests[i].ranges[j].start), + pfn_to_paddr(size)); } if ( pfn_pdx_compression_setup(0) != tests[i].compress ) @@ -233,8 +233,8 @@ int main(int argc, char **argv) if ( !start && !end ) break; - if ( !pdx_is_region_compressible(start << PAGE_SHIFT, 1) || - !pdx_is_region_compressible((end - 1) << PAGE_SHIFT, 1) ) + if ( !pdx_is_region_compressible(pfn_to_paddr(start), 1) || + !pdx_is_region_compressible(pfn_to_paddr(end - 1), 1) ) { printf( "PFN compression invalid, pages %#lx and %#lx should be compressible\n", -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 08:15:49 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 08:15:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251788.1548653 (Exim 4.92) (envelope-from ) id 1w0bCq-0007GD-Mf; Thu, 12 Mar 2026 08:15:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251788.1548653; Thu, 12 Mar 2026 08: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 ) id 1w0bCq-0007G6-Ik; Thu, 12 Mar 2026 08:15:44 +0000 Received: by outflank-mailman (input) for mailman id 1251788; Thu, 12 Mar 2026 08:15:43 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bCp-0007Fu-91 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 08:15:43 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a8b6538a-1deb-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 09:15:41 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-48534b59cf3so6233635e9.2 for ; Thu, 12 Mar 2026 01:15: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-4854ad5ee37sm86741115e9.2.2026.03.12.01.15.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 01:15:39 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a8b6538a-1deb-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773303340; x=1773908140; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=o+x4KFIxZflzg6VTQwH/Ob8N+WJi7OG0Ofvzmyt3h8g=; b=Fx8galqdxR2OiigNui/1+jcmYAXcm2zDKobYxC5cJE2vAbvb9oY4RfajAtbDOUs0eB gQbH79ReH3pHIhvpczRj+TPGwXQm2DiScIw3aAnuDaJgVw92GEjlE1YsJ0TGpwjpByBf RL9WnpHpa+U7SDMVsmQrmRXQjqKYsL0B7YKs3rGXVxDpE1MZnqDo/t5JcRh7vYqxNK/M 0EjfREv7Vn/XWYDZOtGtKbUmpg+ZiE0pcfaug8wP+5Z93V5mvrPAnpnzCP8KbPJNrc6k VPtqvyJ7JkFDdXduxHi/ksGJsQEXhBBPKJxtesykmAytkKpGWk4tkV30do1kD53QMqUq WgoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773303340; x=1773908140; h=content-transfer-encoding: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; bh=o+x4KFIxZflzg6VTQwH/Ob8N+WJi7OG0Ofvzmyt3h8g=; b=OMGlvGcxM/KgB/ApCLE8ivmf8cP+6CtMD5+QhOUakT4A1t5A5HZrcrlF/3/NRqp007 6s4/Pi+nvmBTXi20fo/wUWyNP5lEpawxqNXZ5BPixQkV3LmVDKNFoE15oTH4aPsyV71M 7UNcVvOdsUWHYG6LRh8VBIt9ixgKa4nHWE5wu8HW9eNLJQhZHtzqLPXEUVMuKkDCqnHC nmm7yxvAnb/GAVxnsgWmF3JiiBx+QJ+coTIIdYrHNSZcSKEYSrNXEwPys2p2Ksd8TQjm 15qc1QnuNuGgMPnuoz7I5jp27QLyQDliMuHzIAsmjcu5Kf1rA1No+CDSAZYoGkevK4VY 7Rfw== X-Forwarded-Encrypted: i=1; AJvYcCUC9Kl5HA/arQ9vt8RVStCSa/5HtCNu1CbvRPHfB8Qdw8Lk8hn+Nb8Q++mZJ807cN+aB1qkMZMoUs8=@lists.xenproject.org X-Gm-Message-State: AOJu0Ywntq0zNvohgg7yorLtI05EyzvabuJ5QqAO0BH3DHsJ6qBwtY+F 4mf86ZEfkyBib4GYyJQSCTx++eXgCIug9SeaMAJV3iGVHrINYnpGzNH/K5sq6LTFkQ== X-Gm-Gg: ATEYQzwS6FWSS5WGFghAsISKgijksetqSSk+pOjjDM5Xy8XDJUGdoy7IQA31/gSkxUN K03yNon+LXnvooWbQIFiduUdTSodw8iOFIGx4m7njRKCELZByrT3SllSMvzG8JlVjSF+Eqr44PK mfOSefBxrcEfJc76h0od2Arf/iW13zmCIlH21VP/h0c4tDjv4lx9hdS8CTEUeXuTJDng38el2lX 6Lp1J9nOObEeI0Yr1qDCiZk6la2ARuFjTqJUBp/MgNcDyZ7LPZaVFHb7mTEeW9v2yByn50Jg8CW JzR7gs5N69RI6rgI2hDV8fg/IkJ2b9VaYt6VDaaXJUDQxUI9x7WVv+lsnOgBaMbRGACmFn3QH3j A/zxTJsP66jhfrc6GX/H6JSc5Jfgso6G6UWV1Vcbb91IfnvvZYWbJHdS68kxwLX805LceYFsIfB zCw07ZMmLXrwGr+qCS6FxLqJ9HUafrIHrzJISJ2KzxG+Oxd4EMYCgrHwhYrd3FOgFCfJM6ZLjdT SK4JfN57zpwyxk= X-Received: by 2002:a05:600c:3b16:b0:477:5ad9:6df1 with SMTP id 5b1f17b1804b1-4854b0a4a1emr92300665e9.3.1773303340467; Thu, 12 Mar 2026 01:15:40 -0700 (PDT) Message-ID: <2f006ef9-8a2e-4059-83ed-65dbe50ea9bb@suse.com> Date: Thu, 12 Mar 2026 09:15:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4.1 13/14] x86: Clamp bits in eflags more aggressively To: Andrew Cooper Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Xen-devel References: <20260227231636.3955109-14-andrew.cooper3@citrix.com> <20260311175838.573925-1-andrew.cooper3@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260311175838.573925-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 18:58, Andrew Cooper wrote: > In FRED mode, ERET is stricter than IRET about flags. Notably this means: > > * The vm86 bit (bit 17) and IOPL (bits 12,13) must be clear. > * The sticky-1 reserved bit (bit 2) must be set, so dom0_construct() needs to > set X86_EFLAGS_MBS in order for a PV dom0 to start. > * All other reserved bits must be clear. > > Xen has been overly lax with reserved bit handling. Adjust > arch_set_info_guest*() and hypercall_iret() which consume flags to clamp the > reserved bits for all guest types. > > This is a minor ABI change, but by the same argument as commit > 9f892f84c279 ("x86/domctl: Stop using XLAT_cpu_user_regs()"); the reserved > bits would get clamped like this naturally by hardware when the vCPU is run. > > The handling of vm86 is also different. Guests under 32bit Xen really could > use vm86 mode, but Long Mode disallows vm86 mode and IRET simply ignores the > bit. Xen's behaviour for a PV32 guest trying to use vm86 mode under a 64bit > Xen is to arrange to deliver #GP at the target of the IRET, rather than to > fail the IRET itself. > > However there's no filter filtering in arch_set_info_guest() itself, and it Nit: Excess "filter"? > can't arrange to queue a #GP at the target, so do the next best thing and fail > the hypercall. This is not expected to create an issue for PV guests, as the > result of such an arch_set_info_guest() previously would be to run supposedly > Real Mode code as Protected Mode code. > > This allows PV guests to start when Xen is using FRED mode. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Nevertheless, a largely unrelated remark and two suggestions: > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1193,6 +1193,14 @@ int arch_set_info_guest( > > if ( !__addr_ok(c.nat->ldt_base) ) > return -EINVAL; Seeing this still in context: I had some trouble locating the position where you're making the change, as in my local tree this is long gone. Is there any chance we could make progress on "x86/PV: consolidate LDT checks" [1]? > + > + /* > + * IRET in Long Mode discards EFLAGS.VM, but in FRED mode ERET > + * cares that it is zero. > + * > + * Guests can't see FRED, so emulate IRET behaviour. > + */ > + c.nat->user_regs.rflags &= ~X86_EFLAGS_VM; > } > #ifdef CONFIG_COMPAT > else > @@ -1205,6 +1213,18 @@ int arch_set_info_guest( > > for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); i++ ) > fixup_guest_code_selector(d, c.cmp->trap_ctxt[i].cs); > + > + /* > + * Under 32bit Xen, PV guests could really use vm86 mode. Under > + * 64bit Xen, vm86 mode can't be entered even by PV32 guests. > + * > + * For backwards compatibility, compat HYPERCALL_iret will arrange > + * to deliver #GP at the target of the IRET rather than to fail > + * the IRET itself, but we can't arrange for the same behaviour > + * here. Reject the hypercall as the next best option. > + */ > + if ( c.cmp->user_regs.eflags & X86_EFLAGS_VM ) > + return -EINVAL; Technically we could support VM86 mode, by fully emulating things. Hence I think -EOPNOTSUPP would be more appropriate. > } > #endif Having all of the EFLAGS handling together would be nice. IOPL and IF handling sit further down. Could I talk you into moving these additions down there? Yes, there are downsides to that: It looks to need another "compat" conditional, and it would further the mix of state updates and error checks. Yet I still think having all of the EFLAGS stuff together is a benefit. Jan [1] https://lists.xen.org/archives/html/xen-devel/2023-09/msg00157.html From xen-devel-bounces@lists.xenproject.org Thu Mar 12 08:25:24 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 08:25:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251804.1548662 (Exim 4.92) (envelope-from ) id 1w0bM6-0000Y2-Gx; Thu, 12 Mar 2026 08:25:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251804.1548662; Thu, 12 Mar 2026 08:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bM6-0000Xv-EH; Thu, 12 Mar 2026 08:25:18 +0000 Received: by outflank-mailman (input) for mailman id 1251804; Thu, 12 Mar 2026 08:25:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bM4-0000XB-DE for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 08:25:16 +0000 Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [2a00:1450:4864:20::331]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fe4d4dfa-1dec-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 09:25:14 +0100 (CET) Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-48538c5956bso7318305e9.0 for ; Thu, 12 Mar 2026 01:25: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-4854b66e3f8sm111689065e9.14.2026.03.12.01.25.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 01:25:13 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fe4d4dfa-1dec-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773303914; x=1773908714; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=eDTW8bDAjEjJXFvZLiffSqGsw7st6MYe1edCkQn7ftw=; b=NVpr2PZ8veHxydc1sGylGnvU6oKccRqdiJwnAbX7vnBIJeDZyhak1ONfhzSreswjDI xoc229UBEL/AdpubnVCmlNrn7ZlyMDRWIo8dp10v53dBJWdERyo1bSAMdHegM8ojcOkf OFFhHKH9ugB226A/35CWpYG+A6WUH2xS5GCcs8T0NhqJry6vCUaPTleSfOsO/St9KA0w KmNzHpNNYKqwVjuBwh8tLSmklyASTiVwE6C9qZ56qiO0Tx8ZcE/HUcgXKShktOmf3kXe kyQ/z691sUY7myExwjiLGFZbFOGeyZl/oO2rFlLqVPXcubyzrrsHejL/FXANIYJ7YuIn V5xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773303914; x=1773908714; h=content-transfer-encoding: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; bh=eDTW8bDAjEjJXFvZLiffSqGsw7st6MYe1edCkQn7ftw=; b=teGR+Ss9vrqqot2rW1E94mmtKzFMS4gzFo0Hhkzaklm6WDPIjUzXPcnR5N8GY1a6Lp FKPiDzLgyhp4/rDC9QUDoDAs9Up8gy/WYKe0awK8gvC6+gkk3q0D/xcxmNXEciObINZt k7dErI9T0VX1PF92ZEJj6SFnu/ZgVBjuxCUK4EIv6vSTWiGkPJCCCKbj4BYtDKIVl2B8 TJTt2oVMM53nTFc/URCKp8/nf+qVOQzg84fz0UaF2eVJ0aA0zTB2+wFgo+Eceff82hdz 5lnWxBm1zKVwt3rockrxDVe+ojVFVQrmgLmY3XJuKOmO3QwxQoRtTeSXxfD5tvZ5SMe1 UYkQ== X-Forwarded-Encrypted: i=1; AJvYcCW21q1e09LLkDULGLb8iNRW3Nzm9EWHbFDBcMkK0mz3QBFBQYr2ZutlofIsGw9bcVYyGVK/wgoNJbo=@lists.xenproject.org X-Gm-Message-State: AOJu0YwW5QmZDoHBeq9TDBXFZah+XOHF690FqRN2LmjRKzbOJQT+LyXm 5ToIVm4DWnQgxeem8ruP+0RXZRG9COMkz973zVpUXrDxsvSvQ2Bruz8Q5QvGKq8Vqg== X-Gm-Gg: ATEYQzxwbThDCqTCWcF1R15RdqqHZChjQnmmaqB3iXu7EgZMCaD3wxEVtLOZsHCbnz6 PsdWWLgjEAun2ZOwjfvqzlgUwh0IWbusH4nHDIGsWfY2GRqbzCZ9nqXfrQQJzktQFx7jC3NWkyX hVq+lQzvv34Q6sOSDNXHOqx2r3lYMD/4dG57MZuaGuwoxv1Ku4et3XzOmv/x5p4MoR6CVQoVkL9 WDxzCDtI0acElMmawBAQy68By79Gv80O/VdaNEjpnu8/2EG2U2WVIAmzqH+EqoEW1PMcFEhrE0Z GcppNYzuqb2n/jSr0EL34r9IjasSuI5LHjwnuG1gv0LqzwoJQpBxCqtKIoal8oTqwEHAvnkuZIF bWLZP75Zs/9BM1l1PWo7aijFUZobG03a1RHP9DCGzXzVA2IuAGpnYBCkevWdCu9Db0THE8/iVVA eyMXcb69gMLtOeaXJXfFS2YVZJoIRyrkAYNXXBFdCWrB1htJnu2iD3fWBABEKJVtZzMV1nUriA/ zwWrnhCVobU82yI771sbYURYw== X-Received: by 2002:a05:600d:644d:20b0:485:3c2e:60d5 with SMTP id 5b1f17b1804b1-4854f56a0dcmr29646735e9.2.1773303913658; Thu, 12 Mar 2026 01:25:13 -0700 (PDT) Message-ID: Date: Thu, 12 Mar 2026 09:25:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tests/pdx: fix overflow from conversion from page index to address on 32bit To: Roger Pau Monne Cc: Anthony PERARD , =?UTF-8?B?RWR3aW4gVMO2csO2aw==?= , xen-devel@lists.xenproject.org References: <20260312080206.52648-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260312080206.52648-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2026 09:02, Roger Pau Monne wrote: > When building the PDX test harness as a 32bit executable the page shifts > done on unsigned long types can overflow. Instead use pfn_to_paddr(), > which casts the values to paddr_t previous to doing the shift. > > Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests") > Reported-by: Edwin Török > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich > --- a/tools/tests/pdx/test-pdx.c > +++ b/tools/tests/pdx/test-pdx.c > @@ -208,8 +208,8 @@ int main(int argc, char **argv) > if ( !tests[i].ranges[j].start && !tests[i].ranges[j].end ) > break; > > - pfn_pdx_add_region(tests[i].ranges[j].start << PAGE_SHIFT, > - size << PAGE_SHIFT); > + pfn_pdx_add_region(pfn_to_paddr(tests[i].ranges[j].start), > + pfn_to_paddr(size)); > } > > if ( pfn_pdx_compression_setup(0) != tests[i].compress ) > @@ -233,8 +233,8 @@ int main(int argc, char **argv) > if ( !start && !end ) > break; > > - if ( !pdx_is_region_compressible(start << PAGE_SHIFT, 1) || > - !pdx_is_region_compressible((end - 1) << PAGE_SHIFT, 1) ) > + if ( !pdx_is_region_compressible(pfn_to_paddr(start), 1) || > + !pdx_is_region_compressible(pfn_to_paddr(end - 1), 1) ) > { > printf( > "PFN compression invalid, pages %#lx and %#lx should be compressible\n", Largely unrelated remark, from going through all of the PAGE_SHIFT uses: Isn't the __LP64__ conditional excluding quite a few too many array elements in main()'s tests[]? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 08:36:26 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 08:36:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251816.1548676 (Exim 4.92) (envelope-from ) id 1w0bWm-0002Ko-HD; Thu, 12 Mar 2026 08:36:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251816.1548676; Thu, 12 Mar 2026 08: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 ) id 1w0bWm-0002Kh-DT; Thu, 12 Mar 2026 08:36:20 +0000 Received: by outflank-mailman (input) for mailman id 1251816; Thu, 12 Mar 2026 08:36:19 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bWl-0002Kb-KR for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 08:36:19 +0000 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c112::5]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8954db79-1dee-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 09:36:17 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by DM6PR03MB4924.namprd03.prod.outlook.com (2603:10b6:5:1f2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Thu, 12 Mar 2026 08:36:08 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 08:36:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8954db79-1dee-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=u87acAxyUs7S3MxLsjGLjocEjlUE1JZtoiMQQKMr+csZ0oU9o3oj/jP6m6C8ZiM26lbF03tDJMzHyJHnpVayi1xyO5a3YWo7fEeaubEnOwrGNNlYK/snZZd1o8T50r+d+14w0BzTHqZDuYfQErnSf+EXNqklJsVh1Sc7evjHLiCJyCPqAPUqz1+fZmd3SyGH9QwLpkQ4PdLV3K2w8X36pjS530RYVt9f8fra+X7ycUs4zCF/2bTrPjowWAN1mKtoUqTlX7yszibOUQ4FNHB+rIm+uaX8jFSBijmdhqdfDQqUNT7u3pmHNEg2yZBDPINe70ugmSgk5IjVZsyu7om6Dw== 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=0EAaLruJ0j1AiI5md8lI1uSD7PkKz4SyXqT8+Jd3YB8=; b=AxPHg7kT6LlvnUdjZko90ywKF7hIYPo0A8Ms+Sqk7sOXIYLG5KKyPleyGU6p56H/xLQJOxPs4Y7/9EZX03PKRpyMjUJYLUVkciM1lK9xrn4DAMej0T4HhK/pTdv8jQ/ytNxUGdIPzF+z7Gd6im1/Qyd0/e74A6NNbrb0XT6Fl5uCnurxeYBfrr5v+mfcBjjDt3QrbXOafNPJzF5Se4DUOdV5+RvzrfZnHB2cCr/02W8YIM+SQbNj+4e/pOnJPx5LaqztMH369SBid9RcRNFyKC2OPju4FAFHX+p8X0KogBAhd//ehYLHR4e2E6kIdE8C32ll8awjq4I5f3MzBtz3EQ== 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=0EAaLruJ0j1AiI5md8lI1uSD7PkKz4SyXqT8+Jd3YB8=; b=pUBtlurG9yQ6h7AHGd1Y76y+Zt5RMTzfK+BiNXiOsDv4snTB0q9OTgD9yIU0VJ/2u5vOgEGFt2pt5sp3av/srvq68pRB1OmuYMdh7Km5gFGX4fpAorARSzy6obqY0mk8yUM+/uj8IeQKgOgoDaNtpYLt9FIwm33ScAIK6iHT2pM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; Date: Thu, 12 Mar 2026 09:36:10 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Anthony PERARD , Edwin =?utf-8?B?VMO2csO2aw==?= , xen-devel@lists.xenproject.org Subject: Re: [PATCH] tests/pdx: fix overflow from conversion from page index to address on 32bit Message-ID: References: <20260312080206.52648-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: MR1P264CA0039.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:3e::31) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|DM6PR03MB4924:EE_ X-MS-Office365-Filtering-Correlation-Id: 9f909835-1b20-4d6b-c6c0-08de80126b25 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7053199007|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: NNOx2jbYAchbyF+1HPi8p3Na49L8HY8RfJkAtcYiTvJVMP+3y7vCNDmAcPMb/McFea4oWTkgdqxpSwgO+56vNkye1MHNcB4jIpcbNckgE0fNpEDsW8uPDKMv9BWpPZGjml40G9ko4qkEcNJnAhf6H4NtrzSuNiAxwYfZPswUN6FK4+JLnm0WIcVfVgM+ack12u/uUApGpO4nCNtDHchQCebvbCtErDAccGCiPpIx7rtSR04giKR4UrcUeBp795DH45MrCtvhnmPtIdtdwUTAKUDg02B6M7whSn6/rFw9//7wAT7oR3AIj35GEsgOCSwanr3tQu6MBY98K+/CsIWgIYJP65jIeiXyGnkNFINQS+8n9x24paunP3bC7firXE3Ie9/sRcoLi6nK4ESAv3g58PpLn6rrFaSueim1ww3iWTJ4Z/Z6C12DJTZRJOTVDxsRWdASoFzAHpyamYbjXUkiEHRv6A7MioY7jI2Px2fo+BkIsurfVB2SeofPr6MGg2yK7aPuBADlly/QbdBMgW3wgvjs9j/WxttBMLRTweA47eYp6CvjyduskBiBV7swzEA721wmky5lLbvjOCUQxi91hwMBGeUmGNcNMLHhsjfRyVlCZ15abmkvYD/ncnkT9Z6hZ9BB4AADMb5BellKzAYj9lOtKdenm4eeAZ6aFgiGGytgsHHHJcIYudQi4j/q04eYPDiB6kU/cdn91k3svk8BSQ4MDE0OLYybEczC87lkOaQ= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(7053199007)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eFZsS3ZiTnMrNG80dTN6Mm1YMS9ILzNWc3ZtY0EzcTVYdXlmT3VRL0NlQUpm?= =?utf-8?B?RzNRaVpsWFJmUDdZNTNIVnZrYnVFQSsxQzdZbFhkTk8xZ3l4bW1VYXdnR2Fz?= =?utf-8?B?cGIxdGFjYStEZTJkNEVOU2QvbisyWDhTeWVxUnRRajVnaXV6YUJ0RythSnFB?= =?utf-8?B?Rmp6b3FrZ1Y1U1VwT3BDOVQ0dWZUMGcwcG51K1prdDhmQ0NhejdLYm5xcWdU?= =?utf-8?B?WXVycERFOTRwZlliVVg1Sk9oQWVaTi96em9wYXdhRWpZVjdpTFkvNXlzNDhE?= =?utf-8?B?Nk10cmlMT2dEeWNmbWVCMC9HOG1DZ2tMSTMreTA0TTRZSWQwaGttVk5TUmNq?= =?utf-8?B?TWh5SXFGb1ZrRWdZaU1IWkNLdFkzRnk4ZVdaVGxITUNtY1BOUng3ZkcrMHVm?= =?utf-8?B?T1NmR0N2NngxdXo0QVBEeHdUTWVCMFh0QTFrYWRCVDhBUzZ3Q3ZvR3pwSjdM?= =?utf-8?B?M2dqOUlSN2ZZdlVteUdCSWNpZlpHSjJyWEdPY0tVVVFRejJaSkNRaTh4YnRr?= =?utf-8?B?Y3ZsY2JaeTlKSEQvRHh2SU44Q01PS3lMOUJjYlZaNGs2UmljMXBPYStpYWJy?= =?utf-8?B?bTdJVWVSTU1pczBjczlxVTlFQkdWYUNWQUp2SHdTSGo3UDc3QjVUcHdGODF2?= =?utf-8?B?WG9TdDZUU2R0MjgwdmxyS3FtUFpEZkpyakE0dk12VzlDeGcvbWtlQjFuZWU1?= =?utf-8?B?YkJrYlV2Q1ZvSGF6WldKbUdreVBUOXp4UmgzdlZiSmM5aWZvcW5sK3dmL2xh?= =?utf-8?B?UWFueW05L25ZdE5DdWNWNy9Vc0JpWnlvamhrclJiZUJCTkd3TEU0MFhpTWJz?= =?utf-8?B?YytMTDBDbG9WeHVIWDZQOGZBSHU5N1hXcnRrRXBBcE5lcWdSbkppWGdBRzNt?= =?utf-8?B?VFRJeEtuWVhwUkIzWVVaeTc4WWthMU1UUFhmNFhic0gyT21ZYVM1ZG5jZFZP?= =?utf-8?B?dEwzTitCT0ppTG5sQ0Q1Mm1BV2huL2V2cHNnMTFaWXBLbFNTWkdYcGJYTEEr?= =?utf-8?B?Tm5xWk1SckpDWmYySUk0ZmJzb2c2QThUNW5qVEh4VzdsUmpPY2I4ZnhKd25I?= =?utf-8?B?djRNeVA0Z1JyVU5FVDEzNGk1L1JOWE44anBwOUFYeGpGZWs4cnV1bU9ZVzc5?= =?utf-8?B?SUllbmRwVTg5ZHZ3eEsvYlg4bUJickNIOURGY05LdDdkb3pKa24zcHhXTGlv?= =?utf-8?B?dW5CMFVwSnJpNmx0NG85aFhFRG80NDNjb0Vic1owREU5U1YyRi96SWtNWGNu?= =?utf-8?B?VzI2QWVxMHJFRUZ6L1FEdVVXanpZU3BKbHZUSjJpbTd2Q1Z2dko3ZXBZV096?= =?utf-8?B?dk5LdjB1NUZsN1BHU2lVVDYvK2JFYURlWmdIcWs0YlY5c1NmUVVBYlVnOXdp?= =?utf-8?B?ejI5K2RFczhvWFdQVm9kSm1EUENUMTAvd0U1dHcrUlMyWTNRWnhqdGpvV2xw?= =?utf-8?B?RG1icDdLOFFWUm14NlVOZTNMeklKM2s5S0lLdWg5UUVKVTFSalhmakVtQzE1?= =?utf-8?B?NjFkNGZISmhqYzN0WGYyOXhtUTZkMGszcVVKZVRNRnRzakRCVEt4c3hvcG9G?= =?utf-8?B?eWdMWTY0YjhSeWR3bWZHbVBhUEdYK0ZTckRJNjJ5TFpUL1VRTmtENStiOUgw?= =?utf-8?B?YUZHdWlMTEV5OGdNdDhkK3FOK1M1d09pRFdpdjRoMDdHc0k2SVBHeDNFcHVC?= =?utf-8?B?U25OR29lb05tV1JZRUk4RGw5T0FHbW9DbWRvanNZMU5EYzFLbStvSjQvNW9x?= =?utf-8?B?OHVSUjlDZGRHY0F2UlpDT2c1TEpFRkhRRnNkY0s1TkJ0bDRIVkRrYUhFY0dV?= =?utf-8?B?QjdWOE92MXN3NkxHL1pEZDVyVWovaFVhcWo2bGE0NmpCRkwxZWtZdG10NTd5?= =?utf-8?B?WVFsVzBBN2tSc0FxekdNd3JvVXNKY0RFdlFvcytyOUpDYlFmb0J0Tmd6bGVS?= =?utf-8?B?Y0NpMVVXYk4zeC9uRVE3Z00rbkVwVlBIcHJ6emFhZjVzL0hZVUhFNSs0OUZ0?= =?utf-8?B?VFlwRDg3Wk4rYWozNXBldmk0TU12SFFRKzh4K2UwMGhjOWQ0djZtMG05SGFL?= =?utf-8?B?aW4zOThDQml5MGJsRWFqVnA5dUxQL1NRQUlBaHhqRWtEMVJQRnlmRTdjRWhI?= =?utf-8?B?VkNvcytJMTRrMUFabm1nVmNLVTl5UWIrTzNkbzRyTENxNXRmK1Qzb3RjUm1s?= =?utf-8?B?VXQ4Ull5eFkvQnEvT3p2VTI4V3pvYmh1c3BHbDZHVGpxTXRvMndUMm1EVk9r?= =?utf-8?B?eUFBNUd1U2JGd3VSN3hqcm1EN3FHK255SmRBUFVhNHBOb053cW9zUW1lY2Z0?= =?utf-8?B?RmV4cjFVSEhCU3c2SytyQ2kydkt6aUtaS0xiaHhtQlZhaGIvK0JUdz09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f909835-1b20-4d6b-c6c0-08de80126b25 X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 08:36:13.0891 (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: tMjktjKnSigqwsbwvYZUkEhpJ7TpMCpDpDd00VfTChoakHU3+Uu6tHL1KGcTt9r24QFrQSCU+488YUqwwVsNhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR03MB4924 On Thu, Mar 12, 2026 at 09:25:12AM +0100, Jan Beulich wrote: > On 12.03.2026 09:02, Roger Pau Monne wrote: > > When building the PDX test harness as a 32bit executable the page shifts > > done on unsigned long types can overflow. Instead use pfn_to_paddr(), > > which casts the values to paddr_t previous to doing the shift. > > > > Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests") > > Reported-by: Edwin Török > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > > > --- a/tools/tests/pdx/test-pdx.c > > +++ b/tools/tests/pdx/test-pdx.c > > @@ -208,8 +208,8 @@ int main(int argc, char **argv) > > if ( !tests[i].ranges[j].start && !tests[i].ranges[j].end ) > > break; > > > > - pfn_pdx_add_region(tests[i].ranges[j].start << PAGE_SHIFT, > > - size << PAGE_SHIFT); > > + pfn_pdx_add_region(pfn_to_paddr(tests[i].ranges[j].start), > > + pfn_to_paddr(size)); > > } > > > > if ( pfn_pdx_compression_setup(0) != tests[i].compress ) > > @@ -233,8 +233,8 @@ int main(int argc, char **argv) > > if ( !start && !end ) > > break; > > > > - if ( !pdx_is_region_compressible(start << PAGE_SHIFT, 1) || > > - !pdx_is_region_compressible((end - 1) << PAGE_SHIFT, 1) ) > > + if ( !pdx_is_region_compressible(pfn_to_paddr(start), 1) || > > + !pdx_is_region_compressible(pfn_to_paddr(end - 1), 1) ) > > { > > printf( > > "PFN compression invalid, pages %#lx and %#lx should be compressible\n", > > Largely unrelated remark, from going through all of the PAGE_SHIFT uses: Isn't > the __LP64__ conditional excluding quite a few too many array elements in > main()'s tests[]? Hm, I think so. Will send a separate fix for that however. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Mar 12 08:49:10 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 08:49:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251837.1548684 (Exim 4.92) (envelope-from ) id 1w0bj6-0004Dl-Jk; Thu, 12 Mar 2026 08:49:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251837.1548684; Thu, 12 Mar 2026 08:49:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bj6-0004De-Ft; Thu, 12 Mar 2026 08:49:04 +0000 Received: by outflank-mailman (input) for mailman id 1251837; Thu, 12 Mar 2026 08:49:03 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0bj5-0004DY-9R for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 08:49:03 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4df6b56d-1df0-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 09:48:57 +0100 (CET) Received: from CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) by MN2PR03MB4926.namprd03.prod.outlook.com (2603:10b6:208:1b1::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.11; Thu, 12 Mar 2026 08:48:51 +0000 Received: from CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343]) by CH7PR03MB7860.namprd03.prod.outlook.com ([fe80::f5ba:35df:1c9f:b343%4]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 08:48:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 4df6b56d-1df0-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mEF7vyC7LF1rOVy0b3NrWFreJyR0pB6J+eAWm4Q+K6H/+rYla8Oh4TlUAs5Z3lSB/6XkyCxC5U0st63o2B6FlifcR7I5YEnmSVh+KXyAQK9+EyhMRklkOVCtpqf2wQffld9iqib9dgwFj2brbvMm+vwkqH/qDd3pOsxLO3jSAwVfY+67YdiG99vS82lISMdrW+1JfSVFjxeCOOO8N66Gm0jvyuUnyATRu4uVk5+Pm5ybwFmGxVCQXE4UEJUJP+lppUJXb0VQGo47BqABtIbVTZprIvuokJmZ4caWLuUNA7SiXA8T4CX1JA7FQfj0GCxHoDp47RdSKba9BdcXrHH+Jg== 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=6O1tRDQ0OEzoxqOQDGf88C+BTZkQUGNGJWGEt8y4v8E=; b=eZT0Wt+jvGnEQ9qyr2QPKGvw6ZAcU5XqI9q2ourS9hNzzUE8UYDSAVsBIVAMCkKvfxomd3rI1UqWJojvY4vIvLjacTzmZqTmNjh9coHWvujIu6Mn0fcF9vBpN/r3Egi6j6GeaiD8PlmcDmmDjFqGgI+JHBjUgg+DvY5XFlSk1jHDuaOTmDDL3G2lYBoAQJnKXLL5sB7PknjBxEe/FYhNrHqAPyRksmWqvGqvjs7CP1tzbGjJjp3TrszXZAjdjhuX+X1KoQxAuMuA4RcZcIyHYF15MA5PYk7sV2Jm0rEfou9gVhNOFBSm8eXmtAZg21MyDWlUverhXSYKjKR8C5oq4g== 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=6O1tRDQ0OEzoxqOQDGf88C+BTZkQUGNGJWGEt8y4v8E=; b=KqSnmKB39BaGPh4NPw/chcva9PHFqRsDJesiqusMnUTYZf74CWUCCjgAAcKrFBzcqcpMR2O1K5lBJfcKSqcKplZ+a662x1aIZSGquCuDzDU41AQbF0+5y/23f0xjk7t5tbc8nAcuXzo7mHdJQL9QKV+1/qn04R194ah/fB2ddZ8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com; From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Anthony PERARD , Jan Beulich Subject: [PATCH] tests/pdx: allow more tests on 32bit build Date: Thu, 12 Mar 2026 09:46:38 +0100 Message-ID: <20260312084638.53360-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.51.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MA3P292CA0046.ESPP292.PROD.OUTLOOK.COM (2603:10a6:250:48::16) To CH7PR03MB7860.namprd03.prod.outlook.com (2603:10b6:610:24e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH7PR03MB7860:EE_|MN2PR03MB4926:EE_ X-MS-Office365-Filtering-Correlation-Id: 6feedbfc-285d-42e8-eb1c-08de80142ffa X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|366016|1800799024|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: bRke38gY1881bgqhEpPGnN1P01VzF/NxOJn7t9+80Jc86Ft3BT0yTh17hqXWfHeGygq+UMmikwY3ISPcShFdjZdx/CIQ6MDOeiTjkJ8SeMjzp3Q+PNVbdvpL4BXB8LmIO5MKx1QUaI+QA46KG1ssV1tDzubRWEopPwggFOTZQbwc0jgLSh0zg1/EvP9zKp2Ms4Eez9yAEI4OUsMFSmCa00UEraVVhBS0Ckos5A9LbTCvO6wFQmCzFP59amC6A90n5JqsNbI5rYnGOuZsYJceSlz3X4RHzZ5mW0aSouZXCXd5WJd/nShov8pcqaQXCEoY7hOnIpSJkDbmQD9UDKLwgZ/rxu9bsrEeHrSzoMkerCbJ4UwNwxPC4QzilZOgfJFCo9v2KjoVL47Mp7G112Ej0yzkFIjzTPQhLFOW1aRcXuA3hX/7MIxNIdnoiFnvphJY3cg94elQxwFPU0eABJa/bwbNCRjTNrWixc23zFFnEH/QBkAhjIF5cLskjC80EsnPTUjAR1u6EWSVr+bMvC0zWvswJNn2y185E9f2IIxqdT7zCtiLlsT6ELuqEXMopvC+dWIAWv4ZFnd+h0B5amPqxMa+aEWvu09rGmEUwiIpy+PfIaI/v2xbN92NYbwa25iCeKFXnRQOJoWaHBTwrXt/eCkqr2NH0xXUPGq4BhnomoRxrk2ju4OSScvE2o27E4+POEfKlj6VxEaY63wa9qpt7Kia3d37cOu8XI8yTXBYBak= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH7PR03MB7860.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VEJQZFhPK1I4ZlNMRDdVSTNGS3lGa0xEL1ZmNk4vR2ltdEszbkdPVVpCOHRm?= =?utf-8?B?R0V2U0liblgwMkpIc2hUaHRPa1pvYkoxNjh3SWVwTFh0SzNGSlBYTEdSemRR?= =?utf-8?B?dDRYSWN3aUZaWXluOGFKQkZvWDNBT1JkVktnZnB0UlpldXcxaURYSitTTzRY?= =?utf-8?B?SVJFSGh3TmowTkxTSDZRSnlOZ2NPWGRvM0YvTkZxbVI3RzAwbisrNDcvTlF4?= =?utf-8?B?Mk9iVFRMM0tCb3IveG12VzBQdlYxSHFKcXZrVW9NcTdlMlNQSVBiVWtPUE9s?= =?utf-8?B?Y0ZmNG1RUmswZi9pS0lpKzFoaXl1ckQrYzM1dWRWcHYyWUpoTU5GN0hjc0Jm?= =?utf-8?B?dnpBTkoxQzlrTnRHZ3NycjF3Wk1RMTAwamszWDBXUjZTcDAyaXpaOGRGRUFx?= =?utf-8?B?K2hRMTk3ZUJOaVZtTDFCd29KR25RTFBCK3krd2hJSldCR1c2Y2N6RjM2bFZw?= =?utf-8?B?M3lRYWZiM05EaU1MQWE3eVdPVnlLcEF1YnlUeTNpdnRTdU01MDFCS1l2Q1ZG?= =?utf-8?B?K0ZZeHNjdkVkb2EvemNhcDVTMCt6M0NSUjBkb2NCZE1YanduTEV2Ymg1Z0Ni?= =?utf-8?B?V28yUGswVkNMbVNEckZjNmsrK1BmVDUyUHdZaTRaSnduOTQvRXJaWGU2OHAr?= =?utf-8?B?Rll1VjNBdU8zWTVyaVhKbWtmdUNrUFU1Z2RLdTRjL3p2SkhFZ25lZTlETTNx?= =?utf-8?B?TmlDRjY4K3VVMWk0cHZjc0lUN2dOd1EyRWl4UjBtTWNyQXpXZFFSZEFKaUtz?= =?utf-8?B?bHVkb3g4TklNM1RSZXBPSmxiS3dvZVlIWXY4N1pRSTlNRlRxb0oyWFkyY2tm?= =?utf-8?B?QXJkSmgvdzVxS0NNMkNlRDZib3VDNzRMUmZyanJWOUVaOG4vRW5QQXUzMEhT?= =?utf-8?B?Q3RiNE0xMDBrRFRXY3A0NW11ZEhFL3FueklyajFaQUdSOWo3NlhBM1NRUU5t?= =?utf-8?B?aExkNkdNQ1VzL0RkN2t6SGcvTlFZbDBDUzUxbFR5TnBVQnZEeXRndXFpWnBk?= =?utf-8?B?Skhiblo5TWFVUWdEZThHM2pQbHBrRjI2UlE5R3ZHcVptajQwWUV1WExIVDNq?= =?utf-8?B?RmRCTG0xQVhlTFR4bUZzdklPcnhmdEhTVmM5UlE2dDIxcGxSNis4ellhRElC?= =?utf-8?B?WDVLWW4vWGE5cFlyVDZleEltdkhnZmdJcHFhb1FXdHNpbDRKZTZIZEg4YWU4?= =?utf-8?B?STVZUGgxUy9yYkJJRjNqdFUzZmZPWEFYdUdVbUpRNzZHdi9hdE1PL0dJZTl6?= =?utf-8?B?VElpQnpMUVM1VjJHTXkrTDRuaU5uTUgxUFpJQlhWZUpZemRKNC8xdUc3azdl?= =?utf-8?B?MzJqZ2U3M1Z3bTVlVjQ3eW1VVTJtVlFMaC9FZlExSzFYUGdBaHRpb0VyQmdB?= =?utf-8?B?RHNQclg1azkrcEVLNzFWREZ5Q0JhQWtpUVNJTWh3ZmdoMXR1TzYwdUZlb3I3?= =?utf-8?B?eUd5eW1MYWYzamxJay8rSTFIa255Qkt5QUcrL25wWVMyMkYzdjQyWUpVd1J1?= =?utf-8?B?YlA5Nzdnc3diYk1FNHJTNnRmbHE4TlpQWkFtVmRlbEZaUStXVkUreisvNUtt?= =?utf-8?B?elRtRklkY0NadklkUFdkUVFZYmlOM2NVSHlydzgrVGNneGtDSjhlMko2ck56?= =?utf-8?B?UFVWWmpFdjA5dnBtSzhOT0lzMFBVdUZvRmFHSTE0c1FlWWtEZ2JZdUhZUnhT?= =?utf-8?B?K1h6UnF4YkwxOGhqVmpIdVRWRVlIbmo2am42dmgzMmNweldXV2NuZEZZaDhm?= =?utf-8?B?MThRUEVnUS84RzdNUXZ1WE9lVXIwcUxzSE9DZlZaY2tiTzhidzFFUVRrOVZR?= =?utf-8?B?UklSVnIxcWIzQTZuOEt6Snc1RFlKdzdicXFsdi9iaUQyNFlPeXhxRENXdk1H?= =?utf-8?B?a2RaZ0RzejZjTitpTi93VEJUTmgxQktjUXhlTktGQUZVd3JzYkRFUGRwcUI2?= =?utf-8?B?QnBOdXBQR085dy9Gdm5PQmxYYk1vWkJ6bmJtdVhsZ2RiZFVmV1J2SEdLREdB?= =?utf-8?B?Y1FGL3U1ZVZMbkdrVjFmRmxEMkdGTW03TVd0UmhrTS9xQnN0U0FDNzJIVVpp?= =?utf-8?B?OWk5NkcxYmxxZGtGUUdaaHBnOVNpY2owSjhGaUsvZEgzMVBYQy9la0p4NTl0?= =?utf-8?B?MnJWaWJURHJHWGtNcXlGaUduVjBSeXRYMVNkMjZML0JLOWFMci9HRkZHR0Yv?= =?utf-8?B?NS8wNVpQNmlJTlV1cVVrd0xDSnFWSjBuMURHaHBZTHRCK2xhRndaZkUwdUhZ?= =?utf-8?B?T1J4N1dlZzNhQ1VzM0Z2ZG1OTEsweGNYR0JCWGh0VE9KS2hzZWFHWm4zZ2Rq?= =?utf-8?B?ek5nN0xkRDdHa0FkRUlyYjgxSmx0VjVlS3BNSjNHM2NVMFVFY25aUT09?= X-OriginatorOrg: citrix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6feedbfc-285d-42e8-eb1c-08de80142ffa X-MS-Exchange-CrossTenant-AuthSource: CH7PR03MB7860.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 08:48:52.7642 (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: 0D94nBKonVx/nWR2RgwkEkUAZIuidvNzjCPMbIVJFh4ULzEkDgFsOY/L5/cZ+5sAG4Xol98nq36cH3+hnoH2tw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR03MB4926 The limitation of which tests can be build on 32bit is too strict. Move some tests out of the 64bit explicit region, as they can also be built on 32bits. Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests") Reported-by: Jan Beulich Signed-off-by: Roger Pau Monné --- tools/tests/pdx/test-pdx.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/tools/tests/pdx/test-pdx.c b/tools/tests/pdx/test-pdx.c index 066bd3e7e569..d783186577ef 100644 --- a/tools/tests/pdx/test-pdx.c +++ b/tools/tests/pdx/test-pdx.c @@ -77,6 +77,17 @@ int main(int argc, char **argv) }, .compress = true, }, + /* Two ranges with the same high bit set. */ + { + .ranges = { + { .start = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 0, + .end = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 1 }, + { .start = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 3, + .end = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 4 }, + }, + .compress = true, + }, +#endif /* PDX compression, 2 ranges covered by the lower mask. */ { .ranges = { @@ -132,17 +143,6 @@ int main(int argc, char **argv) }, .compress = true, }, - /* Two ranges with the same high bit set. */ - { - .ranges = { - { .start = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 0, - .end = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 1 }, - { .start = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 3, - .end = (1UL << (51 - PAGE_SHIFT)) + (1 << MAX_ORDER) * 4 }, - }, - .compress = true, - }, -#endif /* AMD Naples Epyc 7281 2 sockets, 8 NUMA nodes. */ { .ranges = { -- 2.51.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:09:09 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:09:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251851.1548692 (Exim 4.92) (envelope-from ) id 1w0c2J-000796-5y; Thu, 12 Mar 2026 09:08:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251851.1548692; Thu, 12 Mar 2026 09:08:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0c2J-00078z-2v; Thu, 12 Mar 2026 09:08:55 +0000 Received: by outflank-mailman (input) for mailman id 1251851; Thu, 12 Mar 2026 09:08:54 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0c2I-00078t-2a for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:08:54 +0000 Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [2a00:1450:4864:20::330]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 172c1f89-1df3-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:08:53 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso6552425e9.1 for ; Thu, 12 Mar 2026 02:08: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-4854b0b906esm56305995e9.4.2026.03.12.02.08.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 02:08:52 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 172c1f89-1df3-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773306532; x=1773911332; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=YzdoxAlYV8Tm4mWJQuIbAT6rS2yPVOYFZZrpTVL28WM=; b=QGCKGPYATs2XVEIp+6npNzKKPGN/uSt4diQvTa/0gQZeeqnyFrnF40TyFsISn+W1bQ ZADkdJpeuTeTju56/6cwQdw7dTPmuyTLRnPy8+MPh6UKaiqCIz7my3QqPGzwvepqxn4E 4jnl67eO0Y79+VOXE269AewO0XNc9oMCXiB7Ez1ukI9TeR0T0uql86R0zy30SfoAFDP+ FQWMzLV7uwQ3dI24W6C7Aw6y8W7ktKPQn6ntd2Hyp5Ion5J/+fTdtnIJIgEEGbaMAfwj j4Y8/Dy4IOliTUuVGcR3Xvbqv54FwgVCNnLFgzMY5AUut4kHypqX2os8CDK1EsokrucY HF3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773306532; x=1773911332; h=content-transfer-encoding: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; bh=YzdoxAlYV8Tm4mWJQuIbAT6rS2yPVOYFZZrpTVL28WM=; b=tFJtPYiIJRA+Ytdh32BBK5oXd7iEtxaq6MN4O97PSAAe10PGH27QayGqwwtbQDPT25 RchcqFqmDeMxWy6xOjbK5RhYf3Gnwoee4pMOvAe3gZ5Q48YZSkDX9HK0EeeAer/Jyw7p 5R17/bkiQxoELZewnPyaIuiVXVjcLQqdHookINvw8VUjIDy9IJpl0yLVYF3W2C8yGce4 4odmpM629pTmlg+mJCfCdRsKgX3E1ww2SJ8JMw2eZBbrcExEGROKM/j/RZX/LtVS9O3S 95NSrIyfn2qx/8aOcdvvykk8Pptde8C6HtVXmUXKEU+hyvEJZEaOW5MM7As2Ko05FTxh I0vw== X-Forwarded-Encrypted: i=1; AJvYcCUZEIzD6de6z7QG7alAJosJ/Ywui2CUGfZ4HRKdUS49x1kcm68EWAn2iiNdyEDmc+zwCX6w5FrIUFQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxFxMEecHTEFJVs8leIlBA3d72aTS+QQhbyJXH5lqOUiw8ei+d3 qyHIOZWXcm77qpBkwqagBxPyzgQh3HJUro5qNFT/R00pQxYlx6RL7FUO5wd4/yaa0+mSVp4JyGG Tabg= X-Gm-Gg: ATEYQzz/4jfces7j6cLjMqOvoj5vph5UAioeGSIisqzCvi7BGRQEYiilDeTddh56Jym LwrIMlTRfSSxJn7fMRrNVpzv0NT3Q7zZ/a5qrCfHEEcFjhE8x30HkAXk0hZj+RYbTsozJ9TFUbg d0PheMZmJoTcaxp/1ENKakzt3m5v3Haa1xTWcwJFJl5DGQDVuF3QR7uhhl/40bDqgMFPlJRmIuz yE0S0BDvPDge7YISefss2OussGxsseymvc2bVdWvPTw1+UyiYXvfihgZJL95zB3a69ElDy+cqsp 7Ihs8AX81YePsD9BN0YFOvhjf9w5uGfZXhHOMB86iOADU+b61vGphJe83+JCBOl8HkRXNwQY4xU IjJKKF3dTvPTP0ZD3jI/HHJa+mbD+YGbwR7FST5boz/UmtMv9ai88XkWX40aKvSiz/g3vWQuv96 EiJ/Ay3eGGoYz2Aa2CySGu+HF6yQXKJlzhLK3HUj195YiPAT+34v2JvkFOFwA4EeOmDJLNs4aH8 /VeMsXWn/n84bY= X-Received: by 2002:a05:600c:3f0c:b0:485:3a27:a961 with SMTP id 5b1f17b1804b1-4854ad770aemr95732335e9.0.1773306532342; Thu, 12 Mar 2026 02:08:52 -0700 (PDT) Message-ID: <3caf8256-971f-42a5-95a8-30c02c64775c@suse.com> Date: Thu, 12 Mar 2026 10:08:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tests/pdx: allow more tests on 32bit build To: Roger Pau Monne Cc: Anthony PERARD , xen-devel@lists.xenproject.org References: <20260312084638.53360-1-roger.pau@citrix.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260312084638.53360-1-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12.03.2026 09:46, Roger Pau Monne wrote: > The limitation of which tests can be build on 32bit is too strict. Move > some tests out of the 64bit explicit region, as they can also be built on > 32bits. > > Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests") > Reported-by: Jan Beulich > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251868.1548702 (Exim 4.92) (envelope-from ) id 1w0cW0-0002bs-AN; Thu, 12 Mar 2026 09:39:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251868.1548702; Thu, 12 Mar 2026 09: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 ) id 1w0cW0-0002bl-7T; Thu, 12 Mar 2026 09:39:36 +0000 Received: by outflank-mailman (input) for mailman id 1251868; Thu, 12 Mar 2026 09:39:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cVy-0002bV-9E for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:34 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5f96c4e9-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:32 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:29 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 5f96c4e9-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=qbkA9KjVziARf69ofAqkwQiX3ZbRjhzNi67pgsBQJrjkq8TS4bjqyCcO47/GefOYv0pncXHK/W+Gi438OodLA+i3d5lQlzB6lbTZ5drGaa0grPCY7cv10d9ar05lCy05Z6rFls23B+JuKkVbLyglKFsjbZnErd5bdu1i15PBp3hKz61vykdhcYVzoxMEu6jJThoD9+8h8s2m1CBBkIXt24vR51Gqsxo/Y4qQGtxTP9HL/ofWvSrDBtzS7rri8tD+ToixJYLhKk1hpKTtzFJaHfo6f/FKRL+NYCzCOpvn7hxbno2DsW/9D3W2lrWnbP9SrxaTAc63EtALEYQrZ+1XGQ== 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=9h1bJ1/tUn7joR6dHEgZAHXjj+b/8RL4Td4YS9QK0Eg=; b=NV2xCkIqILWbjr2ivSLTwC7mf6AZxsU1KPk+3/0foci24hniPfrmKwK8797SXmq23o+lYh+H4SY9zO5X46qA903MjPnYeJ4M8PDRH+GiimYaYGnr3Sl/8tEw2mK4CYGX8BXnkdDnALw/tmypgdbI22H7PcLlODi9XOCdxRg2zNLLXXgnGIVuzXVN45peesS5i7Ye9FW2HM2NxZ69qOAedwcEhD0lt02FN8Pc4H1aaOjjnaWal5eBeCru/4fWjelMpnYli8ib+A2B/5wCN3dZyw7lV6JXE9Aiuf4fLICHDZZKWN+7AybfqOjLll1mgk42sOEbvLnGBgrKvf0f8EskIg== 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=9h1bJ1/tUn7joR6dHEgZAHXjj+b/8RL4Td4YS9QK0Eg=; b=NGL0LPiL4jjW7SIqtuYEAfWGf02GPkDBd9APSvBFTMNtF/QiTjcJqcNIC2HwZCy0kQvmtOh96yYi2NuUyaEhZKPwZWEzqdZoGXZ/aSqM/Lfo9X5Jy/9UEiNl2FwP7krwM9jkFuXeKxG2sj3CgyuNqgqCiMfXK+iN8b5wshBSrbPlNZgsYg1aNE3bVtV+4+WAXZpCzoCJPV9+4wIhwGF3/J9wqcwle1Q9rDlBG4ZdYECy864VYtJSmiTISws7+5bH0uxPZOmb3gyDBO3QPNalYkNv+rYR4NM7vJk++aVkzks8o4J3m3pfkgHgF9ySlg73FQSaottxk3Ay5Kbpe/zC+A== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" , Juergen Gross Subject: [PATCH v6 0/5] Implement CPU hotplug on Arm Thread-Topic: [PATCH v6 0/5] Implement CPU hotplug on Arm Thread-Index: AQHcsgQf1/22PGqzSUaxhkScWwfAyw== Date: Thu, 12 Mar 2026 09:39:29 +0000 Message-ID: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: d6c1536e-738b-49ac-a853-08de801b41f3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021|18002099003|56012099003; x-microsoft-antispam-message-info: VK7j1nq10PonOFXwy81wZhiJBf37hOaXWIYicX+Sji8Cep8AKVdwM1Gu1Xo75XtaG7ZLcZtAF0R1NU6PoP435YVMX0LDXvBV1mpq/+ur0Xrytzg651RT5+51KTXyYEZ1vdoX0CszN7DbEP1Uz1tQF44U1UpCvYYC1v2JzIbxfRUC/F18b2qM2NgNF+B0XYWWpjM2HmaPo0z/znrPid1qW1BfiW4e4WxpRl818cZ+fHU4Jkm2yuWmZUASA8M+7xGSaSUYIRVOrj2MhUsFceAKT228dDDBLAdqFgNE8ynLWOLlHcmZtJE0x8L68Eo/1fzZrRy+TeM1l6FUudkLILITT4jbFoALBQJNnuhSShjvgbHfBDMM3OtFf/645FAyTcIDIugiYOkG0QSeOUBBWhs5aaH7d/ryBYRjnvqxNq8AETs2Vg8TEqFNYNkdyMTYIwHlxQKiNqGQrxwR3bcaQ0f2eUeGyRGDZl0n1d4JebGc2IemFitpxDzrDqjSfaJkQlm04h1X+PNlorayovsi8JPjDHzQpUp+GA6MQFIhewKREYnj2snfRNW/7SNOwE2lEL+5mU3/agXJwjnA9hZVHDttP6j+YFHvC3x+VveRlyDg6nqIRUBTclStqTxkycQcetHcJHu0JSV+Tedsrq9QEIiOBJXdOA9vgjxebPsqZUHCMXjJ6uZ1G9fis7puC7Y4KJxr2ze1alPZu5NMntZ3s99lRHMX35xjytzE9YhAyozYHuRtMuM2ywbR42V8NOm8bI4FQb8rrvOufLTcH4Y1rMQn0OKToCeFB3m+zReDQIG097c= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(38070700021)(18002099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?5oa7z1DZpUYtoPf2GcsI4aUfPROHr8uTjNkH7mrlms7ED56mQV92eDai/Z?= =?iso-8859-1?Q?BkdwDTHuIUBVK6m6bwfJi182Jbfmuzgn0P7WzuJglG+FjN4e7nsUT0GFLe?= =?iso-8859-1?Q?hVqlFAEc+aDtzzKVQsT549Sc3RcMa55JqxyY1fqIsc4OwlCkFQoGaAwCqR?= =?iso-8859-1?Q?0D6Ix76vsgL05pqvOF7sSMtrVaM4q5bzDzQX/vSLwbSwbtCO25J1cdWOBm?= =?iso-8859-1?Q?9Xm5UroY4IqS/WCAfB6m4L/8xqQ8hjKeVq9766Pftu10blI1wUp2g1i4cK?= =?iso-8859-1?Q?EhZGbKhbBE7TGYKEZPNY9PhizLrB1SjAxJXtNiyu/ryrYTohCC1G/gaZCK?= =?iso-8859-1?Q?OMZubm5rbf9LpHxnQrUb4/GBFQFQY+ZfF+s8uQkl5LaJ9btmJeXFS9rmqY?= =?iso-8859-1?Q?9Avmp5mRFk083w3IbDJjSyOYXsFST2M2dy2DIORhvZyrCFT5R2s6NlBJWU?= =?iso-8859-1?Q?JEZC3JEMgvFtc2VHjCkfK9AM6hbtH6g8H2VbOF1/CNubkq6hfx8D/k30Yr?= =?iso-8859-1?Q?hSu7grgpFqSTJvoA4CSXOzUvhYlL2RSXNAIw/XNuHdXUXOn+F+h0o7BAAi?= =?iso-8859-1?Q?7KL5fmMTZV+otUWBtW4VCfB1y7/m7vVltY0z2Dd2/vicVkVsqcOvM7LSbr?= =?iso-8859-1?Q?f+E3AqCdxzWwu/sQoHSg3tslX6OqbhGOPTUHWuJQebsn2RNTZNct43g5i/?= =?iso-8859-1?Q?p+3ThCbwNf/iVlS5ft47dCX8m//ijExu8ij6oHnd/UNoN8S/bc5ypQtMBR?= =?iso-8859-1?Q?K0IvNbQO3XBDD1Aq101oyFRmMbSBAv+7PyO0LaJ2ILc0PNDO5Cop0x4i2p?= =?iso-8859-1?Q?y0W1Z//aMRPNJjxth4kbPiCdkUC7XhV92tiIfw5XIKILWMt5q0RkWGp96I?= =?iso-8859-1?Q?aw94dtVTuJFG34ofFXmRZTJl6cQlI2BsAPLfdd4efQ5j/9kgBGiOUZWXou?= =?iso-8859-1?Q?NSI58Cl1/hoH5NDAfYizp3G4MaDb13xRFD5G+s5Emyde/kmaikS0o4RIzA?= =?iso-8859-1?Q?nOgFu3I+UUxcy3pbbObqh9b7vmnzni8z9/h4m11JMV/ZaSBVp0EPhDj3/K?= =?iso-8859-1?Q?Q4Z3wM0J2F+cGyuLfo0O5E3IBuuDKyiz9IpqoAu3Y1YsV20k41ls7janDa?= =?iso-8859-1?Q?49XCT1grqdC8xLiJZlMRRDGQw1E3bmofFGmWDDyNgbFsmjx9E+jGXOrzD5?= =?iso-8859-1?Q?s+c2/p2JfiexiblDO2q+oIn+eaoDNIGek4rZs33CbtlLHuh0/+HLCx1+h/?= =?iso-8859-1?Q?lGBSXcCS0N0vY1T7cMvTcFay4O9LVwu7AB1+rIISwOTnVwWUhsigm0eg8E?= =?iso-8859-1?Q?0EIoXcl4s0c4UFGP0ChPByM4IWGK8P1lXkV7jOv0VUeGwAFor4IkYfFxTM?= =?iso-8859-1?Q?1JF8i36/OGvFKGPAFKUDL5vZWKx+FqSoaOi2YiBwxvh+eFg+D/ceOG1DOu?= =?iso-8859-1?Q?/L1p8agwXLgmJrQEmAhW/pJ7rPwRD14NMh7fpEEFoGGw3hyNH2ZlqWu/WP?= =?iso-8859-1?Q?6CnXCI4mQClK1QLYBLlffCYEQzlCQS8uKBaQ752MkYvS9zQ8/WaWnMTaWK?= =?iso-8859-1?Q?4yHDtnTZ1PLKZydqxttiAIbtNER+E5Tu66ZXK3yFmFAGV9fCJI0h3ko3fq?= =?iso-8859-1?Q?h/if12WyuvQ5pnwZNM7FZ116DCOgQrobb0rFMpcXbxv5tWrOj6whWPjoo2?= =?iso-8859-1?Q?uzJBarbqgvrg3rIxOF4XVE8DCHmucivNxLGUkOF4cBF6A36cDEVaXKI4GQ?= =?iso-8859-1?Q?r016eTQA8cqzOXhTxG9agsKYR1wIuS2Fi2yB9aZE9WvPx+rSrPvrloRSnt?= =?iso-8859-1?Q?WNSAxgVcfdRh/+BaNY85aYJDKKnWgto=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6c1536e-738b-49ac-a853-08de801b41f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:29.2000 (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: bypMesatOo5iUQxHPzeat9R+xoP3+7zEzqdUanOLZhGBY8wI5De3VoUOjWH0vaO6zLd7ia0jj2xlOwyB14dACA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 This series implements support for CPU hotplug/unplug on Arm. To achieve th= is, 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. 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 (5): arm/irq: Keep track of irq affinities arm/irq: Migrate IRQs during CPU up/down operations arm/sysctl: Implement cpu hotplug ops tools: Allow building xen-hptool without CONFIG_MIGRATE docs: Document CPU hotplug SUPPORT.md | 1 + docs/misc/cpu-hotplug.txt | 50 ++++++++++++++++++++++ tools/libs/guest/Makefile.common | 2 +- tools/misc/Makefile | 2 +- xen/arch/arm/gic-vgic.c | 2 + xen/arch/arm/include/asm/irq.h | 4 ++ xen/arch/arm/irq.c | 69 ++++++++++++++++++++++++++++++- xen/arch/arm/smp.c | 9 ++++ xen/arch/arm/smpboot.c | 8 ++++ xen/arch/arm/vgic.c | 14 ++++++- xen/arch/arm/vgic/vgic-mmio-v2.c | 11 +++-- xen/arch/arm/vgic/vgic.c | 15 +++---- xen/arch/ppc/stubs.c | 4 ++ 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 | 33 ++------------- xen/arch/x86/sysctl.c | 21 ++++++---- xen/common/Kconfig | 6 +++ xen/common/smp.c | 35 ++++++++++++++++ xen/common/sysctl.c | 46 +++++++++++++++++++++ xen/include/xen/smp.h | 4 ++ xen/xsm/flask/hooks.c | 2 +- 23 files changed, 296 insertions(+), 62 deletions(-) create mode 100644 docs/misc/cpu-hotplug.txt --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251871.1548729 (Exim 4.92) (envelope-from ) id 1w0cW2-0003FT-7i; Thu, 12 Mar 2026 09:39:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251871.1548729; Thu, 12 Mar 2026 09:39:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cW2-0003FM-51; Thu, 12 Mar 2026 09:39:38 +0000 Received: by outflank-mailman (input) for mailman id 1251871; Thu, 12 Mar 2026 09:39:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cW0-0002bV-ME for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:36 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6108d8fb-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:34 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:31 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6108d8fb-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=UbO9QMvNEXNJbjC5zad+7U4SMLE9fXhIhaxFLr6BlLhT6/wp8YoSIc3H0I8J8HWukrrwGFgg4ehllq8kjBkBg+NdGO7S+h3G/vaboiuVlyB+6HRaRQJaH85044ZHsLHQW5lzW+KtOwgqPTEhbsbJIa7W890VT0PpJW2tYXsQsUvoNAmfmOGWhj9v11g+OAb5wnuz52bTlPCcCl6SA5+IvKXpT8PipCSgCt97DVhILG7/ZlInA7jmkChR/HgI/gVkENxauUDiDYbuXQYf4EutkpKHjQyGxiJGYtRtRy6n7d/OLOmInI6cwkOyb8/FGS7whsHBXHtTlklVetDPVCkBEw== 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=yuWtjPWNU9VyXa2UEJJGgI+NAzHMcQ+u6cR6OJhOvo4=; b=sVTmUMAVBwnKvuqyCMsed4Z+WMQKa1Qw7Ln/ew4NxhG+Ny1Zdx38Ms8AAptQI04FAcTZBHrhfK6skHIcig7lNW5UlQUpjxnokIwP/WPaiV2vcw+C/OuYbxn2oUKGk0Yumy2l9b2IzmwtzDGLOo3zxpNpIIwgk8V22lfmmSDAyrQqhjRyBi1XIzbr89adM3YR9PVfrwKvuXud5LWizeMwVV/2TFlMEdudavB50VIUOHbdA8w441/bEvx9uTj7gNrVRguNqVqW4ufrg4iEY1hmhF0ENkeCxCEAHvklcM4DHUgnSVPJ2pWPV+ueC8+s8Bg6htkfA+58TkCs9o2ISI/2MA== 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=yuWtjPWNU9VyXa2UEJJGgI+NAzHMcQ+u6cR6OJhOvo4=; b=N3p1Ci6SYsi+Wq1YIzaR1PbjbJKNNL8uSBFkmvgKslpLtHtub6D1kqCEydb5L6ooyi+UhnJKri7LkTUWDlFaJCoHnj6O+8R1C2OP+e5omeV5MgFAzHADdkqR4PIY43R1/apyHtTSLVJEccMUGe/CFocgX7zLUXdcA/673DpUYxr6MBxjiZ/WoMaNQcpvJyuOr+6zdCTzsxiBMZYLNuRkwOoXyReCK/e9+z96eZBlXwv/D7GGVGge71k39UyTypKLbmrjLDSK4VoOE+qUB577VYjcF+7Ce4rtJfcyWpFXxbzcoBbi5KD/b4RZCC2t0S1mAVgU/UHrvtTZIP5leaz4gA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Anthony PERARD , Juergen Gross Subject: [PATCH v6 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Topic: [PATCH v6 4/5] tools: Allow building xen-hptool without CONFIG_MIGRATE Thread-Index: AQHcsgQg0i4vH7ZL6U6laBW0/JcXiQ== Date: Thu, 12 Mar 2026 09:39:31 +0000 Message-ID: <7447a69b84ca9d737b04efca326f2bb884065f17.1773307749.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: 51a24de6-53bd-40a2-ae0f-08de801b4325 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: v6h0aMpisgspyyncuiiN8bFUE+hbKmFm0H1QqFs0qnIL0t7xO9VsTu7GwmFlUbN2FNd233SkyrE2doPRvJJtIYn9skk4XGdIZhc3cErWlsZZNmT/MHiE8sF0zO+XwG9S7plE8qVSME93if1Zhlqhzzecu689gEgNF/MHZf7ZE55zmHhJqG4eJpg2rlsdi6buEjyXYW9TUAwtRGRIPUv2uNV1rpKCnXL4tjHALv+Ytj3OIWDVEa6L7/W22XDOP79iijg66a3/uqFzZBJenUWLuQLBxD0gb3f9yCuruoqjuA4qoVuHQpVIG8s0kJyMf6f3JATmYuHPKRruHM1X4ssHiJ4DOIiHV3NnOxkbj6Rm/bvXNHPRqQtkNM4GBGsIuw5NhKOXkI0fNm99WzZ7f3l2VyGHMTYFTry85TXwA61/qmOpaHVxr6cCbvhL1J3IsGspkar1zPc2Jgy/Xr4mdNNuVUi3WO/qV6FU0mWltSnkziyROZvgyvz7aOL0Ta2bVBIowwV7MdPHxDV1YVlaMBdHZgUXsZQF3L+yjw069mPgz7UnFH4OiXnBi/yX0e1V4RawROrgxyQDW1o43JAOkxBqJ8GXVO6PPKrNhKPHCu5UZTZj1KVnU0+BnA1N1MThz99XZWWenUBZQrElteLixDBgOFArPNVAa3n13gBzrMX2ewtXeDsniSIBMCV7NR7iZsM4DaSIH+R/CTgpWSnyMd96lHQY4LBMXALLPisO7ldJbo+AWvoGw0KfxrOCD6EUZUU9g0k+7jlynLxyOjCdnpC6zjIxfdwt2zKJjR37OwUmLvU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?A/Zh90b8syS4YlfjqxfFtYp1gBV9F23r6DnkixHCTILPJp8Ys9hda1zmaY?= =?iso-8859-1?Q?SHpjPsVDYsVVbCsrH8MnmpFx5oa4bqd5gmd0NigGXY7OYBJE0mEKG4VQJG?= =?iso-8859-1?Q?AYaHTrJbvEMIBsm8QmHnKz9QGxkjIZHtDz/+vALft7USnqsX9eUdrm5syH?= =?iso-8859-1?Q?DJiKCPjmlg33OKO10w9rLVqwQ94g3XxPTfAMp88RcpbpE8F1+j+2mIP1aH?= =?iso-8859-1?Q?u6QYwK/2Fv+FjkDiwW3axg1z58arhcK3iVmET+si02U8vil9hQf1+ZkiPY?= =?iso-8859-1?Q?jkhShIhD0TFy1iQeTFBtUi/UefVg3rKRp/RtbdcB4QCwaqLlrxH5S/aKvF?= =?iso-8859-1?Q?nOQ3aDTCzlO3w+mcCKpHnpdWL+be6C7VJxOFq6EIk1U41d6Kz8MFBu/zBm?= =?iso-8859-1?Q?5ExPboaY2G5nQqtLpgadii+7Y5ZgsJ8KVFx515Kyfv2jwIFE22cpKs7HSt?= =?iso-8859-1?Q?Xk7n7hx7qwn1k7mKe4v9Gfi0F23DiD2PBc8jD5srJSMIJMY7MQ2m/s3TCH?= =?iso-8859-1?Q?98u7UB+aFOt/gwJg/eyMuL+LrX4FrguTDeo50QUpCjTp0q4fCkUyyExqbm?= =?iso-8859-1?Q?+v4hzMN5dSTCP6bQXY04UOqaJSFAVMasCD/gGKxCRadkffQgvsJRQ21KRm?= =?iso-8859-1?Q?hamTNlnkT1dKpO28OQ3jq+JiMRsL4F9wYksDAmChrBS9TYCaKj1tbNoR5U?= =?iso-8859-1?Q?ipmMsw7BB4Paejb4gPAiCf11WAikhHM5ooUpviMDUKaQVRghumXVfbSBXr?= =?iso-8859-1?Q?lv7Vud3mzSxOSaEtpglEaOd+gbBAKK/uL3/LARXmCq0RstBbu+l4odzG1A?= =?iso-8859-1?Q?pNOS+kOBdj+PYSslTG9IkDOhbtCuYd1iKCT/SlPR8WFGQRKucZdX0Prvjt?= =?iso-8859-1?Q?yio2QqIv/yDMNn3PNAwma4TQz58rXR3dExwcTemKr8lu+SMJYgjleci1m6?= =?iso-8859-1?Q?dVe+WpKGPhL2FxKZywEOcBniFWqTsaMCirRMo0al4Vz6Px8+W1oMgHOdb0?= =?iso-8859-1?Q?gdt1aV2oY9VHxKYk4CyS3CCLHOvrXhFnnAp7NIC93dOZKgrR5KymKLzQ0L?= =?iso-8859-1?Q?4nUVw7ze7MHv1u05xzV+1UC9JkmPe50rB+Gw07rdzJ0sfjzVD+AzUgrOmQ?= =?iso-8859-1?Q?y3LpRsyMWFEtY9+4y10zfzztafkQ+Bp4Q8H7MtuP8aElJV+YbKJmRws4vO?= =?iso-8859-1?Q?zDecNkectBD8dzUrwD7aSONBlcMHDl0JtkDLuPmvAv4/REMIiKkBf/SmaA?= =?iso-8859-1?Q?1r/XH+I9EpHOIlfhG9uQzTX8GyolEbPlPICcGV+kb+0fcy+hgXRZgG6evv?= =?iso-8859-1?Q?NULIugStipSM196hjVn+PsueHB2Aby0/F9GOP6c23/279D/oTJM3Xj1DOJ?= =?iso-8859-1?Q?vYL6CGy6RvP7eL02o01s01XyGhS1uZldFT8gIhsQUZq6d1FxlYQX3/brYj?= =?iso-8859-1?Q?SVAkDwW4u3eCiNu3nM9IL6HkknIDl9vhsQYYBnOOPSg2rXUUzxL+qyDWOv?= =?iso-8859-1?Q?YBkZsL3h+u0zZh4JnvEb6wXCp2SIbsP5NRSDckcTBqqWyvsms3hEyreGcc?= =?iso-8859-1?Q?cztCB1vxJcFV/Du9NhZ5T72Gt7A1IoBhljaBA2X9loVCgLt18KJgcwtJsF?= =?iso-8859-1?Q?9lrC9GyekPhDKZthP9FwXkk+gKnemVdizBkE+Kexdx2uQ2tJkajUHB2bQ4?= =?iso-8859-1?Q?0QmK7pqbznRfz24q6ZQiTivFQQSAaWJC/QLUANxBT8+jmbWTv90oM0HyDN?= =?iso-8859-1?Q?pBHzEcBMa0QrzwTynGF3MCnHzBulDbzLWnPSJqEqUUkZ4NLhi/ecKgmonF?= =?iso-8859-1?Q?FxJnE18ERjsR1YxJJrtzGVrOYZbj5hw=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51a24de6-53bd-40a2-ae0f-08de801b4325 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:31.1478 (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: kX5h9faaVDjX2+TkxQVP4pcsYBY+ndefZy3PgP/cO6owhuoBv2CGuPDjZmo11+qiLGyKYkK4Iu2wxvNtRNxu7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 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. Signed-off-by: Mykyta Poturai --- 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/libs/guest/Makefile.common | 2 +- tools/misc/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libs/guest/Makefile.common b/tools/libs/guest/Makefile.c= ommon index b928a4a246..03dfcee7fa 100644 --- a/tools/libs/guest/Makefile.common +++ b/tools/libs/guest/Makefile.common @@ -7,6 +7,7 @@ OBJS-y +=3D xg_private.o OBJS-y +=3D xg_domain.o OBJS-y +=3D xg_suspend.o OBJS-y +=3D xg_resume.o +OBJS-y +=3D xg_offline_page.o ifeq ($(CONFIG_MIGRATE),y) OBJS-y +=3D xg_sr_common.o OBJS-$(CONFIG_X86) +=3D xg_sr_common_x86.o @@ -17,7 +18,6 @@ OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_pv.o OBJS-$(CONFIG_X86) +=3D xg_sr_save_x86_hvm.o OBJS-y +=3D xg_sr_restore.o OBJS-y +=3D xg_sr_save.o -OBJS-y +=3D xg_offline_page.o else OBJS-y +=3D xg_nomigrate.o endif diff --git a/tools/misc/Makefile b/tools/misc/Makefile index 6ee783f43e..5a206133f7 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 --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251870.1548712 (Exim 4.92) (envelope-from ) id 1w0cW0-0002nF-Tc; Thu, 12 Mar 2026 09:39:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251870.1548712; Thu, 12 Mar 2026 09: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 ) id 1w0cW0-0002mP-QN; Thu, 12 Mar 2026 09:39:36 +0000 Received: by outflank-mailman (input) for mailman id 1251870; Thu, 12 Mar 2026 09:39:35 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cVz-0002bV-Ly for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:35 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60b2235c-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:34 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:30 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60b2235c-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mcyGktX6VvhueymwO+cddSSUmfwgEk0lJakSCdPKRZNUoiYS0A9rIGA1bkOEvaKqnuMiv8qumNtav/oPWKsan6bFTv5Q7KcACrrm0QCP4+R/pmqLJ1OFvx4yfbqwTxw2tZQo50DAWGvQR+QLA6YoS2gyqHE45AxZ6BYORl4FjHfnpUPy0mEqh0/Nb9d4HL9MR/4mvu8GbNA/2GjeFfODbGGEtXUgooD2nZ31swT0UI6qSS9PHVqFirXuUm7eJdASzpypnriRhtZecw74WUkiAqsqrFM1TwgXoNWELLnZKlN5pdQ5vVrAV7C6iuQKVZZjVOGK+9rzVf8uaX3CS2lNlQ== 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=KMN7VI+QZDaKn6WMXOoMrSaujSAxE6taeos15THt+X4=; b=hzapEPCIvEgu1d0gtUZcUlaEHzjkE+3iChlq2yagn2HdyHDmzGqlugBAG9lTHlKjIHsqQ8k8GxxpRWgrokTWSjk0mzWME1ezZDROjSqFZDqiCnNE3C/70SX73Rod6fhswY1JFirWgRg4ehIDMX1/MUGZtVmHnod5vhlRG4V3Dtbk1JimbXypeO/7nqlOJAqEjoUOHLWRxpmpBCn7clmYZ56ij/N3dVkAsMPAr6uXirqDa9spSr6VwnvFS8rcWm1yQj5pAwgDVodzsXiRRJuB32DCi+jhzIZRgtbkGJU4FJQFr5k/IwLeWKs8xd7EDawnbZSz3Sp8WW7MMOwq9l41Hg== 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=KMN7VI+QZDaKn6WMXOoMrSaujSAxE6taeos15THt+X4=; b=ETkDP465SoW93Rn6P99VAk6uz+oYu7SpccqxyaSa3HztVsZC0UMWtzZ2bFXE9oYACQbuH8ZUF/9GBYw/r/9qqWiAlvJW3b77h245XYrdSpw3R66NcO9OPLiwCiAS5xazh9B1FOlqmMyCKSvRPt72TKPOnQUVD6wVSi92+DXRPJ/H/qxVtbnRiw8mAXGrdUKLcWZp+ls8sL+DtBMdcstWkLurRpFAjlprYrYOoNQZVD5dms3tt24/hYXfVgIlOFA84k74t/Ag5PKR/fWYQKBImeyRQUizXN0/5tY1akDUQmIscQYn32EB0ONPI46H87QmNMClRSryC/aFaTzgmAbTZQ== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v6 2/5] arm/irq: Migrate IRQs during CPU up/down operations Thread-Topic: [PATCH v6 2/5] arm/irq: Migrate IRQs during CPU up/down operations Thread-Index: AQHcsgQg4Qmkqem0lEKqev7qUPQ9gg== Date: Thu, 12 Mar 2026 09:39:30 +0000 Message-ID: <4e35d2a56d9ab1497dd1a706b80695a38ee90f60.1773307749.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: 179761ec-2de6-4ec2-6ae1-08de801b4298 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: yLN/PvqWqtClp1lo++54VxeMDMYeJ661qIisAaZ977KNWvrFLqcQzBrh1VUdByDQQDO1paGBEPbMbTP9HhHy3n9A2Srs6bozEJmRYpii16ty569uESHDUdQ1x1Yw8SYpcdh8ZXt0gd34likUqJERvh26NBToelaw8Z/ZH2ISBbwwUgmlNK0h/PKsoI8HCu6GgQAGqdheqauTvxEUjAc14mWnKcJ1vePsv3dC7aUw0rcDXPSTQj2bwBar3kKDqDGpz+XRwhTw54uUpxD+r0fBiyRszZU6IM7f0c0HekuZfygm6Tu7JcoSkYMEtMXEx/lhBf8Z+IM+zGYwrrW4OZlAcNQifclOrsMOkl49NzaEh4HKBxef2mGQyhw+KS1lrzCUl++PieCaMp70YzX0W0KFAMtSp2tpRFVogcpPB6ll2WfoHQzpdi+S61RLPXF61HR2eBbx//ZKezcabmXC2KuUhb/ja9P+VqCUEsDLupZKYOh1gjCspwDfmWLFZU8tCZII0N2GWMSXK5b81DTKGUucPr+3lVtO4xQmEsQIMBPBEgDo5SpDDFvgk4cL7Iehd5uNJ+2IlikPK3jgEkSgNTA/MO7aYpRA9WIBxy+yexIdJvnxyRjlUfu5Qukv4zYpQRNU8B7cNphvXID+yj2ydSQb4KxOQkbZCMYHcjnxh+bKUwz6UuilpVJPyA3tcpS746icAcDaf3xC1lnNNFz5/U15+C9RqYjiQEMWjNvzRiEQdvU60A1JqoZmu6/cnJPmbNGWEHOZSpge5RHD6KAuZ8tzFgofW63zCysASfiVrZuYEeY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?B//bPBrXG6j5wckcZXOtpJTOG2FN5CEdFAb/eA/6IZq/cFMcp63OiHWUu6?= =?iso-8859-1?Q?DFf5+TCiYyP+cuTi/UxDorRVfNBrAAvG3aAxnONhUFSd025wnNobHGTVfS?= =?iso-8859-1?Q?KhemYT6lqwR2yjQ4+Cpp+XpEOHu6ihsZk5BEUGsnDjzXs1LYR3Ed1Q2vnO?= =?iso-8859-1?Q?HX0kIcdgkkNBgou0/ZxnRkC2WJT448FWljZBysBHQB0UsPu6rjfyYQ/Wzs?= =?iso-8859-1?Q?PoYxZA9bsHNpsVtTsas5P+8vtNTOpfup0PgDPIho8GT43gX46Awkr2U33R?= =?iso-8859-1?Q?KL29qnIzCA4q4qPCsz2eK44037IfzksUXy8vkRi2WAmV239kz/UUEDXKKY?= =?iso-8859-1?Q?ZJVadUO6UlnACvWy5J+JST53L9XXAQEPOi2h6k/20Jz8VVMsCMok6U3gjX?= =?iso-8859-1?Q?BnL9aaWEglPBkwxuUgLmBs2g9tMZqWX/8LSMnoGxLNJXEFuDIkYM9NCeuP?= =?iso-8859-1?Q?u/CUZb/nrG1y4qNxFeXQh5GyhMR+SSWVLRKf7u470W0Kyatsqt7cD/ojRq?= =?iso-8859-1?Q?UXy4cwK23lkAdpgGWKHyyjPWvndqCrGJsR/996F6j2zrtd9llFq7OuVZ9b?= =?iso-8859-1?Q?6lomDQSf/VwUNoXnFjt7FA3RgXCYvLOOYJ+Yydm8OWBenHo013RoU17b+G?= =?iso-8859-1?Q?SBptpvqTRW0zfD5wahwYoSmUcPd98DqGIjCAK1iV2fbuhEpfbq6aXId9mR?= =?iso-8859-1?Q?by1W1eWaoKJSvST5qCxS7nBHpb9moX8oRXP84/QKAf+zzrFI/HYZzjlYci?= =?iso-8859-1?Q?Ta8wUXOp1AckBGGnWVp+zPUi9TuKGd9eNm6CvEMWxDmUDpwSPbiOFbcRs9?= =?iso-8859-1?Q?DOVojTyEJ24K94+32veKObAp+srqTzvAp0hO60oWHr1qFo7eRF7SrsS4de?= =?iso-8859-1?Q?D6mK7OMvPLAs0LbFQMpBfpTJo8yAA6fm2sLvYIFzKBuOnP3H9DJ8T/vIBG?= =?iso-8859-1?Q?aQc+gx/CZQl5oVPP7bcNB3VfAzaPm00zu0HipSxHgE9fJcZTWODSfiFnMq?= =?iso-8859-1?Q?Vloffc5Jpqh2L4VkFrtMeNQO/h4uBXFpvmJFxbqn7qB+wGk5yRKknNxhVC?= =?iso-8859-1?Q?Qmn90dGjXGRTgBRZ5A3DGtcSb0TBGbAQ6fjCsEH9VisqcLhg94G3JgB2V9?= =?iso-8859-1?Q?AOEoSqB/gVhgBBYxlfvBepZOo+DHPyD5rcXlWyCwpEKv0bFtd06vUbZtFI?= =?iso-8859-1?Q?xuYJy8QVnccsy3fX78MishV6xnXhFaLR9Mc8MN3yBikw+M5r6WUlgV2Rdb?= =?iso-8859-1?Q?CjKeSX7RzE8qs3HbML62DgoEyCSls57VNUWsNfMWAyzkSvy6SRzQgqcdbB?= =?iso-8859-1?Q?ubU/V1GFMYRQxhk77BxEwXh5Ktpc3/oETnm5yd6DD6CWqZOTEQmj28U70F?= =?iso-8859-1?Q?HFyEL6YgiIEPHI9kC6NQ6X+5IkjY14GwVkzbd2NfaCeGkF68Hk7QtKlDtR?= =?iso-8859-1?Q?wT0k5s/68dJe24oiw7k6MPCJjatlfC1DdrkbKeQhMbyKhtgdvP0xyKdQLA?= =?iso-8859-1?Q?KxFQS4wspgHFPBFKzTp8awJcpmYobsZ6uGdgemi83uHOd0ePXajKq0o96C?= =?iso-8859-1?Q?eW7XJrKtwRiqRmTyG+zBcmx7V6zTxa1K33O14xN3UOZT/fzyR0L9EKPo98?= =?iso-8859-1?Q?k5b4MANXIn3VMqGczS9ajVks0mCUQoSIvmMN/NBUohFNcVXmfgP6wG1cDU?= =?iso-8859-1?Q?9yfNndYUPHl9KfTC9X7ambwaVHIIHNxfPRheFASpDjWjEqaWYRgy7c2JhE?= =?iso-8859-1?Q?DmMOv5n4Lq/2T8oHva+5LoTi5dK6whTnhpkMGKyw0In1bZtgYTw4ZdIXvh?= =?iso-8859-1?Q?NIpEGIKdqcp7yHVQgmJU6ypX4UVZ+hI=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 179761ec-2de6-4ec2-6ae1-08de801b4298 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:30.2870 (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: d58vJETzhF8xgpbPwfvM7cmAUI18UWWhfrRmPusDy2qF7gecrssqPSe28E+km2jBOyuREnHfJ/YjvHqKxkFsQg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 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 --- 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 | 4 +++ xen/arch/arm/irq.c | 60 ++++++++++++++++++++++++++++++++++ xen/arch/arm/smpboot.c | 8 +++++ 3 files changed, 72 insertions(+) diff --git a/xen/arch/arm/include/asm/irq.h b/xen/arch/arm/include/asm/irq.= h index 09788dbfeb..a3897ec62d 100644 --- a/xen/arch/arm/include/asm/irq.h +++ b/xen/arch/arm/include/asm/irq.h @@ -126,6 +126,10 @@ 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_HOTPLUG +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..d428d3118b 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -158,6 +158,60 @@ static int init_local_irq_data(unsigned int cpu) return 0; } =20 +#ifdef CONFIG_CPU_HOTPLUG +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_MAX_INTID; irq++ ) + balance_irq(irq, from, up); +#endif +} +#endif /* CONFIG_CPU_HOTPLUG */ + static int cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) { @@ -172,6 +226,12 @@ 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: +#ifdef CONFIG_CPU_HOTPLUG + if ( system_state >=3D SYS_STATE_active ) + rebalance_irqs(cpu, true); +#endif + break; } =20 return notifier_from_errno(rc); diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c index 7f3cfa812e..f17e88e678 100644 --- a/xen/arch/arm/smpboot.c +++ b/xen/arch/arm/smpboot.c @@ -425,6 +425,14 @@ 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 + */ +#ifdef CONFIG_CPU_HOTPLUG + rebalance_irqs(cpu, false); +#endif + /* 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.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251869.1548706 (Exim 4.92) (envelope-from ) id 1w0cW0-0002ez-I0; Thu, 12 Mar 2026 09:39:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251869.1548706; Thu, 12 Mar 2026 09: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 ) id 1w0cW0-0002eo-E2; Thu, 12 Mar 2026 09:39:36 +0000 Received: by outflank-mailman (input) for mailman id 1251869; Thu, 12 Mar 2026 09:39:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cVy-0002bV-Lg for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:34 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 60571d06-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:33 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:29 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 60571d06-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AybG1Qz+w9ZnIsfc2qqHjkhrDTMkXuct+b/rVdY7tbAUCEqie1XWxPAkLCFF9N1Yvzs0pey9COdI1XafvtDQI5+PusL8syD5neifq+V4T1LYyEY73pjGC8SdFR919ThQUyXQzWXCdMyPiOrcDQxsVRMhisJTUgDqyEfGv4rhSU+c7bPLOVcUjJIVjfFjBhZ1G7R2ofkoFO0ibPZuFe79CRlqc1XAcFLPqg0hsCND65Bvlfd8iyw5h69nqFlOtAltZIR+4N+sN18BA4X+au2MuKtefIYfAvxtGNg0E7qqwJw4BOdxplb+7RUer6HsMOEz12Gjkt1AE/aZw5Rsqe90aA== 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=aLI6IwIK+VlXbgQ3Sjr7x5ljFFWsn3YcrGhmOMX1iXY=; b=S5WFk69Xg1KHZgCLcaUg+OFsKEu/TpzSXSsw9tQhuItrV9Fw8Wn+zV5MOBA50EDpN90yu/lnNy5S6pg7EfHG4XhJO9Af+svS8X+poMM6Cukb8k/ngXkSMAj9QB2cvzp5WGcxH9/5ZT05WAe31b/5bV56vi8LCdMJ9PWaAwPWvpFRyXq7V0bgnszLmjp0YbGWXbShdRWzYlICXwVQrA2tPcUUB5xaqXZDcMoHg2rRUAG6FzNOZgEwa0JRhMnAQjzlMlj+T85LgLgDgTIOGyiJM157G1xVOCPvPtbVbtLVwye4nQNHMPmDCSd24OxsVGFnY0XDGXEQ7O3ApyWwLYc5jQ== 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=aLI6IwIK+VlXbgQ3Sjr7x5ljFFWsn3YcrGhmOMX1iXY=; b=OoeKr+0A/yFO5Gv7Y4I56Rdanm8ulUlbe+DxbyUL878Eq04T5JrKx2YXqyp+1sNBRanogLdG5OutuwVxcZ6JpMzSa/KIEeOYxpb0IyUHRxw/FNMnOAxW3rMZLkYzsf9+pilaE3HiWF5iYMh9Er/f8f2IaBojXTOcB/4jsK72PZCCde9EOI4wPJTsnrkTrw07H0jIwDhQxlN8URAj24h1tKgOG4fdlZCYONphQOwMpZbAK/cuobmWz4IXRU/+mTN4mgMaw5mpXUmRQFJKpWPR5/oHUG5PVaIh6o0mezDOsFdSROFLkV85K3B2/h0sYR9H5D6BmAVTffmkfiiKhVN9Pg== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk Subject: [PATCH v6 1/5] arm/irq: Keep track of irq affinities Thread-Topic: [PATCH v6 1/5] arm/irq: Keep track of irq affinities Thread-Index: AQHcsgQfYo2+uc7QB0+uZY6Wrq2Bgg== Date: Thu, 12 Mar 2026 09:39:29 +0000 Message-ID: <733d58a26766a1d15e47447ed4f3cd299dc28cf7.1773307749.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: fc54aa19-5856-4573-714c-08de801b424f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: VpjDlbooQ1zHEXVSZioWg6qY3s702CPSMoPWZDDPn1VSLwOZn/NPlyr8O/ElES18ks1Rd31oTWkTliNb7EGlei0wP4l7hH/CMnm8zRDapHs+tVOVZ779KB3tFwbACvDtHbFeWvroXE18j7RNjq9Nw7OCqnr9x+8Ry+pB7f/XPion7JvU1pYFkUofWCPDXY9wW+z6WGn3KmxVNa326ONe3ZMF9l5XPOsD7OmKNvXzw9J/mSQbBsU9IzJ7CXZgNdVhLLRIO7lS+bYyUzfK5vFhIWQ3Lg+L3B14opVR8xVS19oiJXE92sZOJIA/7rw0oM91oDMlERs0DuYBvQ5NA3xO6+m6whPo+9cnSvek42jEi1TpM101wMiHj8dg6vTZUHFKY6kpLw1ND9RsJRB6dLWC3A8I8t8zht6e+RHfY9KaNm3WeDvTPVGteg6w4mYfHOpCPF7vw8Wb6kZSIPu67sPKLPufAtU1ZIzUzOloU7DOjqjxJV8x3VkSXg3cf1soN12defrKWRkTUhSpouXQ3w4SYDXHg2LmAvSQucu3K8WLlqJ1pOpwFZqMHXZtALgvYm0mwY+B5ugPohQ7wL6qFol93td5wq/0L4S7C++h5xkrqvN4Vu6VtROvuGL4lFzovv3fB36ri7wGm0BiIThpjpswkz5H2uFqxXluTWLwELKen6Ymjrgv51PELLFwBoV/ibYsTy6/Ssi1v1csQR9g93f1PON2toC2OzIB051cnR9Y9P3O8jPLcy+Z1fgZ0j7mfz0GR2kQTbFhE34/YvWhDPcuwEfJJPvxqFfWnF+2fLtNrdc= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?lEs1eqVyJxfDAviCaW2K5hTR/HjXfKlKwLHFC5Hzdnzu/xQHZnNObxgPCM?= =?iso-8859-1?Q?Oio5/P+HFRLna6fHS2Oo1o4nuzuHIEZX8Pd9GV5yySfB7RJyItV/AmD685?= =?iso-8859-1?Q?JrnruB0PzNIC3mRVWsKEoiHyzwtYVNuIqsiEoCn9jrXD/3KEa3nSS6AJqQ?= =?iso-8859-1?Q?v1vjuPmCX4yN51Hp7lPnUV52mZcPdVQLwM8V/JXBz8eyVq5KlQ6UXCcDy6?= =?iso-8859-1?Q?jHtrP89qGQwD1nyM6lGlNGyczU/pIT2qfVisUpXJpac603sgnPlG9ZZVRH?= =?iso-8859-1?Q?xBGisxV3+KrLpQLhZ6dbiC2wK2TiAgdSERkocV6s9KHzCfvZKmZooG/CH8?= =?iso-8859-1?Q?Oa1VLROV6ajsc7XAUchnPN3b9LPA0qzA1WdhfVhBm2gXjNJ30tOBPfRCC5?= =?iso-8859-1?Q?/75lD5/7pp4de6gAKek+st096i60Tyvg0XkibAlgh4CaOpBoWv3x9ro6DR?= =?iso-8859-1?Q?m2i2Cz7lfcYsfhRT3sWPnw9uNXMDPAFF3nmhSX7V1+cVMstuowdhfy6o5o?= =?iso-8859-1?Q?5CLVIERd/hXNKairx5UUOFjez44y/ZGtD45peqsOVA4QBNcH92esV2KIz2?= =?iso-8859-1?Q?SvtaXOJGgUHPZ9c8cFPF9RlKVLHZuKff9Gk9PgwMNnvpqOILp8t/uZuV+J?= =?iso-8859-1?Q?Yw/AcH9psctgW4imX5WtjRsZiZlxiVnTIv4qFwyXQxh+KtpB0nprH2edC4?= =?iso-8859-1?Q?1EvHS7OUXIecGKCJeHj15XKRRYDhrWHxI4VpGZbGe3big+yeOUWxIGY5Hq?= =?iso-8859-1?Q?rlKHIZVT7RWa/+fgPXFSd2mcIpiONBF/aMr7+aFgRCLNgf8/nYX/orftgV?= =?iso-8859-1?Q?1rYaH3lPhWwiMPlVb84QWgh08V8JoRnaoQmkC4zwu+i7TzwH+NkpyDc6iI?= =?iso-8859-1?Q?2r9zPed02NUB8ji3qNKYcXrFwxBDQaiUlWVecg9B7BIt29mMao1H9fhbEI?= =?iso-8859-1?Q?djIXet7txrBJ5Jug+5Kq96XprcYT3Q/thlPSMF7bRbiiR3h1EF+tFbDT18?= =?iso-8859-1?Q?Qbik/My7G3wSTJqSa5XmEK3zBp1+1e6rRwznAtyU4GF+qxY+u+VSy/oY1X?= =?iso-8859-1?Q?431pBnlqVwem+kZhbytA+2bciciGWyZFWpRxoaBHZohZ8x+vuGT4oNAst7?= =?iso-8859-1?Q?egcSArZ2nZQFZZRFvTjL1VhRQkyhQU46953wvUo5CEXUlEMbmJCjrxf3F5?= =?iso-8859-1?Q?YRjL19OzKPZpnhpKqFmDLoFKsRzbvNdr+aXEs0BMcZv5nXfj9WB+ttBlqR?= =?iso-8859-1?Q?F1afENLt6/ON4fXHq+BI4x/CvutD03jSouB3FIPOLrUYATwurcTvDcMY0i?= =?iso-8859-1?Q?kUBvN9Wv8ev5ZGAb3rrMvD4dkEYoRYHc4A/yhj+q+1fSpGs/W2K2UjLTeO?= =?iso-8859-1?Q?SCKTdIzBcJuGwJ4oBfrE7uGNK6xBQqvmBSCcoKABzm2pRrrpCOf3QITdu+?= =?iso-8859-1?Q?i7WZwgcpCBvqy32qVmTPdgFnTVj98otuEUiAnUMKS0ISyw3ZxiiL9KwF2D?= =?iso-8859-1?Q?IvmSiR5+GM5gYM7fHBohMUci6zSQUvlpTD+GDbLmZwq5VgQej0OEMjFlyP?= =?iso-8859-1?Q?tDBwe9boLsWHjh+75fcgTGXD0tcllw6yJTr/PvAnZ5TWGkmmGGBn77We1L?= =?iso-8859-1?Q?Egea/bTUM/TIoJek5q4wh+wU5bpJb7EgO9PPcbr4/9rTtaN7A+at6oSy+9?= =?iso-8859-1?Q?Hcw0KX7D0RzSEacH0DSYRRNAEiNXFnpsBNLmH3gq7PB5AiwzwY7wafYRr5?= =?iso-8859-1?Q?Y7RTGxpm/GR8gub8qbM5/BJI9ljiB2f0A991GYX2F/otb1R+2RMhH/gVaA?= =?iso-8859-1?Q?0wTLPl3ZWZekRaayW8FzG78iy/mOoRc=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc54aa19-5856-4573-714c-08de801b424f X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:29.7339 (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: j9nRvl/F8/1rq3d6lGT3Ya57T5V7KDyBRg0eTwSfaw4ciVz1oarbNrXFN43XQRmwo/0fAdYVbYjRMn3Ps/EaLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 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. Signed-off-by: Mykyta Poturai --- 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 | 15 ++++++++------- 5 files changed, 34 insertions(+), 17 deletions(-) diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c index ea48c5375a..5253caf002 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 6647071ad4..c59f6873db 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -445,7 +445,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; } @@ -453,7 +455,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; @@ -473,6 +477,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 /* @@ -494,7 +499,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 @@ -574,8 +585,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. @@ -944,4 +955,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..81ba4099ef 100644 --- a/xen/arch/arm/vgic/vgic.c +++ b/xen/arch/arm/vgic/vgic.c @@ -812,21 +812,22 @@ 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); + desc =3D irq_to_desc(irq->hwintid); =20 - /* Only hardware mapped vIRQs that are targeting this vCPU. */ - if ( irq->hw && irq->target_vcpu =3D=3D v) - { - irq_desc_t *desc =3D irq_to_desc(irq->hwintid); + spin_lock_irqsave(&desc->lock, flags); + spin_lock(&irq->irq_lock); =20 + /* Only hardware mapped vIRQs that are targeting this vCPU. */ + if ( irq->hw && irq->target_vcpu =3D=3D v ) irq_set_affinity(desc, cpumask_of(v->processor)); - } =20 - spin_unlock_irqrestore(&irq->irq_lock, flags); + spin_unlock(&irq->irq_lock); + spin_unlock_irqrestore(&desc->lock, flags); vgic_put_irq(d, irq); } } --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251872.1548738 (Exim 4.92) (envelope-from ) id 1w0cW3-0003TK-FB; Thu, 12 Mar 2026 09:39:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251872.1548738; Thu, 12 Mar 2026 09: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 ) id 1w0cW3-0003TB-BN; Thu, 12 Mar 2026 09:39:39 +0000 Received: by outflank-mailman (input) for mailman id 1251872; Thu, 12 Mar 2026 09:39:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cW1-0002bV-MY for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:37 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 61514148-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:35 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:30 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 61514148-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=K+WkMYT1KM5f22+Jj0FFAvVtWVhZBMxi+u58C+43PXRFDafpfEGN2g69GmP+XZYMLQvNoDyNJHd6u3/N+1V58yGd1ID8TEAdFa0irOVk13lZ4uYdSt9qDeNbNIjURkYsopPXyToaj50JLw+z6OdxdAn0P0PF6rH37lVRKFveHoEIcHmv01mCwCMQ8+OGOJqYtMEqwlSIITLT/6oq/Q6CR7twr1gl5EiQb+5s5o/WC3DIGXg1aRd7ABTMsPC2lEolp0CjVp62G2OlUXAcoijGeSTSldp3oTMw07QAWGNvLCOwkeMzHxzTiS6lkcqOM3b+C34qybBnoyq7py+9BeEtUw== 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=qXjlnWS1d2mnX92S2FXocUpfckS3YB00I5AeDXjGcFo=; b=bVmcWLeFVWppsDqse1QKkNMrjvqwUKJ7r3QnQU37Hg+9Uwx06lg40hQRcSBWqn4tthGUKV0LuWUNYTbd/pl5160ZO69a8kDivOhBUt6nQ4waGO3ps8gPrQkkTco3AWYm7unJYrQKOO02raVdbA6RGZybSZlf6mt5Z4FMmHaL3eY6ngqSxo5X1IrRM33kdaILCD5RRFQ113WnbyuU4jgMIpis6EqIvqvPjOgYZWfQAI+rMmzsMicxsJEzJg/AxO5RhHYPPUu5nS9YDAUSZsH1iWgbNc/30HwvpfspCmxR6pqeRxnywlaztdKef/YaYJNPbdlN1zlFJg7LWzHcAXiZCg== 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=qXjlnWS1d2mnX92S2FXocUpfckS3YB00I5AeDXjGcFo=; b=f7o+TjIF/G/jD0V5Ss0mVtWEpXWn7KECdKt3CNSzAkOxydDB2LZGuw9hq39WWeBiqUcUzShWc4GHZCE+0W4ULyc0GCuz6qyBCUaMQHvuiijmvJh2wngU9MsYRzXF+TuFA57zaVuNKHi/p5+oYb9LIgxptQDgG3MP/VffgjPDYGqA23Hb6mbCpmvj/iTM4DfpUyavj3a7rnLJfC0cVa/oZElGsb2rvaY6uKB7xSMVzgJTjLT2Kj6Njt6FgodsjlxmCTm/MPpFvGOU5vYnyJHnLlbzjh6FiDpYGFFistj8+YbJs1cJdk5iDYNunNayfdfXujvAegSCIeDg5hwh51F+tA== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Anthony PERARD , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Timothy Pearson , Alistair Francis , Connor Davis , Oleksii Kurochko , "Daniel P. Smith" Subject: [PATCH v6 3/5] arm/sysctl: Implement cpu hotplug ops Thread-Topic: [PATCH v6 3/5] arm/sysctl: Implement cpu hotplug ops Thread-Index: AQHcsgQgazJGD0vsMEiWnzOogqs2jA== Date: Thu, 12 Mar 2026 09:39:30 +0000 Message-ID: <206261ba0b60ebcff25e083c22d9e9b885645199.1773307749.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: 8e98426c-463e-411d-ae83-08de801b42e6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: 7m2PY5HDwEfsAkq/r+1MxQQdBPOmAfuHGYQPX4b1LpmwGXB23uKX+8pWndf+LXEve9DGtwBM/An0rT4D+PSIAt+TP6rNSCre0EaYBxICZD7Rq1jSt9lobnrQz4lzd0anVYquNWa6t84aCMnLkiHcz27t8aZ9ERtJrPQBGV+qqmIZ7IRJerL9KoxsFeUy+D4LqNymt79xTsBv64/3xbeSytQ0UxQZq/Mz19pBNg4w6J06b+PykOPQHWFYY3JjNQCg5bkjXnjFNHMZ+R71RdmeZSzpge0T6Afn10QBsnj5vOaC2idKS2oRTmB4fpzymuW830X6kVL0u4mjCJH/deUC+JdYUo1hfXRbauVX5SUee8he1t8wRD0C5GDummbxShGeaUzNQlwzL4SW3T8cSnRylxAz6TPOj4j+tTIxSaZpzdbdCIkGP+z7GMlttMEbTlKSii7rC2fXb4RmCi3Uqp/zkCHz1/ugw6MbTIb9P5BIsE8I+e37NGviCj6MssAX+muijV3faWpzjRL+xAoswany4BHjHdnria1DUsf8MO2da8Nrc6nQmJDl0sasKhvZs6uL5dM/NYs7pASV95AO0HsMtjItwIwFgrjzX3GlHzVPQx5pESHz3jyBiENO7ycL6bzR8cWjXh5HP9jS3FGSjDGfzdcjkDl7AFTy2ObHPeePQCVJq2fvVDpOffRS/WfINz/PAzlu90VfuKILrjqi5JglvPct9YZN46RUDlcyh0nOcqRDhr/6pb42W6MFkoHnQz9ECOdJgcj63ViSANAnsod920KWfNw5YBzz8U9Gb7YVZGI= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?twY3bd6Jgq+LloP9D4mjppmA9QYOfWiumZITiGOSRqJo1TZECVUANQcamw?= =?iso-8859-1?Q?Z16MuZkpuaHBtpm8FlXYhIpInfBVRvzD0BR/xRhUWrisDZsVbDNKQpfoWe?= =?iso-8859-1?Q?0vAe22DsukABPC8Ms205wVM+ilkXQarL3/HrqkvFXBRFFA2LGEjnUzK4u6?= =?iso-8859-1?Q?00rUAMFqTDdBECgU35MVlIlfScMULX37uGeRufsV3bxCnw3v80icGNVBxi?= =?iso-8859-1?Q?srFmc0g85AStJXT0Px0LBZ2ifmjc6g12PAouwjOw56HW4p7pwIlo3m7kNJ?= =?iso-8859-1?Q?VhmOz59omzqMuJ5G1E6io2rtY8Th6EPFPQDeZnLu+rJU443bBO7+C3zhin?= =?iso-8859-1?Q?Selmm3kM2Cyqv8RrwK5vIq1Bx+NEn2bZvsaicVpybzs96WsSweEgtBjcyK?= =?iso-8859-1?Q?6vH2kBapLFeo5/+eThWdlSUiwWsyplVweGIyZBWrxhpeIIxBDDHu8unKTJ?= =?iso-8859-1?Q?KXvOVg1K+oT0MevQvK4oUr5jCInNCjWVfUIT00MBR7ZHgj9SfUxD3/n2DD?= =?iso-8859-1?Q?2JmTBEjVImLu3IAaePk+SBI+XXGni972/wqhZH4C177d03km4W9dS6aGYr?= =?iso-8859-1?Q?Uemd/zKb4JP9KVc7KqDanIRiD2JPtj1zqD1QtEK4f9tDgI1N1oNejaNd5+?= =?iso-8859-1?Q?GBvrkBAJjFgKcLb3tPp8Rts1lWCi5j0NJVkj4+ypGl7HUD1sowrwSF0rsY?= =?iso-8859-1?Q?4Bnn1hJa0/MLo0LBFTdlN18kq9qFozzK7/gVATbeCAAy4FrcQSK8e6H/t1?= =?iso-8859-1?Q?Rw0mvOaQA0H88FyGmg5NAmpeWDL6KYTJL3MHGlSazF+DSfUusjGGvV3H8/?= =?iso-8859-1?Q?lMzd3JPNmwj0/QHorfgtyOs453IeB9/+v0/1ongyh5GLFhjYAKkjxeJrBU?= =?iso-8859-1?Q?yvecmdiKJC9RqcPITHyo7VY6Q98YCxy1rh5yF1QFafMSwpyvbJvS2W7l9W?= =?iso-8859-1?Q?Pmfzl4Avm5qr2b05AF2MD8x+Ktb/yrPDl5GNeZLIUNocoRGLDvSUmjW/fY?= =?iso-8859-1?Q?nMAIxe2Gq6rCH6QG9qoIifJIsu0p5MAWr+b66TMEUL/uwTkW5x/VbyZoIe?= =?iso-8859-1?Q?g3clMtJkD9YydxlnBlL52t3T5btN/zF3RiXByc2jeerh/dLM09aupLu174?= =?iso-8859-1?Q?TWhd2JhzwsNB6d+HfA/es9bJnzriG1WDwuAmfmZTvKC1PwvXuJ9nxuMDjO?= =?iso-8859-1?Q?HuxfF7Wu9IXsLqDdsc9JzufGfNg4eE4D89O8a3wCTVHj6l9uJCV6xp6xN6?= =?iso-8859-1?Q?rldTi9a0c+rr9WvbvDrj6q4CvHnj7XgGuVvV8SVU+M46y3D4iGeCU8CZhE?= =?iso-8859-1?Q?bTCEz1kGxPOSKs0x7K1jRm4YuYR111/v1NlZvb7yXIwd8PF4kasTwceFTp?= =?iso-8859-1?Q?IPfFP0Uv6JF2mkoASqVQ1DXw9ltCY4U8Ohv/noqnVxIzOgsUZDr6TUlS+g?= =?iso-8859-1?Q?2MmyPbebH2fCPEqKO9OxrMW143jF0Tw6v1xRbgsXTonOl5lM10ydQC2POp?= =?iso-8859-1?Q?fh84JOFd7VHARiMS6OtmJO5ELPpoDTKG7kS+uQmkUvjsbiw9o1qwF8mec0?= =?iso-8859-1?Q?ITJWGGG2avK5EubRsgbnNMXrtGx/7tu+4NIKa3lMmyDziwLsFpGKkXZZ2v?= =?iso-8859-1?Q?cUsBAYhYhPC8fbdkhZsmbxRwZcHiHINcyTFH+AFcxmxLhnVRaeisSUocfL?= =?iso-8859-1?Q?44VWL1K5zXNC/JBR3hQ6CWV5zr994y3aBAzMPyTAJ2cbyD60vDjIeTljON?= =?iso-8859-1?Q?cV9d94P3/10nXuQ5dPKN+gG+KipgAqrzWtHBczG6Srf1KE42DPdsXAkLyn?= =?iso-8859-1?Q?0d6xK6EHORgkYgAOoCWZKYcyb/WegZA=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e98426c-463e-411d-ae83-08de801b42e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:30.7757 (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: OQZSllI+J1JDZQzb/V8FL/iLNU987vVQ0+btk69WRIXg4FehyWGNbpQPrugTN+M9eDbQpkH1YROPSd18Xv2vHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 Move XEN_SYSCTL_CPU_HOTPLUG_{ONLINE,OFFLINE} handlers to common code to allow for enabling/disabling CPU cores in runtime on Arm64. 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, FFA, or TEE is enabled, as they use non-static IRQ actions. Create a Kconfig option CPU_HOTPLUG that reflects this constraints. On X86 the option is enabled unconditionally. As cpu hotplug now has its own config option, switch flask to allow XEN_SYSCTL_cpu_hotplug depending on CONFIG_CPU_HOTPLUG, so it can work not only on x86. Signed-off-by: Mykyta Poturai --- 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 | 4 +++ 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 | 33 ++-------------------- xen/arch/x86/sysctl.c | 21 ++++++++------ xen/common/Kconfig | 6 ++++ xen/common/smp.c | 35 +++++++++++++++++++++++ xen/common/sysctl.c | 46 +++++++++++++++++++++++++++++++ xen/include/xen/smp.h | 4 +++ xen/xsm/flask/hooks.c | 2 +- 12 files changed, 137 insertions(+), 43 deletions(-) diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c index b372472188..984f863a9a 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 + */ +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..8f280ba080 100644 --- a/xen/arch/ppc/stubs.c +++ b/xen/arch/ppc/stubs.c @@ -101,6 +101,10 @@ 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 daadff0138..7c3cda7bc5 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -70,6 +70,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/platform_hypercall.c b/xen/arch/x86/platform_hype= rcall.c index cd4f0ae5e5..e745151790 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_HOTPLUG) ) + { + ret =3D -EOPNOTSUPP; + break; + } + ret =3D xsm_resource_plug_core(XSM_HOOK); if ( ret ) break; @@ -761,6 +767,12 @@ ret_t do_platform_op( { int cpu =3D op->u.cpu_ol.cpuid; =20 + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) ) + { + ret =3D -EOPNOTSUPP; + break; + } + ret =3D xsm_resource_unplug_core(XSM_HOOK); if ( ret ) break; diff --git a/xen/arch/x86/smp.c b/xen/arch/x86/smp.c index 7936294f5f..b781e933f2 100644 --- a/xen/arch/x86/smp.c +++ b/xen/arch/x86/smp.c @@ -418,35 +418,8 @@ void cf_check call_function_interrupt(void) smp_call_function_interrupt(); } =20 -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; } diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c index 1b04947516..35239b73c1 100644 --- a/xen/arch/x86/sysctl.c +++ b/xen/arch/x86/sysctl.c @@ -49,6 +49,7 @@ static void cf_check l3_cache_get(void *arg) =20 static long cf_check smt_up_down_helper(void *data) { + #ifdef CONFIG_CPU_HOTPLUG bool up =3D (bool)data; unsigned int cpu, sibling_mask =3D boot_cpu_data.x86_num_siblings - 1; int ret =3D 0; @@ -89,6 +90,8 @@ static long cf_check smt_up_down_helper(void *data) up ? "enabled" : "disabled", CPUMASK_PR(&cpu_online_map)); =20 return ret; + #endif /* CONFIG_CPU_HOTPLUG */ + return 0; } =20 void arch_do_physinfo(struct xen_sysctl_physinfo *pi) @@ -115,24 +118,24 @@ 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; bool plug; long (*fn)(void *data); void *hcpu; =20 - switch ( op ) + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) ) { - case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: - plug =3D true; - fn =3D cpu_up_helper; - hcpu =3D _p(cpu); + ret =3D -EOPNOTSUPP; break; + } =20 + switch ( op ) + { + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: - plug =3D false; - 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 d7e79e752a..bb73990355 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -637,6 +637,12 @@ config SYSTEM_SUSPEND =20 If unsure, say N. =20 +config CPU_HOTPLUG + bool "Enable CPU hotplug" + depends on (X86 || ARM_64) && !FFA && !TEE && !HAS_ITS + default y + + menu "Supported hypercall interfaces" visible if EXPERT =20 diff --git a/xen/common/smp.c b/xen/common/smp.c index a011f541f1..e2bf82856e 100644 --- a/xen/common/smp.c +++ b/xen/common/smp.c @@ -16,6 +16,7 @@ * GNU General Public License for more details. */ =20 +#include #include #include #include @@ -104,6 +105,40 @@ void smp_call_function_interrupt(void) irq_exit(); } =20 +#ifdef CONFIG_CPU_HOTPLUG +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_HOTPLUG */ + /* * Local variables: * mode: C diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 5207664252..51a3dd699a 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -483,6 +483,52 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_= sysctl) copyback =3D 1; break; =20 + case XEN_SYSCTL_cpu_hotplug: + { + unsigned int cpu =3D op->u.cpu_hotplug.cpu; + unsigned int hp_op =3D op->u.cpu_hotplug.op; + bool plug; + long (*fn)(void *data); + void *hcpu; + + ret =3D -EOPNOTSUPP; + if ( !IS_ENABLED(CONFIG_CPU_HOTPLUG) ) + break; + + switch ( hp_op ) + { + case XEN_SYSCTL_CPU_HOTPLUG_ONLINE: + plug =3D true; + fn =3D cpu_up_helper; + hcpu =3D _p(cpu); + break; + + case XEN_SYSCTL_CPU_HOTPLUG_OFFLINE: + plug =3D false; + fn =3D cpu_down_helper; + hcpu =3D _p(cpu); + break; + + default: + fn =3D NULL; + break; + } + + if ( fn ) + { + ret =3D plug ? xsm_resource_plug_core(XSM_HOOK) + : xsm_resource_unplug_core(XSM_HOOK); + + if ( !ret ) + 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 b250b27065..36d357cae8 100644 --- a/xen/xsm/flask/hooks.c +++ b/xen/xsm/flask/hooks.c @@ -835,7 +835,7 @@ static int cf_check flask_sysctl(int cmd) case XEN_SYSCTL_getdomaininfolist: case XEN_SYSCTL_page_offline_op: case XEN_SYSCTL_scheduler_op: -#ifdef CONFIG_X86 +#ifdef CONFIG_CPU_HOTPLUG case XEN_SYSCTL_cpu_hotplug: #endif return 0; --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 09:39:40 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 09:39:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251873.1548743 (Exim 4.92) (envelope-from ) id 1w0cW4-0003Yl-20; Thu, 12 Mar 2026 09:39:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251873.1548743; Thu, 12 Mar 2026 09: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 ) id 1w0cW3-0003Wl-Qr; Thu, 12 Mar 2026 09:39:39 +0000 Received: by outflank-mailman (input) for mailman id 1251873; Thu, 12 Mar 2026 09:39:38 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0cW2-0002bV-Mr for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 09:39:38 +0000 Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazlp170130007.outbound.protection.outlook.com [2a01:111:f403:c20a::7]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 61c3fa2c-1df7-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 10:39:36 +0100 (CET) Received: from AS2PR03MB10110.eurprd03.prod.outlook.com (2603:10a6:20b:57a::22) by VI0PR03MB11417.eurprd03.prod.outlook.com (2603:10a6:800:33f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.22; Thu, 12 Mar 2026 09:39:31 +0000 Received: from AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581]) by AS2PR03MB10110.eurprd03.prod.outlook.com ([fe80::4d2f:ff40:d0ba:e581%5]) with mapi id 15.20.9700.013; Thu, 12 Mar 2026 09:39:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 61c3fa2c-1df7-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lUh8+l8fAijN2tjwRMz8Ls5WZgIH0FYnN5h8Amy8zU0kaiawgXqNeD6hVrHCn+BnEqv/k8TTPu0qUJkLdZBKZyfGFW+kBZd5lh1G9punrVBk3CuAbQme7o40keiKBC5SfL17/S5z+PQc6T3mZu54garp/BGzzqLlukLNNNz2mYTPKSvqJS0mLrIPHIc25twrvxAWv02f14y8WsPTQofekBs0VUuGYK8ELV3kNlcHN0wpJiK4Mqe00PSDtTGGQ5NEdZAYYWkxZj70r4B71MoTNkP1zpHX0u8KfVuLBBattLHow1E8ZSLgM+JJMxDxGxJK+2OuYVax/Ep1LRqefAEDDg== 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=nZy/cC7uH53ZqgH6AZbNe+UaJ7u0hXrJKUMyqSL4zZk=; b=i5DOcIAh42Em1RkW9sVfZt+GOfRSvQrPU0s/tzLVRG7wlPT5vjkS6oQcFNq8UN++WRIO5LayIAf+xJSCvbmuUcSOUWTENxOe+HveUiqiryowCwVA8zN8d9++01hrImIJOB7iWL1vHmoSkwzffZIYkTowcY2GoeEsSx3v36GXwMrVm3HLGarlij8VRdZJ5BTediOc9U5zYK2A31ZPUKsAkr3bwKd8dksvuNRbRL9O5VKgrm1tXgJh8RavDxMXpwRHGm2QVkCtV8e9OMvXZKbBU+ycJeDRU16mMveBNDLVb3M8r4hydUvskxOea0t54Ce782+rxxn4e6ra337JdG7iGg== 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=nZy/cC7uH53ZqgH6AZbNe+UaJ7u0hXrJKUMyqSL4zZk=; b=ooagV3cAaTaM6hBwkWIKXXpbyL7w6IzQvDFHw+taULEGJbX3T5hdqnR2tCOJAND9Z/5ttaiNaqwUrhIBc1qBj3fmb9VYDiluHe5kr/OzPMK5oJz2uAvfM2WVNFCvwPjFVscQVPFUpGAtbr+GQbePkqwFLZLHL9C4V+JsMDhS4jEo+QDwo4oidmUiRNlgGkgvj4u4eAQehc2E1eyU/otugMMZeOvLJNL45jNDSLR4xd3t3Xez5huDbASi+Frv6OFb4KIduAtCgIC+11UaHkQVaSLTL+v4pcSwby+ONyYpX01elR4BNn/8Fp8l96mgUWRtKA19oEy6cz0Q72agcNCYfw== From: Mykyta Poturai To: "xen-devel@lists.xenproject.org" CC: Mykyta Poturai , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= , Stefano Stabellini Subject: [PATCH v6 5/5] docs: Document CPU hotplug Thread-Topic: [PATCH v6 5/5] docs: Document CPU hotplug Thread-Index: AQHcsgQgNCk5TPCZikiOg71JPbDw/A== Date: Thu, 12 Mar 2026 09:39:31 +0000 Message-ID: <4857e0c10c59f283e4a3686bf9188a1809a9fd55.1773307749.git.mykyta_poturai@epam.com> References: In-Reply-To: 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: AS2PR03MB10110:EE_|VI0PR03MB11417:EE_ x-ms-office365-filtering-correlation-id: 2ce65a7d-1d19-4600-544e-08de801b436e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|38070700021|18002099003|22082099003|56012099003; x-microsoft-antispam-message-info: /pw5MgR+Vim76jdh13fsrhqE4JYx4GqKkEgsIzRv4sQ2xVgHNzREX8/wRgFsouWAlG1pC4+vF9UcPHedthDbFj4g7EYcGQbzb3iEbOI3gxnm/EUof+FFEvpj5Y2HBJQyzPLJcqlXGiaLBc0OHSrUEMXf4uupSILYKyCouxXRTa7QT+FOUT+mKf56+79sLLQlL8Nqm1Ul30k0/jfJh7iGWhydoIDb/OSwyOboTr4vKl/kVeXayWmvYhsjHTNy50t3qOCYw26PASHSGGR4zlNRyBGQdsnYga0Xg30XhVe7u9mFi0asIsfS3cCpC7bZGKCIgqEjVmSe+bCA+sY4gsPemvKfhzSUP8sDOaFb3R761eFm4enbY94lHPY2V5XTR6m6o+6J3RYLKDfKRbjLq42owZFMXuL0b0p3JD3vWLwgTZ3JZ4OiuYFteR10CsChzENa6KA/BG6VY30mXHG4eH0oRNt+zv1lja3RdMs6A+cvVsqopTngi+P07R0VeeoW9S23q2HN1uMKWQGFeuAKT4zuOHDS5zh8wVjUA0Cm814jVIUCX+Ooz0RL8o7OiXYcmcav3GVxiMr7soLGHb7sHHaWZYkTERbEhnhafEnJdfMeLwl5/jCgv5K7hE2X91c6J1gxaghzu8MpHuWMztxaoigRzopelsTqGinnJMJ/Y45X4CGEGWPirde8lPq+291zMDH7c1Ql9XU9TG+EtQaDSTBSkUUQvuFWy9McOjeyQ+OfjKB6MqA3A5huHm/h5ALbgVP+g4ptmjgxyvVk77xPssd/4pw5MB/cSJO9On6+5uNmBTM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS2PR03MB10110.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(38070700021)(18002099003)(22082099003)(56012099003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Hz2A4oz6cnaHyT+0bWCfwgKISZKX/wZciT3GmEhzXYyiy1IVyWG4DmYUX0?= =?iso-8859-1?Q?MjFTyBK+e3GsYUU2NFrSuV9oOkr//WL/+gw29Isj+WJVVeCbSuAl1LwrXF?= =?iso-8859-1?Q?manyZuak5Fnx/X4LBeVCtB7cP+WoIdQCo6lnFgIvOhD8EIrcPytQrB0NOH?= =?iso-8859-1?Q?nA+fq02DdWs9MHK5Z1BYXsxx0LqJkhhuyI2xLunYgLgJBnKEqptBvLfieU?= =?iso-8859-1?Q?gOjf999+zPCbgrJbiPoFMUISJkMZN0QIAvJ2jWY8PoqKkEPm/XduAl2OoB?= =?iso-8859-1?Q?FAx25TvHeiqkPC5WTjVcASTXlM+NJEnI2ZcZ2v2YcR9+mIPs0rk9PqdFq6?= =?iso-8859-1?Q?OAQ2XwKUBGE3v1/JqpN9QWhVC060HrmRL2P6GTETTPNTqk+uiUqxc7Eu70?= =?iso-8859-1?Q?6JGVdLBrBf9Zu5iwL+LDwWCzk1NR4xk6qb9HzXL1uMNmf/2TmZFJIeulVt?= =?iso-8859-1?Q?LhHnPIvs6fkAZ2oVXqcGpDikm3SGTicLX/8tGJW4dMblVJF9t8ojeQaWWO?= =?iso-8859-1?Q?jKSyWzgVdsDrjOHsvbIxHXgekU/iw7HXilaVE+DE/yt1zkleC9G5qaI+EP?= =?iso-8859-1?Q?Wxxfn3nk+OZEWUZFN6GFm0wC2vYXm2mcyTfJWbb5kkhzDKRzG9cJU/f6Iw?= =?iso-8859-1?Q?931XfgpnxV74+KcZT9+8YmmLEqHeMKhvhTt1jiCQxmq8TXpaE2WgP84TpT?= =?iso-8859-1?Q?JPdS+205/IL8Sznw2ninJ3Bq/DKya540L4ykf30z33gzuSRry9TBIhl1sV?= =?iso-8859-1?Q?AHOGHyZtl65AyWO1gwp1unpuIg4vt/HhXNPAjRTxJZ0pvp9zHUwwJ0ESfq?= =?iso-8859-1?Q?82Xmj1xxfjs1QZ7j1vj0VOvNHS8s8m850SxzENkKqq6cld4Ruw9pbTlye1?= =?iso-8859-1?Q?mgluidoXea9IAIWeh9kaaosCquowr5TJFQAiCDxeFrFzLeb/m4ugMUSxor?= =?iso-8859-1?Q?6qUVl4X4ah6xzdnkuOD/n5LRGNQ/JhpX+bTNfnS1hXFegIqCjn0c2cXggc?= =?iso-8859-1?Q?YIURmNRl+5WFGZTvYakC46jGURF11KuvXyhJfO7za2HvKd0wVL58TMXTOI?= =?iso-8859-1?Q?3qxZtfUAGycovB3a3xVMflcpGlbqc6rDksXy6tvQCVQNcSY0uxDcSDWRFV?= =?iso-8859-1?Q?O1/hz4XZqph2tQnNXfyC4ScmBilqgJxf7Vmh78eNDqbIxL5QiwHZTTsNyn?= =?iso-8859-1?Q?yyz+TPd+dB+htpxZkLan99z85WT7mFZXR8jAZruO0KoP6LUvzOZziA1eB/?= =?iso-8859-1?Q?Hb5ond9Yz9NjUmT3TOg/X5O7shq5mn3g7DNKr024ZXgPfrc2avkJICp0MB?= =?iso-8859-1?Q?J9w6dvQGWss392iyPyZ6e31Tq5oyqmdPF5HzsWpaSaR+XA8uFpPnMEy/u0?= =?iso-8859-1?Q?OMGX/UNMBurh1DINkEA9ordPxFMzjRnrkTF/k2HEzGZutrz0bruQLzMLr9?= =?iso-8859-1?Q?fnTJjaffeRNXNwdUkqSf3gQbnbk+zbO9zZJTFlxUAByCPUVcKr8MRBWtpH?= =?iso-8859-1?Q?pZI4uhv+IhEbNz8MHTvETUmTXa+QGI67rIf7ddE68xeujFJ493oJ9hvjfd?= =?iso-8859-1?Q?3scQXElL3h1iL4Vpm4IDwh4CsAIPpkfm+hdp43Ata1YsINQ4WJSw3OGW5C?= =?iso-8859-1?Q?Lo2YuohBwl6mE31IzikdkAEXCxSGzTd9YfUvAC5rBHNDYk4Ox/PBILx/2L?= =?iso-8859-1?Q?sSCS3uHA6lcGR9MVDZxDAwtRFZ6joeZ2cUxhb0D0836Hz7SZI/uKctCc+W?= =?iso-8859-1?Q?IajxcTF6OOsD/rGcnw5YErVSN1OZxYqK5/LGkB9fJr0JFitk52S/QfyR7C?= =?iso-8859-1?Q?3NeX19VyCvz0uKs+XuJHAPQQAHlGYH0=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: AS2PR03MB10110.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ce65a7d-1d19-4600-544e-08de801b436e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2026 09:39:31.6558 (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: u0I7QAJZ4S8sn/DVT3ofeYVTULjWtutwsHZtI7/p1aJzGVlS+L916ZLAXRj9S3Az8vEK4NpxjK4J+ZZJ+97gvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR03MB11417 Signed-off-by: Mykyta Poturai --- v5->v6: * no changes v4->v5: * s/supported/implemented/ * update SUPPORT.md v3->v4: * update configuration section v2->v3: * patch introduced --- SUPPORT.md | 1 + docs/misc/cpu-hotplug.txt | 50 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+) create mode 100644 docs/misc/cpu-hotplug.txt diff --git a/SUPPORT.md b/SUPPORT.md index d441bccf37..7b93ae69e7 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -52,6 +52,7 @@ For the Cortex A77 r0p0 - r1p0, see Errata 1508412. ### ACPI CPU Hotplug =20 Status, x86: Experimental + Status, Arm64: Experimental =20 ### Physical Memory =20 diff --git a/docs/misc/cpu-hotplug.txt b/docs/misc/cpu-hotplug.txt new file mode 100644 index 0000000000..45f20c2002 --- /dev/null +++ b/docs/misc/cpu-hotplug.txt @@ -0,0 +1,50 @@ +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. + +Configuration +------------- + +The presence of the feature is controlled by CONFIG_CPU_HOTPLUG option. It= is +enabled by default on x86 architecture. On Arm64, the option is enabled by +default when ITS, FFA, and TEE configs are disabled. +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 --=20 2.51.2 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 10:55:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 10:55:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251980.1548768 (Exim 4.92) (envelope-from ) id 1w0dhA-0006rD-8l; Thu, 12 Mar 2026 10:55:12 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251980.1548768; Thu, 12 Mar 2026 10:55:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dhA-0006r6-65; Thu, 12 Mar 2026 10:55:12 +0000 Received: by outflank-mailman (input) for mailman id 1251980; Thu, 12 Mar 2026 10:55:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dh9-0006r0-0L for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 10:55:11 +0000 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ee7ed90c-1e01-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 11:55:08 +0100 (CET) Received: from mail.maildlp.com (unknown [172.18.224.150]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fWkyK3T4pzJ46kW; Thu, 12 Mar 2026 18:54:17 +0800 (CST) Received: from dubpeml500005.china.huawei.com (unknown [7.214.145.207]) by mail.maildlp.com (Postfix) with ESMTPS id 32AB64056B; Thu, 12 Mar 2026 18:55:05 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 10:55:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ee7ed90c-1e01-11f1-b164-2bf370ae4941 Date: Thu, 12 Mar 2026 10:55:00 +0000 From: Jonathan Cameron To: Chengwen Feng CC: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , "WANG Xuerui" , Paul Walmsley , "Palmer Dabbelt" , Albert Ou , "Alexandre Ghiti" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , "Wei Huang" , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v6 2/3] x86: Implement acpi_get_cpu_uid() Message-ID: <20260312105500.00005d7c@huawei.com> In-Reply-To: <20260312072316.4806-3-fengchengwen@huawei.com> References: <20260312072316.4806-1-fengchengwen@huawei.com> <20260312072316.4806-3-fengchengwen@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.203.177.15] X-ClientProxiedBy: lhrpeml500011.china.huawei.com (7.191.174.215) To dubpeml500005.china.huawei.com (7.214.145.207) On Thu, 12 Mar 2026 15:23:15 +0800 Chengwen Feng wrote: > Add acpi_get_cpu_uid() implementation for x86, replacing the existing > cpu_acpi_id() function. This completes the unified ACPI Processor UID > retrieval interface across all ACPI-enabled architectures. > > Cc: stable@vger.kernel.org > Signed-off-by: Chengwen Feng Reviewed-by: Jonathan Cameron From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:02:51 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:02:51 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1251991.1548777 (Exim 4.92) (envelope-from ) id 1w0doW-0008RK-0U; Thu, 12 Mar 2026 11:02:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1251991.1548777; Thu, 12 Mar 2026 11: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 ) id 1w0doV-0008RD-TE; Thu, 12 Mar 2026 11:02:47 +0000 Received: by outflank-mailman (input) for mailman id 1251991; Thu, 12 Mar 2026 11:02:46 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0doT-0008Qy-CQ for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:02:46 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id fdcd0d14-1e02-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:02:43 +0100 (CET) Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1w0dnq-0000000BDV5-3GNL; Thu, 12 Mar 2026 11:02:06 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id AC3B5300462; Thu, 12 Mar 2026 12:02:05 +0100 (CET) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: fdcd0d14-1e02-11f1-b164-2bf370ae4941 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=TKIEX/tTmZZzj6V6Q9LOzPYb6+bhVRh9N9evN1bqSfc=; b=an8qvmMRT6e0/uIgvv6SvD7SLo 4m+UvPB5+18GpbDiaL9IxO3UA1h4nyJ0FZtTMBA4+J8t9buo20vz5+l2obe0Hhuhm03AWzFimVp4D YtHlF5LCr5cNGTsUr/nANJN0G/ar8NTW96doAb79xogVjlFtfvWv3tS4G8vgrwid1zRyuKnnoOtRg cRE6fVkUPmEULPsE/mtiFGjwxhTv0E57tOdjLrOaPqcviA5Hx/nImdKNCvkkIHyFLP9mr/wm0JSMb 0Thh4CDgCwqZ4HpWOjjPbbgfQIiKl0MIq4avo+r94PhokRILHHajLVnNT16BcpXuKO/m4C7RcJSQ1 afukQ/VQ==; Date: Thu, 12 Mar 2026 12:02:05 +0100 From: Peter Zijlstra To: Chengwen Feng Cc: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Jonathan Cameron , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , Wei Huang , Andy Gospodarek , Somnath Kotur , punit.agrawal@oss.qualcomm.com, guohanjun@huawei.com, suzuki.poulose@arm.com, ryan.roberts@arm.com, chenl311@chinatelecom.cn, masahiroy@kernel.org, wangyuquan1236@phytium.com.cn, anshuman.khandual@arm.com, heinrich.schuchardt@canonical.com, Eric.VanTassell@amd.com, wangzhou1@hisilicon.com, wanghuiqiang@huawei.com, liuyonglong@huawei.com, linux-pci@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-perf-users@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v6 2/3] x86: Implement acpi_get_cpu_uid() Message-ID: <20260312110205.GG606826@noisy.programming.kicks-ass.net> References: <20260312072316.4806-1-fengchengwen@huawei.com> <20260312072316.4806-3-fengchengwen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260312072316.4806-3-fengchengwen@huawei.com> On Thu, Mar 12, 2026 at 03:23:15PM +0800, Chengwen Feng wrote: > Add acpi_get_cpu_uid() implementation for x86, replacing the existing > cpu_acpi_id() function. This completes the unified ACPI Processor UID > retrieval interface across all ACPI-enabled architectures. > > Cc: stable@vger.kernel.org > Signed-off-by: Chengwen Feng > --- > arch/x86/include/asm/cpu.h | 1 - > arch/x86/include/asm/smp.h | 1 - > arch/x86/kernel/cpu/common.c | 15 +++++++++++++++ > arch/x86/xen/enlighten_hvm.c | 5 +++-- > include/linux/acpi.h | 2 -- > 5 files changed, 18 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h > index ad235dda1ded..57a0786dfd75 100644 > --- a/arch/x86/include/asm/cpu.h > +++ b/arch/x86/include/asm/cpu.h > @@ -11,7 +11,6 @@ > > #ifndef CONFIG_SMP > #define cpu_physical_id(cpu) boot_cpu_physical_apicid > -#define cpu_acpi_id(cpu) 0 > #endif /* CONFIG_SMP */ > > #ifdef CONFIG_HOTPLUG_CPU > diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h > index 84951572ab81..05d1d479b4cf 100644 > --- a/arch/x86/include/asm/smp.h > +++ b/arch/x86/include/asm/smp.h > @@ -130,7 +130,6 @@ __visible void smp_call_function_interrupt(struct pt_regs *regs); > __visible void smp_call_function_single_interrupt(struct pt_regs *r); > > #define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu) > -#define cpu_acpi_id(cpu) per_cpu(x86_cpu_to_acpiid, cpu) > > /* > * This function is needed by all SMP systems. It must _always_ be valid > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 1c3261cae40c..3081557542c7 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -57,6 +58,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2643,3 +2645,16 @@ void __init arch_cpu_finalize_init(void) > */ > mem_encrypt_init(); > } > + > +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) > +{ > + if (cpu >= nr_cpu_ids) > + return -EINVAL; > +#ifndef CONFIG_SMP > + *uid = 0; > +#else > + *uid = per_cpu(x86_cpu_to_acpiid, cpu); > +#endif > + return 0; > +} > +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c > index fe57ff85d004..2f9fa27e5a3c 100644 > --- a/arch/x86/xen/enlighten_hvm.c > +++ b/arch/x86/xen/enlighten_hvm.c > @@ -151,6 +151,7 @@ static void xen_hvm_crash_shutdown(struct pt_regs *regs) > > static int xen_cpu_up_prepare_hvm(unsigned int cpu) > { > + u32 cpu_uid; > int rc = 0; > > /* > @@ -161,8 +162,8 @@ static int xen_cpu_up_prepare_hvm(unsigned int cpu) > */ > xen_uninit_lock_cpu(cpu); > > - if (cpu_acpi_id(cpu) != CPU_ACPIID_INVALID) > - per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu); > + if (acpi_get_cpu_uid(cpu, &cpu_uid) == 0) > + per_cpu(xen_vcpu_id, cpu) = cpu_uid; > else > per_cpu(xen_vcpu_id, cpu) = cpu; > xen_vcpu_setup(cpu); This doesn't look right, it will now set CPU_ACPIID_INVALID, while previously it would not. From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:07:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:07:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252001.1548786 (Exim 4.92) (envelope-from ) id 1w0dtR-0000ZF-H7; Thu, 12 Mar 2026 11:07:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252001.1548786; Thu, 12 Mar 2026 11:07:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dtR-0000Z8-DQ; Thu, 12 Mar 2026 11:07:53 +0000 Received: by outflank-mailman (input) for mailman id 1252001; Thu, 12 Mar 2026 11:07:51 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dtP-0000Z2-Rb for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:07:51 +0000 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b45aed71-1e03-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:07:49 +0100 (CET) Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4fWlFh4gmtzHnH8v; Thu, 12 Mar 2026 19:07:36 +0800 (CST) Received: from dubpeml500005.china.huawei.com (unknown [7.214.145.207]) by mail.maildlp.com (Postfix) with ESMTPS id 29C2E40584; Thu, 12 Mar 2026 19:07:46 +0800 (CST) Received: from localhost (10.203.177.15) by dubpeml500005.china.huawei.com (7.214.145.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 12 Mar 2026 11:07:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b45aed71-1e03-11f1-b164-2bf370ae4941 Date: Thu, 12 Mar 2026 11:07:42 +0000 From: Jonathan Cameron To: Chengwen Feng CC: Bjorn Helgaas , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Jonathan Corbet , Shuah Khan , Huacai Chen , "WANG Xuerui" , Paul Walmsley , "Palmer Dabbelt" , Albert Ou , "Alexandre Ghiti" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H . Peter Anvin" , Juergen Gross , Boris Ostrovsky , Len Brown , Sunil V L , Mark Rutland , Kees Cook , Yanteng Si , Sean Christopherson , Kai Huang , Tom Lendacky , Thomas Huth , Thorsten Blum , Kevin Loughlin , Zheyun Shen , Peter Zijlstra , Pawan Gupta , Xin Li , "Ahmed S . Darwish" , Sohil Mehta , Ilkka Koskinen , Robin Murphy , James Clark , Besar Wicaksono , Ma Ke , "Wei Huang" , Andy Gospodarek , Somnath Kotur , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v6 1/3] ACPI: Rename get_acpi_id_for_cpu() to acpi_get_cpu_uid() on non-x86 Message-ID: <20260312110742.00002716@huawei.com> In-Reply-To: <20260312072316.4806-2-fengchengwen@huawei.com> References: <20260312072316.4806-1-fengchengwen@huawei.com> <20260312072316.4806-2-fengchengwen@huawei.com> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.42; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.203.177.15] X-ClientProxiedBy: lhrpeml500012.china.huawei.com (7.191.174.4) To dubpeml500005.china.huawei.com (7.214.145.207) On Thu, 12 Mar 2026 15:23:14 +0800 Chengwen Feng wrote: > To unify the CPU ACPI ID retrieval interface across architectures, > rename the existing get_acpi_id_for_cpu() function to > acpi_get_cpu_uid() on arm64/riscv/loongarch platforms. >=20 > This is a pure rename with no functional change, preparing for a It's not just a rename. This should mention that the addition of error checks and hence the resulting signature change. > consistent ACPI Processor UID retrieval interface across all ACPI-enabled > platforms. >=20 > Note: Move the ARM64-specific get_cpu_for_acpi_id() implementation to > arch/arm64/kernel/acpi_numa.c to fix compilation errors from > circular header dependencies introduced by the rename. >=20 > Cc: stable@vger.kernel.org > Signed-off-by: Chengwen Feng > Reviewed-by: Jonathan Cameron =46rom a reread, a few minor style consistency things inline. > --- > arch/arm64/include/asm/acpi.h | 16 +--------- > arch/arm64/kernel/acpi.c | 16 ++++++++++ > arch/arm64/kernel/acpi_numa.c | 15 ++++++++++ > arch/loongarch/include/asm/acpi.h | 5 ---- > arch/loongarch/kernel/acpi.c | 9 ++++++ > arch/riscv/include/asm/acpi.h | 4 --- > arch/riscv/kernel/acpi.c | 16 ++++++++++ > arch/riscv/kernel/acpi_numa.c | 8 +++-- > drivers/acpi/pptt.c | 47 +++++++++++++++++++++--------- > drivers/acpi/riscv/rhct.c | 7 ++++- > drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++-- > include/linux/acpi.h | 13 +++++++++ > 12 files changed, 120 insertions(+), 42 deletions(-) > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c > index af90128cfed5..984a11788265 100644 > --- a/arch/arm64/kernel/acpi.c > +++ b/arch/arm64/kernel/acpi.c > @@ -458,3 +458,19 @@ int acpi_unmap_cpu(int cpu) > } > EXPORT_SYMBOL(acpi_unmap_cpu); > #endif /* CONFIG_ACPI_HOTPLUG_CPU */ > + > +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) > +{ > + struct acpi_madt_generic_interrupt *gicc; > + > + if (cpu >=3D nr_cpu_ids) > + return -EINVAL; > + > + gicc =3D acpi_cpu_get_madt_gicc(cpu); > + if (gicc =3D=3D NULL) Seems local style for null pointer checks is if (!gicc) Just for consistency we should follow that. > + return -ENODEV; > + > + *uid =3D gicc->uid; > + return 0; > +} > +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); > diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c > index 2465f291c7e1..56e2e486e49b 100644 > --- a/arch/arm64/kernel/acpi_numa.c > +++ b/arch/arm64/kernel/acpi_numa.c > @@ -34,6 +34,21 @@ int __init acpi_numa_get_nid(unsigned int cpu) > return acpi_early_node_map[cpu]; > } > =20 > +int get_cpu_for_acpi_id(u32 uid) > +{ > + u32 cpu_uid; > + int cpu; > + int ret; > + > + for (cpu =3D 0; cpu < nr_cpu_ids; cpu++) { Given more recent acceptance of the following perhaps it is neater here. for (int cpu =3D 0; cpu < nr_cpu_ids; cpu++) { Amazingly there aren't any for loops in this file so we can do what we like from a consistency point of view. > + ret =3D acpi_get_cpu_uid(cpu, &cpu_uid); > + if (ret =3D=3D 0 && uid =3D=3D cpu_uid) > + return cpu; > + } > + > + return -EINVAL; > +} > + > static int __init acpi_parse_gicc_pxm(union acpi_subtable_headers *heade= r, > const unsigned long end) > { > diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c > index 71698ee11621..bde810d02c4f 100644 > --- a/arch/riscv/kernel/acpi.c > +++ b/arch/riscv/kernel/acpi.c > @@ -337,3 +337,19 @@ int raw_pci_write(unsigned int domain, unsigned int = bus, > } > =20 > #endif /* CONFIG_PCI */ > + > +int acpi_get_cpu_uid(unsigned int cpu, u32 *uid) > +{ > + struct acpi_madt_rintc *rintc; > + > + if (cpu >=3D nr_cpu_ids) > + return -EINVAL; > + > + rintc =3D acpi_cpu_get_madt_rintc(cpu); > + if (rintc =3D=3D NULL) Similar to above. Local style for NULL checks is if (!rintc) so this should follow that. > + return -ENODEV; > + > + *uid =3D rintc->uid; > + return 0; > +} > +EXPORT_SYMBOL_GPL(acpi_get_cpu_uid); > diff --git a/arch/riscv/kernel/acpi_numa.c b/arch/riscv/kernel/acpi_numa.c > index 130769e3a99c..cd8adc9857e3 100644 > --- a/arch/riscv/kernel/acpi_numa.c > +++ b/arch/riscv/kernel/acpi_numa.c > @@ -37,11 +37,15 @@ static int __init acpi_numa_get_nid(unsigned int cpu) > =20 > static inline int get_cpu_for_acpi_id(u32 uid) > { > + u32 cpu_uid; > int cpu; > + int ret; > =20 > - for (cpu =3D 0; cpu < nr_cpu_ids; cpu++) > - if (uid =3D=3D get_acpi_id_for_cpu(cpu)) > + for (cpu =3D 0; cpu < nr_cpu_ids; cpu++) { Can pull the int into the loop her as well. > + ret =3D acpi_get_cpu_uid(cpu, &cpu_uid); > + if (ret =3D=3D 0 && uid =3D=3D cpu_uid) > return cpu; > + } > =20 > return -EINVAL; > } > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index de5f8c018333..d034a217e85b 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > static int check_acpi_cpu_flag(unsigned int cpu, int rev, u32 flag) > { > struct acpi_table_header *table; > - u32 acpi_cpu_id =3D get_acpi_id_for_cpu(cpu); > + u32 acpi_cpu_id; > struct acpi_pptt_processor *cpu_node =3D NULL; > int ret =3D -ENOENT; > =20 > + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) !=3D 0) > + return -ENOENT; > + > table =3D acpi_get_pptt(); > if (!table) > return -ENOENT; > @@ -651,7 +661,8 @@ static int check_acpi_cpu_flag(unsigned int cpu, int = rev, u32 flag) > * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, ret= urn 0 > * indicating we didn't find any cache levels. > * > - * Return: -ENOENT if no PPTT table or no PPTT processor struct found. > + * Return: -ENOENT if no PPTT table, can't get CPU's ACPI Process UID or= no PPTT > + * processor struct found. > * 0 on success. > */ > int acpi_get_cache_info(unsigned int cpu, unsigned int *levels, > @@ -671,7 +682,8 @@ int acpi_get_cache_info(unsigned int cpu, unsigned in= t *levels, > =20 > pr_debug("Cache Setup: find cache levels for CPU=3D%d\n", cpu); > =20 > - acpi_cpu_id =3D get_acpi_id_for_cpu(cpu); > + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id)) > + return -ENOENT; I'd put a blank line here (similar to the code you added just above). > cpu_node =3D acpi_find_processor_node(table, acpi_cpu_id); > if (!cpu_node) > return -ENOENT; > @@ -780,8 +792,9 @@ int find_acpi_cpu_topology_package(unsigned int cpu) > * It may not exist in single CPU systems. In simple multi-CPU systems, > * it may be equal to the package topology level. > * > - * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot be found > - * or there is no toplogy level above the CPU.. > + * Return: -ENOENT if the PPTT doesn't exist, can't get CPU's ACPI > + * Processor UID, the CPU cannot be found or there is no toplogy level > + * above the CPU. > * Otherwise returns a value which represents the package for this CPU. > */ > =20 > @@ -797,7 +810,8 @@ int find_acpi_cpu_topology_cluster(unsigned int cpu) > if (!table) > return -ENOENT; > =20 > - acpi_cpu_id =3D get_acpi_id_for_cpu(cpu); > + if (acpi_get_cpu_uid(cpu, &acpi_cpu_id) !=3D 0) > + return -ENOENT; Again, I'd put a blank line here. > cpu_node =3D acpi_find_processor_node(table, acpi_cpu_id); > if (!cpu_node || !cpu_node->parent) > return -ENOENT; > @@ -872,7 +886,8 @@ static void acpi_pptt_get_child_cpus(struct acpi_tabl= e_header *table_hdr, > cpumask_clear(cpus); > =20 > for_each_possible_cpu(cpu) { > - acpi_id =3D get_acpi_id_for_cpu(cpu); > + if (acpi_get_cpu_uid(cpu, &acpi_id) !=3D 0) > + continue; and here. > cpu_node =3D acpi_find_processor_node(table_hdr, acpi_id); > =20 > while (cpu_node) { From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:14:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252013.1548795 (Exim 4.92) (envelope-from ) id 1w0dzk-00028V-7f; Thu, 12 Mar 2026 11:14:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252013.1548795; Thu, 12 Mar 2026 11:14:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzk-00028O-4k; Thu, 12 Mar 2026 11:14:24 +0000 Received: by outflank-mailman (input) for mailman id 1252013; Thu, 12 Mar 2026 11:14:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzj-00028I-Ok for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:14:23 +0000 Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [2607:f8b0:4864:20::542]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9e9d699b-1e04-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:14:22 +0100 (CET) Received: by mail-pg1-x542.google.com with SMTP id 41be03b00d2f7-c73a5473bbdso327130a12.2 for ; Thu, 12 Mar 2026 04:14:22 -0700 (PDT) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae34eaacsm49271645ad.49.2026.03.12.04.14.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 04:14:19 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9e9d699b-1e04-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773314060; x=1773918860; 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; bh=eHEcVdS/sWWyKqS0PygUhFz4ja7UaUTr7MKPVVRagws=; b=DQvJwFP3HOKn0FD6wEvXVzYdEQsprDc0BwmFXkGzP3II2McIHhrX6jPtYPBpuMzO1G T73FAwqhbRyeSbxkgYomNnEybekK7RSacFYtsoDfG/nTKZPtOnJr+GnL/Qd2DDgSKyfP N8qkcne/NuEQU3MkSVib5qjrKpfykvz8xqzMIZOwAVq+dECJ5gRuBvhGULNwuGgIO6u9 o/k4ATbDaeTXxQarRYIhKVbmahI+Y0wS9vB5H5AopU1ut0fLsHCvEWDrVvkTapWcl1c2 PaoajP4OKDD0bsuk75rbBgXUjNvFhWD5Z/BgwvLsextNpviCty5DDepAnoAPXM+viwK4 G+fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314060; x=1773918860; 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; bh=eHEcVdS/sWWyKqS0PygUhFz4ja7UaUTr7MKPVVRagws=; b=kDygM7Em8EUfqE1suwyi2HHMpEGCD9IAKUP3gKj93febp8/VctRc1ARpvmjwoSkWPi ByvcnFq+gTa7mWu5gnhJCA+xUOBjckFOWEXudjFTdAnLjtHDacu0AzOeUzXtWOQEW22u UomF5sH36BxnjpUN86feiNCW5IREZ720Xa0hgmnm0QUISe6yQRpU5TTwuN/N/F7CP8qw VLhzYVfywlaYb51iMLN6nv4VidEnUcrZ/1Qw7ZgJpAIugLzjttJAI8jYxHrBwXj1IAPw KA5NJ4y7qvlEVsMM7f1F4N1wC0745cP+EY5bgY5TFxfU/2uXfnN1TIeTQV0kxrG+KH4g 44eQ== X-Gm-Message-State: AOJu0Yzupnu6Je4SEWiQiMlrnqOUrXfe9zmdhAf0lGaje18lXavejwvq Pp6q125I48NpisamraDck7wQhbkouiWeomXeWs5dTMbjHMokuYea4tZwmcNhY28q X-Gm-Gg: ATEYQzwMdAaO8x32k1kkfe5Ab0THk9B3SMiZi6fw5XNVS2WRaJItJ3um2NxXwGNgZ+8 qyccWOynzA3vkera0pAYH5KVBX9V/yXteCFIUZQkclv2cWTJ0mtzTGN4gYqoCdKH+ilhgeuTBi1 rP3/F59Ip0vzC34vqBR8uHQ6h6TI5ez7F0yFLg0pHldZixMtEbJ8E9qffdU3FEiOVbrTXJIHOo3 kBhHdSGDUcHOrw+0Y8ffTBShHNllHwXrfWbu2DSkQ9TpUo72CZZrPAy6agjGX/Uzln/D4TOHmlT PxQcD5KUQBnO48LA6LuQNFx7j+SjUJmMyzYhw1qRRYE5FdJNPkW/72SL5PZwTUJ6cwQUjZfpg4g 9WHuzQrFV2zPHmbMmYViXqP5CU4+i1kboh359bGJd4BD3J57MNwvNrDAQTtrJHZm0EltX2o8aRa ZvrSYL8MGet1lukKNstKgTmRP4D4UjVZcq32o+aFZgdzfO/dmIxIzfJitbVF393l0ci2NqyUK09 t8JOH3KveoHEMPP7ftjOk6FQpM7tKH2gYfbPIyJGmzUidS/wkPSksTnR0sNAXONEN895qPpula/ dEO4OsZg X-Received: by 2002:a17:902:e84d:b0:2ae:5eee:7a5 with SMTP id d9443c01a7336-2aeae78c1dbmr64401185ad.12.1773314060394; Thu, 12 Mar 2026 04:14:20 -0700 (PDT) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Andrew Cooper , "Daniel P . Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Soumyajyotii Ssarkar Subject: [RFC PATCH v3 0/3] Fixing ACPI BGRT (Boot Graphics Resource Table) corruption Date: Thu, 12 Mar 2026 16:44:11 +0530 Message-ID: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This RFC series plans to addres ACPI BGRT (Boot Graphics Resource Table) corruption, that occured when Xen reuses the memory containing the boot logo image before dom0 is able to parse ACPI tables. The BGRT table contains a pointer to a BMP image stored in BootServicesData memory. When Xen reclaims this memory early in boot, the pointer becomes invalid, causing Linux dom0 to report: Xen: `(XEN) ACPI: BGRT: invalidating v1 image at 0x47cc2018` Linux (dom0): `ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0xF9, should be 0xB4 (20250807/utcksum-58)` This series: 1. Adds BGRT image preservation infrastructure during EFI boot (validates BMP format, allocates EfiACPIReclaimMemory, stores pointers) 2. Integrates preservation with ACPI subsystem (clarifies acpi_invalidate_bgrt() safety net behavior, adds status reporting via efi_bgrt_status_info()) 3. Provides opt-out mechanism (-nobgrt for xen.efi direct boot, efi=no-bgrt for multiboot2, both via early EFI-phase parsing) The preservation is enabled by default to fix the corruption for all users, with minimal overhead (~1MB). Also, servers that don't need boot graphics can disable it using the "efi=no-bgrt" option. Thank you everyone for the constructive feedback! It is really helpful, I hope this RFC series is upto standards, I would greatly appriciate further feedback. Changes since v1: - The BGRT invalidation behaviour should still presist and server as a safety net when "efi=no-bgrt" or the preservation fails for some reason thus: Add Clarify comment for BGRT invalidation behavior with preservation. Reported-by: Marek Marczykowski-Górecki Changes since v2: - Use existing ACPI headers (actbl.h, actbl3.h) instead of custom structs - Modify the function names and code in function to conform with Coding Style. - Reuse efi.acpi20 from efi_tables() instead of manual RSDP search - Use appropriate types: EFI types for firmware code, unsigned int for loop counters (matching ESRT pattern) - Used of sizeof() over sizeof() - Remove fixed-type widths & limited typecasting - Add Blank line ahead of the main return statement of a function. - Better wording error message for image cap size - Remove parse_boolean(no-bgrt) since it could be bit misleading - Add const qualifiers throughout for safety - Use %p format for pointers (32-bit compatibility) - Initialize failure_reason with string literal for proper relocation - Use memcmp() with ACPI_SIG_* constants for signature checks - Add direct Xen.efi calling. - Add opt-out mechanism with proper early parsing during EFI phase. Reported-by: Marek Marczykowski-Górecki Reported-by: Jan Beulich  Please refer to QubesOS Issue for more context: https://github.com/QubesOS/qubes-issues/issues/10764 This is a companion series to Linux Kernel side at https://patchew.org/linux/cover.751f45ebbb644244b1d9da3aff289d6b66db4c6b.1773058629.git-series.marmarek@invisiblethingslab.com/ Testing: - Verified on Intel UEFI system with Fedora 43 dom0 - Before: ACPI checksum errors in dom0 - After: Clean boot, no ACPI warnings - Memory overhead: ~972 KB (preserved image size) Signed-off-by: Soumyajyotii Ssarkar Soumyajyotii Ssarkar (3): x86/efi: Add BGRT image preservation infrastructure x86/acpi: Integrate BGRT preservation with status reporting x86/efi: Add opt-out mechanism for BGRT preservation xen/arch/x86/acpi/boot.c | 8 ++ xen/arch/x86/efi/efi-boot.h | 5 ++ xen/common/efi/boot.c | 158 ++++++++++++++++++++++++++++++++++++ xen/include/xen/efi.h | 1 + 4 files changed, 172 insertions(+) -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:14:29 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:14:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252014.1548804 (Exim 4.92) (envelope-from ) id 1w0dzn-0002NZ-ET; Thu, 12 Mar 2026 11:14:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252014.1548804; Thu, 12 Mar 2026 11:14:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzn-0002NN-BD; Thu, 12 Mar 2026 11:14:27 +0000 Received: by outflank-mailman (input) for mailman id 1252014; Thu, 12 Mar 2026 11:14:26 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzm-00028I-U6 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:14:26 +0000 Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [2607:f8b0:4864:20::641]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a0bd6a30-1e04-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:14:26 +0100 (CET) Received: by mail-pl1-x641.google.com with SMTP id d9443c01a7336-2ae88e16485so7067395ad.0 for ; Thu, 12 Mar 2026 04:14:26 -0700 (PDT) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae34eaacsm49271645ad.49.2026.03.12.04.14.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 04:14:23 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a0bd6a30-1e04-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773314064; x=1773918864; 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; bh=RPerCwQjjELYfGowH6evflvClMRzfpgAd8/IYGd3nUo=; b=mDebFh2bQ5yIw+y0cb2hdOzNRGLJ8VTeuY5SUkV0+B5rSOrHh7bUKwGALpygOKehm2 mgl16lGkVUB9o11mQKVjaZYiylI22UBvJpYkF25sblHu3m4qUgKRjsWeUC/W7YHMfgIf BnYAMC/smos1C8pbz1MpcOKbADAZGzE4p8nW3aN56M0pAGdlBc6VL0BV6TtF+nBijyoh g4wGPn2zXE3t4gkj5E7onZgsPGHNvLnUWguqBOuvGFMAKXFuU7+6mWF3GGgF1zg0vx1n NSQAZQXrbmXvwKjOx0+Yq81NOFwi1G+eA/PXghEbxchUylXxAa+0UdTz0YhQ4FlxlKDy fcxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314064; x=1773918864; 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; bh=RPerCwQjjELYfGowH6evflvClMRzfpgAd8/IYGd3nUo=; b=NhR/j5JaT2BMnF1zOpYindi9vN+JCeu2pdSFHEb3Aa/OsLioSLlgXdRpsL6rSH0cip UYAyJHJg0ExGD7/YtCT5FSosPg3/4vrcZ4mT8XQKyHt0nmBI8JYRcF9aggTyaXU6j48R omqtpcN0Xkm41rxTTcn7IAjaEdPSpLSS8KlA5oWY1n2YrLTEPDq8MLgj1cAjUIBET9Gq U/3rQPPPPirv35dUEkeR/vCSwo/0bKwP4x/kKFo7qcxgc0lEP9B0emrdN9MHQXpMXxWM dt5Njtp+oRwpqqpGgC9LWqTVcewKpHwReqKOEcFL6M2+stttIwR1W48olA7ul0lIosQP KldA== X-Gm-Message-State: AOJu0Yw27j4aQYyOiIL/6rDcJ9gxtzI7gqBQ/qCMOp4sprBQhxA5TB8B HtTUhWGIbUdkAyQQeo6UINo4f55D056zlvawOf0bY9nFUZvX5l3Yp9/ELlL1oCAz X-Gm-Gg: ATEYQzxfeqe7Z1UxsO5Q8FPraMxIiDABdVQX7WUjcg3suIgmzKF/1PpCiZ5ecoYSpKk GCzz7b74CmI2BvcsoUEkoBHFeZeamVFkxHwFZj4c1GWc2ta+UdyFVEzbanifhKtd071fx5oQRxB PcH5g+I/1gpiH7U46DgbaFUnc0lYtH0C4YQkwUsmVcOLAyYGelP35yTDDDKOpOmOfVPhoHuNw14 mTbatBZOnVyjWCitf+O/KBd/qUJtHFv2c88Lua0ajJV/KLDyMAt6Dd/GN9gho5eBv2CAf+7ZTrS 7aIrNsUrQ5UgVZJIbydbXCv9nHx5il5nWcfNHYO9O9tDbx3c1/fbuBMWFYPBL6x85l4bmNdXBny Q9FSTzGv2zwkxjniJPqGnyAlnU+FiSFhXjc5O1otiXvAn3dHLQ5Nm3BMTm9M25X6luNzhARSQcN NugBi36N3QUlauLpjr1Ml+Gbwwd6bxkQILR8HvdWd4DaK/tRKRBn6F6+3pFczKKl0ZgXJXpu1W7 FcMdjMXBsWUZYRIWEaTXsJCML9J1Il/thsWgd8+2cYgtfDfKqiX6ALZKyZTSpYDrKsA6jTt5g== X-Received: by 2002:a17:903:1a30:b0:2ae:4d23:334d with SMTP id d9443c01a7336-2aeae9207f4mr58137715ad.56.1773314064003; Thu, 12 Mar 2026 04:14:24 -0700 (PDT) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Andrew Cooper , "Daniel P . Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Soumyajyotii Ssarkar Subject: [RFC PATCH v3 1/3] x86/efi: Add BGRT image preservation infrastructure Date: Thu, 12 Mar 2026 16:44:12 +0530 Message-ID: <20260312111414.17808-2-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> References: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add core EFI boot services code to preserve BGRT (Boot Graphics Resource Table) images during Xen boot. The BGRT contains a pointer to a boot logo stored in BootServicesData memory. Without preservation, this memory is reclaimed causing ACPI checksum errors in dom0. Implementation: - Walk XSDT to locate BGRT table (reusing efi.acpi20 from efi_tables()) - Validate BMP image signature and size constraints (max 16MB) - Allocate EfiACPIReclaimMemory and copy image data - Update BGRT table with new address and recalculate checksum The preservation follows the ESRT pattern, running before ExitBootServices() to ensure image remains accessible. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/efi/efi-boot.h | 2 + xen/common/efi/boot.c | 133 ++++++++++++++++++++++++++++++++++++ 2 files changed, 135 insertions(+) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 42a2c46b5e..0547d845cd 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -910,6 +910,8 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, efi_relocate_esrt(SystemTable); + efi_preserve_bgrt_img(); + efi_exit_boot(ImageHandle, SystemTable); } diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 967094994d..e6451130ce 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1,12 +1,16 @@ #include "efi.h" #include #include +#include +#include +#include #include #include #include #include #include #include +#include #include #include #include @@ -747,6 +751,133 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TABLE *SystemTable) efi_bs->FreePool(memory_map); } +typedef struct { + UINT16 signature; + UINT32 file_size; + UINT16 reserved[2]; + UINT32 data_offset; +} __attribute__((packed)) BMP_HEADER; + +static __initdata struct { + bool preserved; + const void *old_addr; + const void *new_addr; + UINTN size; + const char *failure_reason; +} bgrt_info = { + /* We would prefer the failure_reason to print */ + .failure_reason = "", +}; + +static const struct acpi_table_bgrt *__init efi_get_bgrt(void) +{ + const struct acpi_table_rsdp *rsdp; + const struct acpi_table_xsdt *xsdt; + UINTN entry_count; + unsigned int i; + + if ( efi.acpi20 == EFI_INVALID_TABLE_ADDR ) + return NULL; + + rsdp = (const void *)(UINTN)efi.acpi20; + if ( !rsdp || !rsdp->xsdt_physical_address ) + return NULL; + + xsdt = (const void *)rsdp->xsdt_physical_address; + + if ( memcmp(xsdt->header.signature, ACPI_SIG_XSDT, 4) != 0 ) + return NULL; + + if ( xsdt->header.length < sizeof(xsdt->header) ) + return NULL; + entry_count = (xsdt->header.length - sizeof(xsdt->header)) / + sizeof(xsdt->table_offset_entry[0]); + + for ( i = 0; i < entry_count; i++ ) + { + const struct acpi_table_header *hdr; + + hdr = (const void *)xsdt->table_offset_entry[i]; + if ( !hdr ) + continue; + + if ( memcmp(hdr->signature, ACPI_SIG_BGRT, 4) == 0 && + hdr->length >= sizeof(struct acpi_table_bgrt) ) + return (const struct acpi_table_bgrt *)hdr; + } + + return NULL; +} + +#define BMP_SIGNATURE 0x4D42 +#define MAX_BGRT_IMAGE_SIZE (16 * 1024 * 1024) + +static void __init efi_preserve_bgrt_img(void) +{ + const struct acpi_table_bgrt *bgrt; + const BMP_HEADER *bmp; + const void *old_image; + void *new_image; + UINTN image_size; + EFI_STATUS status; + UINT8 checksum; + unsigned int i; + + bgrt_info.preserved = false; + + bgrt = efi_get_bgrt(); + if ( !bgrt ) + { + bgrt_info.failure_reason = "BGRT table not found"; + return; + } + + if ( !bgrt->image_address ) + return; + + old_image = (const void *)bgrt->image_address; + bmp = old_image; + + if ( bmp->signature != BMP_SIGNATURE ) + { + bgrt_info.failure_reason = "Invalid BMP signature"; + return; + } + + image_size = bmp->file_size; + if ( !image_size || image_size > MAX_BGRT_IMAGE_SIZE ) + { + bgrt_info.failure_reason = "Image size exceeds limit"; + return; + } + + /* + * Allocate memory of type EfiACPIReclaimMemory so that the image + * will remain available for the OS after ExitBootServices(). + */ + status = efi_bs->AllocatePool(EfiACPIReclaimMemory, image_size, &new_image); + if ( EFI_ERROR(status) ) + { + bgrt_info.failure_reason = "Memory allocation failed"; + return; + } + memcpy(new_image, old_image, image_size); + ((struct acpi_table_bgrt *)bgrt)->image_address = (UINTN)new_image; + ((struct acpi_table_bgrt *)bgrt)->header.checksum = 0; + checksum = 0; + + for ( i = 0; i < bgrt->header.length; i++ ) + checksum += ((const UINT8 *)bgrt)[i]; + + ((struct acpi_table_bgrt *)bgrt)->header.checksum = -checksum; + + /* Filling the debug struct for printing later */ + bgrt_info.preserved = true; + bgrt_info.old_addr = old_image; + bgrt_info.new_addr = new_image; + bgrt_info.size = image_size; +} + /* * Include architecture specific implementation here, which references the * static globals defined above. @@ -1671,6 +1802,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, efi_relocate_esrt(SystemTable); + efi_preserve_bgrt_img(); + efi_exit_boot(ImageHandle, SystemTable); efi_arch_post_exit_boot(); /* Doesn't return. */ -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:14:31 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:14:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252015.1548813 (Exim 4.92) (envelope-from ) id 1w0dzr-0002dN-Ls; Thu, 12 Mar 2026 11:14:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252015.1548813; Thu, 12 Mar 2026 11:14:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzr-0002dG-Ir; Thu, 12 Mar 2026 11:14:31 +0000 Received: by outflank-mailman (input) for mailman id 1252015; Thu, 12 Mar 2026 11:14:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzq-00028I-Bv for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:14:30 +0000 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [2607:f8b0:4864:20::644]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a2c9b25f-1e04-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:14:29 +0100 (CET) Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-2ae5423b02aso6538255ad.1 for ; Thu, 12 Mar 2026 04:14:29 -0700 (PDT) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae34eaacsm49271645ad.49.2026.03.12.04.14.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 04:14:26 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a2c9b25f-1e04-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773314067; x=1773918867; 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; bh=tr7F9R+tUqPLczRWKCRwjM4O+ic73FL25ctZpaWIvEA=; b=gcLWqtKAyWpapckl7CL+iy5G8nSwyQsgMBFzDTAif4ntcsiXMFde1zXvzMEUxbgVT9 3FjWkjM+65hrCdad0RTUuuVxwiP/JnC/AsVpNMad/a3OhWS7hT6F8ZerkoQ6nwUmMMER GW8E2793ZzkvSL2SqEXH09Xz2BnkG0ASk1iiDvn47UU2d/tsSJqM4vZIrTPr5Da3gHTy xeXlnbIZYUpOlzeW5TwCUD7M2ryEVBvFZzEct8mreDtTdssT/KuxokoPIuae6Wz52761 kuDl2pw8e/1nDDG4eapRqSJovwOdSGG1Yqrol8Imt6sEQGrXn1ZzxruDKJ14cDf4ltLr cheA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314067; x=1773918867; 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; bh=tr7F9R+tUqPLczRWKCRwjM4O+ic73FL25ctZpaWIvEA=; b=xPF/eJjMiOFSBhx1X1QuwF97pSyJULJp0DrOmA9qPQgDSQ1TQLRqp+iUisvGBcfv95 33NVGncIcNnsC9A4x0O40htyJPje/1S7bUr01LRorqvAArxSNVQTqnIURHNrkFhAHh06 qlzSRSoXNEW4IVeT2ZN+y/3H1fGaa5aUMb6ZgDRreilWSnYrPQ58n66V7zUvJHK1kdQ2 YslMZ6YdFy6HlEaVnQrhpZYsNHfx7QPUKojjC1+IJGKFuBuh6BI7+skas+bxsvR+CVMW d39XzODXnAJIOSkvczq1B0dQrhbKXS6TOtE42Nao9tAeRcWJZpNUnXPNzAddnsRJ5lFc VgBQ== X-Gm-Message-State: AOJu0YxFXm3HxnzG4nSoia7m1vr1A+JrO6zd6WVJDyetMc1EZ3irs/7e YF/9YAZf21x3P2Z0Gz8EyEI/wuEA05bgTQGyBc0sb4Dnd29WzHUOYMyvFRfpfCqm X-Gm-Gg: ATEYQzzOdJ1+q8cg2bqE0z3iENms+VHTfegSZJf2uk8vog1hpdHXvnYibuABojbx9xU eL+sBBiqtq4m+q1sAI/x/UAFRb76NMSdGW7Lk3d4a3Fl2V/MftbqGVMG/zK/gof08J3Y8QFbmSt OaQIiiZ6RZESwSLWrm57Tie84V4/3hKNQ8OFvP8Aw9XnuYIfDIkpwlYims2TqlTAT9qK7CLVd85 b47hpeJS8a4VywwCQLp0wyAjdMCUvSv5WTp1uaqEs3BP7N+GdsewJnCm+ZNKuHsNZ/kduO/oUdh TaVEMX35efmIY7GV1p24mLXnivmuPwlXw8FV7oohOXe1cDwvwjV/UscD1DXzcTncVSIfSmP7ijn CT+SiPS27CCox5T1+seGkJvkoYFjzZP9vLe+hSrJQZKHRBWChMgFlP0mBfoguGaOr1Xo3lmmACQ bX59WWX9pDS2jeGIT8iID/ADTNIes4/8khiO7AmSAdsMzVQ0r+NkDuy9yncUr4vJmkIKK8msDIj BX74TveDlnR9UCaixRPsT18EnF/W8CgiXLpWF5zFLg+5Llx92XtbErrXpren3+h8BLeUv6sXWFF LtqUJvyJ X-Received: by 2002:a17:902:f712:b0:2ae:6092:8d93 with SMTP id d9443c01a7336-2aeae890c0amr60376925ad.28.1773314067415; Thu, 12 Mar 2026 04:14:27 -0700 (PDT) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Andrew Cooper , "Daniel P . Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Soumyajyotii Ssarkar Subject: [RFC PATCH v3 2/3] x86/acpi: Integrate BGRT preservation with status reporting Date: Thu, 12 Mar 2026 16:44:13 +0530 Message-ID: <20260312111414.17808-3-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> References: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Add status reporting for BGRT preservation and integrate with Xen's ACPI subsystem: - efi_bgrt_status_info() prints preservation status (success/failure) - Called from acpi_boot_init() after ACPI tables are processed - Clarifying comment explains why invalidation code remains The invalidation code in acpi_invalidate_bgrt() now acts as a safety net: if preservation fails, the image remains in conventional RAM and gets invalidated. If preservation succeeds, the image is in EfiACPIReclaimMemory which won't match the RAM_TYPE_CONVENTIONAL check, leaving the table valid. Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/acpi/boot.c | 8 ++++++++ xen/common/efi/boot.c | 16 ++++++++++++++++ xen/include/xen/efi.h | 1 + 3 files changed, 25 insertions(+) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index 1ca2360e00..20afe79db9 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -327,6 +328,11 @@ static int __init cf_check acpi_parse_hpet(struct acpi_table_header *table) return 0; } +/* + * Invalidate BGRT if image is in conventional RAM (preservation failed). + * If preservation succeeded, image is in EfiACPIReclaimMemory, which + * won't match RAM_TYPE_CONVENTIONAL check, so table remains valid. + */ static int __init cf_check acpi_invalidate_bgrt(struct acpi_table_header *table) { struct acpi_table_bgrt *bgrt_tbl = @@ -754,5 +760,7 @@ int __init acpi_boot_init(void) acpi_table_parse(ACPI_SIG_BGRT, acpi_invalidate_bgrt); + efi_bgrt_status_info(); + return 0; } diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index e6451130ce..68e06d707c 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -1911,6 +1911,22 @@ static bool __init cf_check rt_range_valid(unsigned long smfn, unsigned long emf return true; } +void __init efi_bgrt_status_info(void) +{ + if ( !efi_enabled(EFI_BOOT) ) + return; + + if ( bgrt_info.preserved ) + { + printk(XENLOG_INFO "EFI: BGRT image preserved: %lu KB\n", + bgrt_info.size / 1024); + printk(XENLOG_INFO "EFI: BGRT relocated from %p to %p\n", + bgrt_info.old_addr, bgrt_info.new_addr); + } + else if ( bgrt_info.failure_reason[0] ) + printk(XENLOG_WARNING "EFI: BGRT preservation failed: %s\n", + bgrt_info.failure_reason); +} void __init efi_init_memory(void) { diff --git a/xen/include/xen/efi.h b/xen/include/xen/efi.h index 723cb80852..e72ab3c6b5 100644 --- a/xen/include/xen/efi.h +++ b/xen/include/xen/efi.h @@ -39,6 +39,7 @@ static inline bool efi_enabled(unsigned int feature) extern bool efi_secure_boot; void efi_init_memory(void); +void efi_bgrt_status_info(void); bool efi_boot_mem_unused(unsigned long *start, unsigned long *end); bool efi_rs_using_pgtables(void); unsigned long efi_get_time(void); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:14:36 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:14:36 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252017.1548823 (Exim 4.92) (envelope-from ) id 1w0dzw-0002vV-UD; Thu, 12 Mar 2026 11:14:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252017.1548823; Thu, 12 Mar 2026 11:14:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzw-0002vO-PT; Thu, 12 Mar 2026 11:14:36 +0000 Received: by outflank-mailman (input) for mailman id 1252017; Thu, 12 Mar 2026 11:14:35 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0dzv-0002tK-79 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:14:35 +0000 Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [2607:f8b0:4864:20::644]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a4e39ee7-1e04-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:14:33 +0100 (CET) Received: by mail-pl1-x644.google.com with SMTP id d9443c01a7336-2ab39b111b9so4112565ad.1 for ; Thu, 12 Mar 2026 04:14:32 -0700 (PDT) Received: from fedora ([103.2.232.250]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae34eaacsm49271645ad.49.2026.03.12.04.14.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 04:14:30 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a4e39ee7-1e04-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773314071; x=1773918871; 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; bh=1cDGQruln6tADqd5GJFoKiZEDSzQNLfuESS4cK4O5GU=; b=i/Y93/TheXEqQDXW/9BrSmZcO5qI5NuQlvONMeYLP/QMZGOz+s8b7FoRfVKvZQhiOT HxnV4WfgXmb7MaIWDC4nKRecpGhUHygB6ugUFJ0SuKEW3MIrn3lrAGKxCrmNJcqn80Fp EvXNPT027RCDiUE3tDQYt+N8edG65scxFGZ3d/y9jme+RnIQv7cte8/OI0yEmfGiVOvN BvnWrr2i/xL+YMSoYjRA2d3Gjy1ZmuTjSSuZtFHHaQonWZsBzOr0hbSJNIPGorzJakL3 0PcfBD4qX8Qka+is1mbVC6VYfxD+CZBjusMe/R+2fCyvSMmlaQIis8rKN89tXa3KirNd CjZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314071; x=1773918871; 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; bh=1cDGQruln6tADqd5GJFoKiZEDSzQNLfuESS4cK4O5GU=; b=HlYNMcwnZLGoi47kEwvhtCMp35hIJB/EhRS8UeFvbqo0q2qiszJujckA6A2QHtykA0 ha45VfDNPDh7pG8QXsp5BS3GovUW94jIj9R7fH6T1R/5tazZDaVlz+NXWhu6TpeZ5skU cGiTCMItm5E0EwKBi5DNtvKqnbSKVEKRHQaAp6djdEftDyAXdagcL+0XtJdQOJmgH9Es imeHEjY2LN1IDNH4Z+ta58npU4Ap3WlGQDidhAjZXvPZY9YStBsscg93YVgn/x1w3jG5 FnQslpsNFxvntXDKna5bPKh/5TYGujlrqZQxJyywzeLaQ00nujxoA/MviXg8fBFSHZRH hHhw== X-Gm-Message-State: AOJu0Yw3iRPoRmR61WVoDv/dZhVKZGa2Umu+6y5/z4u3jnBxn4uVcYUB FsPrPcqOwqsDNCTXpN+jgtaOd8zaiAWUHqMZoEIg7OdDhtbr1RYUUoMlANDrn4C8 X-Gm-Gg: ATEYQzy4SxhvbE6I4Zx3CXPUVLF6j1BV+BgaIghZPlqRUWbtnnmUzZdsFxNeIej516f WxeAdy2rwmg/PbASzZgQprIeuasgzs3L9zmk8oQs/tg8MNnSjItvXy2tkwyrCvrSBzLrKidzuwy jEBj4TtfmsOLLWkYphmc+XpJXveniK/7Gh8DyNkVpRQok63n5eaHr6lDuOX2yjkWN95UND+bxvy 9ZWf/yz3BnD3gifyOqkAbeP5qsQ3IHWLprGCD1uRxCGfAws4PJM4jbKqDwHckmaGtglICjgZzYX ftc3+/7vDdq8XsnbVlafDTbn2tda5XQLYc3ztmW7rPG14y5CdaLdeG63JBhRhC9kftV/lUBoo+f J1Tyn+aD53GWLAMybvAK/KbKvvSlvio7a4RMrJCQXsQe7YkA7xoVIeu6aypdv8yzyCicZjQA0oJ UnagT44FGnBHEvlbZ9MUVegZfrRs1tpxD0XzFFFk2bTWqn5f2JBh2+DJK0p/sVQyr+LqR5+txCG sQH7xBQTH3mlcaFm05HKO+NrKgxReX+FIMIPChUZx10G/fRaGPYXTP5aYS+ZvC4Tf7SbKrhAQ== X-Received: by 2002:a17:902:f68d:b0:2ae:5ec4:2f80 with SMTP id d9443c01a7336-2aeae8eaf1emr54731745ad.47.1773314070986; Thu, 12 Mar 2026 04:14:30 -0700 (PDT) From: Soumyajyotii Ssarkar To: xen-devel@lists.xenproject.org, sarkarsoumyajyoti23@gmail.com Cc: Andrew Cooper , "Daniel P . Smith" , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Soumyajyotii Ssarkar Subject: [RFC PATCH v3 3/3] x86/efi: Add opt-out mechanism for BGRT preservation Date: Thu, 12 Mar 2026 16:44:14 +0530 Message-ID: <20260312111414.17808-4-soumyajyotisarkar23@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> References: <20260312111414.17808-1-soumyajyotisarkar23@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit BGRT preservation is now enabled by default to fix ACPI corruption for desktop/workstation systems (similar to ESRT). As described in the task: https://github.com/QubesOS/qubes-issues/issues/10764 Add an opt-out parameter to allow disabling BGRT preservation on systems where the ~1MB memory overhead is not desired. The opt-out is implemented through two boot paths with early parsing during the EFI boot phase before preservation runs: 1. xen.efi direct boot: '-nobgrt' command line option (parsed in efi_start()) 2. Multiboot2 (GRUB): 'efi=no-bgrt' peeked from mb2 cmdline tag using get_option() in efi_multiboot2() The flag is checked at the start of efi_preserve_bgrt_img() to skip preservation entirely when disabled. Status logging indicates whether preservation was disabled, succeeded, or failed. Usage: Default: BGRT preserved automatically xen.efi: Add '-nobgrt' option GRUB/MB2: Add 'efi=no-bgrt' to Xen command line Signed-off-by: Soumyajyotii Ssarkar --- xen/arch/x86/efi/efi-boot.h | 3 +++ xen/common/efi/boot.c | 11 ++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 0547d845cd..6c986cf6c0 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -897,6 +897,9 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle, efi_arch_edid(gop_handle); } + if ( cmdline && get_option(cmdline, "efi=no-bgrt") ) + opt_bgrt_disabled = true; + efi_arch_edd(); efi_arch_cpu(); diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index 68e06d707c..dc46e783f3 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -170,6 +170,7 @@ static SIMPLE_TEXT_OUTPUT_INTERFACE *__initdata StdErr; static UINT32 __initdata mdesc_ver; static bool __initdata map_bs; +static bool __initdata opt_bgrt_disabled = false; static struct file __initdata cfg; static struct file __initdata kernel; @@ -825,6 +826,9 @@ static void __init efi_preserve_bgrt_img(void) bgrt_info.preserved = false; + if ( opt_bgrt_disabled ) + return; + bgrt = efi_get_bgrt(); if ( !bgrt ) { @@ -1582,6 +1586,8 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, base_video = true; else if ( wstrcmp(ptr + 1, L"mapbs") == 0 ) map_bs = true; + else if ( wstrcmp(ptr + 1, L"nobgrt") == 0 ) + opt_bgrt_disabled = true; else if ( wstrncmp(ptr + 1, L"cfg=", 4) == 0 ) cfg_file_name = ptr + 5; else if ( i + 1 < argc && wstrcmp(ptr + 1, L"cfg") == 0 ) @@ -1592,6 +1598,7 @@ void EFIAPI __init noreturn efi_start(EFI_HANDLE ImageHandle, PrintStr(L"Xen EFI Loader options:\r\n"); PrintStr(L"-basevideo retain current video mode\r\n"); PrintStr(L"-mapbs map EfiBootServices{Code,Data}\r\n"); + PrintStr(L"-nobgrt disable BGRT preservation\r\n"); PrintStr(L"-cfg= specify configuration file\r\n"); PrintStr(L"-help, -? display this help\r\n"); blexit(NULL); @@ -1916,7 +1923,9 @@ void __init efi_bgrt_status_info(void) if ( !efi_enabled(EFI_BOOT) ) return; - if ( bgrt_info.preserved ) + if ( opt_bgrt_disabled ) + printk(XENLOG_INFO "EFI: BGRT preservation disabled\n"); + else if ( bgrt_info.preserved ) { printk(XENLOG_INFO "EFI: BGRT image preserved: %lu KB\n", bgrt_info.size / 1024); -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:15:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:15:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252046.1548831 (Exim 4.92) (envelope-from ) id 1w0e17-00047v-Aj; Thu, 12 Mar 2026 11:15:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252046.1548831; Thu, 12 Mar 2026 11: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 ) id 1w0e17-00047o-6o; Thu, 12 Mar 2026 11:15:49 +0000 Received: by outflank-mailman (input) for mailman id 1252046; Thu, 12 Mar 2026 11:15:47 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e15-0002tK-D4 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:15:47 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id cecb0d8c-1e04-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:15:42 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-439aeed8a5bso938364f8f.3 for ; Thu, 12 Mar 2026 04: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-4854b0ea7easm87259465e9.5.2026.03.12.04.15.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:15:41 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: cecb0d8c-1e04-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773314142; x=1773918942; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=/YgVZzVAUCkiwt1usxKtFwmZSlfoYoGgDkLJLubAeSQ=; b=DNW+8l+cyIxe7mIeflQNt2+bsKSo2a5qAjxxf9ETwil+9rhtOJbb1IWSgZzV/HWKm0 pa65cp/mIVIR9uuaTjuswys/cZA8QpHuqPKpBN/SWAysem3B26ajo4QL9IutTxLPCRuy su8RS5SXyzjIkMgz2Jc8OhAOuyZdZ4BC2WJHjwU5/yxdRONiQCKKTBVRAu8LYaLRpRc+ WDnDBOd1GBY00sUSDHFCx5mdD8RtV67m++JolXEHPj51UVyBDD1jfShezfBGyEa9lqEd 7xYNp51YQXL8/FOGOG13O8ordF4HjJ14zSvgq0x2isYTT0nW9lcPFZ8WSxXcMMUaeFSo GmIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314142; x=1773918942; h=content-transfer-encoding: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; bh=/YgVZzVAUCkiwt1usxKtFwmZSlfoYoGgDkLJLubAeSQ=; b=SEN5Gn5sVBTVsoKLRAsg23VSrQBbZWQqCmxqeFJzVt+PapWpY+imYf/SM7lPZ8tk4S dLG0YMSmlC8k9tgDu88icHK5Xus6ormGCx6zhLPQ3BpPtgypD0mwBNdGbDcjeOAXUwIO KTklVtpp+9PHc86SCXl1R7SUFWAjqi/PbK/JkhokkoMW5nw6zXCu4BKZn9o+tAkHf6fF MG4IG6fdogcUvjdLsTqc0KFApH5SpUlIxQKw+jHGmzyw+OBXachyzDC1i8yLr9ft4dud qyJa1dqccnTF/F+EgdxVCPl76s1AVLl/sIcYTLMfG8+R67KZeGxRliXOdsBkn3tE86Iw k6SQ== X-Forwarded-Encrypted: i=1; AJvYcCXj8ONRsJnCKu76X32+6zhzZ4THANqbSHAOrf2U+1bQnBSvPUF3zQJNdMYKud/ZUn6jSiUt6HTfFzA=@lists.xenproject.org X-Gm-Message-State: AOJu0YyNwpUifX6OZb1DPLNXXKwvReH3hkY4d0Xqm1p/GK9I3+26Vg4j d+J7VevcuWfgY76lo/+0bmIN96/mz8lvpmIFd552hPwAbov/JKV/pWShrOGUHGe+hQ== X-Gm-Gg: ATEYQzxHga7TXib01jXfR3mc2oCVV91WcOzNXQ6CdNwLV5Y/uB6SpW0WszOY2EsddfA DbXY5rYpf9/unhcuzJSOQuLUBVEjCsjS/G/8Lj1wUu/S6hgWmuvz1RgFj6kjwddEyEfGtDaiOqV JnBt6QBQ/kxT5EtCtrsV8yzPcPbPqIImM0YMc5Zu/fEii19azRMQzhUa8/lHivcefq3Y3RfJYfl 1r55QdmAy+D6DauPkHuwD/8olofp3MTbCKNO2k3aLNEZM6VH4DIzrK+P5B6f17d4uqQZCpTEuZI 5l1ZM1hj/R05iqQKUtLpn5VTqQeRfghganzhfFn7e2I1KKOzWEAKcAYPPktAHDS3wKFQPXg1TXX 2rtkCO1C9lh5xlyb6Isf7NxCfAKx9T7ogO5PHOQQpqTG7Oq/Uemswd4DEgl65vphR9OP0RWK+GI 127+XYTxMVVf5CYVjoAAvgyt7Q5f7oCEWVj7s8EYG41be7Q//N5FxFhACl+NTcJzSdJnE0WIcHW 8DqJRpvAu+NSiA= X-Received: by 2002:a05:600c:8b62:b0:485:4388:348b with SMTP id 5b1f17b1804b1-4854ad76aa7mr99817925e9.0.1773314141785; Thu, 12 Mar 2026 04:15:41 -0700 (PDT) Message-ID: <9f40fbec-008f-4a50-bfb2-27c35d88f2a2@suse.com> Date: Thu, 12 Mar 2026 12:15:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/7] x86/hvm: Support extended destination IDs in virtual MSI and IO-APIC From: Jan Beulich To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-3-julian.vetter@vates.tech> <1e371e65-ca79-42a0-93f9-804f73084033@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: <1e371e65-ca79-42a0-93f9-804f73084033@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 16:27, Jan Beulich wrote: > On 09.03.2026 13:31, Julian Vetter wrote: >> @@ -618,6 +620,21 @@ static int cf_check ioapic_check(const struct domain *d, hvm_domain_context_t *h >> e->fields.reserved[0] || e->fields.reserved[1] || >> e->fields.reserved[2] || e->fields.reserved2 ) >> return -EINVAL; >> + >> + /* >> + * An RTE in the saved state has ext_dest_id bits set. Check that >> + * the destination Xen has extended destination ID support enabled, >> + * otherwise interrupt routing to APIC IDs > 255 would be broken >> + * after restore. >> + */ >> + if ( e->fields.ext_dest_id && !d->arch.hvm.ext_dest_id_enabled ) > > This won't build, as the ext_dest_id_enabled field appears only in patch 6. > But yes, that looks to be the opt-in mechanism I mentioned above. Actually no, how could it be. That's for the DM to invoke. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:18:19 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:18:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252061.1548841 (Exim 4.92) (envelope-from ) id 1w0e3V-0004w7-MH; Thu, 12 Mar 2026 11:18:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252061.1548841; Thu, 12 Mar 2026 11:18:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e3V-0004vz-IG; Thu, 12 Mar 2026 11:18:17 +0000 Received: by outflank-mailman (input) for mailman id 1252061; Thu, 12 Mar 2026 11:18:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e3U-0004vt-FU for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:18:16 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 27513701-1e05-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:18:11 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4853aec185aso7840505e9.1 for ; Thu, 12 Mar 2026 04:18: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-48541b6f708sm311706855e9.11.2026.03.12.04.18.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:18:10 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 27513701-1e05-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773314290; x=1773919090; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=rKNfadOFeIlBU9K3iYL1zTP3YSOV3hGO2ddaUbUR1yo=; b=XnqUYaQCFOUOgUlIJVOUE9H93seVeqwgt6PJ10gziQtje2YWTPHTM5uaYvEzXyKi24 1jBrOx/L1o6QDx8Vazig4xww2n40qXb89YA4Ce8gVrmflkkMURMxIKHNpdrYB7DIhiSU 74dLj/vBHuX+kl8rNI4wP1in8BfkxW6lB3CpAKDZBhS1LbBykRvrgqLpM/TfukSmbI9T 5dD3Qe9os+m4koKPXIr47n9IfQga53KCHIrh/pivRGw6Pen5ilhAAjCisPOGnyMRAjgw ups4xeETPA0PiILh4aGqmhGPoj5m5D2FJiE1DF3KTWHdlY5Up42rMQFCMOxG2YybSvd3 LLCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773314290; x=1773919090; h=content-transfer-encoding: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; bh=rKNfadOFeIlBU9K3iYL1zTP3YSOV3hGO2ddaUbUR1yo=; b=n3wx/NxtNVrnftmM4LuatnQFw5K2cwMPKRnpo4P/bDINPqm1sfpCiYEt00i+SiX0vp Jtuxhn2dgDc/f+vSoI4yR92b/DSkgj/M2sVoi0Ve2HRf2cScYpLoLZ5Z5Ed/QJBkc3gl 498q1nj9ES+ehZqkq+LiATscTaGaAfe22G4byMed1eongPQU4eC1to5ayy0r02XhA62X mLi76g14VPNGp2K/xaLdYB3mz7Ir2HC9x30HYbVHJxwbDu36AKc4sp1HGSTcZSf6ESPB 2z0X2NReJT1WvDFc9YzvQHXdG6Gx7XaOEX4EYS4v2azkENJk+exnYq049pMZNPb1UAmL k32w== X-Forwarded-Encrypted: i=1; AJvYcCVuvZoDbYnIcR3xdNmYiQfnFFNkPa57hVtQGANZonfnvjYJ/vvydbXyRJb6Ql48UYznFgcqqpVWdS4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yz1EfzB5ci25E4YyiGS1eoOWMSUoR0lxiI7qD6HO2cf0UvoCCqI adcwoowCAHm6jedpLso717ZsycdoloLGiAlzyzRhTQoRcaMRTQILQbA2s2tib6SPbw== X-Gm-Gg: ATEYQzw4avq6Y/Wo18ValNOrVf5Q+JV/Z0yKdTmo2KSp92SeEAj/3wIu40kMmMm99G8 Y+w4ILYj+4SfL3MHLireTt7VaIoE6k8lklB1X9ReOjir4pv/fa342EeqwQguI84yluDG/IeUjCo RObS5qWpPtcwndh3HlU3QCWmwicGOpujmdFaRWWiT0SsLG2SUEudUgdsxiQUEZVWmMl0xE6LrU4 PZwhv6I5l8XJqLc9n02WilLAV9Vbv9ykgGF4PRFTzC8WQMnb8CxwDtU31lvJf31QuQS0IeUANLO Mv0faeWkCb3t3UxMHz68EJzv9Dg8xaV08P8aviHzupX+MHnElw9MyO5ub1Gmt8ti5/p9W2Zp/32 HMfQPN5WdOITLkonjHmNF9tqwpe7oXbSjKSkEw7xMs7KzeWTFmz6FgTx6YPv4C3fcW4N1bAk/bq kaWUpae6J47RRn7l0ALXexQbiIj44K3OD2N1qz3HQBy2Reoq63X1oXwAT6bUItZJ8DsuyOIs6Qs isaLc/Mv7l+ATmFhVqSPGFiMg== X-Received: by 2002:a05:600c:1f87:b0:485:42ba:fc8 with SMTP id 5b1f17b1804b1-4854b0a547cmr100873325e9.4.1773314290366; Thu, 12 Mar 2026 04:18:10 -0700 (PDT) Message-ID: Date: Thu, 12 Mar 2026 12:18:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/7] x86/dmop: Add XEN_DMOP_enable_ext_dest_id DM op To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-6-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-6-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > --- a/xen/include/public/hvm/dm_op.h > +++ b/xen/include/public/hvm/dm_op.h > @@ -447,6 +447,15 @@ 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 > > +/* > + * 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 > + > struct xen_dm_op_bind_pt_msi_irq { > /* IN - physical IRQ (pirq) */ > uint32_t machine_irq; How come this is put between #define-s and their corresponding struct? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:50 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252073.1548848 (Exim 4.92) (envelope-from ) id 1w0e6r-0006Qt-27; Thu, 12 Mar 2026 11:21:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252073.1548848; Thu, 12 Mar 2026 11:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6q-0006Qm-Vk; Thu, 12 Mar 2026 11:21:44 +0000 Received: by outflank-mailman (input) for mailman id 1252073; Thu, 12 Mar 2026 11:21:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6q-0006Qg-Co for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:44 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a515461b-1e05-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:21:42 +0100 (CET) Received: from BLAPR03CA0175.namprd03.prod.outlook.com (2603:10b6:208:32f::14) by SA0PR12MB7089.namprd12.prod.outlook.com (2603:10b6:806:2d5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.4; Thu, 12 Mar 2026 11:21:38 +0000 Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com (2603:10b6:208:32f:cafe::ca) by BLAPR03CA0175.outlook.office365.com (2603:10b6:208:32f::14) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.27 via Frontend Transport; Thu, 12 Mar 2026 11:21:41 +0000 Received: from satlexmb07.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.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:37 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:34 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a515461b-1e05-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cANjpbbNdAhIVgUFtD5ujr0TpLAuRDbpvVAhhSTKnH/vz3jat4v9YfGklkNGr9XM5NxPgbySyoL2icEo8NyNVhEH8aJzx5YcUBq9pzuLxvnVi0pV3HGstUyiZxMmk0HPZWOw5qLRwvG1XtYgxdbVxivBZjLpp+YSAtR9A6iwZ4gZk3KrGEj5c5TdojqmKxa08YVGj3lhVUXjTrduE2JMatu/Ejvj20945uYlISU1kgSsq9zqVf64OkdMWwnwP4QLptafW4CLrDmMX9TmI5akeL14lvmIjdZ3YZ7uJJ/I6/bZwkExqm+EB3LfNvFU+nuwQkE9dLeLybCp2lHQtYQq4Q== 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=fl9WOa5+CGWuMt/NgIMPauuuEm/Py0qSEHzrocRSpSk=; b=KIpdDqN2Jk8F1oVzD1azMWtbIiC0gWtf1lymkhKxTku+i+hn4iUbfYYAUp/wYOMXRG685lJ31iGZWRs6sz7/vFwTlFSd5Ds+t5qFE8B8SVIGQPOVWvGZgWtHKkNogEmc2aM7o8uZ/TCFuGJLb3K6+XHErnt4G4Nqdp5dJogNoYq5TXVGWP7fN056FQoBEnBHHEj+is/+N4w4VYVajCR8meRlyLuz8txCnv3mDSbW2Um1mpA+I3iK5x0kb8TVCqpSTYDP3kKxwbyRr01lksYW/R6B1OcrI90Hkik8WDyBAM7rBaNp0h7zO8iep6+JgJiYfMew4yKJPzoYLHnJHfwPrA== 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=fl9WOa5+CGWuMt/NgIMPauuuEm/Py0qSEHzrocRSpSk=; b=gmE0VExvzmbivTJ8YJABUdF5dGjM6HeMx7nTkJgys/+gbdmyVwW1Ya/xC23rvVf9im+wY2otqfJfAr5YJTea+8Gx6iN75sNbR9yUO3hqzkqZPBoMY0YMzTy1Ygu3MK1ijHZJNp5yoRzhOmE+6NOfJ+FJC1Z0kNjmuABTxvNYcww= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD , "Jason Andryuk" Subject: [PATCH v5 0/5] x86: Drop cross-vendor support Date: Thu, 12 Mar 2026 12:21:09 +0100 Message-ID: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0DF:EE_|SA0PR12MB7089:EE_ X-MS-Office365-Filtering-Correlation-Id: 05fc8d67-1952-4044-98e9-08de80298698 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|376014|1800799024|56012099003|18002099003|13003099007; X-Microsoft-Antispam-Message-Info: 74wxoyiOkc7d5+3CxLMAOtMVRMa5WfbSuQ++oAfEaaeG5fFXSZB1TPjFvvC9K2FICyaq/houCI84jMhQuJG/Q2OI6JsztBMAxjx8esMqAn/r3Eq0YWFOeBe4X8mVjAmIHBx/sDR6cLkpk5UeXTnKkyAlh9NueUItpEpvHsEhUkFpmrpK3zyZYUNzoMKxwh+hzEb5j3vffaCozTUftnsgZEyGHKBeJG8SbWjMcPnJBZ27dp+gnbYFPt0ecKefvNdRwYTXg8nE9G9Xuxxm7OB5gnr40tigK5XrUqc1vZrD+qxu6OT4x2DsoXiqOo+4vi9SxDrBeP+x3qtMXZ0F/X3+n4Q6TE5RsllgIC41zMoPXnB9CrZevdqIFhKsNVBLjpCOpvEH+6FWGJP5dQbiTsvAChF8zTCGwdmAgbInlML+y7mooa4gcoBor8Wl8A9llCxHr/ctqfj+oedGw1hPmRnvS2bxLaeMwE0GQb2V0rlefDZZUGZ9iyAswP4SWGrjxhOvyIBnWQtnMF7x4EmtcyfEmcpqVrkMfs6s+kRBC9nzrLKbidSyLDj/6SjJ+gs6DFckloTjyvpd3wByLQDdrZ2P4FPAhrZgngjSb9qhYiiLgCa27JH2QV030jAXHE/hpS13at9/EXgVaO1KPkhrn5Ei9MNFqq7UDEliyGnJuhebXBOAsWtjOHs1LiR6p9pFTxsROXAgx3D5gXr7GuL9UDVgitHfpna6ohZbBgFbBA/n1JhkxmVA0Fnwpu0+4LfxfI2dT+4cFg/IQuqEKO3KXpjsyunyMpPIfOl4N/Rs0XFmQ7Q= 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)(376014)(1800799024)(56012099003)(18002099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: c+LdKe8jgbOrr1ayz52g3eumnNRkyCEgXaj4hPzUBoXQjzoSsWT4bpar7bcwdZf0q6brh8TaeOaZnWdDcS5CS7zW+/iweFc0s6o1hj/Fc9Qq9PBUie0eSAg96uSGw8+KWkBaZKlqfc0DLihMzQHRnr/mX7IN8+l4Q78NF9+kLkXAsi/t5FoHP70ASQq1spBU+Bx8wXVSwVCzlu2NMKyFe2/RxHIXz+Hn9sFStpAXf5Ne90nh8GGHygf+IEGiHVazuSqUQz1iCVOHcARjO7b0YxBaIdbuU/ythbcjAO1Ij2upfR15Q+bgmM8bjL7hCR4bYpu01DcsfJ55/pWycOpBjq9LoyMZCkJdNtxj4ZLAIZp7QvtXrIy1cP7c/yN/eDyFAdM8yTKNWP/N+iZs6cUQMRZ2HTb2hnHsQWLnuW9OW8I6mFVYkKmzkHhr1ODA7qit X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:37.2888 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 05fc8d67-1952-4044-98e9-08de80298698 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: MN1PEPF0000F0DF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB7089 Hi, Patches 2, 4 and 5 missing acks. Patch 2 now does a minimal diff change, while 4 and 5 perform the meat of what v4/patch2 used to do. I had patches 4 and 5 appended to the end in the hopes of having 1-3 committed sooner. v1: https://lore.kernel.org/xen-devel/20260122164943.20691-1-alejandro.garciavallejo@amd.com/ v2: https://lore.kernel.org/xen-devel/20260205170923.38425-1-alejandro.garciavallejo@amd.com/ v3: https://lore.kernel.org/xen-devel/20260213114232.42996-1-alejandro.garciavallejo@amd.com/ v4: https://lore.kernel.org/xen-devel/20260311142711.16754-1-alejandro.garciavallejo@amd.com/ Cheers, Alejandro Alejandro Vallejo (5): x86: Reject CPU policies with vendors other than the host's x86/hvm: Disable cross-vendor handling in #UD handler x86/hvm: Remove cross-vendor checks from MSR handlers. x86/svm: Drop emulation of Intel's SYSENTER MSR behaviour x86/hvm: Un-indent the HVM_FEP block in the #UD handler CHANGELOG.md | 5 ++ tools/tests/cpu-policy/test-cpu-policy.c | 27 +++++++++++ xen/arch/x86/hvm/hvm.c | 62 +++++++++--------------- xen/arch/x86/hvm/svm/svm.c | 45 ++++++++--------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/hvm/vmx/vmx.c | 3 +- xen/arch/x86/include/asm/hvm/svm-types.h | 10 ---- xen/arch/x86/lib/cpu-policy/policy.c | 5 +- xen/arch/x86/msr.c | 8 ++- 9 files changed, 86 insertions(+), 82 deletions(-) base-commit: a3a1e61ce9a00c5a0c8003bad8f1285360399cf4 -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:53 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252075.1548859 (Exim 4.92) (envelope-from ) id 1w0e6z-0006gm-CL; Thu, 12 Mar 2026 11:21:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252075.1548859; Thu, 12 Mar 2026 11:21:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6z-0006ge-6o; Thu, 12 Mar 2026 11:21:53 +0000 Received: by outflank-mailman (input) for mailman id 1252075; Thu, 12 Mar 2026 11:21:52 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6y-0006gG-Bs for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:52 +0000 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazlp170120001.outbound.protection.outlook.com [2a01:111:f403:c10d::1]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a6ee6a70-1e05-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:21:46 +0100 (CET) Received: from MN2PR16CA0054.namprd16.prod.outlook.com (2603:10b6:208:234::23) by LV2PR12MB6013.namprd12.prod.outlook.com (2603:10b6:408:171::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.6; Thu, 12 Mar 2026 11:21:40 +0000 Received: from MN1PEPF0000F0E5.namprd04.prod.outlook.com (2603:10b6:208:234:cafe::8a) by MN2PR16CA0054.outlook.office365.com (2603:10b6:208:234::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.28 via Frontend Transport; Thu, 12 Mar 2026 11:21:40 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MN1PEPF0000F0E5.mail.protection.outlook.com (10.167.242.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:39 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:37 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a6ee6a70-1e05-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=N7zp4KZc9j0ywkgTjZmROpWJTadr0WJ5dzYNtCTcPTQwKdsybYZcBksjArJq6cgmX8AP5NJKNKcusdbXUqHIkad5VLL0UXXhpExaj4lfsAW5zKECnn53+y0Wl+VU5AN2xNacujnEkJhu1MpGZO2Z1eg3TJwIIgdd0NdPxyq9xa403bsQDfxPmfB2LYEfQI753smHaj4K8y2BSZEUEChdMMTNnF0nkoXKAp8tMTG8r8k6xbARIFdFsePNBavRN9ZvtXppN75a33FZ5hFAes+yDtpTSHAbRgrIAMgH0btsejgWKZYyLtcSAX5ocgmVT8iWAJKqyKAtDPoKUnxa5f3/jQ== 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=DUuyrM9nbhvSaUzGq1+p73eNNfOyYjtxNbuorXkrPm4=; b=ECoXZJK+OM96DoqUqrZbr/yKEUvis5YqafWh6zAI9xMtpkbb8vy63V1mD/cjxT7rOBkDEO7P27aiE/F4miJoodhA+gmZOOny+o1PZkSiNZZOCE7cxTdFJBOLkNIKJ6PJRHf95NUSR31lETgVum9XQPVlEHTte3yVVEqueJ3y1uFC3230MxEBZ1VcYAx7qLxEIiHtP1la0cXWdSyvLxH7ZimDb8yHGaCEVunOEKVAyT9wAMYUhQqMkXHCN1czUsdQvJOzL4Acg740gSsHEO6I3dmiA1oMExFWp8XOia6xdH849xzJGpjQCg2numbaun5LKcCqYWzhR9qw4u+OVChRPA== 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=DUuyrM9nbhvSaUzGq1+p73eNNfOyYjtxNbuorXkrPm4=; b=xgI1HopUNHl5UViDqCqrS/jFO403UNI8O8OPerjlxdPR1++XlrPorMWCDAo2r+CLDyL4UrFfxILjvnHZv3cgM9i0fld8k/bgaidhTdJ5kPO7tws8PoxZQeDGRs4Xt1SUK1TT9Q7Iorw2OKZa2vH4k+x/mB63cO/+7bwfI2sD134= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Oleksii Kurochko , Community Manager , Jan Beulich , "Andrew Cooper" , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Anthony PERARD Subject: [PATCH v5 1/5] x86: Reject CPU policies with vendors other than the host's Date: Thu, 12 Mar 2026 12:21:10 +0100 Message-ID: <20260312112116.22563-2-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0E5:EE_|LV2PR12MB6013:EE_ X-MS-Office365-Filtering-Correlation-Id: 10c4aa1e-0274-4f9b-d5a2-08de80298819 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|82310400026|13003099007|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: Yt80KbQovZePI7mp8e6N6PZn76yVQEoG3qtFG0/E67Z7RcCR6CbDOuk/OZiU2K81EdWRq31t6xiCZeoMY+gUL3/VZ+W0uiPQE7xLMu/D6Ror6/slS+fhdg9d60tab6508xjUq9Irhx2qKsWuVLzx2qy0nWQJjsQOA+L13arCQNlklMj742kIGLKeWbIyv8YUnIGeJx7W41v5yKZNnZ1RK8WV8fipSBqManU8Vzl7oUL8CAg2U3iqNQTxP2MoEI24x946T7OSXpJOZqovqfrMukkGQGXQl2hYpCkGANTGsisUoGaMTcotAmdwhYw/mNT4mc4qpagxiC7OGKINdhpxsGemUF4LMLL3TqYhVP/7PeXmgwkmraz4Up8SdfV6S0aREOfLXbDQtX5+0g531h3eEoT6/XdyLRf0VUJOs4KCR9Med6LACZAZB1EPmF+yxHkdALD/bN175UuJk5H7qeyLVi9h7bhsomc6LFU98fRyQqxJ/gIsK+v4CIn0ZVsWm/TS3OJXovw+SSRAuJjPeitoGprx2n1IKs7x+gXVxI/LJEvk6YFFmDtL31JOiEjLTS30oMRknLs1CUzSFwaAFM+DVbqEmNHtowjntmb1SYz7k0h/9Cy7EEhbDhT1i5bJVv6EpZzVDXPtHk+HFYs3vfOpAzoLnZM9a/G5KMXj2n8jLurUrs7ilwDNj7srxsKFT47FZfPqd4LAuw58QxY0PlmGerSuTsyJZO6o+M0P2cx0ios= 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)(13003099007)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: qRAoR9EcpPjhTn4fyCO1kEubQnRbg8O/TxparZHPbEQG5aY3Tv2kZeXYvo1mmcWnj2wax/e7gOdzbq4wISdRA94lqUQ9uLdHpNCJd6rU3QTcbexiMZIEsyS1tuk2WIIVvaCrInXkaY2R51WuQrL9sA2VlP7NIR12hhQgbsSsEb7f+JRsqQdYfjb/yijIuDUTO4kFGPOtOa7AMmAAUGNJJ7c4qrXwbnr4WEGp6JPqqLnThNr6JhyxxCu7lPPBZX3pdy4pWH3CV+pqxGyuvaHGqFgOE3VR4yIj48Ata268Ex87yIgN5XA9nQgtDocKn6cNc7jqDFAVCbFaUDzqzOMXTQld6djbxZY2kJ6Md9pSaabC/Kk69bbjbGtiqnqGtCSRHISXc6sSXKLGfEtlv4YiIOEKCiXRiSeflbiI6QHSfKy4ifp8KyaeaDyRzDlfUlzG X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:39.8149 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 10c4aa1e-0274-4f9b-d5a2-08de80298819 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: MN1PEPF0000F0E5.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB6013 While in principle it's possible to have a vendor virtualising another, this is fairly tricky in practice and comes with the world's supply of security issues. Reject any CPU policy with vendors not matching the host's. Signed-off-by: Alejandro Vallejo Reviewed-by: Jan Beulich --- CHANGELOG.md | 5 +++++ tools/tests/cpu-policy/test-cpu-policy.c | 27 ++++++++++++++++++++++++ xen/arch/x86/lib/cpu-policy/policy.c | 5 ++++- 3 files changed, 36 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c191e504aba..90ba5da69e4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 prior to the version 1.0 release, and there has been no development since before then in Xen. + - Domains can no longer run on a system with CPUs of a vendor different from + the one they were initially launched on. This affects live migrations and + save/restore workflows across mixed-vendor hosts. Cross-vendor emulation + has always been unreliable, but since 2017 with the advent of speculation + security it became unsustainably so. - Removed xenpm tool on non-x86 platforms as it doesn't actually provide anything useful outside of x86. diff --git a/tools/tests/cpu-policy/test-cpu-policy.c b/tools/tests/cpu-policy/test-cpu-policy.c index 301df2c0028..88a9a26e8f1 100644 --- a/tools/tests/cpu-policy/test-cpu-policy.c +++ b/tools/tests/cpu-policy/test-cpu-policy.c @@ -586,6 +586,19 @@ static void test_is_compatible_success(void) .platform_info.cpuid_faulting = true, }, }, + { + .name = "Host CPU vendor == Guest CPU vendor (both unknown)", + .host = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .guest = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + }, }; struct cpu_policy_errors no_errors = INIT_CPU_POLICY_ERRORS; @@ -629,6 +642,20 @@ static void test_is_compatible_failure(void) }, .e = { -1, -1, 0xce }, }, + { + .name = "Host CPU vendor != Guest CPU vendor (both unknown)", + .host = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .guest = { + .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 2, + .basic.vendor_ecx = X86_VENDOR_AMD_ECX, + .basic.vendor_edx = X86_VENDOR_AMD_EDX, + }, + .e = { 0, -1, -1 }, + }, }; printf("Testing policy compatibility failure:\n"); diff --git a/xen/arch/x86/lib/cpu-policy/policy.c b/xen/arch/x86/lib/cpu-policy/policy.c index f033d22785b..f991b1f3a96 100644 --- a/xen/arch/x86/lib/cpu-policy/policy.c +++ b/xen/arch/x86/lib/cpu-policy/policy.c @@ -15,7 +15,10 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host, #define FAIL_MSR(m) \ do { e.msr = (m); goto out; } while ( 0 ) - if ( guest->basic.max_leaf > host->basic.max_leaf ) + if ( (guest->basic.vendor_ebx != host->basic.vendor_ebx) || + (guest->basic.vendor_ecx != host->basic.vendor_ecx) || + (guest->basic.vendor_edx != host->basic.vendor_edx) || + (guest->basic.max_leaf > host->basic.max_leaf) ) FAIL_CPUID(0, NA); if ( guest->feat.max_subleaf > host->feat.max_subleaf ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:54 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252076.1548866 (Exim 4.92) (envelope-from ) id 1w0e70-0006vK-Jc; Thu, 12 Mar 2026 11:21:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252076.1548866; Thu, 12 Mar 2026 11:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e70-0006v7-GG; Thu, 12 Mar 2026 11:21:54 +0000 Received: by outflank-mailman (input) for mailman id 1252076; Thu, 12 Mar 2026 11:21:53 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6y-0006gG-Vo for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:52 +0000 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azlp170110003.outbound.protection.outlook.com [2a01:111:f403:c110::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a92e7c0a-1e05-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:21:49 +0100 (CET) Received: from BL1PR13CA0326.namprd13.prod.outlook.com (2603:10b6:208:2c1::31) by IA0PR12MB8746.namprd12.prod.outlook.com (2603:10b6:208:490::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.8; Thu, 12 Mar 2026 11:21:44 +0000 Received: from MN1PEPF0000F0E1.namprd04.prod.outlook.com (2603:10b6:208:2c1:cafe::be) by BL1PR13CA0326.outlook.office365.com (2603:10b6:208:2c1::31) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Thu, 12 Mar 2026 11:21:44 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MN1PEPF0000F0E1.mail.protection.outlook.com (10.167.242.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:43 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:42 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a92e7c0a-1e05-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=L6tiSSxfWGep66AXiweCBgbnJJjtNk3Nfr1vNxHJnSiqNAUctsNF9tqCz2mNXQvdLYZgN+sIDovFtEi5wNxzuYtLzz0Lh+7cUdaCqht5KC0KsZhsTzhJ+uRjD6j7oCQwHEkXE30HL4HdUv3cngWwiGVbGOhy3lvPlzSCTgphRH9lsh2/1KupgTNUfQbN7JuWeNo4n30e1VfUpygM0knimxTGvhE1G7Zb8RRDvnkkb2TgpYEY6rHCCTwlPqTQlgzVsDOot6ZGHmCG7hxD1wGlyAEJgK7l/thF6mCdE9lwQ/19qJYFnMEN5pboC92g+RaGrieRk1V7dsvOUyhayrinpg== 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=PdWkxG9i7l3rW3T6Rp/jnTpeGEs/5PuOgfzAZHWlwfs=; b=T11K9iAzdkyxogVDPOgWwn9euCjJGSfjo2LaI5PmMK5maDevrWSfNx9tbwhjhhzo5rXb3oEMX/BFsf84Pz58bbh0IhLW5ztP0KNKSd4kxg/5viHVDX26bezXrU6GqeSx9eL03X2PqGp4vVlvGnPhtJS6tJB4k+F0gZRMH5eu5zY7fin3Ub4menVnq2MPFk9PnW3BYUgt/I+PgWR49nlp7wg+QCMNVUHyYdOn+mmbSqP4Tw2+faVtMV3YRFQ8VCZaPMpxvnBVGYVItEAYL8qGgdWoItSLkIGhnY7oGUQ0YhrsRWBMNKdfjkrca29ORqhUA0OuxR9/vUcVREs62SsSUw== 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=PdWkxG9i7l3rW3T6Rp/jnTpeGEs/5PuOgfzAZHWlwfs=; b=WZSRH1PKTZzq2RkWcQl329WCT6NRG8KKUfeS89fBPC/DY4re0rbrOr6+QE7nPY6oGed5bmQHb6hWRYDCpDa4e7r6/KpW8KeeyU+9rRmehHVjF82pJICWzitoyb8V+nv0fq4L10tEOIPNrE5fbCboH9ZOa7iBT879Vp8IpYI8gWs= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Teddy Astie Subject: [PATCH v5 3/5] x86/hvm: Remove cross-vendor checks from MSR handlers. Date: Thu, 12 Mar 2026 12:21:12 +0100 Message-ID: <20260312112116.22563-4-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0E1:EE_|IA0PR12MB8746:EE_ X-MS-Office365-Filtering-Correlation-Id: 890a0033-8e69-4725-e3be-08de80298a8e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|82310400026|1800799024|36860700016|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: MT4HRgnSStF36CMp1hPj6Ej21MtbAN9m6FfH0VqiYy/8yAw0GA1nUTuxnIUOvohkK67mxNHosdS2fC2ZmqJBKEJhZeNRIEYGRzpMe/FTdYF2goBzC+ie6hxFYldQaGq4tN5N8HjCCM4W7pPEJymaTcgu2cgqsRhnuAk6K7JCS1+zyNd8d6vxW537D4mjEoucpcgAkMkc8BshLJUqLo8oHLOQ7PyxfdTARDA9u3oxub7uUm0OLm5lGk6FFNerRIALGZs4bN+X2TMxC/6tSNN9CFrtqgF/h4gamr1daylVBtnHTiKFC+dxw2an8E3MtS6qj9ZJeqO+6c5//9uZ6wQpyiABXdoyqtw4SKqKqWE5aEtap72sfY4Ziib7pou2MXGK7l7RokhgBe2MmYNVEpAFyl+HCw1ZXrqZcz8Zy28XDVU73gossb8W/FF5+MktDc1C5ks7OfsVnlwcQZETI4vNZ6ltickdUQ6KVAafGq+ZsAX7M/T2HCH26x1A91T2BnkTqZ0T7ienDmjSTpi4fL8smPUdTRkyWmX8baV4PNyzuFZCiDZg/lTjOFa8PKYJnSDH+3DiDOICzpAfaf4OO0B0z60Pi9ew6Vi+X9jLxA+i4QMYQP6AyvC12aF5S5buIvnJ801gKKFDNrcxdj5sMQQNEKAFRHfQl7o1aH0sFLD3PD3VFqXmRr2D5gD19KoIbHDRyblEWFNwBWUryueF2i2xPa9jxi5FuXljbGTKV4FswAe2x+IqUtM3ddifoQVwaK0z54VVghvXOd19N67DiC8Y0w== 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)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: LrviW/m6EdCv/MZmRMjmxbXCmD63tMX+CgbNuEaSJUQ4+yBwfuupNpl1wpn1uqzuRuq0Leqa4LwLe7QxK5ro2z1TFJgkteMJqqu+LbnmlDUr+KUi/gSlz590uct90LJHbm4Vn6QBVUy4MXcbpZ3lAs9jUdxU0G26aGsbdtEbcW/6JxEsAjIzp/hACxqd/IY76fKKW2Hn/U+j043F/9ULQy2K9MoNInEdeN1Uij97of2rMDdRQVVkLvDpekAI5wAQl+HNd4fNtONbfoZrtpX/O5HPS2E360S0yVL5oEJWx7+25RD+UWPKKyA39r8Y/sO6/rAmuFHvGf32dL4dsvgIFBX1eqUYBAIoipxG0fYPouBLANjtTLz4y7bguDsM7LlRQNjnwd7AfQmpINCgE0OBOCZ8HLOxXhVGDWGzRgpXCxd6wQkEiGPgbx+lF+ixnnAl X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:43.9381 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 890a0033-8e69-4725-e3be-08de80298a8e 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: MN1PEPF0000F0E1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB8746 Not a functional change now that cross-vendor guests are not launchable. Signed-off-by: Alejandro Vallejo Reviewed-by: Teddy Astie Acked-by: Jan Beulich --- xen/arch/x86/msr.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 6a97be59d52..d10891dcfc8 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) break; case MSR_IA32_PLATFORM_ID: - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) || - !(boot_cpu_data.vendor & X86_VENDOR_INTEL) ) + if ( boot_cpu_data.vendor != X86_VENDOR_INTEL ) goto gp_fault; + rdmsrl(MSR_IA32_PLATFORM_ID, *val); break; @@ -189,9 +189,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) * from Xen's last microcode load, which can be forwarded straight to * the guest. */ - if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || - !(boot_cpu_data.vendor & - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || + if ( !(boot_cpu_data.vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) || rdmsr_safe(MSR_AMD_PATCHLEVEL, val) ) goto gp_fault; break; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:55 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252077.1548873 (Exim 4.92) (envelope-from ) id 1w0e71-0006yI-1R; Thu, 12 Mar 2026 11:21:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252077.1548873; Thu, 12 Mar 2026 11:21:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e70-0006xA-NP; Thu, 12 Mar 2026 11:21:54 +0000 Received: by outflank-mailman (input) for mailman id 1252077; Thu, 12 Mar 2026 11:21:53 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6z-0006Qg-99 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:53 +0000 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazlp170100001.outbound.protection.outlook.com [2a01:111:f403:c105::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id aa9b1b7b-1e05-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:21:52 +0100 (CET) Received: from BL1PR13CA0313.namprd13.prod.outlook.com (2603:10b6:208:2c1::18) by CH3PR12MB8754.namprd12.prod.outlook.com (2603:10b6:610:170::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9700.8; Thu, 12 Mar 2026 11:21:46 +0000 Received: from MN1PEPF0000F0E1.namprd04.prod.outlook.com (2603:10b6:208:2c1:cafe::11) by BL1PR13CA0313.outlook.office365.com (2603:10b6:208:2c1::18) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.25 via Frontend Transport; Thu, 12 Mar 2026 11:21:46 +0000 Received: from satlexmb07.amd.com (165.204.84.17) by MN1PEPF0000F0E1.mail.protection.outlook.com (10.167.242.39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:46 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:44 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: aa9b1b7b-1e05-11f1-b164-2bf370ae4941 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=occdNwNAxGe/QkbK3kUGeDaWy5SyuDTLAvQFupUrbQKMFzHl9cqJZ3rakyhiWspmiQUJcdkwpqpZdw8KR9b7aaus8lHyy4g0+cj+R7/cDrbdOzwNvrAUxl2FbzgBwyQZ5kSldm42tdE4QKr+8y6hAlr4G0J7KonpcQfqoYsmWSefaa+BEjBqP6qB+REu4mV8eu9aCxoafqUgxksMvRCqc7jmMDMw9rlSNTYSZCIWKz4p3F5s+21FMU1uLxdRIOKHUdYmv45A74ssttqblD83fTCRzO7JOAEYa4MFVlUYjWpH5APDUjaKTdf3oOpYW+vM9xC77ushgv5HUYW5iBVUeQ== 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=Soh9rhU/Aoc+mc4XaiFXphWcynULpkzWojo6OlbgdPQ=; b=CdTB2ijb08ewRQulmiG7eTIYRYzXnbBFDrb/yp6HIPwr9E9gKemR4I2iEDMPMjghFRxrAWyPPpFX9Vyuuy73tPDlHA4ta22U/4dhA++FnZSICjLrv+eJADlt/tRsuC+T0ZXKPdEsY6Hrl+pTFiva7mbXxJd2E81275UdSBe3D43jKlrgYXvgUI3CIMMbe9IrdPzdoWb0C+GDlShwP94Sn1hxxFpdoPgLpuMxNZ/ZdzjoXz7QMEeTYyLMK/w5QRu+PDe3jHsdmTKtKXA7fPOtNTNUrKDyzk/IdQEcUERQpOe0YdzdIOs5Qy8tgRUxnrUFe0jP0OImspFKXSt5hygtqQ== 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=Soh9rhU/Aoc+mc4XaiFXphWcynULpkzWojo6OlbgdPQ=; b=JEMYQ6Uu/lcHH3lYNRKgwP0cxqXl/nuQhZ3IePe7isz09MWf7tiD4CiLCoaZ4EIEccRpUUQQl84rXd3fSDVkrWyn6W13IQFoW5+zENraYZ/Hzi1jHiIxvHrK9v3I35ytQlTB/0tiLAR13Lb5QTR2HhQXNQpdVej9Ez9QA0B0hKo= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk , Teddy Astie Subject: [PATCH v5 4/5] x86/svm: Drop emulation of Intel's SYSENTER MSR behaviour Date: Thu, 12 Mar 2026 12:21:13 +0100 Message-ID: <20260312112116.22563-5-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0E1:EE_|CH3PR12MB8754:EE_ X-MS-Office365-Filtering-Correlation-Id: 3ac9a602-f8b5-4dcf-30ba-08de80298c1c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|82310400026|36860700016|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: oPD5RXA+UVks79lWS9Aa28gog5dqjSHQhA0CUcFOCd6kiBssIxhnUn4SK+hr9/HF+9SnDhvu6mi6Dy/ifu6F8k1DUo+NFTGDDIwZnvec/vEmwwg3EegGmkZR//3NaIeToO3jXOR9gygR/luaszXVCV3graAuotRcy5oKqQ509WStc9zb7761qjUdtgmaha2I5GSc3pOOCQhmgJUcbEeX2BE77/DrLjyvHLWnEiYB+yps8WqYWuAS4pAQ02cupNIrMXwRGaeWEEcyTIB6XsTkrLHA4ROFHNuElmbCp5p1td1VP6FOxfU4mg8uXGf6RKSJasS6NHN+6TnmWve9IMi4SwVV7Kfr6yFbEDy0X3iISK/5FmiMeeX/CqLT72w7YyfkcZXY/XRBqRNunExO7XAkd+L9Kezl93MhiWnmFiYooTAO7KMX3ZddeJVghOhbvhoxYz+NnRkcG5k6VOaMDNn+Q/JdUc9KloOCPp+nYwIOorVXIZyYPsV4dzeo3q09pUNZdG9ZH6cXCP9c3CIDHGcHecZBgYc0NhVHImXoJFZU8Gf1Vlq7AZXQlg6rrVeZQ+KioXyOCXDuTsLD/ndZHeAxEegar7BRkprxPW00pyu5JmNkBogEJQGgOnBLI9tPvdfW/kusd+Ht0y4TJVhWJdbZwoGTf3KKgJnSqmL1ODPEbzzcRvjTeFVVbaeY0Xe/CLBhAnBhUGt8E2+TBusvyid/1GWIp1YBUvBBmmwRXyA2kwNLi0HudDVyb9ZKSTg9M6dH 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)(376014)(82310400026)(36860700016)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: GrLsm6r9WTyMkmTr/2Bzs3Bz0efOeuD8OIfcwPuTSqD8t1qkxS7ei9S2aS2GGkqr4KrrEjBaOU/V7ElgcSXz+H6KJsJUFtzOJAPqaS5mY/QyMtSM3euIp81e7OF4sZBsbEvYvGEuEKiohBpJdo/DaQkJGtrlqhW9Cd7iILP1QAxU7UKTY1/WgfJ1PF72gPJydaCed1ECTdZ+U9bxNrj6biTo816h3DAmF0lk6pvSzqAxylB2Tb+KMfVcIr4gaVeHvxjDoHEfN0dBgavVdwB138CtFIKY2DuBKONaNy1PulTxjZoY7mvkh/KHNQo6Q59D6N4zz14gGCExJftkEBH+gAePK7jPrEzwj7W14y7X+c2wLpMM+49rUP+1PTRzJ6HH61Hp1ZNUFwi7Ha6WhUi6So68ODL50171rpTV06l7CcvyUjxkcfyUdQwBqZZNCzM1 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:46.5488 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3ac9a602-f8b5-4dcf-30ba-08de80298c1c 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: MN1PEPF0000F0E1.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8754 With cross-vendor support gone, it's no longer needed. AMD CPUs ignore the top 32 bits of the SYSENTER/SYSEXIT MSRs, which is not how this emulation worked due to the need for cross-vendor support. Any AMD VMs storing state in the top 32bits of the SEP MSRs will lose it. It's very unlikely to affect any production VM because having 64bit width just isn't how real AMD CPUs behave. Signed-off-by: Alejandro Vallejo Reviewed-by: Teddy Astie Acked-by: Jan Beulich --- v5: * New title --- xen/arch/x86/hvm/svm/svm.c | 42 +++++++++++------------- xen/arch/x86/hvm/svm/vmcb.c | 3 ++ xen/arch/x86/include/asm/hvm/svm-types.h | 10 ------ 3 files changed, 22 insertions(+), 33 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 20591c4a44f..076d57e4847 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -401,10 +401,6 @@ static int svm_vmcb_save(struct vcpu *v, struct hvm_hw_cpu *c) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - c->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs; - c->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp; - c->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip; - if ( vmcb->event_inj.v && hvm_event_needs_reinjection(vmcb->event_inj.type, vmcb->event_inj.vector) ) @@ -468,11 +464,6 @@ static int svm_vmcb_restore(struct vcpu *v, struct hvm_hw_cpu *c) svm_update_guest_cr(v, 0, 0); svm_update_guest_cr(v, 4, 0); - /* Load sysenter MSRs into both VMCB save area and VCPU fields. */ - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = c->sysenter_cs; - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = c->sysenter_esp; - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = c->sysenter_eip; - if ( paging_mode_hap(v->domain) ) { vmcb_set_np(vmcb, true); @@ -501,6 +492,9 @@ static void svm_save_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; + data->sysenter_cs = vmcb->sysenter_cs; + data->sysenter_esp = vmcb->sysenter_esp; + data->sysenter_eip = vmcb->sysenter_eip; data->shadow_gs = vmcb->kerngsbase; data->msr_lstar = vmcb->lstar; data->msr_star = vmcb->star; @@ -512,11 +506,14 @@ static void svm_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data) { struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb; - vmcb->kerngsbase = data->shadow_gs; - vmcb->lstar = data->msr_lstar; - vmcb->star = data->msr_star; - vmcb->cstar = data->msr_cstar; - vmcb->sfmask = data->msr_syscall_mask; + vmcb->lstar = data->msr_lstar; + vmcb->star = data->msr_star; + vmcb->cstar = data->msr_cstar; + vmcb->sfmask = data->msr_syscall_mask; + vmcb->kerngsbase = data->shadow_gs; + vmcb->sysenter_cs = data->sysenter_cs; + vmcb->sysenter_esp = data->sysenter_esp; + vmcb->sysenter_eip = data->sysenter_eip; v->arch.hvm.guest_efer = data->msr_efer; svm_update_guest_efer(v); } @@ -1734,12 +1731,9 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { - /* - * Sync not needed while the cross-vendor logic is in unilateral effect. case MSR_IA32_SYSENTER_CS: case MSR_IA32_SYSENTER_ESP: case MSR_IA32_SYSENTER_EIP: - */ case MSR_STAR: case MSR_LSTAR: case MSR_CSTAR: @@ -1754,13 +1748,15 @@ static int cf_check svm_msr_read_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_CS: - *msr_content = v->arch.hvm.svm.guest_sysenter_cs; + *msr_content = vmcb->sysenter_cs; break; + case MSR_IA32_SYSENTER_ESP: - *msr_content = v->arch.hvm.svm.guest_sysenter_esp; + *msr_content = vmcb->sysenter_esp; break; + case MSR_IA32_SYSENTER_EIP: - *msr_content = v->arch.hvm.svm.guest_sysenter_eip; + *msr_content = vmcb->sysenter_eip; break; case MSR_STAR: @@ -1954,11 +1950,11 @@ static int cf_check svm_msr_write_intercept( switch ( msr ) { case MSR_IA32_SYSENTER_ESP: - vmcb->sysenter_esp = v->arch.hvm.svm.guest_sysenter_esp = msr_content; + vmcb->sysenter_esp = msr_content; break; case MSR_IA32_SYSENTER_EIP: - vmcb->sysenter_eip = v->arch.hvm.svm.guest_sysenter_eip = msr_content; + vmcb->sysenter_eip = msr_content; break; case MSR_LSTAR: @@ -1984,7 +1980,7 @@ static int cf_check svm_msr_write_intercept( break; case MSR_IA32_SYSENTER_CS: - vmcb->sysenter_cs = v->arch.hvm.svm.guest_sysenter_cs = msr_content; + vmcb->sysenter_cs = msr_content; break; case MSR_STAR: diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index e583ef8548c..76fcaf15c2b 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -97,6 +97,9 @@ static int construct_vmcb(struct vcpu *v) svm_disable_intercept_for_msr(v, MSR_LSTAR); svm_disable_intercept_for_msr(v, MSR_STAR); svm_disable_intercept_for_msr(v, MSR_SYSCALL_MASK); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_CS); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_EIP); + svm_disable_intercept_for_msr(v, MSR_IA32_SYSENTER_ESP); vmcb->_msrpm_base_pa = virt_to_maddr(svm->msrpm); vmcb->_iopm_base_pa = __pa(v->domain->arch.hvm.io_bitmap); diff --git a/xen/arch/x86/include/asm/hvm/svm-types.h b/xen/arch/x86/include/asm/hvm/svm-types.h index 051b235d8f6..aaee91b4b61 100644 --- a/xen/arch/x86/include/asm/hvm/svm-types.h +++ b/xen/arch/x86/include/asm/hvm/svm-types.h @@ -27,16 +27,6 @@ struct svm_vcpu { /* VMCB has a cached instruction from #PF/#NPF Decode Assist? */ uint8_t cached_insn_len; /* Zero if no cached instruction. */ - - /* - * Upper four bytes are undefined in the VMCB, therefore we can't use the - * fields in the VMCB. Write a 64bit value and then read a 64bit value is - * fine unless there's a VMRUN/VMEXIT in between which clears the upper - * four bytes. - */ - uint64_t guest_sysenter_cs; - uint64_t guest_sysenter_esp; - uint64_t guest_sysenter_eip; }; struct nestedsvm { -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252078.1548885 (Exim 4.92) (envelope-from ) id 1w0e72-0007LK-4o; Thu, 12 Mar 2026 11:21:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252078.1548885; Thu, 12 Mar 2026 11:21:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e71-0007KS-W3; Thu, 12 Mar 2026 11:21:55 +0000 Received: by outflank-mailman (input) for mailman id 1252078; Thu, 12 Mar 2026 11:21:54 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e6z-0006gG-Vq for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:53 +0000 Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [2a01:111:f403:c105::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a9874ec0-1e05-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:21:51 +0100 (CET) Received: from BLAPR03CA0179.namprd03.prod.outlook.com (2603:10b6:208:32f::33) by LV8PR12MB9405.namprd12.prod.outlook.com (2603:10b6:408:1fa::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.7; Thu, 12 Mar 2026 11:21:42 +0000 Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com (2603:10b6:208:32f:cafe::36) by BLAPR03CA0179.outlook.office365.com (2603:10b6:208:32f::33) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.27 via Frontend Transport; Thu, 12 Mar 2026 11:21:37 +0000 Received: from satlexmb07.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.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:42 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:39 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a9874ec0-1e05-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pzFx4z92leE4X94xzu6vXFjM59CEBxe0fnTSy0wdRI6obVtU+DxheYnlV+yBGahDO0Uk6qZUL2RQWDcog3MxdadXcqWdBo6NnSVwTpAHVvDpf9OFRI/T+T6mLs7afU6r3IFI28zD6aklfsRz+mHDKd607I8Z834/afqFdCO9qwIvfbbOJsGyxLdY6Wp+u5SrvhrFEaBL+liuR8E0hSvOKTw7F6b+StW+yYgdVvsYp2mSPSn40F5YBsMjPaYVlmOm2P1633CIDIwhCYjDpURHd2H+b9y+6WpX8aj/5ASuAIB8nTRNV/BOKR1+jIiNXHfajSj9O6H6Ri/QhfEeYgbqeA== 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=wv5wvI380mS69M5JH7UHNf7qmRDw4qiA/tgGNcS4cFM=; b=feBmPoti15B5Q4AoZ1DKIEngV8URAIk6B44RRlrlEsJG+44j/1+t9l5lyQ8+xStRVkEfGsLKYfXMt1AFbw6iKnQK+oZalzQdOVFmh8chw4ImRZK5NZahB6pN3jsIOjrrafjKoBMNAY6GAU6Ld20MsoOl52JTY82IVSJeSyU9wMu+BSOpDK6AcoYPGXYnx872p2ugwsIJkT/qIWxkpp50ah1Mt3dsCoOw+mcfJeWlqzJD/kF7q/rvuuCIT928cT3tmqSS/64hMU0aZh0MOUQxyve5DwU2Am0YIIqUMzhOhHBaDPBFuqvwzvw3wGnPXpeXGhhdw0q4ke8Xpz1o0JDQZg== 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=wv5wvI380mS69M5JH7UHNf7qmRDw4qiA/tgGNcS4cFM=; b=GX/rSusZYPQm81Z6n0EQJKB3UAfJpaaUIq5ZR+RXWD0zW1LTbedBJ5qeDAfaDaRQyKmFGxB98VJPwGXQvPywhDhaSDeMYSzi7RfS5IkFCEIqveJuQbfWj0rW2VwaxqQ4kNBFQHILgmYCvaEF2RUm3EfV7XCvu50z5LcAq1GJlcs= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Jason Andryuk Subject: [PATCH v5 2/5] x86/hvm: Disable cross-vendor handling in #UD handler Date: Thu, 12 Mar 2026 12:21:11 +0100 Message-ID: <20260312112116.22563-3-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0DF:EE_|LV8PR12MB9405:EE_ X-MS-Office365-Filtering-Correlation-Id: 3cfe8d4c-7893-4c72-3952-08de8029896d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|36860700016|82310400026|376014|1800799024|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: tUoTV/kTkQL2wetZ09nm49C92ytV/0meKac80akq1LuKClxmq9qhlq0mUrHpDGsSlk7Hmd83EocIS+GYaINXV8JYH65CbgpUah8mHulqDFdr7ZtVC0WHFQDDPNLB8iDeLo3HEydWzBkEN6ux9dyre6zOoHxFrFY5K5RNmpylFf2t9hfeBkfRMUEdcmRo9Kdt2nZJ6eS5U4S6vQmCu7SYfrsEpkS4aSgDI8xaeLyZE2QCRpjI6Vl0Dl4kx0FX3/ad0MCflByk/a3jmwuJergu6ad287S2YKsawBWPx/pgkBUWEx23Lf1rWJK9GcOVVHpgqIclAzh7AOWTwJpqW2Uds09LUvfmYSxm5n5iZykq5mIMbQ6cLW3QAqlKCMWk3mDsHZoSNKqB19IbyR/HUhf7ID3/8a3+5bCk+/Cj6G4bq63HyMQEAVttmPpqW2fZrBsnVxquhFbnw2fTewxywFFBIEWJMRgx1FlTMkeTBjb0I1cL0QbSlNfrf+xKWcUTpAQpq9sygXeNv3vfnA4SLkTodqFZpjhad2Ryvjgdiz1rU0MTQK7TLgQSkkvB2uWCjkVBhcN9y6S5UXeymOGhzrjlM3PxUGITZmQBnyJ6GIGpFmYda9Lr9QexH/FyZPKs3XyGUHAGQqGAXMBcd/7eQJYZR8ohWsgpfQlqk22JePrpc/IQPImpEfpW2gfkGvMXj5wC6tk6+Kgrpb9qAko0W2OLvbvA5lt1L+eg6wyp+cxxA7dw0QIq1gXGEjBk1scw//DYbugKTBsodcZf0eGRLfX7XQ== 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)(376014)(1800799024)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: +QpxfV8ndm2BiwAr6EMhW9o1SOzpXerkK1X5rEDNjoRwPHwUFBD88eKPmYkQqx/Pk76bRv2d3XwQRLJ/RzVwStMlNJFPuZE/SL0tQ6ICyOtHkTwIzjb+mOrqoYivOD1akeGtNaQcxrsqMdJMwtk/eLwxZGYDAoz8eR0/4pbZYI59Zj0qS6yJbOBXVDSZt9nX915Aj7coxnOhBeFBnrOqbbiKWL/tPrtm28TrY+d6wa4Y0VReEJenBublWKwioXSIgLn/x0H5NhA3tBTG8KIzsM6RzReR11I7wdOslzVk0gid4OlUvLZbEzC/y+ANQjf3ZvxiR8ZdK+YMfG/E0eLC4H7jVi6rQaXLxY4QMrPBpVQ0ozVav41GjgfRbXZRwP7riF+DEuYULfo1q8WTXGmhQP3TQTxDE6lGUbP6JGxBhy67dg1bxrMkwSQXukdiuFqb X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:42.0393 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3cfe8d4c-7893-4c72-3952-08de8029896d 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: MN1PEPF0000F0DF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9405 Remove cross-vendor support now that VMs can no longer have a different vendor than the host. No functional change intended. Signed-off-by: Alejandro Vallejo --- v5: * This patch now performs a minimal diff, with the other parts appended to the tail of the series. --- xen/arch/x86/hvm/hvm.c | 19 ++----------------- xen/arch/x86/hvm/svm/svm.c | 3 +-- xen/arch/x86/hvm/vmx/vmx.c | 3 +-- 3 files changed, 4 insertions(+), 21 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 4d37a93c57a..c8cae41705d 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3832,28 +3832,13 @@ int hvm_descriptor_access_intercept(uint64_t exit_info, return X86EMUL_OKAY; } -static bool cf_check is_cross_vendor( - const struct x86_emulate_state *state, const struct x86_emulate_ctxt *ctxt) -{ - switch ( ctxt->opcode ) - { - case X86EMUL_OPC(0x0f, 0x05): /* syscall */ - case X86EMUL_OPC(0x0f, 0x34): /* sysenter */ - case X86EMUL_OPC(0x0f, 0x35): /* sysexit */ - return true; - } - - return false; -} - void hvm_ud_intercept(struct cpu_user_regs *regs) { struct vcpu *cur = current; - bool should_emulate = - cur->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor; + bool should_emulate = false; struct hvm_emulate_ctxt ctxt; - hvm_emulate_init_once(&ctxt, opt_hvm_fep ? NULL : is_cross_vendor, regs); + hvm_emulate_init_once(&ctxt, NULL, regs); if ( opt_hvm_fep ) { diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 243c41fb13a..20591c4a44f 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -589,8 +589,7 @@ static void cf_check svm_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; u32 bitmap = vmcb_get_exception_intercepts(vmcb); - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) bitmap |= (1U << X86_EXC_UD); else bitmap &= ~(1U << X86_EXC_UD); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 82c55f49aea..eda99e268d1 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -803,8 +803,7 @@ static void cf_check vmx_cpuid_policy_changed(struct vcpu *v) const struct cpu_policy *cp = v->domain->arch.cpu_policy; int rc = 0; - if ( opt_hvm_fep || - (v->domain->arch.cpuid->x86_vendor != boot_cpu_data.x86_vendor) ) + if ( opt_hvm_fep ) v->arch.hvm.vmx.exception_bitmap |= (1U << X86_EXC_UD); else v->arch.hvm.vmx.exception_bitmap &= ~(1U << X86_EXC_UD); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:21:58 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:21:58 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252080.1548895 (Exim 4.92) (envelope-from ) id 1w0e74-0007g3-LV; Thu, 12 Mar 2026 11:21:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252080.1548895; Thu, 12 Mar 2026 11:21:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e74-0007ft-GR; Thu, 12 Mar 2026 11:21:58 +0000 Received: by outflank-mailman (input) for mailman id 1252080; Thu, 12 Mar 2026 11:21:57 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0e73-0006gG-1e for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:21:57 +0000 Received: from DM1PR04CU001.outbound.protection.outlook.com (mail-centralusazlp170100005.outbound.protection.outlook.com [2a01:111:f403:c111::5]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id ac67d48b-1e05-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:21:55 +0100 (CET) Received: from BLAPR03CA0173.namprd03.prod.outlook.com (2603:10b6:208:32f::35) by DS5PPFD22966BE3.namprd12.prod.outlook.com (2603:10b6:f:fc00::662) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9723.6; Thu, 12 Mar 2026 11:21:49 +0000 Received: from MN1PEPF0000F0DF.namprd04.prod.outlook.com (2603:10b6:208:32f:cafe::ae) by BLAPR03CA0173.outlook.office365.com (2603:10b6:208:32f::35) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9678.27 via Frontend Transport; Thu, 12 Mar 2026 11:21:44 +0000 Received: from satlexmb07.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.20.9678.18 via Frontend Transport; Thu, 12 Mar 2026 11:21:49 +0000 Received: from xcbagarciav01.xilinx.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.17; Thu, 12 Mar 2026 06:21:46 -0500 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ac67d48b-1e05-11f1-9ccf-f158ae23cfc8 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SdwFOJLt9vlEHVBamaCRsdGomWgkR28q8jXTETF5GHnCNPqjGoDJdAFndp9JJoWrfCWVpUl2NDqxwAD3MJDJxWOqsHT5U7EXkxcgHF9JCu//OgmNxtFrj6ISbPZU0u6PCkCBmTtl9uscQZ/d0hzKXy23NbyPFr9Z3CmRdLGigtmGy2wH6hx82PSQby/TcrnjV5I0gYiEzeJtKbBwH7ujOUuZHGKsh9jES2E5dSscchqMH8T4r9SgAmhZ/bUYXiNSYIB1MzlYXQp12ybV/H9MbSXL7Rbv+LMrX7vu4P1X7rkDJtFYwwYcoXXJhW9f1GWis6+yn3/h2TedMdgz+qp+NA== 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=N3XZe9B6SBQbKn8ypeUZSmODNlvYz970OWYJkLumTS8=; b=Zotl9oheACloDlcH4fuVeVA9pA8kTKNjs16BsFs/tKGQja2orxHsq1wFixX8KelCj3uJhDKDKjvoCKp+KYWioTv1DD7cMUEfm5+owSBS+E9SwWqTSc4lkFWf/BIPmcU2tdcaW6ukh+RDBvrsfmnOQPdkYZAIGzb4AZj0TMWDfDS4Rouu3RNKCHXLUKWXMgY78quJbIta9OhHd+B6FQtpl8jl0IRSBeg/FigYY/rxvjrUhAqGIFr++26vZ0/Awqe6vpg/VbVwxK/ri1W0z2J6ApSnvajgUZpF9N7lM68Lpc4sjhunzezmMCM0I0L8ZKP1cdfwR4rPHNZjGiJQw3/FaA== 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=N3XZe9B6SBQbKn8ypeUZSmODNlvYz970OWYJkLumTS8=; b=I41yhbnbCCdgxN4HPe7jxHsRLs1+DJQrW9TQO00TYuJ/OSljlFN4UBfqukqJvevuauTZqYEflT6OLCOYSyc/G8Fyby3dhwRVh0SZ5ruM2gemQMqCL9ocIU9f/Da7TbK3vcP5ThSXoijyFo0PY74TtprOviLMjTNMqz4wj5b6QWw= 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: Alejandro Vallejo To: CC: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Subject: [PATCH v5 5/5] x86/hvm: Un-indent the HVM_FEP block in the #UD handler Date: Thu, 12 Mar 2026 12:21:14 +0100 Message-ID: <20260312112116.22563-6-alejandro.garciavallejo@amd.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain 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: MN1PEPF0000F0DF:EE_|DS5PPFD22966BE3:EE_ X-MS-Office365-Filtering-Correlation-Id: a1bddbd4-34bb-46d9-c773-08de80298d9d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|376014|82310400026|22082099003|56012099003|18002099003; X-Microsoft-Antispam-Message-Info: M80IomQrWaBTjaPrn8qRafC1MRET4Uc6BdN07XML7ADd693QHE5w2s9Cuo3TLolDUQ3EmEEeoKhKEIdYd1CN3W5+AMlwvYiKaCUYSHeIostRq1zQUsxAvFFEtWRDhyIcjVr2LovdS10gt2VFpyeLzoaNh3bZ260M9S0fVAFiQ066nCwbuY9+wwINvEgqbU/EQzj0UayNNZrlp8/Ezq71sZsQKoRGwP43Up8vgdIFB5Zxs8ofww+BRNCHNIV5MGLu0V9UNt3iFOlfR+fKimKl5VF3fVh58XPeik2nztJ4GJQ0UVSr+T+eGzEvQe7qOxH4yxVgWLeL9weS1QyoaMmeJ0AutRg1H3pooPAOz+2+i8t102/2zk5ZTzl5XLoeoV+T6j8Z7cvwm6opHEpAHMRX/E5jt8WQ1pmEt1nKUw3TqA8jmTyxG85+qgt7k7eFaTJZyHgBL0XK+yjIdpTizYUmlX87dJcO6gSp2EbslL2WumxbGnpqF13sHWTEDqK0GmS+NceIyUBGC/Tg/irjtPyBmYXyD19c5N8m7uOxFTcMMBgghPyBatdf6pI7/i04XdjDGgD3mjBuIw15u3KKqoPAPFiPNiSjRJNng2nTJxRObFbfEujH8SoshdBDDScQcCEBzWOoD4Xlr0f+Qr/NDMZlTWgQ1CI5mz1sO0npf1DiZuzOFi6En7RXrjJqFFBWg/fEoy87oeOxKsxwLco6LrstBppVr0GqRvL6mrIxJaAKtldol5eqvaV2ar9EkWbZSHwU/XjscZYttzBclzf9fGpitg== 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)(22082099003)(56012099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: B41kkjv6oc6ttN8PFcrSRImCRottItfd9+FR7GwO7jGjKS49tWsrbJhr/ILyeKRVnEE716wUw74R5GijJ2DoirUR3xeIoY/tmpjmvwqImm9bJnXoyU3C5HHoL8+OcAE8W6I3F1b+JycSXR+NrRUu5676LYU+XiqGDkbi6IOXzYO/X5vJ6dq1ZeKA1aenS8vefk5Fz9TFUqW7CLgwtmXVfdtb24rZYXBU4uTqteY1TPQG8CEwa/KoLXzUv+Sl1oiRL2Kmt0RiJixNPm++cz9lV6glzSosEZp2u6uIhGTL0QAcix++qAxidQtxgOhN+fyp+Eiohzl+NOQH/GK6tZo8LBAYiAazvNxASs1D6WA/y+NJSmWJbFK6C1iU2vwxmGgQZMYHVnejY/zQdiXJxqMEfjxJS7tlr0ZEFBZiZjZKuC0ikPtg3uZ+aTUX6pinKXJN X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Mar 2026 11:21:49.0692 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a1bddbd4-34bb-46d9-c773-08de80298d9d 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: MN1PEPF0000F0DF.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS5PPFD22966BE3 FEP is now the only reason for the #UD handler to run. Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/hvm.c | 43 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index c8cae41705d..4c00cf4c4fe 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3837,35 +3837,34 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) struct vcpu *cur = current; bool should_emulate = false; struct hvm_emulate_ctxt ctxt; + const struct segment_register *cs; + uint32_t walk; + unsigned long addr; + char sig[5]; /* ud2; .ascii "xen" */ hvm_emulate_init_once(&ctxt, NULL, regs); - if ( opt_hvm_fep ) + cs = &ctxt.seg_reg[x86_seg_cs]; + walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) + ? PFEC_user_mode : 0) | PFEC_insn_fetch; + + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, + sizeof(sig), hvm_access_insn_fetch, + cs, &addr) && + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), + walk, NULL) == HVMTRANS_okay) && + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) { - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) - ? PFEC_user_mode : 0) | PFEC_insn_fetch; - unsigned long addr; - char sig[5]; /* ud2; .ascii "xen" */ - - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, - sizeof(sig), hvm_access_insn_fetch, - cs, &addr) && - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), - walk, NULL) == HVMTRANS_okay) && - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) - { - regs->rip += sizeof(sig); - regs->eflags &= ~X86_EFLAGS_RF; + regs->rip += sizeof(sig); + regs->eflags &= ~X86_EFLAGS_RF; - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ - if ( !(hvm_long_mode_active(cur) && cs->l) ) - regs->rip = (uint32_t)regs->rip; + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ + if ( !(hvm_long_mode_active(cur) && cs->l) ) + regs->rip = (uint32_t)regs->rip; - add_taint(TAINT_HVM_FEP); + add_taint(TAINT_HVM_FEP); - should_emulate = true; - } + should_emulate = true; } if ( !should_emulate ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:30:42 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:30:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252135.1548902 (Exim 4.92) (envelope-from ) id 1w0eFP-0002cS-Eh; Thu, 12 Mar 2026 11:30:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252135.1548902; Thu, 12 Mar 2026 11:30:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eFP-0002cL-CC; Thu, 12 Mar 2026 11:30:35 +0000 Received: by outflank-mailman (input) for mailman id 1252135; Thu, 12 Mar 2026 11:30:34 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eFO-0002cD-5r for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:30:34 +0000 Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [2a00:1450:4864:20::32a]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dfa9e506-1e06-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:30:29 +0100 (CET) Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4852f73d0a3so8308275e9.3 for ; Thu, 12 Mar 2026 04:30: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-439fe21b631sm9340256f8f.27.2026.03.12.04.30.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:30:28 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: dfa9e506-1e06-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773315029; x=1773919829; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=O36rUnkadiIg6aqkuKyYmmGiuGQxdTDhnVE3HZFlPL4=; b=WZtybFTLwa3ZR68ewSEFDM0F3PyuFAIupPsDxtasPO//TTMi/IfBlwUEX3HYzEP6Fu 4KImWaXACGxcRCC7AK8XNbDRRS9+v+DOpdqeUvVKJfnHAlx3fJczn5JHVBxMUJpFFZy3 HxOx+eRXw7OKtaEuF3Me3wHbrcujJmeAmG60FjkpV3ttagnsQTdLSi0mJTLw/II1Qfk4 gUvFgkNGEKM08HQm4REDu+Pz6GiBBw6wpRA6hfBuk4TuT/AckbFQRKhILGX0JARH2v2n ir8cp8TzO1I21O0228I4Z7f31SHyjjajm3IfhjIQmDTBggPc9vcx2SWJcQZOuR7VbUyo 6zLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315029; x=1773919829; h=content-transfer-encoding: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; bh=O36rUnkadiIg6aqkuKyYmmGiuGQxdTDhnVE3HZFlPL4=; b=NDYz8yvXhEcs1iOOF32s+8ULfNLl+kpimbLwddkwfFKw5ehAx0eJHC3qdmGdSmya6s N8TIqm2himlR5tM90OReTMPgTzrv7IZlVEO/3tNLqOg87FCPrXSSAwXzjhpG73WDqsJd CgBlkQ/HfDBOHB3lyZEo5ywBqyjSiH9SHA0GqE6IY3iVvbSB0dKBXcBg8ysk/NEsz35P /wykaQhMVWggeMmeVIPHA2SykCAKNI2BmfkerRt9k/T6usRbNU2+Y2KqNZBBsWfvcQ0r COc974zqq7apfkhhlSOMtB+R8ExCwbr70nNtBnlxqvlzU/uEEgjl6PMagutYlRo6lOH/ lBxA== X-Forwarded-Encrypted: i=1; AJvYcCVqZhDUzcKjasZ3iLdENhJ3ZF3EH7HD1jNGYSGjk+V0lLqDhCGtM6W6nWq3BbYiYvqqx/pnKMvSLnA=@lists.xenproject.org X-Gm-Message-State: AOJu0Yyn8t4MUtBruFgJBVB6MGd5l6t+41npNp73vOqbWVyk5k6rCCNi Z0jAvelSBfWWSoIDkAKcbKbpXpZTPiPQhpsdtjlH8QQSC847VjHMbzULAY2i5YneSg== X-Gm-Gg: ATEYQzwsNT9Q2x76CPAWw9whYTlQOIZuAHX90mzqxmYWB1bwxWPpeEsbpqzHMiXytX/ Uuq96ax/JQuSWAr6vtvcwe6aXIhU0L9FAPERNlbxTLve/q52jNGPu4XAJi3/30Jk1XPoS4EASyb NNdv1lsODvObG7qmYeQaexvnt/uFxNutdblnGmKMMDNZWq2iVx1c606gNbSUvq4P3ZxguAlDRhm NAF0UZa6vY9x3px/4SN0YUgWJ4W5jQiHq4/nrclshwNL8JYYVMjRb84Y6KCv11nVRKYspFSEpc2 w99AHnB8P0VoEErDgZa1f/PnnSdEvUGKIwn0xYpaCqdGhvUjO6xCRi5CT/aKFKuC+jW6errmx2w /giBvrIrB8TC2qJl8JAdhem7UqatB1eciD29tK/rD6HcDgpV1HorBK7wnjBnelS7/ucWWTEL8dE X2KIQzHLwistUMyeXHo/v0wEL7oMwrdExELU1nphJ7fyKX6MhaVFOPFdJIewHkq7Mleg6em2V8c ScFVyix4xPQ0t8= X-Received: by 2002:a05:600c:8b02:b0:485:3f72:323f with SMTP id 5b1f17b1804b1-4854b0c74e0mr103504155e9.11.1773315029131; Thu, 12 Mar 2026 04:30:29 -0700 (PDT) Message-ID: <4197491b-a7dd-4402-bc44-eb26368e390e@suse.com> Date: Thu, 12 Mar 2026 12:30:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/7] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM ops To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-5-julian.vetter@vates.tech> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260309123055.880050-5-julian.vetter@vates.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 09.03.2026 13:31, Julian Vetter wrote: > Add two DM ops for MSI passthrough IRQs. These new DM ops take the raw > MSI address and data fields rather than a 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. > > Signed-off-by: Julian Vetter Since there's no cover letter to reply to, this one will need to do. What I'm missing in the series is leveraging of the (limited) cleanup potential. You're obsoleting the PT_IRQ_TYPE_MSI sub-case of XEN_DOMCTL_{,un}bind_pt_irq. Respective libxc functions could now call the libdevicemodel ones, rather than invoking those domctl-s. The domctl-s could then reject attempts to use that sub-case. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:34:25 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:34:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252146.1548911 (Exim 4.92) (envelope-from ) id 1w0eJ6-000396-Tp; Thu, 12 Mar 2026 11:34:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252146.1548911; Thu, 12 Mar 2026 11:34:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eJ6-00038z-QV; Thu, 12 Mar 2026 11:34:24 +0000 Received: by outflank-mailman (input) for mailman id 1252146; Thu, 12 Mar 2026 11:34:23 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eJ5-00038o-Bw for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:34:23 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 6a7acea6-1e07-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:34:22 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-485345e1013so15224365e9.1 for ; Thu, 12 Mar 2026 04:34: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-4854b65fd3dsm126827285e9.10.2026.03.12.04.34.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:34:21 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 6a7acea6-1e07-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773315262; x=1773920062; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=SpPVNA9rnXMIJLYHdmj70bxry6tv0vKNhaFDLieBNkk=; b=D7fp2ummzJfrJT4/6uGKctjCERb9lC7jP2jjCEc1Fhfo7fqU7FwcLikzkmk8AmCKQp xal0/KDVF7GTa9BfSjzm6WTJ2Wjgnvxaht9E3qsZm8U/Q8fUhR/KWqDjg3dpg1m3AF6n axMVWFztCmtqGCsO9ScUEmcFShC2KxEyEL6OH79Heh6SGuGJ4LJ03BuqUm985b8VDhWK N8hTrAUezoaw/y87xszHIXj0y8O8n3P365OG6SPWEMYtJTOXRODQBNZSnsibpr4T2hSH 1/JtpmcBWSwnccntH1CcYo62KYLQ2Gne0ztWkC8w0J0tI6SCSpybqfm599Ib6YSgKbAc SzdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315262; x=1773920062; h=content-transfer-encoding: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; bh=SpPVNA9rnXMIJLYHdmj70bxry6tv0vKNhaFDLieBNkk=; b=QX724tK2Hjj7qdsaj5QULN16I1jpECXIqhhR5nvbjluHkCM4EVIpcnnZyqk+uj1n45 dS/d1abaMBxef1T5OjTfV46QbNGJW8EUCLsQ/SxUrLzrvgY95S93hHRWh3l78caIAPC/ 2/A8gxYK003/0MjKFRFRhunG7juOcV0SCmHZkbH+F8F+OnqrVnGAGKH5Tb+IwLW33OHu 5IkbZalTSMw55xsUp1On6myWOeOsdvGSXgLQaSVazbQTGNB8kmky/qKMTB+i+IXTvj3S CcAzjnA4LOt9vp0yflWtTMRDAyBejIeM5eJ0Gj1snwvH15JYS/DZc61p3FCq5QNAfYIK Y4JA== X-Forwarded-Encrypted: i=1; AJvYcCWStN6X3+8Hr4qLh8CzlLqS9VMsdeW2bYGwDZCqj9MJ/GkfYJasn1NcjPuMKEAIPbDWvv8/a4zEGpU=@lists.xenproject.org X-Gm-Message-State: AOJu0Yy9jWdffvpI5zNAppveT/54EFT8DNram5tSg4ZFEJci929gkyCc uDROl4U2BGCrrMKcqosWS3umZqYhjGK+oGJbtjVorhWB9t0fWedpRh5LRvuVlmKPJw== X-Gm-Gg: ATEYQzzEWH9Wev9FZvmE70hateyjmOScYLS/8IBc32jVhiG6H9DyR9zoS8OeyW1BDEG GypTCUcMpfgf0XyPAXUh6rQ6bVhAk21mBkQHg6nOs/B733Qo0XsC9JsCXy6Bs+XfMjowly0esrK xQjZHcCzyJV7Hk7gjIg29ZvYcwByyALoRDy1YteSQyZ5GxpKMqEHbJ7NxXpI4um9hhQSswyh3av bD7fjQVH5M58EF6SID6l/VkWEwM7y7HCplmT/lWXNzhS2MPhPIqqiH2GsHDzSFdt0AtXhfIR9M9 rgvwf0CL4h9f3wyqH2AhM2C/zoWQTQYYBhIplfbNb9a2hgdfsBX6mn3lDyasqiIByTs9ZikfagZ SaQiETZwVsta/M7slqllh/0q8z8ZN83rYmJmsQPw+k2HtzakkfKqZArhN02KUq/zOK7IFDhoHaX 5X6y3nNkNQzeWSVX/bWYAvpDBuJC0ZeG6THHhft++Z1OMX8koXKNuCBC1uRy0Dx+7Lv0fBHGf1f ZpK8G6UMO7Z+gw= X-Received: by 2002:a05:600c:c48f:b0:479:13e9:3d64 with SMTP id 5b1f17b1804b1-4854f59f1cdmr46459475e9.15.1773315262043; Thu, 12 Mar 2026 04:34:22 -0700 (PDT) Message-ID: <6f464bd1-7ba9-4804-8eb8-af8f079ac936@suse.com> Date: Thu, 12 Mar 2026 12:34:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 2/5] x86/hvm: Disable cross-vendor handling in #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> <20260312112116.22563-3-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260312112116.22563-3-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2026 12:21, Alejandro Vallejo wrote: > Remove cross-vendor support now that VMs can no longer have a different > vendor than the host. > > No functional change intended. > > Signed-off-by: Alejandro Vallejo Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:35:41 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:35:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252154.1548921 (Exim 4.92) (envelope-from ) id 1w0eKJ-0003eh-5c; Thu, 12 Mar 2026 11:35:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252154.1548921; Thu, 12 Mar 2026 11:35:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eKJ-0003ea-2e; Thu, 12 Mar 2026 11:35:39 +0000 Received: by outflank-mailman (input) for mailman id 1252154; Thu, 12 Mar 2026 11:35:37 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eKG-0003eO-Vq for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:35:36 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 95ade7c5-1e07-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:35:35 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-439b97a8a8cso946961f8f.1 for ; Thu, 12 Mar 2026 04:35: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-439fe1b22e7sm8145182f8f.16.2026.03.12.04.35.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:35:34 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 95ade7c5-1e07-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773315334; x=1773920134; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=yfVZWoOf5y1hseaIR/V1s9D943lTLQym8jqc7vHY4HA=; b=KR4lic9YvhOcW3VgE4zkf2HuBoD+ebbd10w45Vg3pG0v+B4PkJEWJ+fwqtEzcMAy9g bxjNCFk7ho1Q51yEQvWc7KR7nCnaMi3aIfNTajqB/qsBMygOYfrQOCImei6nC9mTBdQq IPUFc8CAnRCdr/yviESHHBkq/1H+Ppdpid4xoYtF5Gfjf3HAgGLNN/VGq1fWMBtvJuj4 r4HkXd7d+otpz7TaUlaEuIXSQWpvVofXPjzWO5r2BS6BL+TeXxiVIV5u5LfR6khReN3+ dYfGrK4w1iPAfdQs0SdlODGkmPyHm/aU3nNTIvFJnFSw7vdsormNTwvUa8Z0jO24Fcga axPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315334; x=1773920134; h=content-transfer-encoding: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; bh=yfVZWoOf5y1hseaIR/V1s9D943lTLQym8jqc7vHY4HA=; b=Bn0X/POGlvfzfcER9DeOFccdpIl5A1+wUT8OONvndTAGLtPeV1+4+hg04rsltAzZnz SzIy1vcnTEqJRMKyDcbbQJVOQQPC4PQRZsyD38JLNisNXrxiOUxxus9G/QB1JvWrYPFf tLbm7OwLwDY2nspCw0X3nIh+nSC3GkqC8WP1l6t2+9VXX8v/EFQ09dwfgfjocDVmyCPk bHv4/FAsbJvfs8+e1QlGWVgd+gNnRoNkttVsSW89JjrXxfE07twi2KSDN8os0h5kKFa7 6MXeCqytWPWP3On7IZw87ZOHDB8sWlee9x0qECHJh8uSTr/6BCDSoAX63vyM7n8UsHiA LhZg== X-Forwarded-Encrypted: i=1; AJvYcCWVaIvqvPc+aB7DrDZw0ESW5vaB5kPOU0iTBNP5Pw9cw0jM3kyDCBY1HY/myBRH+LrHl5YUMYRAZQo=@lists.xenproject.org X-Gm-Message-State: AOJu0YzOpHq9WLSMbSXDe+eXBNfgnV0UNm/tIyHJoVluDL1Ay31mgt5E sZToj549r52AYATG8XkfyVr7uhx5YR4q9e5oTGWjhk8MYvzNVp/LjjamMA4GrV/oTA== X-Gm-Gg: ATEYQzwdzHEdOhOLn64KpZIyrM59OFARXtiod7Qrl97xHFe+AfxJg/MnTECf1ldPf8O +acNll1OQsocPy+lNBKHlbk9nzJSMQLnagBuXSN8hfm0Em6dfx74ZbVhLUdsde+s4L9/9XWxZ37 gyTwi390C74IuIhF926Z4wE/QvUMIHBMorRTCM4IMAQZlpmiTdoh4jR8ZVrJwwOsOQEHG0FyqJO qnNjA9na3I7XQ8Zj8NrvUoJPvezYr0uYxCxoI+EMtgBww+BxEdOgvb7vfATCnwPXGT3iwZ4DrN1 n2g7qDVssl1KQDd3TS+3aAF8Hf6f3FOqbRjhd2tv2Ouc4tf1fLi2W7epuJpTgp7tgZjlTVVaHSG S4s8+CkzRtGDawRfcqADvNFJql2rGDHYOD6HlXUwuzQqCv0OqMIooYGrM3pCf7/QhC4Hz9LMSux NmeQUMC2zVBZ93JMr7oCLacIHBrDyp5PONuDkL+wyCIJmvl7RuTXfXPtY3aueOZBkVUCSJW8vJ0 8Wj4srSmxIVe1E= X-Received: by 2002:a05:6000:4028:b0:439:b7c9:2ef0 with SMTP id ffacd0b85a97d-439f822a7c3mr10343137f8f.33.1773315334536; Thu, 12 Mar 2026 04:35:34 -0700 (PDT) Message-ID: <18fbb44c-92b8-4298-9931-6db1c252b043@suse.com> Date: Thu, 12 Mar 2026 12:35:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/5] x86: Drop cross-vendor support To: Alejandro Vallejo Cc: Oleksii Kurochko , Community Manager , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Jason Andryuk , xen-devel@lists.xenproject.org References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2026 12:21, Alejandro Vallejo wrote: > Patches 2, 4 and 5 missing acks. What's missing for patch 4? Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:42:12 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:42:12 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252166.1548929 (Exim 4.92) (envelope-from ) id 1w0eQX-0005hL-U8; Thu, 12 Mar 2026 11:42:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252166.1548929; Thu, 12 Mar 2026 11: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 ) id 1w0eQX-0005hE-RB; Thu, 12 Mar 2026 11:42:05 +0000 Received: by outflank-mailman (input) for mailman id 1252166; Thu, 12 Mar 2026 11:42:04 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eQW-0005h8-Lt for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:42:04 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 7c08d6a5-1e08-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:42:02 +0100 (CET) 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 62C7e1Ri509757 for ; Thu, 12 Mar 2026 11:42:01 GMT Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cus9w0m7a-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 12 Mar 2026 11:42:00 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2aea7747aeeso10846265ad.2 for ; Thu, 12 Mar 2026 04:42:00 -0700 (PDT) Received: from [192.168.1.10] ([38.254.186.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae22217dsm53886225ad.4.2026.03.12.04.41.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:41:58 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 7c08d6a5-1e08-11f1-b164-2bf370ae4941 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= O6HJTG517rx7BZNC+Lqbxk38jHNOTKDXfitY+fGl2Qg=; b=cTWDR23rSNC6RXYv NYm5xAfJP6JIuBegbdJxesqHYjbPVMpbyoaplrYspybiURpA1Trs2IBBicGX/68c /5p+bLJWsmwM5nkoINvohPNjkwnCV2Td1WLJKuiQev/oeNlwdMwm/GB45fgFyHxJ HBiAKD73NnOBoytDQFweyjSwkRPfJWCUyj7pEosaMeJDL4V+7DNFEgrEfn/EASZJ 6+Gx97SZIgZENJcFW2XKZ7T0QIf+zW3nzwfP8DgMViWz3ZckUTqhX36WvwMOPypt LWOJsODEoFAaVja57lITwPwa+tEi6nJkKgY1F91wyXAO/nJARSgaUFBOp4o2h3W9 cdmcuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773315720; x=1773920520; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=O6HJTG517rx7BZNC+Lqbxk38jHNOTKDXfitY+fGl2Qg=; b=P/TrTao7DCJRJDLvwFdYigRJfd0K3vZYzq5FiCjw8tCZs0DgNCddzf51aJwCnLeSJe bPSRZmLtw3Ntg97mamZwTkg7iueNvI1/5LV6l2QHvVmcTsLCY1nXsKKtRGU5mhZ7pkLm RZhjI/i4GMYmciJboh8e8Uh0emt6RqnrPl9mXShViAm0gWQO3Yb14sxxNWjy/zS6UUEw TxpBAA8XB2NvLlb2iRwKtv5NsqvXVe8NVQ4VhxZNxe5PgQUoeCOjicJsaCJHrFM6Ze7q D9lbfv5W5NiFWgkudoXaGXcIblaL3aQgYC2dMdJBVuMxnbT6OE/9R0U4oNVStOMfMWBq MLuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315720; x=1773920520; h=content-transfer-encoding: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; bh=O6HJTG517rx7BZNC+Lqbxk38jHNOTKDXfitY+fGl2Qg=; b=MBARlIaF+NDsA0tPeHCh9Jt0gGmxEHtfeZGOyoRF0IbuxsH6tZ+FO+e0CPd620l2VH a6R2Qcz6cyqfSkySGVWEoGCTwzS7bXYpZAqvKT+RxGS1I2oxbSkeCp5q0DiOBji3IqyC 3J0OMJpCBavuN9WO0bTAgR/ZD+AV+hkDNI8Q1z2qB1TY/ByiUlg/49UvM5s9O7xP79y1 Ph7WMcCQVXiynatxrvxAMGRbsAgV3zAfUj/q3/sRV8YXnjueK//4vW2PLVw5fo0iSnL2 C8xSpQFYyD2gtaT/ZbNMUj92pPiwXWQWjohN1Si6Pk5uTZdew6VuEi2wh/SYcQWntdK4 J6hg== X-Forwarded-Encrypted: i=1; AJvYcCU5C2eoehPtztnGgGjmJjlJiAePxnr13+kKlXtoDMijtDIDHbQdrddW3oDZ2XIy5gzawg52xLA0cJw=@lists.xenproject.org X-Gm-Message-State: AOJu0YynlZETX8Q18oxGPOOVZXBGEnEzTocjvIc71L1M57eBS/Ksz/70 I0dA9U5A/NVYf6l70/yEreHn1NkJc8g7zNK8JLnfAllbE4NJVe2ZS3hGUUp4gV0mpW4V1z469um Wp1pWaVNUS8rUWF9nFOONeEd2V5eDM+NyropHlVAX+5bSbCTuiKsrY5LfERHykUKNk9lTxQ== X-Gm-Gg: ATEYQzy5/jHpT4NQKokwv7c7LBehJ32wF5KOAIb4WwB4RcCHNCYk2MNmnWt2v+qzh80 EaROVNP0Ywmh8rrubbuTl1HE4NoOL8UoQV3dCNit4bCqPwiUKt6L4RkvzqMoCuuGa6YPWH4J1sD dhYafz8kR9nP4RyVhkefs1rVPk85pwXQI2XNdyem0miF9he2LSs+EpRC0kjXVEUb1WnU9CEfFsN CgBgyDNRehEGNcOvAlNF5vDhOQsc+pqkSqKCnhfsRmL5Eog7+3RePLjOFqpJBAwEQ8Frbd9fA8F lzWtyFprfSP8WpgavyCbJzxLqlGMayBkbJl73KLFzc4FRAs1CnyAlElAI/ZSimgue+lSPR70lFb nKqxOHHbjTqrIjb5hRX8Lt1JUXdjzf+8V289pbLL1JzRNjY9sUw2/Cqk8PQ== X-Received: by 2002:a17:902:e807:b0:2ae:478f:2ec with SMTP id d9443c01a7336-2aeae89119emr62683655ad.29.1773315719588; Thu, 12 Mar 2026 04:41:59 -0700 (PDT) X-Received: by 2002:a17:902:e807:b0:2ae:478f:2ec with SMTP id d9443c01a7336-2aeae89119emr62683115ad.29.1773315719067; Thu, 12 Mar 2026 04:41:59 -0700 (PDT) Message-ID: <57537059-4989-4704-ae6a-72576d031216@oss.qualcomm.com> Date: Thu, 12 Mar 2026 17:10:25 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 1/3] of: Add convenience wrappers for of_map_id() To: Dmitry Baryshkov Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> <20260309-parse_iommu_cells-v10-1-c62fcaa5a1d8@oss.qualcomm.com> <3plcdobbd6teiluzijzk33yepbpsur24tnmjr32sco7a4loptm@xmzmsaurvmvj> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: <3plcdobbd6teiluzijzk33yepbpsur24tnmjr32sco7a4loptm@xmzmsaurvmvj> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: dmzzP9AJWWl2KSzxbHtoUQGOWLSQDdY2 X-Authority-Analysis: v=2.4 cv=IIIPywvG c=1 sm=1 tr=0 ts=69b2a688 cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=FuYIH7Xx0xzBSkYrynBYgw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=7CQSdrXTAAAA:8 a=VwQbUJbxAAAA:8 a=8AirrxEcAAAA:8 a=EUspDBNiAAAA:8 a=6wy38kV5EeFARYyu09AA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 a=a-qgeE7W1pNrGK8U0ZQC:22 a=ST-jHhOKWsTCqRlWije3:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEyMDA5MiBTYWx0ZWRfXzQrPjahLaj9b caQyE7C+n4u2opSdCAjEsA4hi/z2dbSeQ/Vp0aL8RAE+3Z1GXK6JuPXTPNbjSUvqX7qQxC3LcVM D6SghshldR0xm/Swhyq9vCEjeNSJMrEqo9FbkB7UdKG7TlJO7Im4+gMwS7FhiCI8IAArIBzhoLo JXwWjd19+Fr/2ioodLhN1qh8buI8ZYvHzM4v0KtZlBpaC9qQW6pTJwzHkLFhLoRfhH/ZGoqEPEI iMz23prFfghScJimKWJpO6bVtTIz/SwVv6TvvhaudYlaTMdNRMCdwbfYJB7Kf9MGJsSj9LVdFXk SGeWoeqJb85BFn9uOQyAxSHvVFOONlE1eyGrQUoQNz7OwQZ3mulWyjtCkSESDdZCOe8e81OERhN sMJH/xemkoSdKVufb4YTO4P1FnqSu7ukscVruzIZ++R/iG+oOaiyXuhKYnvd14Gd92jXGngJZAR 1ZlWg+lSGIgGX6ZG/Xg== X-Proofpoint-ORIG-GUID: dmzzP9AJWWl2KSzxbHtoUQGOWLSQDdY2 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-12_01,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 bulkscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 impostorscore=0 spamscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603120092 On 3/10/2026 2:46 AM, Dmitry Baryshkov wrote: > On Mon, Mar 09, 2026 at 01:03:37AM +0530, Vijayanand Jitta wrote: >> From: Robin Murphy >> >> Since we now have quite a few users parsing "iommu-map" and "msi-map" >> properties, give them some wrappers to conveniently encapsulate the >> appropriate sets of property names. This will also make it easier to >> then change of_map_id() to correctly account for specifier cells. >> >> Reviewed-by: Rob Herring (Arm) >> Reviewed-by: Frank Li >> Signed-off-by: Robin Murphy >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/cdx/cdx_msi.c | 3 +-- >> drivers/iommu/of_iommu.c | 4 +--- >> drivers/irqchip/irq-gic-its-msi-parent.c | 2 +- >> drivers/of/base.c | 36 ++++++++++++++++++++++++++++++++ >> drivers/of/irq.c | 3 +-- >> drivers/pci/controller/dwc/pci-imx6.c | 6 ++---- >> drivers/pci/controller/pcie-apple.c | 3 +-- >> drivers/xen/grant-dma-ops.c | 3 +-- >> include/linux/of.h | 18 ++++++++++++++++ >> 9 files changed, 62 insertions(+), 16 deletions(-) >> >> + >> +/** >> + * of_map_msi_id - Translate an ID using "msi-map" bindings. > > Which ID are we talking about wrt. MSI interrupts? > id refers to the device’s requester ID (RID/BDF or platform stream ID), not an MSI interrupt number; it is the key used in msi-map to obtain the translated MSI device ID (id_out). I'll update the kernel doc as below to clarify. * @id: Requester ID of the device (e.g. PCI RID/BDF or a platform * stream/device ID) used as the lookup key in the msi-map table. Thanks, Vijay >> + * @np: root complex device node. >> + * @id: device ID to map. >> + * @target: optional pointer to a target device node. >> + * @id_out: optional pointer to receive the translated ID. >> + * >> + * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask". >> + * >> + * Return: 0 on success or a standard error code on failure. >> + */ >> +int of_map_msi_id(const struct device_node *np, u32 id, >> + struct device_node **target, u32 *id_out) >> +{ >> + return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out); >> +} >> +EXPORT_SYMBOL_GPL(of_map_msi_id); > From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:42:15 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:42:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252167.1548938 (Exim 4.92) (envelope-from ) id 1w0eQh-0005wW-3t; Thu, 12 Mar 2026 11:42:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252167.1548938; Thu, 12 Mar 2026 11: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 ) id 1w0eQh-0005wP-1F; Thu, 12 Mar 2026 11:42:15 +0000 Received: by outflank-mailman (input) for mailman id 1252167; Thu, 12 Mar 2026 11:42:14 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eQg-0005h8-8X for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:42:14 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 8232573f-1e08-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:42:13 +0100 (CET) Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62C9Yd9C4025894 for ; Thu, 12 Mar 2026 11:42:11 GMT Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cuh50swqs-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 12 Mar 2026 11:42:11 +0000 (GMT) Received: by mail-pl1-f198.google.com with SMTP id d9443c01a7336-2adc527eaf5so7701925ad.0 for ; Thu, 12 Mar 2026 04:42:11 -0700 (PDT) Received: from [192.168.1.10] ([38.254.186.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae22217dsm53886225ad.4.2026.03.12.04.41.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:42:09 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 8232573f-1e08-11f1-b164-2bf370ae4941 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= LE+t+QqJAI+/mgc7W1OIUYrBRVzqbLNj9RJHGrZKK9Q=; b=P5phZrdji2XNB1A7 dTTi/RsItP2yc1RU394FYJtIegEYWxTNyrkQb0nAwMYAKmSD8GZ0IhcKP0iEn39T gPpRZjfwGbi1uO32Yfl3TFFBlGMioBr9HyrKxTKT8kBqhEkU2yEOd8CFcf6t9eyv CqE9kdZD7mCqzR8uNPVT4RBKJOpmu73ReHRA/EkhWeGpxE2vkNMzto6iDdQJgujY LOGl+LoKIbBfmjlUgTd3w3s3q1mw3x1d3hdxAvi6MWs7VO5s+YYappVus92gUf+M U2peZk8AIN/AUUgB+VjEDiVd6wpnW54pw9QdSIRCsBJQQnWWpQcwYQoQm+ZwhEgs wMOK5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773315730; x=1773920530; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=LE+t+QqJAI+/mgc7W1OIUYrBRVzqbLNj9RJHGrZKK9Q=; b=DL+61k1o1sp056Z6Uc7h7v+SRET/lztzVyc9lMKIKL+YFh4kLmONU070IZACvYeOhL As8sZza9hw9CZFG4TCItIie2L0pBMWnMkurYs7eKql8K3DhSzvm00FpJLUD5i1X+8K58 po6kc7NHBzBo4XHtKET25GVzP2FcK5B/iQMZHzBWY5sKk5T5g6fOY0bxqjseVvfCebOh qOkYVcmQGSvjHwLN14enPABVXLD3mZc6VNMxulxJ1OFsZ8Ntc87UZbhJnyIc9CEasAYx 2pCCizUvO8gLMya1HdbNRa+WM0gZOys/TL7rU0OE3d7OKhXKDVxkOYsWH2uPhlE8+uKJ f32g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315730; x=1773920530; h=content-transfer-encoding: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; bh=LE+t+QqJAI+/mgc7W1OIUYrBRVzqbLNj9RJHGrZKK9Q=; b=qANVhPdGZOxdlFX+b2iBFPZ476xpmK44yYsQsfhhK4tipuoOOXl/v8+GbqfBCveues a1KUGCIXXQ4ivPaseBoDe2UQ59b6D1FwdWnC7qCT87+0B8WNXGWmwIjhpKjACZj9o7PH lYHjoMEIK5s9QUPhGqKzJsvmPj7KuTUwR0TQE1kVRyZ2x0EUcv1g+EWVBU8GpGMci+au ZrKb8rWW43bgmWqwEFaC1aj3FroG6gcMwLXX+4g9N1iQB6PZL7BBd9JO4ZGCJ60kaU9V YJOl1PeC6PY0fI/jnY090IXEstNiqC03Di7PCmIFKTY10SY/zahI+b0vw5pf1Y4vyc6U jOog== X-Forwarded-Encrypted: i=1; AJvYcCWIyeItdiNbXaLfdbvwLOLHKJmMwf0f+I/PIu3uDoqNJeRITWnDCLOexiDZ32OB0HoVNM1pObzpm8w=@lists.xenproject.org X-Gm-Message-State: AOJu0YyLdfNUb6aPyAkgwY9od6zVPLcpaBnZfMAMi/36WzjzxvF5MBlJ 986g9cIYIUjXolIA/FutdS1DpOtN8ckAsUq8coKecI9qucNCcx/NbfGX5nOZxA3pDWzMGnZ23yC 2lk4OYMeBy29Fq40+UgLsRxWiI+swAU7q2dYDqxUPT8mLbwZnt+O6tSlO8Ue+cjLM5vLq8g== X-Gm-Gg: ATEYQzyxOZNO8ysCYHSjXxUDg47Poe7Y5n4TgPwQNW5S9P/cwLxlr07EHG/lsou4s3x fOCb9tbfas4uk/OyS7axQJoBRq6KywH7A7mKQr3KC80evOtSjlTohUIXwBtvnm0SuAd8xUaTa6q EDN/ALNE4OVEJ+SyU9Qsjrm5wBEkvDk1yZtckDr5rF8Af0LrPqq+EIbBmvwpisFdICAweXNe7DT A+XJasYti2lbUc/5A3EMaNlXJ8ZjbAGkCfBkPgSJIIDoPccEMuInGJSYEz9KpB44gyDMrtrNPjd SuYV4iH4POW72YLSK29qe5JlU2A/GS4wtGWT5bIyp0gzKU+kYxi3FMIaIt6xCuXP9o9h29RTGpM SjhfWAViHb9/PF6kwshQ+mCUO/SbnS6HvdYPu24JXLRMs05/8U8z1dyv9ag== X-Received: by 2002:a17:902:d4ce:b0:2ae:47af:3b29 with SMTP id d9443c01a7336-2aeae92124bmr54674275ad.57.1773315730446; Thu, 12 Mar 2026 04:42:10 -0700 (PDT) X-Received: by 2002:a17:902:d4ce:b0:2ae:47af:3b29 with SMTP id d9443c01a7336-2aeae92124bmr54673835ad.57.1773315729939; Thu, 12 Mar 2026 04:42:09 -0700 (PDT) Message-ID: Date: Thu, 12 Mar 2026 17:11:56 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 0/3] of: parsing of multi #{iommu,msi}-cells in maps To: Bjorn Helgaas Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260309210506.GA589665@bhelgaas> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: <20260309210506.GA589665@bhelgaas> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: Sh7rxbXagaDByQQEAdQ1b1ahHIewXRnF X-Authority-Analysis: v=2.4 cv=LvKfC3dc c=1 sm=1 tr=0 ts=69b2a693 cx=c_pps a=MTSHoo12Qbhz2p7MsH1ifg==:117 a=FuYIH7Xx0xzBSkYrynBYgw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=Iq-Xo7JqGUrbNy38CdcA:9 a=QEXdDO2ut3YA:10 a=GvdueXVYPmCkWapjIL-Q:22 X-Proofpoint-ORIG-GUID: Sh7rxbXagaDByQQEAdQ1b1ahHIewXRnF X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEyMDA5MiBTYWx0ZWRfX5nfzaf1IoEfJ aQ/hXsO0ozsYGz0N6PpCowcQWtr8yBmioZtUqnhSYjtx9uzXGu0vZ8F07+MKJD9YfWpsiNtYTtm 93eFuD9lssw35aGbFT67NvnA+HZOK1eTlCCtkQj18phdC5BZvu+g2P3l8wcmHcUYNXW8DVNyn2u kNx2Uo1FwIRbp1CQ+UeMjz/EdadxaQN/fJU1qstPo6BT5MHQT+MeH8MtQIqe1ewr/ZPpcEOCwFm dnLQ0sA4ZS3YxhRin74XJJ4i1Cw1xOUhz3+F3uI4ksieFGAJA/0b/s0S1aTXNSBoShs5Nz/vZXd XcFFkvKzVmMNfDWCHS42hC/qFkEi27Ynqye1HoB3cum9c3zS3PJ/GXY7tQ2lZsKFYyTF6uHXLA0 yAuoQo6SUZG+gitM559ne4GJ3nkE4v9J9qbeM8YrFnpn/b1mJ9yuAoAhRzVCBiGSTaF7/lFuwmX 5HvNeuMaoXeraCblD5g== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-12_01,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603120092 On 3/10/2026 2:35 AM, Bjorn Helgaas wrote: > On Mon, Mar 09, 2026 at 01:03:36AM +0530, Vijayanand Jitta wrote: >> ... > >> Charan Teja Kalla (1): >> of: factor arguments passed to of_map_id() into a struct > > Please make this subject line match the capitalization of those below, > i.e., "of: Factor arguments ..." > Sure, I'll update it. Thanks, Vijay >> Robin Murphy (2): >> of: Add convenience wrappers for of_map_id() >> of: Respect #{iommu,msi}-cells in maps From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:43:00 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:43:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252182.1548949 (Exim 4.92) (envelope-from ) id 1w0eRQ-0006cX-Ea; Thu, 12 Mar 2026 11:43:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252182.1548949; Thu, 12 Mar 2026 11:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eRQ-0006cQ-AD; Thu, 12 Mar 2026 11:43:00 +0000 Received: by outflank-mailman (input) for mailman id 1252182; Thu, 12 Mar 2026 11:42:59 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eRP-0005h8-7u for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:42:59 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9de79760-1e08-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:42:58 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-48532925a4bso4745705e9.1 for ; Thu, 12 Mar 2026 04:42: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-4854a2eeae0sm46799375e9.4.2026.03.12.04.42.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:42:57 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9de79760-1e08-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773315778; x=1773920578; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=FsUFTaV0z01pgH4y2xJG1WKE7bJTwVlb52gmTepqVGs=; b=bjClDklIkBX0AHjYIU6YefG7mwVZR2jcUSJWIJmADxLwE5w2f/ULQCotFk4H7dfckG IR0InUl4D264KOqxP4IDueazmvpsDgPXnv3qVCitbd+Y1v9yZbQncdTg58+iEaSCrtdS itrjCCUv9lUZnprrPxln//Mv9PVhBf3xcirfakfOJCsbaFun1IH6b2McB4ENGaQtno5E XFtDsC2IsSeNVjmT+AgNw/3gfOMKAks4EceeMWo/85Cm350zT499FraBhlk070rgnxlk s5xJyUO3a18a4CdECTYzWzkYNurpGjzarvzB3NoRkUz15Cmq9CmKU/UwCu31GzhyARZG dfRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315778; x=1773920578; h=content-transfer-encoding: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; bh=FsUFTaV0z01pgH4y2xJG1WKE7bJTwVlb52gmTepqVGs=; b=rSS7vtF3bPBbPE8u06edpyZblMjaKcmS49RDD1mImIhFsPQmxZWKF6jDgSpDJ4qdKA jO5PcxF2bzXrwncq6mDpHrB6Hn+AP6QPdfjxfGLOusec7CUNipcv97GbJwThJlHovYmU Wq788670COcCqD2B96lzXpQhMmn6pNh4nEDlMsfa0HOFYfoPHbINGXBbzmyQoyUAv5Pt D0iuPal/POE658t0aoBm04lRBDangi9fSar/qN6Yg3l3LTsusBl22qvslf/jjjt80OVA /u8gapFXFF8vSTWedswSF3kjq0j1U8q0ctpMaf31weGgwQ2m1pBG1TQX74J1lcfAAhTJ ccKw== X-Forwarded-Encrypted: i=1; AJvYcCVZS9Kkq1HcnRm2BAghuRDULycETrkNcjy4irtelGQfF+eJmdJuxrFs+6pyucPKqAgRMu+p7M+qAWU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwiwT1Rppmx9OjD8fLDLMtjTg4nW5cPncHMjv+gjMhPiLjlhD8X kRkUoFEUacT+xSXqVYvcvyWW/JvGN4vqR5azf+U9AbRoad66TGY6iczCBh4QDRJe/g== X-Gm-Gg: ATEYQzyqwXEUx7OGLfpJMzNppoqv3tE0hTsvJYIP355L0BBhX6VVTALQL/IszIBrJL0 skKqRzdRlNqkVlE/lYZW8w9uPvt7qzWVVDmVpMhNaAhiUs/C1xruslTMjQ8KYGxRDBjEdBQOvgt lXpqnP/EOuKS6QmRUxFdSN5j/XZfJFHcGal4VIm9w16GAhNu/WVnQHpVdLlE341JUooUl9gA2TW EGl/rwAt7VJxR26MdbblXwyfAEa/OJKsNs39l2VMq5mRr2yiuuqb9d6JVRqdOJ4NpgkuzvnXBGR uP/TCIilLhuSHcXk0zXsrNEb0lMye0twL68FnZKje/xk3sr3BB4ldzBRcyxM1anhQAEi4AkbLIO 9mQ/CZJQfFKOqxiCd+2/E8tz6XHTA7qEhSRTVSNf6j+QcPLGlRuf87n6rIjwviZO6Odg6YoCTRm DDFmfHYLwv1v/iiazgeJeGkZMJ/96qSOya68RABKg1VBPNeCBmPT1BF/a+P8N1Tte5IgHFsNuOQ 5iC1muutwAsr7k= X-Received: by 2002:a05:600c:1d16:b0:485:35ee:f836 with SMTP id 5b1f17b1804b1-4854b0a6d74mr103111565e9.2.1773315777865; Thu, 12 Mar 2026 04:42:57 -0700 (PDT) Message-ID: <12ed74c0-1ea2-4458-881e-ccb7e59e0088@suse.com> Date: Thu, 12 Mar 2026 12:42:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 5/5] x86/hvm: Un-indent the HVM_FEP block in the #UD handler To: Alejandro Vallejo Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , xen-devel@lists.xenproject.org References: <20260312112116.22563-1-alejandro.garciavallejo@amd.com> <20260312112116.22563-6-alejandro.garciavallejo@amd.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20260312112116.22563-6-alejandro.garciavallejo@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12.03.2026 12:21, Alejandro Vallejo wrote: > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3837,35 +3837,34 @@ void hvm_ud_intercept(struct cpu_user_regs *regs) > struct vcpu *cur = current; > bool should_emulate = false; > struct hvm_emulate_ctxt ctxt; > + const struct segment_register *cs; > + uint32_t walk; > + unsigned long addr; > + char sig[5]; /* ud2; .ascii "xen" */ > > hvm_emulate_init_once(&ctxt, NULL, regs); > > - if ( opt_hvm_fep ) > + cs = &ctxt.seg_reg[x86_seg_cs]; > + walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > + ? PFEC_user_mode : 0) | PFEC_insn_fetch; While of course functionally everything's fine this way, I'm now entirely lost: Why are what were ... > + if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > + sizeof(sig), hvm_access_insn_fetch, > + cs, &addr) && > + (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > + walk, NULL) == HVMTRANS_okay) && > + (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > { > - const struct segment_register *cs = &ctxt.seg_reg[x86_seg_cs]; > - uint32_t walk = ((ctxt.seg_reg[x86_seg_ss].dpl == 3) > - ? PFEC_user_mode : 0) | PFEC_insn_fetch; ... initializers before not initializers anymore, when all you're doing is (supposedly) re-indentation (and, necessarily, moving decls up to the top of the scope they need to live in)? > - unsigned long addr; > - char sig[5]; /* ud2; .ascii "xen" */ > - > - if ( hvm_virtual_to_linear_addr(x86_seg_cs, cs, regs->rip, > - sizeof(sig), hvm_access_insn_fetch, > - cs, &addr) && > - (hvm_copy_from_guest_linear(sig, addr, sizeof(sig), > - walk, NULL) == HVMTRANS_okay) && > - (memcmp(sig, "\xf\xb" "xen", sizeof(sig)) == 0) ) > - { > - regs->rip += sizeof(sig); > - regs->eflags &= ~X86_EFLAGS_RF; > + regs->rip += sizeof(sig); > + regs->eflags &= ~X86_EFLAGS_RF; > > - /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > - if ( !(hvm_long_mode_active(cur) && cs->l) ) > - regs->rip = (uint32_t)regs->rip; > + /* Zero the upper 32 bits of %rip if not in 64bit mode. */ > + if ( !(hvm_long_mode_active(cur) && cs->l) ) > + regs->rip = (uint32_t)regs->rip; > > - add_taint(TAINT_HVM_FEP); > + add_taint(TAINT_HVM_FEP); > > - should_emulate = true; > - } > + should_emulate = true; > } > > if ( !should_emulate ) With this, the purpose of the should_emulate variable effectively vanishes, without it actually being purged (unlike you had it earlier). Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:43:01 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:43:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252183.1548957 (Exim 4.92) (envelope-from ) id 1w0eRR-0006qV-OQ; Thu, 12 Mar 2026 11:43:01 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252183.1548957; Thu, 12 Mar 2026 11: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 ) id 1w0eRR-0006qK-LS; Thu, 12 Mar 2026 11:43:01 +0000 Received: by outflank-mailman (input) for mailman id 1252183; Thu, 12 Mar 2026 11:43:00 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eRQ-0005h8-81 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:43:00 +0000 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9d706301-1e08-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 12:42:58 +0100 (CET) Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62C9EfQ64025739 for ; Thu, 12 Mar 2026 11:42:57 GMT Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cuh50sws4-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 12 Mar 2026 11:42:56 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2aec784479cso5175845ad.3 for ; Thu, 12 Mar 2026 04:42:56 -0700 (PDT) Received: from [192.168.1.10] ([38.254.186.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae25cd67sm56194955ad.38.2026.03.12.04.42.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:42:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9d706301-1e08-11f1-b164-2bf370ae4941 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= W9ejYWHNwRhjPiGAgnplcOS8lPIHbm/6D31/N+auTSw=; b=HmaP0o5E8kDigSFa alJVniCiNF7DjBpO3slqiNJ3tC/PYMDuDwHYrqAZ6m3faf3xBUSqMLfpUEiT0ME7 uWWAeSVIZ60cNAHJhwuo6Vb8dOptnxFIZD2ZPlI6SJHGh0bEalGe5AilAQjBoaDU QZVlr/4PFlZA2kIerIpl0o8Gs05Rqi4LvYe2xoN8EAgrInA5+6ymKHj2jVoDFZlX twDN9GpYJxK9TErk0jdzr2qqWM7kBKQCbwArOlfCHOrYnIloY9u/so8cENTOFlPK 42iYYDiTfRSrfY3aZO54lNm32900MmfmU17DmtlRZIiqhD4bfqXTlQnqegCK9Mod 59ZCww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773315776; x=1773920576; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=W9ejYWHNwRhjPiGAgnplcOS8lPIHbm/6D31/N+auTSw=; b=iSHbZYUbXYH/msHyTMZDMSJ5dYZF62LDRNRJ6QX9yS60Pd1dmBZtOgA0O2VOt1IhAc kQ32+BpW1cncsWj+SIqbdHaWrJE3tcP1IcjCkiRRM/IOXwGyM4dAfzlmjS4BthN6H5MI hqAVk/AuVn2z3fnMEDuXW3h5yYqiT+tQ1e0yPE/F4I9QEii/jLI09CiQ0AKVvi/rpT9W mky5unpUqEgmDhBAhSC3U6mHyBOuQ6EVMuMYyjFkag3UhSLAqYK+ry2kxLcWE9JtoIEx DXpuQL9pDy3+yLwVLMkcTRAKlJ+3LLCTRmKVyBY5Kli3mhrZOBlPFJZxKAYEhe5sNWsg NhHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315776; x=1773920576; h=content-transfer-encoding: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; bh=W9ejYWHNwRhjPiGAgnplcOS8lPIHbm/6D31/N+auTSw=; b=nUV98jLJPX/5o0WYDUjbW2k/ElUb5NGPsGMlI0UT0n1aHNxs/9Y+JEyxs1AnShV2PW GXsW/zz2qJAzfTVG1Jq3iLK0faMxpkwBimo0Fx/00NiA7oavfVXpw5aHKLnuIULDT+kz Ziywyei5egdrbmq+A/EU6zKyaC2dG2E1oG0fpTqufqgEL79Udrn+T18Y4D6VNFIh4izG LLSzChnuNqly4d+Wg+Q5DNtMKx3JpvfE0l5BXrgc7iqYlmu2xMDzenOT8ExNAeBz0BMf 7QbQKs7rS8ua69Pi2L+1keyUv9NJ1vlF/6QQ3gmPhlCrusdGvzueu8Lue6j0Dyl7FLJE dxVw== X-Forwarded-Encrypted: i=1; AJvYcCX8gLK9jXe47lgnU75Y0fOn6W++RLdtdafg/N/u9FlSSLuZSNSKlq2/5tjcTpb4men+oulM+MnEEng=@lists.xenproject.org X-Gm-Message-State: AOJu0Yw4ZPKmSMsQefT9NhFTBrNOF6JXmko1Ci1ApFmeHGg2BpL0LAaR 5C9LHLPBYEn0txQCHdXTsb0vWqs+KUmCpk34FDy1hyrrrGpHz8hx1l57HJj8CKzq4WTvENek/K8 jroZm6+JDF2inXSJwUUUjm0b/iw/UCuxKROf0Fjfs0WV4GAjZdQQpDpPqaHkQlOEGt8oU8Q== X-Gm-Gg: ATEYQzxlhZzy4gsn1mhlZ6obx7XbGsH7QmRNAMf3yruB3Kj9j+5CBnCeMaQQPx00+1M FGqISmrww+y0brs/UaB0Rc3hHBGc1j4H/2LdW29yNW8ppezBJX5somiQjxbueAafcLF9kVHyB5x 1bg0H5NkRK5BSsRTCITqoa83lzyR+UebazobH6FWB9g7O5/o5RutSm2/vqGUxJGEV6wdxSU/JkJ ooiU/BCpORqO6n3zzyR7ZpVrROO9rbyIHe4b9OIjOl/s2Q+iPWmYugNzn20rRAQMQBy747TdXag yZ0JxunL+0losdYGHz5J+YW3T54jvPpbTaRwsbz78n6mXJLzP/DvI7d7CqDZH6UsZl45Fc8Tzgv JhYrC+34aR6S0bmDNQxpbsRtAf2ZLsp3V6GCaMzoj5aDNhjxjfuxP9+QCKg== X-Received: by 2002:a17:902:db06:b0:2ae:3fb2:ec9a with SMTP id d9443c01a7336-2aeae7ad446mr64958905ad.16.1773315776355; Thu, 12 Mar 2026 04:42:56 -0700 (PDT) X-Received: by 2002:a17:902:db06:b0:2ae:3fb2:ec9a with SMTP id d9443c01a7336-2aeae7ad446mr64958285ad.16.1773315775895; Thu, 12 Mar 2026 04:42:55 -0700 (PDT) Message-ID: <04eabe08-f339-4d9c-8b61-184241d192a4@oss.qualcomm.com> Date: Thu, 12 Mar 2026 17:12:43 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 3/3] of: Respect #{iommu,msi}-cells in maps To: Bjorn Helgaas Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260309210849.GA591344@bhelgaas> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: <20260309210849.GA591344@bhelgaas> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: -jTU0FV6wIePD5MNaxJL77M5TIEtPsZC X-Authority-Analysis: v=2.4 cv=LvKfC3dc c=1 sm=1 tr=0 ts=69b2a6c1 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=FuYIH7Xx0xzBSkYrynBYgw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=7CQSdrXTAAAA:8 a=2oAOsZZM3GA0Nya8fkwA:9 a=QEXdDO2ut3YA:10 a=d1F_yjlUjjEA:10 a=uG9DUKGECoFWVXl0Dc02:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-ORIG-GUID: -jTU0FV6wIePD5MNaxJL77M5TIEtPsZC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEyMDA5MiBTYWx0ZWRfX/5lnslTB10gF jr9cUxVVFPhev1rgechAxxUkDQFwwlfffG3J+vEmhVZuu1Uws3tlKDZYTchRJ4r7/bf5xnvPHn8 l5BjPinxVIyFuxH++8Oq5MeN0/Ff7YzhlLiCGF+fslq31rBza1Twl/fUpl3xte8C2Vk55z4o30f bvd2OW1PfDIGwvpafLzsK6JgLWwiykqb1i1lTt/YBF63shAPYQGS78flEZ8RzSxVtJprNNnmpa1 IFot+2Q2yyUKxxJL+SajUIkoF0LezDKQz8/SfBwMOkA+1DGVAfwSKwJvFTVB3wG3MW9XraVl1ID EUb5lixAMsbtLTLmc+ZFUCszmYVmCVE5yuhdtQNKWXYYaV+Uh3r2FuDnoDUZ56EtGewf50jGo25 e1vE8SBggQ8bq1Axe9tto/3zyrNO2bSi5pvVXS9IN7M1nWRwDcW3Pk+BfBWl9gbkHs66+HduwYJ rk72HbZ2q/I/k2eBhFg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-12_01,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603120092 On 3/10/2026 2:38 AM, Bjorn Helgaas wrote: > On Mon, Mar 09, 2026 at 01:03:39AM +0530, Vijayanand Jitta wrote: >> From: Robin Murphy >> >> So far our parsing of {iommu,msi}-map properites has always blindly > > s/properites/properties/ sure , will update. Thanks, Vijay From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:43:17 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:43:17 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252188.1548966 (Exim 4.92) (envelope-from ) id 1w0eRf-0007Gp-22; Thu, 12 Mar 2026 11:43:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252188.1548966; Thu, 12 Mar 2026 11: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 ) id 1w0eRe-0007Gi-Ty; Thu, 12 Mar 2026 11:43:14 +0000 Received: by outflank-mailman (input) for mailman id 1252188; Thu, 12 Mar 2026 11:43:14 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0eRe-0005w8-0b for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:43:14 +0000 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a4775f66-1e08-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:43:10 +0100 (CET) Received: from pps.filterd (m0279872.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62CA6NhZ263417 for ; Thu, 12 Mar 2026 11:43:09 GMT Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cuh4yhwx4-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 12 Mar 2026 11:43:08 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2aec6c572fbso9994535ad.1 for ; Thu, 12 Mar 2026 04:43:08 -0700 (PDT) Received: from [192.168.1.10] ([38.254.186.229]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2aeae25cd67sm56194955ad.38.2026.03.12.04.42.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:43:06 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a4775f66-1e08-11f1-9ccf-f158ae23cfc8 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= pVihyfEVv9KoFRyaGUgwYSBE5ZXMKxbsi+xWvdEgydE=; b=cuIgsaPDCpjPQizt 0NHBv5jjn/jXISGW57UxIf1k5Xu0iyORYIMcUYWeJlBRrGKhgI9pL4FmIBwf5DVl 3tt9dW7MlCfSbQewK2BKinwVtG7lWXhVA5ZFrESWS8JhlhPNGtLeQxoiYWsgRfhF sPdiL7e/lWx9qs/2aCRoDvzK8fz15IG3gIlIPdt/kFsccxqEy5hNrJWWjZ8GrNnm bNdsjFPw8GqmLOyQxZllHdvttI3qeaEYgEurG3+f/2l7q8Csv+y8bwlOn3soN2cb E2ycM89HWorASgLc2zbrjNBGYojkHubOksbBAUykTaErSiimLefagq23R/1Z3AU5 H63GgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773315788; x=1773920588; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=pVihyfEVv9KoFRyaGUgwYSBE5ZXMKxbsi+xWvdEgydE=; b=dADu37eQmA4XiAAHzEYDn1fdFWZH1QlKlVqVQF3U1okMAzrQOGhL9+8TAQpBkZrMm6 3E/ktiCPOjbIMy7wxXSwOojAut+BCGAekdz0gFb+PHO6v3AnW8CX8oZd18fBO3Hxm2ZV BjCiosWe39if1zfXREv5AzLhhcNCYz6y1nrjm3AKQ2aKWrYB/64+6IOxUr2Yyh7yJDho GSUzVy/LXjun7LaSc1LdSerYpmm6B1FCOu3VJKY85I26i+jwtkMbpb9q3srXJDLkggDP aW73Y7+4agow/B3wrkhkPSClbiEGDQcaYZPDcCbIK0PY7Yd61ga2XEGxeUKjVC2KNGxI 07NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773315788; x=1773920588; h=content-transfer-encoding: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; bh=pVihyfEVv9KoFRyaGUgwYSBE5ZXMKxbsi+xWvdEgydE=; b=qDiqMbxyP2mE47j7FzZ/fX0zEmPQNOjatH0LjadPIZIwA2O8+1Mguu/rW7GOe6/Sd6 i2qubFD4SGIW/H8ORuSPj4k8nM7jT92vbgZDUpmiAUA5u+CKpYWHch0xzHpTBC18Fpix ojBS0aJ6Vml+KsH6JzfONjB2zdIPFL0oAuuBpiNfWviBu5M5VgrG2OdwPkvSioBAs3if nnIu9svO7TMsm9SwAA0T+A/xMhiMZBt7lQy5TAtZOlvZYD9NvmZB37296RXc5qYd6Wla 5NOJFbXj+ty8muyQ7dketYulcyBTr4rDib6JM47iF4NommH3lHwNN8JuQ0LXKCyDd/fP l4lQ== X-Forwarded-Encrypted: i=1; AJvYcCViN0xwGxQMX9w6vh62kYFB02qCwan93szFcXtpjUx0RKfJhGwjLtxFFpIcxZJS2gqeouifoYj/oqU=@lists.xenproject.org X-Gm-Message-State: AOJu0YxL2AC0Pg5tb+CO4oh3B4i7MtXQlpyKGujbUgiZ614uvQfYuZ5H oJvFPe4j4bkUo3J8n4PVBYkB030aLsNfVLjhqz7RjivZKnF3HFQlPhY5H9kY2qI+v0FWmDLKaQu xo8xAAQfs5z2yBugilvULEwkF0JkUJM7Kn7SZrYQiMd2jWuy3g8TBloekOsBs/ttTn86Xyw== X-Gm-Gg: ATEYQzxhKolEwbjsjIi6Qcuayllerl1SYrdY8iX7oqaNgRx5gq4En4sXAhvGzN+YB2U fuk1pPNX+9wLa7PwCjr9en6vLUb5GwdQfNCIIFVC+Yvn7mtFD7sxRDSL4xtE8FLhAhsK+indiyK o+/50lh37CbR9e5hbOk6FLfBleavif2kOmPdzeZQTZtuFCk//SpmeI2+/J4m4tquJYmrEuMY899 KSL1QpSqdZRKe+J2vRpCf/y+CZzSoksdZHTDWxKDwNSAm3mrR/L1KLdYeyAcvdR83rxqcC8qPCf 3enf82dzBNMPywd+l5lRz62HqEE5vQeIp7noKx9f7u5biAXvZf+HQHn9SOUBWMcwHUVRKPzEe+u TVmWsAu2kpUUKpPWI9YrcagupbJyw2nA4jgzcVwZ5Ea4SdmuA5AgBXXCaFg== X-Received: by 2002:a17:902:db11:b0:2ae:59d3:27f8 with SMTP id d9443c01a7336-2aeae7b4ecdmr63852325ad.19.1773315787492; Thu, 12 Mar 2026 04:43:07 -0700 (PDT) X-Received: by 2002:a17:902:db11:b0:2ae:59d3:27f8 with SMTP id d9443c01a7336-2aeae7b4ecdmr63851865ad.19.1773315786884; Thu, 12 Mar 2026 04:43:06 -0700 (PDT) Message-ID: <27edd195-b0d3-4214-9df3-74a84da1e3e1@oss.qualcomm.com> Date: Thu, 12 Mar 2026 17:12:51 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v10 2/3] of: factor arguments passed to of_map_id() into a struct To: Dmitry Baryshkov Cc: Nipun Gupta , Nikhil Agarwal , Joerg Roedel , Will Deacon , Robin Murphy , Marc Zyngier , Lorenzo Pieralisi , Thomas Gleixner , Saravana Kannan , Richard Zhu , Lucas Stach , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Manivannan Sadhasivam , Bjorn Helgaas , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Konrad Dybcio , Bjorn Andersson , Rob Herring , Conor Dooley , Krzysztof Kozlowski , Prakash Gupta , Vikash Garodia , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-pci@vger.kernel.org, imx@lists.linux.dev, xen-devel@lists.xenproject.org, linux-arm-msm@vger.kernel.org, Charan Teja Kalla References: <20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com> <20260309-parse_iommu_cells-v10-2-c62fcaa5a1d8@oss.qualcomm.com> Content-Language: en-US From: Vijayanand Jitta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEyMDA5MiBTYWx0ZWRfX6F2LkwikaEY6 t6/q4LP7KFfKk7nrfPpzSEH3bgmjnZG1XDT35w7ewB2FocHWBQIZaH7PcEOGDJ98hDNslc/rrXU RatPVu47GIqlo74PpDAr66I39D/4m6h46B3lkST+6MTbG196i41p8YRnSDH9LkneUqFbobfXAE1 iZiPfWe6mj8f2mc2Iu3ky3NQYRTmcCsLKFpt0JdUjL6WOhZbSXmfOJQ0a71VNxJTIuBpqUyNtqn 0Twhmj+d+qltlgu3nMVvEvjP7nF4HCGrGrwyLqluHP+Yo3RiN1DTWAKB9Wcn/UleB5pX32K7uJ9 cXbK0F5W/W3trSAAPicV5wOgTL150aDgokfY3dCBI02CQ6MUqccMVCZCt4E9q/NUrvnpvw7wkAa eNwH7XInRyTK5uggGnXxwG73Jt5hwCg/qE06oyE00P2UjyG3Bsez4FgisFixRTI9ypLDfgmOjeJ 8kUqF+z3c4rtEQCnlNA== X-Proofpoint-ORIG-GUID: 91JdKXeDZtGMTAdy0YFNfrEJFjvdLEtz X-Authority-Analysis: v=2.4 cv=C+7kCAP+ c=1 sm=1 tr=0 ts=69b2a6cc cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=FuYIH7Xx0xzBSkYrynBYgw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yx91gb_oNiZeI1HMLzn7:22 a=EUspDBNiAAAA:8 a=VwQbUJbxAAAA:8 a=tICBgMK4MGcbsJ-UzjAA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 X-Proofpoint-GUID: 91JdKXeDZtGMTAdy0YFNfrEJFjvdLEtz X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-12_01,2026-03-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 priorityscore=1501 phishscore=0 adultscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603120092 On 3/10/2026 2:53 AM, Dmitry Baryshkov wrote: > On Mon, Mar 09, 2026 at 01:03:38AM +0530, Vijayanand Jitta wrote: >> From: Charan Teja Kalla >> >> Change of_map_id() to take a pointer to struct of_phandle_args >> instead of passing target device node and translated IDs separately. >> Update all callers accordingly. >> >> Subsequent patch will make use of the args_count field in >> struct of_phandle_args. >> >> Suggested-by: Rob Herring (Arm) >> Signed-off-by: Charan Teja Kalla >> Signed-off-by: Vijayanand Jitta >> --- >> drivers/cdx/cdx_msi.c | 5 ++- >> drivers/iommu/of_iommu.c | 2 +- >> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++-- >> drivers/of/base.c | 63 ++++++++++++++++---------------- >> drivers/of/irq.c | 8 +++- >> drivers/pci/controller/dwc/pci-imx6.c | 16 ++++++-- >> drivers/pci/controller/pcie-apple.c | 5 ++- >> drivers/xen/grant-dma-ops.c | 4 +- >> include/linux/of.h | 12 +++--- >> 9 files changed, 76 insertions(+), 50 deletions(-) >> >> diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c >> index 63b3544ec997..03232b5ffbca 100644 >> --- a/drivers/cdx/cdx_msi.c >> +++ b/drivers/cdx/cdx_msi.c >> @@ -121,6 +121,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, >> struct device *dev, >> int nvec, msi_alloc_info_t *info) >> { >> + struct of_phandle_args msi_spec = { .np = NULL }; > > Why do you need to set it? Parse functions ignore passed args, don't > they? > The parse function does check arg->np on input — if it is non-NULL, it is used to match only entries targeting that specific node. Also, there is this existing path in drivers/pci/msi/irqdomain.c which pre-sets the node and passes it as input to of_msi_xlate(), so the node pointer is not ignored by the parse code: u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev) { struct device_node *of_node; u32 rid = pci_dev_id(pdev); pci_for_each_dma_alias(pdev, get_msi_id_cb, &rid); of_node = irq_domain_get_of_node(domain); rid = of_node ? of_msi_xlate(&pdev->dev, &of_node, rid) : iort_msi_map_id(&pdev->dev, rid); return rid; } >> struct cdx_device *cdx_dev = to_cdx_device(dev); >> struct device *parent = cdx_dev->cdx->dev; >> struct msi_domain_info *msi_info; >> @@ -128,11 +129,13 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain, >> int ret; >> >> /* Retrieve device ID from requestor ID using parent device */ >> - ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id); >> + ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, &msi_spec); >> if (ret) { >> dev_err(dev, "of_map_id failed for MSI: %d\n", ret); >> return ret; >> } >> + of_node_put(msi_spec.np); >> + dev_id = msi_spec.args[0]; >> >> #ifdef GENERIC_MSI_DOMAIN_OPS >> /* Set the device Id to be passed to the GIC-ITS */ >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c >> index a511ecf21fcd..d255d0f58e8c 100644 >> --- a/drivers/iommu/of_iommu.c >> +++ b/drivers/iommu/of_iommu.c >> @@ -48,7 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np, >> struct of_phandle_args iommu_spec = { .args_count = 1 }; > > .args_count = 1 should be set by of_map_iommu_id now (and dropped here). > Sure, will move it. >> int err; >> >> - err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args); >> + err = of_map_iommu_id(master_np, *id, &iommu_spec); >> if (err) >> return err; >> >> diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c >> index b63343a227a9..729fa2f9f758 100644 >> --- a/drivers/irqchip/irq-gic-its-msi-parent.c >> +++ b/drivers/irqchip/irq-gic-its-msi-parent.c >> @@ -152,6 +152,8 @@ static int its_v5_pci_msi_prepare(struct irq_domain *domain, struct device *dev, >> static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u32 *dev_id, >> phys_addr_t *pa) >> { >> + struct device_node *msi_ctrl __free(device_node) = NULL; >> + struct of_phandle_args msi_spec = { .np = NULL }; >> struct of_phandle_iterator it; >> int ret; >> >> @@ -178,9 +180,12 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u >> } >> } >> >> - struct device_node *msi_ctrl __free(device_node) = NULL; >> - >> - return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id); >> + ret = of_map_msi_id(dev->of_node, dev->id, &msi_spec); >> + if (!ret) { >> + msi_ctrl = msi_spec.np; >> + *dev_id = msi_spec.args[0]; >> + } >> + return ret; >> } >> >> static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev, >> diff --git a/drivers/of/base.c b/drivers/of/base.c >> index 959305a84748..b6e07c5fe715 100644 >> --- a/drivers/of/base.c >> +++ b/drivers/of/base.c >> @@ -2102,36 +2102,37 @@ int of_find_last_cache_level(unsigned int cpu) >> * @id: device ID to map. >> * @map_name: property name of the map to use. >> * @map_mask_name: optional property name of the mask to use. >> - * @target: optional pointer to a target device node. >> - * @id_out: optional pointer to receive the translated ID. >> + * @arg: pointer to a &struct of_phandle_args. On input, @arg->np may be >> + * set to a target device node to match, or NULL to match any. On >> + * success, @arg->np will be set to the matched target node (with a >> + * reference held) and @arg->args[0] will contain the translated ID. > > Is this part being actually used (and useful)? > Please refer the above comment. I see there is existing path in drivers/pci/msi/irqdomain.c which sets np. Thanks, Vijay >> * >> * Given a device ID, look up the appropriate implementation-defined >> * platform ID and/or the target device which receives transactions on that >> - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or >> - * @id_out may be NULL if only the other is required. If @target points to >> - * a non-NULL device node pointer, only entries targeting that node will be >> - * matched; if it points to a NULL value, it will receive the device node of >> - * the first matching target phandle, with a reference held. >> + * ID, as per the "iommu-map" and "msi-map" bindings. If @arg->np points to >> + * a non-NULL device node, only entries targeting that node will be matched; >> + * if it is NULL, it will receive the device node of the first matching >> + * target phandle, with a reference held. >> * >> * Return: 0 on success or a standard error code on failure. >> */ >> int of_map_id(const struct device_node *np, u32 id, >> const char *map_name, const char *map_mask_name, >> - struct device_node **target, u32 *id_out) >> + struct of_phandle_args *arg) >> { >> u32 map_mask, masked_id; >> int map_len; >> const __be32 *map = NULL; >> >> - if (!np || !map_name || (!target && !id_out)) >> + if (!np || !map_name || !arg) >> return -EINVAL; >> >> map = of_get_property(np, map_name, &map_len); >> if (!map) { >> - if (target) >> + if (arg->np) >> return -ENODEV; >> /* Otherwise, no map implies no translation */ >> - *id_out = id; >> + arg->args[0] = id; >> return 0; >> } >> >> @@ -2173,18 +2174,15 @@ int of_map_id(const struct device_node *np, u32 id, >> if (!phandle_node) >> return -ENODEV; >> >> - if (target) { >> - if (*target) >> - of_node_put(phandle_node); >> - else >> - *target = phandle_node; >> + if (arg->np) >> + of_node_put(phandle_node); >> + else >> + arg->np = phandle_node; >> >> - if (*target != phandle_node) >> - continue; >> - } >> + if (arg->np != phandle_node) >> + continue; >> >> - if (id_out) >> - *id_out = masked_id - id_base + out_base; >> + arg->args[0] = masked_id - id_base + out_base; >> >> pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n", >> np, map_name, map_mask, id_base, out_base, > From xen-devel-bounces@lists.xenproject.org Thu Mar 12 11:53:22 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 11:53:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252221.1548975 (Exim 4.92) (envelope-from ) id 1w0ebM-0001GM-Ta; Thu, 12 Mar 2026 11:53:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252221.1548975; Thu, 12 Mar 2026 11:53:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0ebM-0001GF-QP; Thu, 12 Mar 2026 11:53:16 +0000 Received: by outflank-mailman (input) for mailman id 1252221; Thu, 12 Mar 2026 11:53:16 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0ebM-0001G9-7F for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 11:53:16 +0000 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [2a00:1450:4864:20::336]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0ca57f07-1e0a-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 12:53:13 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4853510b4f3so11878155e9.0 for ; Thu, 12 Mar 2026 04:53: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-4854b66ffe2sm121016715e9.13.2026.03.12.04.53.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2026 04:53:12 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0ca57f07-1e0a-11f1-9ccf-f158ae23cfc8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1773316393; x=1773921193; darn=lists.xenproject.org; h=content-transfer-encoding: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; bh=m5lp2iKgko+e2S9raenz03hPtnNB0mQ5tKB85rLA/so=; b=GvBh92jht2AaVzs3Fzx4/+5g7ux8jwej4FeH7ZjEeHwTFC/xVyx7c6lIxi6gydQBZh JwTauyujnJ0A9v4wakJcKY0nGOyfp7oY4xN3cmwQg35icRVVZguQv6jsvJD8H/3nwqQZ M5lV6wUsBYyiTviFr8MJtcjRAgk1CnLrZzGU3gML3n309w+fGrkjPUzhYojtLmValuOi X5ykYCVvemhYguVmrs6h8bg7X25AImQHHsD2xTkcmka99U70qMCMkJWknsO8GRoN42Os p/h9RvLk6dPHFsiV6CGD1s77KxhLhHCCgElPBZTQ9Tl7VgbnI4G7ZImUWAkAE1wXZ4Lx o4yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773316393; x=1773921193; h=content-transfer-encoding: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; bh=m5lp2iKgko+e2S9raenz03hPtnNB0mQ5tKB85rLA/so=; b=Wz1CNnX3Yt4rDdCihERM/tAceeigHPCg5hR83o/PPQXQl/W+A+j28jKDtBvVx6EzFb oRs9qO3u5bUsEPnqlnvEASixwJMMT//wm/7HbsPWk7OlOM5r9dukpaqFX/2XbpY4NbjY 90aj2epURySb28vos+p/W+ceNFQCrkJlO+lv6Zdo3+8P5ILSs8P3oNLsMjz31pkRGYXR nWOX0BJNEvUrF4UiKhgX1ws7N4bnTEyTqycc2lfHgVa8Yr+hkRC82ujo+cjvxdk340O+ 0vkNDAZHZtmp0MdeQTgcCr/+inZUpvfoX3be8KERE+G67TgwzJo5SH3sZanyH7QeTk0v CmTA== X-Forwarded-Encrypted: i=1; AJvYcCX4BYMlQ0guy6WzGom8Xksf9XCZmJiHWN9tJ7BiHm8iV37TEPoKsLJnS5+OuVGjhqBpSjSTH4VACRQ=@lists.xenproject.org X-Gm-Message-State: AOJu0YxS+8dTJTiuy7SlhjtD3HSdGQISnGjYPQhLBnWSte7FBdSgdSop xzA44GhMNKCh48cW6Nq7GEteBO6yzo3ViKUk+l4T7hfz7YhznulA004koLhoUP2+WA== X-Gm-Gg: ATEYQzwA4vbk2IPxvuBYbuYAZwyC+RjdE+mbkpSUAzCOpiNCe3FpMWrd2VqI3QPUGBr 98IA0ACM2Au3THkVE7E6x18x/6rx2D7omGJ1I7JmmbaDwCm/jUAk1x/5gAVOtr4fr+gj/s1LUgy NP+Ha1p+qVYZjzS6InHsFstcut/SLZX9AREWAwm47k0uiQ3sPfO4TNn+QL5neYeER6Sh3wCrqHm BB0DtFl/nkH93b6DJYZL4KoP4NhORrYIT7LyAtQrG4yypKXkBVdz6ZFlvew3dgBhBFs4CkBZLA5 ZeQ4P/oPU2WPZWQpiCv0jKx3k6batP58v3w+/QPA1oQ/nmkHvSJwJ1LAbnGV848F+fW1YCMDc2v ZkMzL0wHHWIyoRAEZmpEMX7JFbMBv3CPyMVloARPToLuZbBIMxAVH/2zCskUf32UX/XwiloJ5tu UBEg8mi2Tw3S24y7WMetVjslTQPjzTokTvwrrQ1YQU5FcOtJk95beTkL/rPaEKpwJcZSiCWDLrQ BLrjm2IFKz5c1I= X-Received: by 2002:a05:600c:3544:b0:485:30f7:6e88 with SMTP id 5b1f17b1804b1-4854b12189amr103770855e9.31.1773316393107; Thu, 12 Mar 2026 04:53:13 -0700 (PDT) Message-ID: <8ac5f8a5-456d-45e0-8efa-13cc7050dcb0@suse.com> Date: Thu, 12 Mar 2026 12:53:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 5/7] x86/dmop: Add XEN_DMOP_{bind,unbind}_pt_msi_irq DM ops From: Jan Beulich To: Julian Vetter Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Stefano Stabellini , Juergen Gross , Julien Grall , xen-devel@lists.xenproject.org References: <20260309123055.880050-1-julian.vetter@vates.tech> <20260309123055.880050-5-julian.vetter@vates.tech> <55a65f8d-40df-4841-8e76-200c82f397c5@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: <55a65f8d-40df-4841-8e76-200c82f397c5@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11.03.2026 17:04, Jan Beulich wrote: > On 09.03.2026 13:31, Julian Vetter wrote: >> @@ -607,6 +631,83 @@ 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; >> + struct xen_domctl_bind_pt_irq bind = { >> + .machine_irq = data->machine_irq, >> + .irq_type = PT_IRQ_TYPE_MSI, >> + }; >> + int irq; >> + >> + rc = -EINVAL; >> + if ( data->pad0 || data->pad1 ) >> + break; >> + >> + if ( data->flags & ~XEN_DMOP_MSI_FLAG_UNMASKED ) >> + break; >> + >> + irq = domain_pirq_to_irq(d, bind.machine_irq); >> + >> + rc = -EPERM; >> + if ( irq <= 0 || !irq_access_permitted(current->domain, irq) ) >> + break; >> + >> + bind.u.msi.gvec = data->gvec; >> + bind.u.msi.gflags = >> + msi_addr_to_gflags(data->addr, data->data, >> + !(data->flags & XEN_DMOP_MSI_FLAG_UNMASKED)); >> + bind.u.msi.gtable = data->gtable; >> + >> + rc = -ESRCH; >> + if ( is_iommu_enabled(d) ) >> + { >> + pcidevs_lock(); >> + rc = pt_irq_create_bind(d, &bind); >> + pcidevs_unlock(); > > I understand the same locking is used at the other call site, but it's as > questionable there as it is here. We should try hard to avoid use of this > global lock when something lighter-weight would do. I should perhaps have added that I have this on my own list of things to look into, just that I didn't get to it yet. Jan From xen-devel-bounces@lists.xenproject.org Thu Mar 12 12:22:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 12:22:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252252.1548993 (Exim 4.92) (envelope-from ) id 1w0f3t-0005qU-AL; Thu, 12 Mar 2026 12:22:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252252.1548993; Thu, 12 Mar 2026 12:22:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f3t-0005qN-5m; Thu, 12 Mar 2026 12:22:45 +0000 Received: by outflank-mailman (input) for mailman id 1252252; Thu, 12 Mar 2026 12:22:44 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f3s-0005q1-68 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 12:22:44 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2b702ef6-1e0e-11f1-b164-2bf370ae4941; Thu, 12 Mar 2026 13:22:43 +0100 (CET) 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 53DBC5BCC3; Thu, 12 Mar 2026 12:22:42 +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 257463FF78; Thu, 12 Mar 2026 12:22:42 +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 Q/6SBxKwsmn8bQAAD6G6ig (envelope-from ); Thu, 12 Mar 2026 12:22:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2b702ef6-1e0e-11f1-b164-2bf370ae4941 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1773318162; 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=Pb43MK7Il5S1H1egLvT8+n0qUAoOsACewtHiK/T0SMc=; b=mzmfuF2PUzt8Juq1v0lw/RidnvanOFxSfvoPt8fY4X1LVmFbis3ES6Vz7vrzjf2EHDDaqp KJAgAAYSm7QKAmbz1SedkMYadpUVjzvEjqtFfrk3Cs54fnbyZDMWWsb9r59wCgWvvd8xLh kwP0lcE96qEBaPK99qXBIk7wXFAdYWY= Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1773318162; 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=Pb43MK7Il5S1H1egLvT8+n0qUAoOsACewtHiK/T0SMc=; b=mzmfuF2PUzt8Juq1v0lw/RidnvanOFxSfvoPt8fY4X1LVmFbis3ES6Vz7vrzjf2EHDDaqp KJAgAAYSm7QKAmbz1SedkMYadpUVjzvEjqtFfrk3Cs54fnbyZDMWWsb9r59wCgWvvd8xLh kwP0lcE96qEBaPK99qXBIk7wXFAdYWY= From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH 0/4] docs: add some Xenstore related man pages Date: Thu, 12 Mar 2026 13:22:36 +0100 Message-ID: <20260312122240.2784725-1-jgross@suse.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-2.77 / 50.00]; BAYES_HAM(-2.97)[99.87%]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.com:mid,imap1.dmz-prg2.suse.org:helo]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FUZZY_RATELIMITED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.com:s=susede1]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[] X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: For some of the Xenstore client programs the man pages are missing. Juergen Gross (4): docs: add man page for xenstore-exists docs: add man page for xenstore-list docs: add man page for xenstore-rm docs: add man page for xenstore-watch docs/man/xenstore-exists.1.pod | 17 +++++++++++++++++ docs/man/xenstore-list.1.pod | 24 ++++++++++++++++++++++++ docs/man/xenstore-rm.1.pod | 24 ++++++++++++++++++++++++ docs/man/xenstore-watch.1.pod | 25 +++++++++++++++++++++++++ 4 files changed, 90 insertions(+) create mode 100644 docs/man/xenstore-exists.1.pod create mode 100644 docs/man/xenstore-list.1.pod create mode 100644 docs/man/xenstore-rm.1.pod create mode 100644 docs/man/xenstore-watch.1.pod -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 12:22:56 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 12:22:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252253.1549001 (Exim 4.92) (envelope-from ) id 1w0f40-00064p-Fg; Thu, 12 Mar 2026 12:22:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252253.1549001; Thu, 12 Mar 2026 12:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f40-00064i-C9; Thu, 12 Mar 2026 12:22:52 +0000 Received: by outflank-mailman (input) for mailman id 1252253; Thu, 12 Mar 2026 12:22:50 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f3y-00063r-M6 for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 12:22:50 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2e4da46f-1e0e-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 13:22:48 +0100 (CET) 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 DC3295BCC3; Thu, 12 Mar 2026 12:22:47 +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 B749A3FF79; Thu, 12 Mar 2026 12:22:47 +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 +NYxKxewsmmLbgAAD6G6ig (envelope-from ); Thu, 12 Mar 2026 12:22:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 2e4da46f-1e0e-11f1-9ccf-f158ae23cfc8 Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH 1/4] docs: add man page for xenstore-exists Date: Thu, 12 Mar 2026 13:22:37 +0100 Message-ID: <20260312122240.2784725-2-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260312122240.2784725-1-jgross@suse.com> References: <20260312122240.2784725-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-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Queue-Id: DC3295BCC3 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: -4.00 X-Spam-Level: There is no man page for xenstore-exists, add it. Signed-off-by: Juergen Gross --- docs/man/xenstore-exists.1.pod | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 docs/man/xenstore-exists.1.pod diff --git a/docs/man/xenstore-exists.1.pod b/docs/man/xenstore-exists.1.pod new file mode 100644 index 0000000000..c4d9eeecaf --- /dev/null +++ b/docs/man/xenstore-exists.1.pod @@ -0,0 +1,17 @@ +=head1 NAME + +xenstore-exists - test Xenstore key to exist + +=head1 SYNOPSIS + +B I + +=head1 DESCRIPTION + +Tests whether the specified Xenstore I is readable and sets +the exit value accordingly (B<0> if I is readable, B<1> if not). + +=head1 BUGS + +Send bugs to xen-devel@lists.xenproject.org, see +https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project on how to send bug reports. -- 2.53.0 From xen-devel-bounces@lists.xenproject.org Thu Mar 12 12:22:57 2026 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 12 Mar 2026 12:22:57 +0000 Received: from list by lists.xenproject.org with outflank-mailman.1252255.1549010 (Exim 4.92) (envelope-from ) id 1w0f45-0006L2-My; Thu, 12 Mar 2026 12:22:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1252255.1549010; Thu, 12 Mar 2026 12:22:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f45-0006Kt-KP; Thu, 12 Mar 2026 12:22:57 +0000 Received: by outflank-mailman (input) for mailman id 1252255; Thu, 12 Mar 2026 12:22:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w0f43-00063r-LE for xen-devel@lists.xenproject.org; Thu, 12 Mar 2026 12:22:55 +0000 Received: from smtp-out2.suse.de (smtp-out2.suse.de [2a07:de40:b251:101:10:150:64:2]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 31905f54-1e0e-11f1-9ccf-f158ae23cfc8; Thu, 12 Mar 2026 13:22:53 +0100 (CET) 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 6E7205BCC3; Thu, 12 Mar 2026 12:22:53 +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 48F953FF79; Thu, 12 Mar 2026 12:22:53 +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 apk9EB2wsmmXbgAAD6G6ig (envelope-from ); Thu, 12 Mar 2026 12:22:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 31905f54-1e0e-11f1-9ccf-f158ae23cfc8 Authentication-Results: smtp-out2.suse.de; none From: Juergen Gross To: xen-devel@lists.xenproject.org Cc: Juergen Gross , Anthony PERARD Subject: [PATCH 2/4] docs: add man page for xenstore-list Date: Thu, 12 Mar 2026 13:22:38 +0100 Message-ID: <20260312122240.2784725-3-jgross@suse.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260312122240.2784725-1-jgross@suse.com> References: <20260312122240.2784725-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-Rspamd-Queue-Id: 6E7205BCC3 X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Spam-Score: -4.00 X-Spam-Level: X-Spam-Flag: NO X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org There is no man page for xenstore-list, add it. Signed-off-by: Juergen Gross --- docs/man/xenstore-list.1.pod | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 docs/man/xenstore-list.1.pod diff --git a/docs/man/xenstore-list.1.pod b/docs/man/xenstore-list.1.pod new file mode 100644 index 0000000000..4bc1ff9846 --- /dev/null +++ b/docs/man/xenstore-list.1.pod @@ -0,0 +1,24 @@ +=head1 NAME + +xenstore-list - list Xenstore key children + +=head1 SYNOPSIS + +B [I